Token Forgery: Make and Impersonate Token (T1134.003)

Per replicare questa tecnica in laboratorio, il primo passo consiste nel creare un nuovo token utilizzando credenziali note. Il comando PowerShell seguente dimostra l'approccio base:

$SecPassword = ConvertTo-SecureString 'Password123!' -AsPlainText -Force $Credential = New-Object System.Management.Automation.PSCredential('DOMAIN\targetuser', $SecPassword) Start-Process cmd.exe -Credential $Credential

Un approccio più sofisticato prevede l'utilizzo diretto delle API Windows. Cobalt Strike implementa questa funzionalità attraverso il comando make_token, che internamente chiama LogonUser con tipo di logon 9 (NewCredentials):

make_token DOMAIN\administrator Password123!

Per un controllo granulare, puoi utilizzare Incognito V2 (strumento preferito da FIN13) che permette di creare token con specifici privilegi:

incognito.exe add_user admin_token DOMAIN\targetuser Password123! incognito.exe impersonate_token "DOMAIN\targetuser"

SILENTTRINITY offre un modulo dedicato che automatizza l'intero processo. Il modulo ipy/maketoken crea il token e lo assegna automaticamente al thread corrente:

use ipy/maketoken set USERNAME targetuser set DOMAIN CORP set PASSWORD Password123! execute

Per verificare il successo dell'operazione, controlla l'identità corrente del processo:

whoami /all

L'output mostrerà il nuovo contesto di sicurezza con i privilegi associati al token creato. Mafalda implementa una variante che permette di specificare il tipo di logon, utile per bypassare specifiche policy di sicurezza.

La detection chain DET0498 fornisce un approccio strutturato per identificare questa tecnica. Il primo indicatore critico è l'evento 4624 con LogonType 9 (NewCredentials) generato da processi non interattivi.

Configura il monitoraggio per catturare la sequenza: processo sospetto → chiamata LogonUser → evento 4624 → nuovo processo con LogonId diverso dal parent. Questa catena si verifica tipicamente entro 5-10 minuti.

I falsi positivi comuni includono servizi legittimi come IIS worker processes e winlogon.exe. Crea una whitelist dinamica basata sul comportamento baseline del tuo ambiente, prestando attenzione a:

EventCode 4624 AND LogonType:9 AND NOT (ProcessName:("w3wp.exe" OR "winlogon.exe"))

Implementa il monitoraggio ETW per catturare chiamate dirette alle API:

• LogonUser/LogonUserEx
• SetThreadToken
• ImpersonateLoggedOnUser

Un indicatore ad alta fedeltà è il salto di integrity level, specialmente da Medium a High/System. Configura alert per processi che mostrano questo pattern:

ParentIntegrityLevel:Medium AND ProcessIntegrityLevel:(High OR System) AND ParentUser != ProcessUser

Monitora anche comandi PowerShell contenenti P/Invoke di LogonUser o utilizzo di runas con parametro /netonly. BlackByte ha dimostrato come questa tecnica possa seguire exploit di Exchange, quindi correla con eventi di exploitation sui server critici.

L'analisi forense di questa tecnica richiede la correlazione di molteplici artefatti Windows. Il Security Event Log contiene la chiave primaria: eventi 4624 con LogonType non standard generati da processi atipici.

Esamina il registro Microsoft-Windows-Security-Auditing ETW per tracce di chiamate API:

• Timestamp della chiamata LogonUser
• Handle del token creato
• Thread ID che ha ricevuto il token

Il Prefetch può rivelare l'esecuzione di tool come Incognito o moduli Cobalt Strike. Cerca file .pf per:

• INCOGNITO.EXE
• BEACON.DLL caricato in processi legittimi
• PowerShell con hash di comando anomali

FIN13 tipicamente lascia tracce nel registro MRU (Most Recently Used) quando utilizza token impersonati per accedere a risorse di rete. Verifica:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU

La timeline reconstruction deve includere:

1. Momento iniziale di compromissione
2. Creazione del token (evento 4624)
3. Primo processo spawned con nuovo LogonId
4. Azioni successive con privilegi elevati

Analizza la memoria del processo per identificare token handle aperti. Tools come Volatility possono enumerare tutti i token e mostrare discrepanze tra il token del processo e quello del thread.

BlackByte ha dimostrato pattern specifici post-exploitation di Exchange: cerca eventi 4624 entro 30 minuti da alert di ProxyShell/ProxyLogon.

FIN13 rappresenta il caso d'uso più maturo di questa tecnica. Il gruppo integra Incognito V2 nelle loro operazioni post-compromise per movimento laterale silenzioso. Pattern geografico: targeting primario su istituzioni finanziarie nordamericane ed europee.

Le loro campagne mostrano una progressione standard:

• Initial access via phishing
• Privilege escalation con token manipulation
• Lateral movement verso sistemi di pagamento
• Data exfiltration di carte di credito

BlackByte adotta un approccio diverso, utilizzando la tecnica come ponte post-exploitation. Dopo aver compromesso Exchange servers, creano token validi per mantenere l'accesso privilegiato anche dopo il patching delle vulnerabilità iniziali.

Il ransomware del gruppo sfrutta questi token per:

• Disabilitare soluzioni EDR
• Accedere a share di rete privilegiate
• Distribuire il payload su scala enterprise

L'overlap nei tool è significativo: entrambi i gruppi utilizzano varianti di Cobalt Strike con moduli custom per token manipulation. Questo suggerisce possibili connessioni nella supply chain criminale o accesso a risorse comuni nel underground.

Le previsioni per l'evoluzione includono:

• Automazione completa del processo in ransomware-as-a-service
• Integrazione con tecniche di persistence più sofisticate
• Targeting specifico di ambienti cloud dove i token hanno validità estesa

Monitor per indicatori di compromissione correlati: presenza di Incognito, moduli Cobalt Strike non standard, pattern di logon anomali seguito da ransomware deployment entro 72 ore.

Tecnica documentata nel framework MITRE ATT&CK con evidenze operative da FIN13 e BlackByte. Detection chain DET0498 basata su Windows Security Auditing e ETW. Riferimenti a campagne reali dimostrano l'utilizzo in contesti ransomware e financial crime.