Privilege escalation in Windows via Potato attacks

SeImpersonatePrivilege is a permission in Windows that lets a program or user assume the identity of another process. Anyone who holds this permission can execute commands on behalf of another user. In privilege escalation, the permission is often abused to gain access to the SYSTEM account, and with it full control over the system.

If you manage Windows infrastructure, SeImpersonatePrivilege is a permission to keep an eye on. For legitimate reasons it is often granted to service accounts. In the hands of an attacker, however, it is a direct route to SYSTEM access.

In this article we look at Potato attacks: a collection of exploits that abuse SeImpersonatePrivilege for privilege escalation.

What is SeImpersonatePrivilege?

To understand what SeImpersonatePrivilege does, we first need to know how Windows manages identity and permissions.

How Windows manages identity and permissions

Every process in Windows (a running program) has an access token. Windows uses it to check whether a process is allowed to perform actions such as opening files. The token contains, among other things, the username, groups and privileges.

A process consists of threads that actually run the code. Each thread can have a thread token. By default a thread inherits the token of the process, but a thread can temporarily be given a different token. This is called impersonation: the thread pretends to be another user.

What does SeImpersonatePrivilege do?

SeImpersonatePrivilege (in Windows: “impersonate a client after authentication”) is a privilege that determines whether a process may use the Windows impersonation APIs. Without this privilege, a call to ImpersonateLoggedOnUser(), ImpersonateNamedPipeClient() or SetThreadToken() fails.

In short: whoever has SeImpersonatePrivilege may place another user’s access token on their thread and temporarily act as that user.

Why does Windows need this?

Services such as IIS (web server), SQL Server and the Print Spooler often run as SYSTEM, the most powerful account on Windows. When someone requests a web page or sends a print job, the service needs to know who did that. Otherwise the service cannot determine which files or printers that person has access to. The solution is impersonation.

Suppose Jan clicks Print in Word. Word connects to the Print Spooler, which runs as SYSTEM. The spooler needs to know that Jan is printing, otherwise it does not know which printer to send the job to. This is how it works:

1. Word authenticates through a named pipe or RPC.
2. Windows attaches Word’s access token to the connection. The spooler retrieves this token via OpenThreadToken() or DuplicateTokenEx().
3. The spooler calls ImpersonateNamedPipeClient() (an API guarded by SeImpersonatePrivilege) and places Jan’s token on its own thread.
4. The spooler’s thread now runs in Jan’s security context. The spooler can determine which printer to send the job to.
5. After the job, the spooler calls RevertToSelf() and switches back to SYSTEM.

For IIS (opening files on behalf of the user) and SQL Server this works the same way.

How attackers abuse this

Now that it is clear how impersonation works (a service receives a connection, retrieves the client’s access token and, with SeImpersonatePrivilege, places it on its thread), the attack becomes logical. The attacker reverses the roles.

The core of the attack

In the legitimate scenario the client is the user’s program (for example Word) and the service (for example the Print Spooler) runs as SYSTEM. The service impersonates the client to act on behalf of the user.

In the attack, the attacker is the service. The attacker runs a program that waits for a connection. The problem: who connects to the attacker? Normally no one, until the attacker gets a SYSTEM service to make that connection. As soon as a process running as SYSTEM connects to the attacker’s program, that program gains access to SYSTEM’s access token. Because the attacker has SeImpersonatePrivilege (often through a service account such as IIS AppPool or MSSQL), they may place that token on their thread. From that moment they can start a new process with the duplicated SYSTEM token and have full control over the system.

The question then is: which SYSTEM service can an attacker force to connect to their program? There are two commonly used routes.

Attack via the Print Spooler (PrintSpoofer)

The Print Spooler runs as SYSTEM and communicates through named pipes, a Windows mechanism for inter-process communication. When a user prints, the spooler writes to a pipe. The attacker creates a fake pipe with a path the spooler tries to write to. As soon as the spooler connects to that pipe, the spooler is the “client” and the attacker’s program the “server”. The access token attached to that connection is the Print Spooler’s token, so SYSTEM. The exploit calls ImpersonateNamedPipeClient() (as described above), gets the SYSTEM token on its thread and starts a new process (for example cmd.exe) with that token. The result is a shell as NT AUTHORITY\SYSTEM.

Attack via COM (JuicyPotato, GodPotato, SigmaPotato)

COM (Component Object Model) is the mechanism Windows programs use to communicate with one another. Services call COM objects to perform tasks. The attacker registers a fake COM object and manipulates the system so that a SYSTEM service (for example BITS or the Task Scheduler) tries to connect to that object. As soon as that connection is made, the attacker’s program receives the SYSTEM service’s access token. With SeImpersonatePrivilege the attacker can duplicate that token, place it on their thread and start a new process that runs fully as SYSTEM. The technique is the same as with the Print Spooler, only the channel differs: COM instead of named pipes.

Which exploit fits which target?

Several public exploits have been developed. As operating systems change, new exploits appear too. Below is an overview.

What does this exploitation look like in practice?

Windows 7

For Windows 7 we use JuicyPotato. The exploit is user-friendly and works out of the box, without configuration changes.

We start by confirming whether the user has SeImpersonatePrivilege with:

whoami /priv

Then we run the exploit to elevate our privileges:

./JuicyPotato.exe -l 1337 -p c:\Windows\System32\cmd.exe -t *

The video below shows the execution.

Windows 8.1

For Windows 8.1 we use PrintSpoofer. If the Print Spooler service is not enabled, we recommend JuicyPotato.

PrintSpoofer

First we verify whether our current user has SeImpersonatePrivilege enabled:

whoami /priv

Next we quickly check the status of the spooler service:

sc query spooler

If the spooler service is running, we can spawn a new shell with:

PrintSpoofer64.exe -i -c "cmd.exe"

We can see that we escalated our privileges to SYSTEM with the PrintSpoofer exploit.

JuicyPotato

Note: during our testing, the default CLSID value of JuicyPotato together with all BITS and TrustedInstaller CLSIDs produced a clean shell as NT AUTHORITY\SYSTEM. If JuicyPotato’s default CLSID does not work, you can find an extensive list of known CLSIDs here: ohpe.it/juicy-potato/CLSID/

After confirming that our user has SeImpersonatePrivilege enabled, we use JuicyPotato with:

juicypotato.exe -l 1337 -p c:\windows\system32\cmd.exe -t * -c {8F5DF053-3013-4dd8-B5F4-88214E81C0CF}

The exploit runs successfully and starts a new SYSTEM shell. In that new shell, whoami confirms that we escalated our privileges.

Windows 10, 11 and Server 2022

On these systems we use SigmaPotato. The exploit works out of the box and only requires SeImpersonatePrivilege and PowerShell or .NET (in-memory).

We start by confirming whether the user has SeImpersonatePrivilege with:

whoami /priv

Then we run the exploit. With SigmaPotato we add our own user to the Administrators group:

./SigmaPotato.exe "net localgroup Administrators Hackify /add"

The video below shows what that looks like in practice.

How do you protect against and monitor these attacks?

Protection starts with the principle of least privilege: give users and service accounts only the permissions they really need. Regularly audit which accounts have SeImpersonatePrivilege, SeBackupPrivilege or SeAssignPrimaryTokenPrivilege. Many organisations unknowingly grant elevated permissions to accounts that do not need them. Consider disabling the Print Spooler on workstations where nothing is printed; that rules out the PrintSpoofer attack.

Monitoring is important, because SeImpersonatePrivilege cannot be disabled everywhere. Some services legitimately need it. Microsoft recommends monitoring Windows Event ID 4672 (“Special privileges assigned to new logon”). Watch for events where the Subject\Security ID does not belong to known service accounts (such as LOCAL, SYSTEM, NETWORK SERVICE, LOCAL SERVICE) or trusted administrative accounts. Event ID 4720 (the creation of new user accounts) is also relevant: attackers often create accounts to maintain persistence.