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

Per testare la sicurezza dei token Kubernetes nel tuo ambiente di lab, inizia identificando i token dei service account. Il comando kubectl get secrets -A ti mostrerà tutti i secret disponibili nei namespace.

Una volta identificato un token interessante, puoi estrarlo con: kubectl get secret [nome-secret] -o jsonpath='{.data.token}' | base64 -d

Strumenti come Peirates automatizzano questo processo, raccogliendo token attraverso varie tecniche. L'installazione è semplice: scarica il binario e lancia ./peirates per avviare la modalità interattiva.

Per simulare il furto di token OAuth in Azure, AADInternals offre funzionalità complete. Dopo l'installazione del modulo PowerShell, puoi creare applicazioni malevole che richiedono consenso agli utenti target. Il comando New-AADIntApplication ti permette di registrare un'app con permessi elevati.

Negli ambienti AWS, il metadata endpoint è il punto di partenza. Da un'istanza EC2 compromessa: curl http://169.254.169.254/latest/meta-data/iam/security-credentials/[role-name]

Questo restituirà token temporanei che puoi utilizzare per autenticarti alle API AWS. La chiave sta nel tempismo: questi token hanno vita limitata, quindi automatizza la catena di attacco per sfruttarli rapidamente.

Per testare ambienti CI/CD, cerca nei file di configurazione delle pipeline. Token hardcoded in .gitlab-ci.yml o .github/workflows sono vulnerabilità comuni che permettono accesso persistente ai repository e agli artefatti di build.

La detection efficace richiede correlazione tra eventi apparentemente disconnessi. Monitora l'accesso ai metadata endpoint: richieste a 169.254.169.254 seguite da chiamate API con user-agent insoliti indicano potenziale compromissione.

Nei log Kubernetes (kubernetes:audit), cerca pattern di accesso ai secret seguiti da chiamate API anomale. Un service account che improvvisamente esegue operazioni mai viste prima merita investigazione immediata.

Per OAuth, concentrati sui log di Azure AD (azure:audit). Nuove registrazioni di app seguite da consensi multipli in breve tempo sono red flag. Il rapporto tra utenti che autorizzano un'app e il totale degli utenti può rivelare campagne di phishing mirate.

I log di Microsoft 365 (m365:unified) mostrano l'uso effettivo dei token. Accessi programmatici a risorse mail o SharePoint da IP geograficamente distanti o app sconosciute vanno investigati. La velocità geografica impossibile - token usati da continenti diversi in pochi minuti - è un indicatore affidabile.

Implementa threshold dinamici basati sul comportamento normale. Un'app che normalmente accede a 10 file al giorno e improvvisamente ne scarica 1000 probabilmente sta usando un token rubato. L'automazione è cruciale: correlazioni manuali non scalano in ambienti cloud complessi.

Durante Leviathan Australian Intrusions, gli attaccanti hanno estratto JSON Web Token (JWT) per creare sessioni VDI. Questi token erano conservati in appliance compromesse, lasciando tracce nei log di autenticazione e nei file di configurazione.

In Kubernetes, i token rubati lasciano artefatti nel /var/run/secrets/kubernetes.io/serviceaccount/ dei pod compromessi. Confronta i timestamp di accesso con le attività API anomale per ricostruire la sequenza di compromissione.

Per OAuth, esamina i log di consenso in Azure AD. La timeline tipica mostra: registrazione app malevola, invio email phishing, click utente, consenso OAuth, accesso risorse. Ogni fase lascia tracce nei log di audit che permettono di ricostruire l'intero attacco.

Nei sistemi compromessi, cerca nella history dei comandi riferimenti a curl verso metadata endpoint. File temporanei contenenti token potrebbero essere rimasti in /tmp o nelle directory home degli utenti. I browser mantengono traccia dei redirect OAuth nelle loro history, utili per identificare le vittime.

Gli attaccanti spesso automatizzano l'esfiltrazione post-furto. Cerca script o task schedulati che utilizzano token per accedere periodicamente a risorse cloud. La persistenza richiede refresh token: identificali per comprendere la durata potenziale della compromissione.

APT28 ha dimostrato sofisticazione nell'ingegneria sociale, creando app OAuth che imitano servizi legittimi. "Google Defender" e "Google Email Protection" sfruttano la familiarità degli utenti con i brand per ottenere consensi. Il gruppo ha anche diversificato con "Delivery Service" per Yahoo, mostrando adattabilità cross-platform.

APT29 utilizza un approccio più silenzioso, concentrandosi sul riutilizzo di token già esistenti piuttosto che sulla generazione di nuovi. Questa tattica riduce l'interazione con l'utente e rende la detection più difficile, suggerendo operazioni a lungo termine.

Leviathan ha mostrato pazienza nelle campagne australiane, mantenendo l'accesso per 5 mesi. Il focus su JWT per sessioni VDI indica targeting di ambienti enterprise con infrastrutture virtualizzate complesse. L'esfiltrazione di credenziali valide suggerisce preparazione per future campagne.

I pattern geografici mostrano che gruppi state-sponsored preferiscono OAuth per campagne su larga scala, mentre criminali comuni sfruttano più spesso token di servizi CI/CD per cryptomining. L'overlap nei tool è limitato: ogni gruppo tende a sviluppare proprie varianti di raccolta token.

L'evoluzione verso ambienti containerizzati significa che vedremo più focus su service account Kubernetes e token di orchestrazione. I gruppi APT stanno già adattando le loro catene di attacco per sfruttare queste nuove superfici.

Tecnica T1528 documentata nel framework MITRE ATT&CK. Campagna Leviathan Australian Intrusions (C0049) analizzata per pattern JWT. Strumenti AADInternals e Peirates referenziati per capability offensive. Mitigazioni M1017, M1018, M1021, M1047 per controlli preventivi e detective.