Token Rubati: Use Alternate Authentication Material: Application Access Token (T1550.001)

Il primo passo per testare la sicurezza dei token è identificare quelli attivi nel sistema. In ambiente AWS, puoi utilizzare il comando:

aws sts get-federation-token --name test-session --policy file://policy.json

Questo genera un token temporaneo che simula quello che un attaccante potrebbe rubare. Una volta ottenuto, il token può essere utilizzato per accedere alle risorse senza autenticazione aggiuntiva.

Per ambienti Azure, il tool Peirates automatizza l'estrazione e l'abuso di service account token Kubernetes. L'installazione è immediata:

kubectl exec -it compromised-pod -- curl -L https://github.com/inguardians/peirates/releases/download/v1.1.0/peirates-linux-amd64 -o peirates

Una volta dentro un pod compromesso, Peirates enumera automaticamente tutti i token disponibili e permette di switchare tra diversi service account con un singolo comando. Questo simula perfettamente l'attività di HAFNIUM che ha abusato service principal con permessi amministrativi.

Per testare OAuth token theft in ambiente Office 365, puoi utilizzare PowerShell per simulare richieste API con token rubati:

$token = "eyJ0eXAiOiJKV1QiLCJhbGciOi..."
$headers = @{Authorization = "Bearer $token"}
Invoke-RestMethod -Uri "https://graph.microsoft.com/v1.0/me/messages" -Headers $headers

Il malware CreepyDrive dimostra come refresh token legittimi possano mantenere accesso persistente a OneDrive. Per replicare questo comportamento in laboratorio, configura un'applicazione OAuth che richiede refresh token con scope estesi e testa la persistenza anche dopo il cambio password dell'utente vittima.

La detection comportamentale è cruciale perché i token rubati appaiono legittimi ai sistemi di sicurezza tradizionali. Monitora AWS CloudTrail per chiamate API sts:GetFederationToken da principi o regioni inaspettate.

Un pattern critico da rilevare è l'uso di token senza attività MFA precedente. In Azure Sign-In Logs, cerca eventi dove il campo mfaDetail è vuoto ma viene utilizzato un token di accesso. Questo indica potenziale compromissione.

Per ambienti Kubernetes, configura alert sull'API server quando un service account token viene utilizzato fuori dal namespace previsto. La query Splunk:

index=kubernetes source=apiserver "serviceaccount" | where namespace!=expected_namespace

Identifica immediatamente movimenti laterali attraverso token rubati. L'83% dei falsi positivi deriva da applicazioni legittime che cambiano comportamento, quindi mantieni una baseline accurata dei pattern normali di utilizzo token.

I log di Google Workspace e Salesforce devono essere correlati per identificare token con scope inusuali. Se un token richiede accesso completo ai contatti quando l'applicazione normalmente legge solo il calendario, genera un alert immediato. La chiave è monitorare non solo l'esistenza del token, ma il contesto del suo utilizzo.

L'analisi forense dei token rubati richiede la correlazione di molteplici fonti di log. In AWS CloudTrail, cerca prima l'evento di creazione del token federato, poi traccia tutte le azioni successive effettuate con quel token attraverso il campo userIdentity.sessionContext.

Per Office 365, il campo correlationId nei Unified Audit Logs collega tutte le azioni effettuate con lo stesso token. Durante l'incidente SolarWinds, gli investigatori hanno ricostruito l'intera catena di compromissione seguendo i service principal modificati attraverso questo identificatore.

Gli artefatti di refresh token OAuth spesso persistono nel browser della vittima. Su Windows, esamina:

%LOCALAPPDATA%\Google\Chrome\User Data\Default\Cookies

Dove i token sono memorizzati in formato SQLite. L'estrazione richiede decrittazione con DPAPI ma rivela timestamp precisi di quando il token è stato rubato.

In ambienti container, i token montati lasciano tracce in /var/run/secrets/kubernetes.io/serviceaccount/. Il timestamp di modifica di questi file indica quando un attaccante potrebbe aver acceduto al token. Correla sempre con i log dell'API server per identificare l'uso anomalo successivo.

La ricostruzione della timeline deve mappare: acquisizione iniziale del token, primo utilizzo malevolo, espansione dei privilegi attraverso il token, e eventuale persistenza ottenuta. Questa sequenza permette di capire l'intero scope della compromissione.

APT28 ha pionerato l'abuso di OAuth tokens attraverso applicazioni malevole che richiedono permessi eccessivi durante l'autorizzazione. Il gruppo tipicamente targetta provider email popolari come Gmail e Yahoo, sfruttando la fiducia degli utenti nelle applicazioni third-party.

APT29 ha elevato questa tecnica durante SolarWinds Compromise, dimostrando come service principal compromessi possano modificare intere tenant Azure. La loro metodologia prevede l'uso di token per mantenere persistenza anche dopo la remediation iniziale.

HAFNIUM rappresenta l'evoluzione tattica: invece di rubare token utente, compromette service principal con privilegi amministrativi per massimizzare l'impatto. Questo gruppo cinese ha dimostrato capacità di data exfiltration massiva attraverso token compromessi.

L'overlap negli strumenti è significativo: sia Peirates che CreepyDrive implementano meccanismi di refresh token abuse, indicando una convergenza nelle TTP. I gruppi APT stanno standardizzando l'approccio ai token theft come metodo primario di persistenza.

Il trend emergente mostra uno spostamento dai token utente ai service account token, particolarmente in ambienti Kubernetes e cloud-native. I threat actor riconoscono che questi token spesso hanno privilegi più elevati e controlli di sicurezza meno stringenti. Aspettati un'evoluzione verso il targeting di token di infrastruttura critica piuttosto che endpoint utente.

Framework MITRE ATT&CK T1550.001 documenta Application Access Token abuse con evidenze da APT28, APT29/SolarWinds Compromise, e HAFNIUM. Detection strategies includono behavioral analytics su AWS CloudTrail, Azure Sign-In Logs, e Kubernetes API server per identificare token usage anomalo.