Creazione e Impersonificazione Token: Make and Impersonate Token (T1134.003)

Il modo più immediato per replicare questa tecnica in laboratorio è il comando nativo Windows runas con il flag /netonly. Questa modalità crea un token di tipo NewCredentials (LogonType 9): il processo locale mantiene l'identità originale per le risorse locali, ma utilizza le credenziali specificate per ogni accesso di rete. È esattamente il meccanismo che sfruttano gli attaccanti quando vogliono muoversi lateralmente senza generare un logon interattivo sulla macchina sorgente.

runas /netonly /user:DOMINIO\utente cmd.exe

Il comando apre un prompt che, a tutti gli effetti locali, sembra appartenere all'utente corrente, ma ogni connessione SMB, LDAP o Kerberos utilizzerà le credenziali iniettate. Per verificare il contesto effettivo, da quel prompt è sufficiente lanciare:

klist

per osservare i ticket Kerberos associati all'identità impersonata, oppure tentare un accesso a una share di rete riservata all'account target.

In Cobalt Strike (a pagamento), il comando make_token esegue esattamente la stessa operazione — chiama LogonUser con LOGON32_LOGON_NEW_CREDENTIALS e assegna il token risultante al beacon corrente. La sintassi nel beacon interattivo è diretta:

make_token DOMINIO\utente password

Da quel momento ogni azione di rete del beacon opera sotto l'identità specificata. Per tornare al contesto originale si usa rev2self.

Con SILENTTRINITY (open source), il modulo di token manipulation offre funzionalità equivalenti. Il framework, scritto in C# con un'architettura basata su .NET, consente la creazione di token da credenziali note attraverso i suoi moduli post-exploitation.

Per chi preferisce un approccio diretto in C, la catena API è compatta: chiamare LogonUserW con il tipo di logon desiderato, ottenere l'handle al token, e poi invocare SetThreadToken o CreateProcessWithTokenW per eseguire comandi nel nuovo contesto. Un PoC minimale in PowerShell può utilizzare P/Invoke per richiamare queste API senza compilare codice nativo — tecnica frequentemente osservata in esercizi red team.

Lo strumento Incognito (open source), utilizzato storicamente come modulo Meterpreter e disponibile anche nella versione standalone V2, permette enumerazione e impersonificazione di token. Il gruppo FIN13 ha adottato proprio Incognito V2 per manipolazione e impersonificazione di token nei propri attacchi.

Un aspetto da non sottovalutare in laboratorio: la creazione di token richiede il privilegio SeImpersonatePrivilege o un contesto già amministrativo. Se il punto di partenza è un utente standard, occorre prima scalare i privilegi — rendendo questa tecnica tipicamente un secondo passo nella catena di escalation.

Il cuore della detection per questa tecnica è la correlazione tra eventi di logon anomali e la comparsa di processi che operano sotto identità incoerenti con il loro processo padre. Non esiste un singolo evento che grida "token fabbricato", ma una catena comportamentale ben definita che, una volta configurata, offre risultati affidabili.

Il punto di partenza è l'evento Security 4624 con LogonType 9 (NewCredentials). Questo tipo di logon è relativamente raro in ambienti ordinari — viene generato proprio da LogonUser con il flag LOGON32_LOGON_NEW_CREDENTIALS, lo stesso usato da runas /netonly e da make_token di Cobalt Strike. Un SIEM che filtra i 4624 per LogonType 9, escludendo i processi legittimi come winlogon.exe, lsass.exe e i worker IIS, cattura la maggior parte degli scenari offensivi.

La seconda fonte critica è Sysmon EventID 1 (open source, richiede installazione e configurazione). Quando un processo figlio presenta un SID o un LogonId diverso dal processo padre, e quel mismatch non rientra in pattern noti (servizi, scheduled task, UAC elevation), si è quasi certamente di fronte a un'impersonificazione. La regola di correlazione dovrebbe operare così:

1. Rilevare un evento 4624 LogonType 9 o LogonType 3 di provenienza locale
2. Entro una finestra di 5-10 minuti, cercare un Sysmon EventID 1 il cui LogonId corrisponda alla sessione appena creata
3. Verificare che il processo padre non sia nella whitelist degli impersonatori legittimi
4. Alzare la severity se il salto di integrity level è significativo (Medium → High o System)

I parametri di tuning sono cruciali per contenere i falsi positivi. La whitelist degli AllowedImpersonators va popolata con i service account che legittimamente creano token — tipici candidati sono i pool applicativi IIS, SQL Server, e i service account di backup. Il TimeWindow di correlazione va calibrato sull'ambiente: 5 minuti è un buon default, ma ambienti con automazione pesante possono richiedere finestre più ampie.

Per ambienti con telemetria ETW avanzata, i provider Microsoft-Windows-Security-Auditing catturano le chiamate a LogonUser e SetThreadToken a livello kernel. Questa visibilità, integrabile in soluzioni EDR, consente detection in tempo quasi reale senza dipendere esclusivamente dal log di Security.

Un segnale complementare è la comparsa di operazioni privilegiate (accessi a share amministrative, query LDAP estese, WMI remoto) da processi che normalmente non le eseguono. Se un cmd.exe o powershell.exe lanciato da un utente standard improvvisamente accede a \\DC01\ADMIN$, la probabilità che operi sotto un token fabbricato è elevata.

L'analisi forense di un token fabbricato si costruisce incrociando gli artefatti di autenticazione Windows con la catena di esecuzione dei processi. Il token in sé non lascia un file su disco, ma la sessione di logon che ne risulta genera tracce consistenti in più sorgenti.

Il primo artefatto da cercare è l'evento Security 4624 nel log Security del sistema compromesso. L'analista deve filtrare per LogonType 9 — indicativo di NewCredentials — e per LogonType 3 quando l'indirizzo sorgente è 127.0.0.1 o il nome macchina locale, segnale di un logon di rete originato localmente, pattern tipico di tool come Cobalt Strike. Per ogni occorrenza, annotare il LogonId (campo TargetLogonId): questo valore è il filo conduttore che lega la sessione a tutti i processi successivi.

L'evento 4672 (Special privileges assigned to new logon) accompagna il 4624 quando il token creato possiede privilegi elevati come SeDebugPrivilege, SeImpersonatePrivilege o SeTcbPrivilege. La presenza di questi privilegi in una sessione LogonType 9 è un indicatore di forte rilevanza.

Sul fronte dei processi, i log Sysmon EventID 1 documentano ogni creazione di processo con il relativo LogonId. L'analista può ricostruire l'intera catena di processi eseguiti sotto il token fabbricato filtrando per il LogonId estratto dal 4624. In particolare, un mismatch tra il SID del processo padre e quello del figlio — dove il figlio opera sotto un'identità diversa — è l'artefatto firma di questa tecnica.

Per il caso specifico di BlackByte, che ha costruito token validi dopo lo sfruttamento di Microsoft Exchange, gli artefatti aggiuntivi si trovano nei log di IIS (directory %SystemDrive%\inetpub\logs\LogFiles) e nei log di Exchange (ECP/OWA). La sequenza forense mostra tipicamente: exploitation della vulnerabilità Exchange → creazione del token privilegiato → esecuzione di comandi con quel contesto elevato. La correlazione temporale tra gli ultimi log di exploitation e il primo 4624 anomalo delimita il momento esatto del pivoting.

Per FIN13 e l'uso di Incognito V2, l'artefatto più probabile è la presenza del binario stesso su disco o in memoria. L'analisi della MFT con tool come MFTECmd (open source, parte della suite Eric Zimmerman Tools) permette di identificare la creazione o il download del tool. L'analisi della memoria con Volatility 3 (open source) consente di ispezionare i token attivi e le sessioni di logon per identificare sessioni orfane — quelle create programmaticamente che non corrispondono a un logon interattivo reale.

Infine, il Windows Prefetch (C:\Windows\Prefetch) può rivelare l'esecuzione di strumenti di impersonificazione, anche se il binario è stato successivamente cancellato. L'analisi con PECmd (open source, Eric Zimmerman Tools) fornisce timestamp di prima e ultima esecuzione.

La tecnica T1134.003 compare nel repertorio di due gruppi con profili operativi nettamente distinti, il che offre una prospettiva interessante sulla versatilità di questo meccanismo.

BlackByte ha impiegato la creazione di token come passo immediatamente successivo allo sfruttamento di Microsoft Exchange. Il pattern è significativo: il gruppo non si è limitato a ottenere l'accesso iniziale attraverso la vulnerabilità, ma ha immediatamente consolidato il proprio contesto di sicurezza fabbricando un token di autenticazione valido. Questo approccio — exploitation seguita da token manipulation — consente di dissociare le azioni successive dalla traccia dell'exploitation iniziale, complicando la correlazione forense. L'indicazione per l'analista TI è che ambienti con Exchange on-premise esposti rappresentano il vettore di ingresso, e la creazione di token è il primo atto di privilege escalation nella catena post-compromise.

FIN13 presenta un profilo diverso: gruppo motivato finanziariamente, ha adottato Incognito V2 come strumento dedicato alla token manipulation. L'uso di un tool specifico piuttosto che di una funzionalità integrata in un framework C2 suggerisce un approccio più modulare — il gruppo seleziona e combina tool standalone per comporre la propria catena offensiva. Per l'analista TI, la presenza di Incognito V2 in un'investigazione dovrebbe immediatamente attivare ipotesi di collegamento con questo attore.

Sul fronte del software, la convergenza di Cobalt Strike e SILENTTRINITY su questa tecnica è indicativa di una tendenza più ampia: i framework C2, sia commerciali che open source, considerano la creazione di token una primitiva fondamentale. Mafalda, malware con capacità di creazione token per utenti diversi, rappresenta invece un esempio di implementazione custom integrata in un impianto dedicato.

Un pattern trasversale emerge dall'analisi: la tecnica T1134.003 non viene mai usata in isolamento. È sempre un anello in una catena che parte da credenziali ottenute precedentemente (credential dumping, phishing, exploitation) e prosegue verso lateral movement o accesso a risorse protette. L'analista TI che osserva indicatori di token fabrication dovrebbe immediatamente cercare a monte le fonti delle credenziali utilizzate e a valle i target delle azioni privilegiate.

Le due mitigazioni mappate — Privileged Account Management e User Account Management — convergono su un principio: ridurre il numero di account con credenziali riutilizzabili e privilegi sufficienti a rendere utile un token fabbricato. L'adozione di soluzioni PAM con rotazione automatica delle password e l'enforcement del privilegio minimo tramite GPO (restrizione di Create a token object e Replace a process level token) sono i controlli strategici più efficaci.

Framework MITRE ATT&CK v16 — T1134.003 Make and Impersonate Token, TA0004, TA0005. Gruppi: G1043 BlackByte, G1016 FIN13. Software: S1060 Mafalda, S0692 SILENTTRINITY, S0154 Cobalt Strike. Mitigazioni: M1026, M1018. Detection: DET0498/AN1375. Integrato con conoscenza professionale per tool e procedure operative.