Privilege escalation in Windows via Potato-aanvallen

SeImpersonatePrivilege is een permissie in Windows waarmee een programma of gebruiker de identiteit van een ander proces kan aannemen. Wie over deze permissie beschikt, kan opdrachten uitvoeren namens een andere gebruiker. Bij privilege escalation wordt de permissie vaak misbruikt om toegang te krijgen tot het SYSTEM-account, en daarmee tot volledige controle over het systeem.

Beheert u Windows-infrastructuur, dan is SeImpersonatePrivilege een permissie om in de gaten te houden. Om legitieme redenen wordt de permissie vaak toegekend aan service-accounts. In handen van een aanvaller is het echter een directe route naar SYSTEM-toegang.

In dit artikel bekijken we Potato-aanvallen: een verzameling exploits die SeImpersonatePrivilege misbruiken voor privilege escalation.

Wat is SeImpersonatePrivilege?

Om te begrijpen wat SeImpersonatePrivilege doet, is het nodig om eerst te weten hoe Windows identiteit en rechten beheert.

Hoe Windows identiteit en rechten beheert

Elk proces in Windows (een draaiend programma) heeft een access token. Daarmee controleert Windows of een proces toestemming heeft voor acties zoals het openen van bestanden. Het token bevat onder andere de gebruikersnaam, groepen en privileges.

Een proces bestaat uit threads die de code daadwerkelijk uitvoeren. Elke thread kan een thread token hebben. Standaard erft een thread het token van het proces, maar een thread kan tijdelijk een ander token krijgen. Dat heet impersonatie: de thread doet alsof hij een andere gebruiker is.

Wat doet SeImpersonatePrivilege?

SeImpersonatePrivilege (in Windows: “impersonate a client after authentication”) is een privilege dat bepaalt of een proces de Windows-impersonatie-API’s mag gebruiken. Zonder dit privilege faalt een aanroep naar ImpersonateLoggedOnUser(), ImpersonateNamedPipeClient() of SetThreadToken().

Kort gezegd: wie SeImpersonatePrivilege heeft, mag het access token van een andere gebruiker op zijn thread zetten en tijdelijk als die gebruiker handelen.

Waarom heeft Windows dit nodig?

Services zoals IIS (webserver), SQL Server en de Print Spooler draaien vaak als SYSTEM, het machtigste account op Windows. Wanneer iemand een webpagina opvraagt of een printopdracht stuurt, moet de service weten wie dat deed. Anders kan de service niet bepalen tot welke bestanden of printers die persoon toegang heeft. De oplossing is impersonatie.

Stel: Jan drukt op Print in Word. Word maakt verbinding met de Print Spooler, die als SYSTEM draait. De spooler moet weten dat Jan print, anders weet hij niet naar welke printer hij de taak moet sturen. Zo gaat dat:

1. Word authenticeert zich via een named pipe of RPC.
2. Windows koppelt het access token van Word aan de verbinding. De spooler haalt dit token op via OpenThreadToken() of DuplicateTokenEx().
3. De spooler roept ImpersonateNamedPipeClient() aan (een API die door SeImpersonatePrivilege wordt bewaakt) en zet het token van Jan op zijn eigen thread.
4. De thread van de spooler draait nu in de security context van Jan. De spooler kan bepalen naar welke printer hij de taak moet sturen.
5. Na de taak roept de spooler RevertToSelf() aan en schakelt terug naar SYSTEM.

Voor IIS (bestanden openen namens de gebruiker) en SQL Server werkt dit op dezelfde manier.

Hoe aanvallers dit misbruiken

Nu duidelijk is hoe impersonatie werkt (een service ontvangt een verbinding, haalt het access token van de client op en zet dat met SeImpersonatePrivilege op zijn thread), wordt de aanval logisch. De aanvaller draait de rollen om.

De kern van de aanval

In het legitieme scenario is de client het programma van de gebruiker (bijvoorbeeld Word) en draait de service (bijvoorbeeld de Print Spooler) als SYSTEM. De service impersoneert de client om namens de gebruiker te handelen.

Bij de aanval is de aanvaller de service. De aanvaller draait een programma dat wacht op een verbinding. Het probleem: wie verbindt er met de aanvaller? Normaal niemand, tot de aanvaller een SYSTEM-service ertoe brengt om die verbinding te maken. Zodra een proces dat als SYSTEM draait verbinding maakt met het programma van de aanvaller, krijgt dat programma toegang tot het access token van SYSTEM. Omdat de aanvaller SeImpersonatePrivilege heeft (vaak via een service-account zoals IIS AppPool of MSSQL), mag hij dat token op zijn thread zetten. Vanaf dat moment kan hij een nieuw proces starten met het gedupliceerde SYSTEM-token en heeft hij volledige controle over het systeem.

De vraag is dan: welke SYSTEM-service kan een aanvaller dwingen om verbinding te maken met zijn programma? Daarvoor zijn twee veelgebruikte wegen.

Aanval via de Print Spooler (PrintSpoofer)

De Print Spooler draait als SYSTEM en communiceert via named pipes, een Windows-mechanisme voor interprocescommunicatie. Wanneer een gebruiker print, schrijft de spooler naar een pipe. De aanvaller maakt een nep-pipe aan met een pad waar de spooler naartoe probeert te schrijven. Zodra de spooler verbinding maakt met die pipe, is de spooler de “client” en het programma van de aanvaller de “server”. Het access token dat aan die verbinding hangt, is het token van de Print Spooler, dus SYSTEM. De exploit roept ImpersonateNamedPipeClient() aan (zoals hierboven beschreven), krijgt het SYSTEM-token op zijn thread en start een nieuw proces (bijvoorbeeld cmd.exe) met dat token. Het resultaat is een shell als NT AUTHORITY\SYSTEM.

Aanval via COM (JuicyPotato, GodPotato, SigmaPotato)

COM (Component Object Model) is het mechanisme waarmee Windows-programma’s onderling communiceren. Services roepen COM-objecten aan om taken uit te voeren. De aanvaller registreert een nep-COM-object en manipuleert het systeem zo dat een SYSTEM-service (bijvoorbeeld BITS of de Task Scheduler) verbinding zoekt met dat object. Zodra die verbinding tot stand komt, ontvangt het programma van de aanvaller het access token van de SYSTEM-service. Met SeImpersonatePrivilege kan de aanvaller dat token dupliceren, op zijn thread zetten en een nieuw proces starten dat volledig als SYSTEM draait. De techniek is dezelfde als bij de Print Spooler, alleen het kanaal verschilt: COM in plaats van named pipes.

Welke exploit past bij welke target?

Er zijn meerdere openbare exploits ontwikkeld. Naarmate besturingssystemen veranderen, verschijnen er ook nieuwe exploits. Hieronder een overzicht.

Hoe ziet deze exploitatie er in de praktijk uit?

Windows 7

Voor Windows 7 gebruiken we JuicyPotato. De exploit is gebruiksvriendelijk en werkt direct, zonder configuratiewijzigingen.

We beginnen met het bevestigen of de gebruiker de SeImpersonatePrivilege heeft met:

whoami /priv

Daarna draaien we de exploit om onze rechten te verhogen:

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

Onderstaande video toont de uitvoering.

Windows 8.1

Voor Windows 8.1 gebruiken we PrintSpoofer. Is de Print Spooler-service niet ingeschakeld, dan raden we JuicyPotato aan.

PrintSpoofer

Eerst verifiëren we of onze huidige gebruiker SeImpersonatePrivilege heeft ingeschakeld:

whoami /priv

Vervolgens controleren we snel de status van de spooler-service:

sc query spooler

Draait de spooler-service, dan kunnen we een nieuwe shell maken met:

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

We zien dat we onze privileges met de PrintSpoofer-exploit hebben geëscaleerd naar SYSTEM.

JuicyPotato

Let op: tijdens ons testen leverde de standaard CLSID-waarde van JuicyPotato samen met alle BITS- en TrustedInstaller-CLSIDs een schone shell op als NT AUTHORITY\SYSTEM. Werkt de standaard CLSID van JuicyPotato niet, dan vindt u een uitgebreide lijst van bekende CLSIDs hier: ohpe.it/juicy-potato/CLSID/

Na bevestiging dat onze gebruiker SeImpersonatePrivilege heeft ingeschakeld, gebruiken we JuicyPotato met:

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

De exploit voert succesvol uit en start een nieuwe SYSTEM-shell. In die nieuwe shell bevestigt whoami dat we onze privileges hebben geëscaleerd.

Windows 10, 11 en Server 2022

Op deze systemen gebruiken we SigmaPotato. De exploit werkt direct en vereist alleen SeImpersonatePrivilege en PowerShell of .NET (in-memory).

We beginnen met het bevestigen of de gebruiker de SeImpersonatePrivilege heeft met:

whoami /priv

Daarna voeren we de exploit uit. Met SigmaPotato voegen we onze eigen gebruiker toe aan de Administrators-groep:

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

Onderstaande video toont hoe dat er in de praktijk uitziet.

Hoe beschermt en monitort u tegen deze aanvallen?

Bescherming begint bij het principe van least privilege: geef gebruikers en service-accounts alleen de rechten die ze echt nodig hebben. Audit regelmatig welke accounts SeImpersonatePrivilege, SeBackupPrivilege of SeAssignPrimaryTokenPrivilege hebben. Veel organisaties kennen onbewust verhoogde permissies toe aan accounts die ze niet nodig hebben. Overweeg de Print Spooler uit te schakelen op werkplekken waar niet wordt geprint; dat sluit de PrintSpoofer-aanval uit.

Monitoring is belangrijk, omdat SeImpersonatePrivilege niet overal kan worden uitgeschakeld. Sommige services hebben het legitiem nodig. Microsoft raadt aan Windows Event ID 4672 (“Special privileges assigned to new logon”) te monitoren. Let op events waarbij de Subject\Security ID niet behoort tot bekende service-accounts (zoals LOCAL, SYSTEM, NETWORK SERVICE, LOCAL SERVICE) of vertrouwde administratieve accounts. Ook Event ID 4720 (het aanmaken van nieuwe gebruikersaccounts) is relevant: aanvallers maken vaak accounts aan om persistentie te behouden.

Hoe kunnen wij u helpen?

Wilt u weten of uw werkplekken kwetsbaar zijn voor Potato-aanvallen? Een werkplek pentest is hiervoor het meest geschikt. Onze OSCP-gecertificeerde ethische hackers testen of privilege escalation mogelijk is op uw Windows-werkplekken en geven concreet advies over bescherming en detectie. Neem vrijblijvend contact met ons op om de mogelijkheden te bespreken.