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

L'operatore red team dispone di un ventaglio consolidato di tecniche per riprodurre T1134.001 in ambiente autorizzato. Il prerequisito è quasi sempre un contesto con privilegio SeDebugPrivilege o SYSTEM, ottenibile in laboratorio tramite escalation locale o esecuzione via servizio.

Il percorso classico parte da Cobalt Strike (a pagamento), il cui comando steal_token estrae l'handle del token primario da un processo bersaglio e lo applica al beacon corrente; il comando complementare make_token DOMAIN\user password crea invece una nuova sessione logon di tipo 9. Su alternative open source, Meterpreter (open source) espone incognito con i comandi list_tokens -u e impersonate_token "DOMAIN\User", che sfruttano internamente DuplicateTokenEx seguito da ImpersonateLoggedOnUser.

Per scenari puramente C2-less, SharpToken e TokenPlayer su GitHub (open source) permettono di enumerare processi con OpenProcessToken, duplicare handle e lanciare cmd.exe nel contesto impersonato. Un pattern molto usato è quello di SILENTTRINITY (open source), che tramite modulo Boo cerca processi appartenenti a un utente specifico e ne ruba il token per movimento laterale in memoria senza toccare LSASS.

Un esempio di catena operativa in laboratorio:

• enumerazione dei processi target con tasklist /v per identificare processi eseguiti da account di dominio privilegiati
• da un beacon SYSTEM: ps per elencare PID e owner, quindi steal_token 1234 per assumere l'identità
• verifica del contesto con shell whoami /all e shell klist per confermare TGT ereditati
• esecuzione laterale con jump psexec64 target-host smb-listener che riutilizza le credenziali di rete del token rubato

Per test di CreateProcessWithTokenW, Rubeus (open source) integra la funzionalità createnetonly che avvia un processo con un token logon di tipo 9, utile a proiettare credenziali su servizi remoti senza modificarle localmente. Impacket (open source) non implementa direttamente il furto di token Windows ma è complementare per lo sfruttamento del contesto ottenuto, ad esempio con smbexec.py o wmiexec.py usando hash o ticket derivati.

In laboratorio è utile riprodurre anche il pattern FIN8 e BADHATCH, che impersonano il token di lsass.exe o vmtoolsd.exe: si scelgono processi long-running con SID di alto valore, riducendo il rumore rispetto a un semplice runas. Ogni test dovrebbe essere accompagnato da baseline Sysmon per validare la telemetria difensiva.

La detection di T1134.001 si fonda su correlazione multi-sorgente perché nessun evento singolo è sufficiente. La chain difensiva descritta in DET0482 individua tre momenti osservabili: invocazione di API di token, duplicazione dell'handle, assunzione del contesto da parte di un processo nuovo o esistente.

Le log source primarie sono WinEventLog:Security, WinEventLog:Sysmon e la provider ETW Microsoft-Windows-Kernel-Audit-API-Calls (chiamata comunemente ETW:Token). Da Security interessano soprattutto EventID 4624 con LogonType 9 (NewCredentials, tipico di CreateProcessWithTokenW) e EventID 4672 che segnala assegnazione di privilegi speciali a nuovi logon. Da Sysmon i cardini sono EventID 1 (process create) per catturare la lineage genitore-figlio anomala, EventID 10 (ProcessAccess) con GrantedAccess contenente 0x1000 o 0x1400 verso lsass.exe, e EventID 25 per process tampering.

Un pattern ad alta confidenza descritto nelle tuning di DET0482 è la sequenza: comando runas o invocazione in memoria di DuplicateTokenEx → handle duplication → processo figlio con user context differente dal parent entro una finestra di 5 minuti. La query base in KQL su Microsoft Defender for Endpoint può correlare DeviceProcessEvents dove InitiatingProcessAccountName differisce da AccountName del processo child, escludendo processi di sistema legittimi come services.exe, svchost.exe e lsass.exe quando agiscono su propri figli attesi.

Gli indicatori comportamentali più solidi:

• processi utente (Office, browser, PowerShell) che aprono handle a lsass.exe con permessi di duplicazione token
• creazione di processi con LogonId diverso da quello della shell interattiva dell'utente
• utilizzo massivo di SeImpersonatePrivilege o SeAssignPrimaryTokenPrivilege da parte di processi non-service
• catene cmd.exe → runas o powershell.exe → New-Object System.Diagnostics.Process con credential parameter

Sul fronte hardening, la mitigazione M1026 raccomanda di configurare via GPO Computer Configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment limitando Create a token object al solo Local System e Replace a process level token ai soli Local Service e Network Service. La mitigazione M1018 aggiunge la disciplina degli account amministrativi: least privilege, MFA e restrizione dei logon interattivi.

I falsi positivi più frequenti provengono da agenti di backup, EDR stessi, software di deployment come SCCM e da services.exe nelle fasi di avvio. La whitelist va costruita per hash del binario e non per nome, e la finestra di correlazione temporale (parametro TimeWindow) va tarata osservando la baseline reale del parco macchine.

L'analisi forense di T1134.001 richiede la ricostruzione temporale di tre elementi: il processo che ha invocato le API di token, l'handle duplicato e il processo che ha ereditato il contesto impersonato. Gli artefatti chiave risiedono nei log Windows, nella memoria volatile e nei residui su disco lasciati dai tool utilizzati.

Sul filesystem gli artefatti primari includono l'NTUSER.DAT dell'utente il cui token è stato rubato, dove le chiavi UserAssist possono mostrare esecuzioni incoerenti con la logon session originale; le prefetch (C:\Windows\Prefetch\.pf*) di binari come cmd.exe, powershell.exe o payload custom eseguiti in finestre temporali anomale rispetto ai logon dell'utente. Le ShimCache e Amcache.hve conservano evidenze di eseguibili come SharpToken, Rubeus o loader custom anche dopo la rimozione dai file system.

I log Windows rilevanti da acquisire con wevtutil epl o Kape sono: Security.evtx per EventID 4624/4672/4634, Microsoft-Windows-Sysmon/Operational.evtx per ProcessAccess e Process Create, e quando disponibili i canali Microsoft-Windows-Kernel-General per correlare LogonId sui processi. Il campo TargetLogonId nel 4624 e il LogonId nei Sysmon EventID 1 permettono di collegare deterministicamente un processo alla sessione di logon effettiva, evidenziando quando due processi apparentemente dello stesso utente hanno LogonId differenti — segnale forte di impersonation.

Sulla memoria, l'acquisizione con WinPmem (open source) o FTK Imager (gratuito) abilita analisi con Volatility 3 (open source). I plugin più utili:

• windows.pslist e windows.psscan per elencare processi e confrontare l'owner con la parent lineage
• windows.getsids per estrarre i SID associati a ogni processo e individuare token con SID incoerenti rispetto al binario
• windows.handles --pid con filtro su tipo Token per identificare handle di token duplicati
• windows.malfind per rilevare iniezioni in processi il cui token è stato acquisito

La timeline ideale integra output di Plaso/log2timeline (open source) sui log EVTX con la timeline dei processi da memoria, allineando gli EventID 4624 tipo 9 con successive Process Create di processi non attesi in quella sessione.

Un riferimento operativo è la campagna HomeLand Justice (C0038, maggio 2021 - settembre 2022), in cui attori state-sponsored iraniani hanno mantenuto persistenza per circa 14 mesi nelle reti governative albanesi prima di attacchi ransomware e wiper, utilizzando tooling custom con ImpersonateLoggedOnUser e SetThreadToken. Il pattern osservato mostra impersonation dopo movimento laterale iniziale e prima delle fasi di exfiltration, suggerendo che l'analista debba estendere la timeline forense retrospettivamente su finestre lunghe, non limitarsi al giorno dell'incidente conclamato.

Il panorama degli attori che adottano T1134.001 mostra una convergenza operativa tra APT state-sponsored e criminalità organizzata a movente finanziario, con la tecnica ormai commodity in tutti i framework offensivi moderni.

APT28 (G0007), attribuito al GRU russo, ha impiegato la tecnica in combinazione con CVE-2015-1701 per accedere al token SYSTEM e copiarlo nel processo corrente come step di privilege escalation. È un pattern significativo perché mostra come gli attori tier-1 combinino exploit kernel-mode con token manipulation user-mode per ottenere continuità operativa quando la sola exploitation lascerebbe tracce più visibili.

FIN8 (G0061), gruppo finanziariamente motivato attivo contro retail e hospitality, utilizza un framework malevolo progettato per impersonare token di lsass.exe o vmtoolsd.exe. La scelta di vmtoolsd.exe è tatticamente rilevante: essendo un processo VMware presente in molti ambienti virtualizzati, riduce l'anomalia rispetto al furto di token da LSASS, che è più monitorato dagli EDR. Il tooling BADHATCH (S1081) associato a FIN8 replica esattamente questa capacità, e c'è overlap operativo evidente con la scelta dei processi target.

Sul fronte state-sponsored la campagna HomeLand Justice (C0038, maggio 2021 - settembre 2022) attribuita ad attori iraniani contro l'infrastruttura governativa albanese ha impiegato tooling custom per acquisire token via ImpersonateLoggedOnUser e SetThreadToken. Il contesto geopolitico — targeting del gruppo di opposizione iraniano MEK rifugiato in Albania — mostra come la tecnica supporti operazioni disruptive di lungo periodo (14 mesi di persistenza) prima dell'attivazione di ransomware e wiper.

L'ecosistema malware che integra token theft è vastissimo e trasversale ai motivi: Cobalt Strike (S0154) è il denominatore comune di intrusion penetration testing e attacchi reali; Emotet (S0367) e BitPaymer (S0570) confermano l'adozione nel crimeware di alta gamma; REvil (S0496) dimostra come i ransomware-as-a-service usino l'impersonation per rubare il token dell'utente che ha lanciato explorer.exe, evitando di cifrare il desktop SYSTEM e massimizzando l'impatto visibile sulla vittima.

Altri malware notevoli: Shamoon (S0140, wiper distruttivo attribuito ad attori iraniani), FinFisher (S0182, spyware commerciale), Okrum (S0439, associato a Ke3chang), Aria-body (S0456, usato da Naikon), Stuxnet (S0603), Siloscape (S0623, primo malware noto a targetizzare container Windows), Tarrask (S1011, associato a HAFNIUM), SILENTTRINITY (S0692) e Havoc (S1229), quest'ultimo framework C2 open source in rapida adozione tra attori di ogni livello.

Il trend dominante è la standardizzazione: T1134.001 è oggi funzionalità di base in ogni C2 moderno e nel tooling ransomware, non più discriminante attribuzionale. Il valore intelligence si sposta sulla selezione dei processi bersaglio (lsass.exe vs vmtoolsd.exe vs explorer.exe) e sulle catene di combinazione con altre tecniche.

MITRE ATT&CK: tecnica T1134.001 (Access Token Manipulation: Token Impersonation/Theft), tattiche TA0004 e TA0005. Gruppi G0007 (APT28), G0061 (FIN8). Software S0140, S0154, S0182, S0192, S0367, S0439, S0456, S0496, S0570, S0603, S0623, S0692, S1011, S1081, S1229. Campagna C0038 (HomeLand Justice). Mitigazioni M1018, M1026. Detection DET0482 (AN1324). MITRE D3FEND per mapping difensivo. Il documento integra conoscenza professionale di cybersecurity per comandi, tool e procedure operative, con riferimenti verificati a progetti pubblici e documentazione ufficiale.