Furto e Impersonazione di Token: Token Impersonation/Theft (T1134.001)

La simulazione di token impersonation in laboratorio richiede un ambiente Windows con almeno due sessioni utente attive — una non privilegiata da cui si opera e una con privilegi elevati da cui si ruba il token. L'obiettivo è dimostrare al cliente quanto sia semplice, con accesso amministrativo locale, assumere l'identità di qualsiasi utente connesso.

Il punto di partenza più immediato è Cobalt Strike (a pagamento), che rende l'operazione quasi banale. Il comando steal_token accetta il PID di un processo target e duplica il suo token assegnandolo al Beacon corrente. Per individuare un processo SYSTEM adatto si usa ps nella console Beacon, si identifica un processo come lsass.exe o winlogon.exe, e si lancia:

steal_token <PID>

Da quel momento ogni comando eseguito dal Beacon opera sotto il contesto SYSTEM. Il comando rev2self ripristina il token originale.

Con Meterpreter di Metasploit Framework (open source) l'approccio è analogo. Una volta ottenuta una sessione con privilegi sufficienti, il modulo incognito offre una gestione completa dei token:

load incognito list_tokens -u impersonate_token "DOMINIO\Utente"

Il comando list_tokens -u enumera tutti i token di delegation e impersonation disponibili sul sistema. La distinzione è importante: i token di delegation sono associati a logon interattivi e permettono operazioni di rete, mentre quelli di impersonation sono più limitati.

Per chi preferisce strumenti standalone, Pupy (open source) offre funzionalità analoghe consentendo di elencare SID e selezionare token di processo da impersonare direttamente dalla sua shell. Anche SILENTTRINITY (open source) può cercare un processo di proprietà di un utente specifico e impersonarne il token.

A livello di codice nativo, la catena API è lineare. Si apre un handle al processo target con OpenProcess, si ottiene il suo token con OpenProcessToken, lo si duplica con DuplicateTokenEx specificando SecurityImpersonation come livello, e infine si chiama ImpersonateLoggedOnUser oppure CreateProcessWithTokenW. Un esercizio formativo utile consiste nello scrivere un piccolo eseguibile C che implementa questa catena — permette di capire esattamente cosa vedranno i difensori nei log.

Un aspetto spesso trascurato nei test: il privilegio SeImpersonatePrivilege è necessario per impersonare token. Account di servizio come quelli di IIS o SQL Server lo possiedono di default, il che rende le web shell su questi servizi un vettore privilegiato per questa tecnica. Durante un engagement, vale la pena verificare con whoami /priv quali privilegi sono disponibili nel contesto corrente prima di tentare l'impersonazione.

Il rilevamento di token impersonation richiede un approccio behavior-chain: nessun singolo evento è sufficiente, ma la correlazione di più segnali in una finestra temporale ristretta produce alert ad alta fedeltà.

Le log source fondamentali sono tre: Security Event Log, Sysmon e ETW (Event Tracing for Windows) sul provider Token. Sul fronte Security Log, l'evento 4672 (Special privileges assigned to new logon) segnala quando un token con privilegi elevati viene associato a una sessione, mentre 4624 con Logon Type 9 (NewCredentials) cattura i casi in cui runas /netonly o API equivalenti creano un token con credenziali alternative.

Sysmon fornisce la visibilità più granulare. L'evento EventCode 8 (CreateRemoteThread) rileva quando un thread viene iniettato in un processo remoto — operazione spesso propedeutica all'assegnazione del token rubato. L'evento EventCode 10 (ProcessAccess) con access mask 0x0040 (PROCESS_DUP_HANDLE) cattura i tentativi di duplicare handle da un processo all'altro, comportamento caratteristico della catena OpenProcessToken → DuplicateTokenEx.

La detection comportamentale raccomandata dai dati MITRE si basa sulla correlazione di comandi runas o invocazioni API (DuplicateToken, DuplicateTokenEx, ImpersonateLoggedOnUser, SetThreadToken) con la successiva comparsa di un processo che opera sotto un contesto utente diverso dal padre. La finestra temporale suggerita per la correlazione è di 5 minuti.

Per il tuning dei falsi positivi, quattro filtri sono essenziali:

• AllowedSystemProcesses: whitelist di processi che legittimamente duplicano token, come services.exe, svchost.exe e lsass.exe stesso
• UserContextFilter: esclusione di service account e account amministrativi che eseguono impersonation legittima (es. account di IIS Application Pool)
• ParentProcessAnomalyThreshold: soglia di anomalia nella catena padre-figlio — un processo cmd.exe figlio di w3wp.exe che opera come SYSTEM è sospetto, lo stesso comportamento da services.exe è normale
• TimeWindow: intervallo tra la chiamata API e il processo impersonato

Un indicatore particolarmente efficace è il cambio di contesto utente senza evento di logon corrispondente: se un processo inizia a operare come un utente diverso senza che 4624 registri un logon per quell'utente, è quasi certamente token theft. Le soluzioni PAM come CyberArk o BeyondTrust (a pagamento) possono integrare questa visibilità monitorando l'uso di account privilegiati.

Sul piano preventivo, la mitigazione M1026 indica di limitare tramite GPO i diritti "Create a token object" e "Replace a process level token" al solo account locale e network service, riducendo la superficie d'attacco. Il percorso GPO è: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment.

L'analisi forense di un incidente che coinvolge token impersonation si concentra su artefatti che dimostrano il cambio di contesto di sicurezza e la catena di processi che lo ha generato. Il punto di partenza è sempre il Security Event Log del sistema compromesso.

L'evento 4672 è il marcatore principale: ogni volta che un token con privilegi speciali (SeDebugPrivilege, SeImpersonatePrivilege, SeTcbPrivilege) viene assegnato a un logon, Windows lo registra. Correlare il Subject SID di questi eventi con l'albero dei processi ricostruito da Sysmon permette di identificare quale eseguibile ha acquisito privilegi elevati. L'evento 4624 con Logon Type 9 segnala esplicitamente la creazione di un token con credenziali alternative — condizione tipica dell'uso di CreateProcessWithTokenW.

Per ricostruire la catena di chiamate API serve il log Sysmon. L'EventCode 10 (ProcessAccess) registra quando un processo accede a un altro con permessi specifici. Le access mask da cercare sono 0x0040 (PROCESS_DUP_HANDLE) e 0x0400 (PROCESS_QUERY_INFORMATION), combinazione tipica della sequenza OpenProcess → OpenProcessToken → DuplicateTokenEx. Il campo SourceImage indica il processo che ha eseguito la duplicazione, mentre TargetImage è il processo vittima.

Nella campagna HomeLand Justice (C0038), attori iraniani hanno impiegato tooling custom che utilizzava ImpersonateLoggedOnUser e SetThreadToken per acquisire token durante operazioni preparatorie durate circa 14 mesi prima della fase distruttiva. In un caso forense simile, il punto chiave è correlare la prima evidenza di token theft con le attività di lateral movement successive — spesso il token rubato viene usato per accedere a share di rete o eseguire comandi remoti via WMI.

La memoria volatile è una fonte critica. Con Volatility 3 (open source) il plugin windows.handles elenca gli handle aperti per tipo, e filtrando su tipo Token si possono individuare processi con handle a token di altri utenti. Il plugin windows.privileges mostra i privilegi abilitati per ogni processo, rivelando eventuali anomalie — un processo notepad.exe con SeDebugPrivilege abilitato è un segnale inequivocabile.

Per malware specifici dai dati forniti, Tarrask sfrutta il furto del token di lsass.exe per ottenere i suoi permessi di sicurezza, mentre BADHATCH e Aria-body puntano rispettivamente a lsass.exe/vmtoolsd.exe e ntprint.exe. Durante il triage, verificare se questi processi target mostrano handle aperti da processi inusuali è un passaggio rapido ma efficace. Il tool Process Hacker (open source) o System Informer (open source, successore di Process Hacker) permette l'ispezione in tempo reale degli handle token su un sistema live.

Il panorama degli attori che impiegano token impersonation copre un arco che va dallo spionaggio statale al cybercrime finanziario, con un denominatore comune: la tecnica è quasi sempre un anello intermedio nella catena d'attacco, mai il vettore iniziale.

APT28 (G0007), il gruppo di spionaggio russo attribuito al GRU, ha integrato questa tecnica sfruttando la vulnerabilità CVE-2015-1701, una privilege escalation nel kernel Windows che permetteva di accedere al token SYSTEM e copiarlo nel processo corrente. Questo approccio — combinare un exploit kernel con token theft — è caratteristico di attori con capacità di sviluppo exploit avanzate. APT28 usa il token SYSTEM non come fine ma come mezzo per operazioni successive di credential access e lateral movement all'interno di reti governative e militari.

FIN8 (G0061), gruppo a motivazione finanziaria, adotta un approccio diverso ma altrettanto specifico. Il loro framework custom, implementato in BADHATCH, è progettato per impersonare il token di lsass.exe o vmtoolsd.exe. La scelta di questi due processi non è casuale: lsass.exe opera come SYSTEM ed è sempre presente, mentre vmtoolsd.exe è il processo di VMware Guest Tools, presente su ogni macchina virtuale in ambienti enterprise. FIN8 opera primariamente nei settori retail e hospitality, dove l'infrastruttura virtualizzata è la norma.

La campagna HomeLand Justice (C0038) offre un caso di studio particolarmente istruttivo. Attori statali iraniani hanno condotto operazioni distruttive contro reti governative albanesi tra il 2021 e il 2022, impiegando tooling custom con ImpersonateLoggedOnUser e SetThreadToken. L'elemento rilevante dal punto di vista intelligence è la fase temporale: l'accesso iniziale è avvenuto a maggio 2021, ma le operazioni distruttive — ransomware, wiper e leak — sono state eseguite solo a luglio 2022, con una seconda ondata a settembre 2022 dopo l'attribuzione pubblica. Il token theft è stato utilizzato durante i 14 mesi di permanenza per mantenere accesso privilegiato senza generare nuovi eventi di autenticazione.

L'analisi dei 15 software associati rivela pattern significativi. Il ransomware REvil ruba specificamente il token dell'utente che ha lanciato explorer.exe per operare nel contesto desktop dell'utente anziché di SYSTEM — scelta progettuale mirata a cifrare i file accessibili dall'utente. BitPaymer, altro ransomware, usa token duplicati per creare processi su sistemi infetti. Shamoon, il wiper iraniano, impiega un trittico di API (LogonUser, ImpersonateLoggedOnUser, ImpersonateNamedPipeClient) che suggerisce versatilità operativa adattata al contesto.

Il trend che emerge è chiaro: token impersonation è diventato un capability standard sia nei framework offensivi commerciali (Cobalt Strike, FinFisher) sia nel malware custom sviluppato da attori statali e criminali. Per il threat intelligence, il valore predittivo sta nell'identificare quale token target sceglie un attore — la selezione del processo da impersonare rivela le priorità operative e il livello di conoscenza dell'ambiente vittima.

Framework MITRE ATT&CK v16 — T1134.001 Access Token Manipulation: Token Impersonation/Theft. Tattiche: TA0004, TA0005. Campagna: C0038 (HomeLand Justice). Gruppi: G0007, G0061. Software: S0154, S0182, S0367, S1229, S0603, S1011, S0692, S0570, S0140, S0439, S0456, S0496, S0192, S1081, S0623. Mitigazioni: M1018, M1026. Detection: DET0482/AN1324. Tool di detection: Sysmon, Volatility 3, System Informer. Integrato con conoscenza professionale per tool e procedure operative.