Furto di Token Applicativi: Steal Application Access Token (T1528)

Il furto di token applicativi si presta a molteplici scenari di red team, ciascuno legato a un ambiente specifico. L'obiettivo è dimostrare al cliente che un token rubato equivale — e spesso supera — il valore di una password compromessa.

Scenario Kubernetes: estrazione di service account token. In un cluster dove il pod non ha disabilitato l'automount, il token è leggibile dal filesystem del container. Da una shell nel pod compromesso:

cat /var/run/secrets/kubernetes.io/serviceaccount/token

Con il token in mano, si interroga l'API server direttamente. Lo strumento Peirates (open source) automatizza l'intera catena: enumera i service account disponibili, raccoglie i token e tenta di utilizzarli per eseguire azioni privilegiate nel cluster. Una volta lanciato all'interno del pod, offre un menu interattivo per esplorare i secret Kubernetes e tentare il pivoting verso altri namespace.

Scenario Azure: abuso di IMDS per Managed Identity. Se si ottiene accesso a una VM Azure con Managed Identity configurata, il token è a una richiesta HTTP di distanza. Dal terminale della VM:

curl -s -H "Metadata:true" "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"

Il JSON di risposta contiene un access_token utilizzabile con le Azure REST API. Per testarne i privilegi, si può interrogare l'elenco delle sottoscrizioni:

curl -s -H "Authorization: Bearer <TOKEN>" "https://management.azure.com/subscriptions?api-version=2020-01-01"

Scenario OAuth phishing: consent grant attack. Si registra un'applicazione multi-tenant su Azure AD (ora Microsoft Entra ID) e si configura con permessi delegati ampi (Mail.Read, Files.ReadWrite.All). Si invia un link di autorizzazione alla vittima tramite spearphishing. Se l'utente concede il consenso, il token OAuth risultante garantisce accesso alla casella email e ai file OneDrive. Il tool AADInternals (open source) offre cmdlet PowerShell per gestire token Azure AD, inclusa la richiesta di access token a partire da refresh token sottratti.

Scenario CI/CD. Nei pipeline compromessi, i token sono spesso memorizzati come variabili d'ambiente. Un semplice env | grep -i token dalla shell del runner può rivelare credenziali API per servizi esterni. Lo strumento truffleHog (open source) è utile per scandagliare repository alla ricerca di secret esposti, inclusi token OAuth e JWT hardcoded.

La detection del furto di token è una partita che si gioca su più log source contemporaneamente, perché il token può essere rubato in un ambiente e usato in un altro. La chiave è correlare l'emissione del token con il suo successivo utilizzo anomalo.

Kubernetes audit log (AN1423). La prima cosa da monitorare è l'accesso ai secret che contengono service account token, seguito da chiamate API inattese. Nei log di audit Kubernetes, si cercano richieste a /api/v1/namespaces//secrets* da parte di pod che normalmente non necessitano di quel livello di accesso. Il tuning richiede una baseline solida: bisogna catalogare quali service account accedono legittimamente all'API server, e flaggare tutto il resto. La finestra temporale tra accesso al token e prima chiamata API anomala è solitamente breve — minuti, non ore.

CloudTrail e Azure audit (AN1424, AN1425). Per gli ambienti IaaS, l'indicatore critico è la richiesta al metadata endpoint seguita da chiamate API con il token ottenuto, specialmente se il User-Agent non corrisponde agli strumenti di automazione noti. Su AWS, le richieste a IMDS che provengono da processi insoliti (un curl manuale invece dell'SDK ufficiale) meritano attenzione. Su Azure, occorre monitorare la registrazione di nuove applicazioni OAuth e il consenso utente: un'app sconosciuta che riceve consenso da più utenti in rapida successione è un segnale d'allarme forte. Lo scope dei permessi concessi è un discriminante fondamentale — permessi come Mail.Read o Directory.ReadWrite.All su un'app appena registrata giustificano un'escalation immediata.

Microsoft 365 Unified Audit Log (AN1426). Qui si monitorano le app di terze parti che accedono a posta, calendario e SharePoint. La strategia è mantenere una allowlist di Client App ID noti e generare alert per qualsiasi app non presente nella lista. Il volume di accesso è un altro indicatore: un'app appena autorizzata che legge centinaia di email in pochi minuti non è un comportamento utente normale.

SaaS e geo-velocity (AN1427). Per piattaforme come Google Workspace e Slack, la detection si basa sull'anomalia geografica: se un token viene usato da un IP in Europa e dieci minuti dopo da uno in Asia, l'allarme è giustificato. Gli scope ad alto rischio (admin, file.read) vanno pesati maggiormente nella logica di scoring.

Come controllo preventivo, la misura più efficace è bloccare il consenso utente alle applicazioni OAuth, forzando l'approvazione amministrativa tramite le policy di Azure AD / Entra ID. Un Cloud Access Security Broker (CASB) completa il quadro permettendo di bannare applicazioni sospette e monitorare l'utilizzo dei token in tempo reale.

L'analisi forense del furto di token richiede un approccio multi-piattaforma: il token nasce in un punto, viaggia attraverso un canale e viene consumato in un altro. La timeline deve ricostruire questa traiettoria.

Artefatti Azure AD / Entra ID. Il punto di partenza è l'Azure AD Sign-in Log e l'Audit Log. Si cercano eventi di tipo Consent to application, che registrano l'ID dell'applicazione, lo scope dei permessi concessi e l'utente che ha fornito il consenso. Se il furto è avvenuto tramite consent phishing, la timeline mostrerà un click su un link di spearphishing (tracciabile nei log del mail gateway o del proxy web), seguito dall'evento di consenso OAuth, seguito dall'accesso dell'app alle risorse dell'utente. I token hanno un campo iat (issued at) e exp (expiration) che permettono di definire con precisione la finestra temporale di validità.

Artefatti Kubernetes. Nei cluster compromessi, i log di audit Kubernetes sono la fonte primaria. Si ricostruisce la sequenza: accesso al pod (via exploit o credenziali compromesse), lettura del file del token (ResponseComplete con path al secret), poi chiamate API con quel token. Sul filesystem del nodo, se è disponibile un'immagine forense, si verifica l'eventuale presenza di tool come Peirates nei layer del container o nelle directory temporanee.

Artefatti cloud IaaS. Per i token rubati via IMDS, i log CloudTrail (AWS) o Activity Log (Azure) registrano ogni chiamata API effettuata con il token. L'elemento chiave è il sourceIPAddress: se il token è stato esfiltrato e usato da un IP esterno alla rete del provider cloud, la compromissione è evidente. La campagna Leviathan Australian Intrusions (C0049), condotta tra aprile e settembre 2022, offre un caso studio pertinente: il gruppo ha abusato dell'accesso ad appliance compromesse per raccogliere JSON Web Token (JWT) utilizzati per creare sessioni di virtual desktop. La ricostruzione forense in scenari analoghi passa dall'analisi dei log degli appliance di rete, dalla correlazione dei JWT emessi con le sessioni create, e dall'identificazione delle azioni eseguite all'interno di quelle sessioni.

Artefatti endpoint. Sul client della vittima di un consent phishing, il browser conserva tracce nella cronologia di navigazione: la redirect URL dell'applicazione OAuth malevola compare nei log del browser (file History di Chromium, analizzabile con tool come Hindsight (open source)). Il proxy web o il DNS resolver possono fornire conferme indipendenti della connessione al dominio dell'app malevola. Su macchine dove AADInternals è stato utilizzato dall'attaccante, i log PowerShell con ScriptBlock Logging attivo (EventID 4104) registrano i cmdlet invocati per la manipolazione dei token.

Il furto di token applicativi è una tecnica adottata da gruppi nation-state di primo livello, con un pattern chiaro: l'obiettivo è ottenere accesso persistente e silenzioso senza lasciare le tracce tipiche del credential theft tradizionale.

APT29 (G0016) — il gruppo russo legato all'SVR — utilizza token rubati per accedere agli account delle vittime bypassando completamente l'autenticazione basata su password. Questa scelta tattica è coerente con il profilo operativo del gruppo, storicamente orientato allo spionaggio a lungo termine in ambienti governativi e diplomatici. L'uso di token consente di eludere le protezioni MFA, poiché il token rappresenta un'autenticazione già completata. L'intelligence analyst deve considerare che in ambienti dove APT29 è una minaccia rilevante, la rotazione periodica dei token e il monitoraggio del loro utilizzo anomalo sono contromisure prioritarie.

APT28 (G0007) — il gruppo russo associato al GRU — ha adottato un approccio più aggressivo e basato sul social engineering. Ha costruito applicazioni OAuth malevole mascherate con nomi credibili come "Google Defender", "Google Email Protection" e "Google Scanner" per colpire utenti Gmail, e "Delivery Service" e "McAfee Email Protection" per utenti Yahoo. Questo pattern di denominazione rivela una strategia di impersonificazione di brand di sicurezza, progettata per abbassare la guardia della vittima: chi rifiuterebbe l'accesso a un'app che sembra un prodotto di protezione email? L'intelligence su APT28 suggerisce di monitorare attivamente le registrazioni di app OAuth con nomi che richiamano prodotti di sicurezza noti.

La campagna Leviathan Australian Intrusions (C0049), attiva da aprile a settembre 2022, dimostra come il furto di token si integri in intrusioni complesse e multi-fase. Il gruppo ha sfruttato appliance di rete compromesse per raccogliere JWT destinati alla creazione di sessioni di virtual desktop, in un contesto di esfiltrazione di dati sensibili e credenziali. Questo schema — compromissione di un'appliance perimetrale, raccolta di token in transito, utilizzo per il movimento laterale — è un pattern replicabile e da considerare nelle threat model di organizzazioni con infrastruttura ibrida.

Dal punto di vista dei trend, il furto di token sta convergendo con l'abuso di pipeline CI/CD e ambienti containerizzati. I tool come Peirates per Kubernetes e AADInternals per Azure AD abbassano la barriera tecnica e rendono questa tecnica accessibile anche ad attori meno sofisticati. L'adozione crescente di architetture cloud-native amplifica la superficie d'attacco. Per gli analisti TI, il consiglio è mappare le Managed Identity e i service account token dell'organizzazione come asset ad alto valore, e monitorare l'ecosistema underground per la vendita di token OAuth validi — un mercato in crescita nei forum di accesso iniziale.

Framework MITRE ATT&CK v16: T1528 (Steal Application Access Token), TA0006 (Credential Access). Campagna: C0049 (Leviathan Australian Intrusions). Gruppi: G0016 (APT29), G0007 (APT28). Software: S0683 (Peirates), S0677 (AADInternals). Mitigazioni: M1021, M1047, M1017, M1018. Detection: DET0515 con analytic AN1423–AN1427. Integrato con conoscenza professionale per tool e procedure operative.