Token Rubati, Accesso Garantito: Application Access Token (T1550.001)

L'obiettivo in laboratorio è dimostrare che un token sottratto permette di operare come l'utente vittima senza bisogno di password né MFA. L'esercizio si articola su tre superfici d'attacco: cloud AWS, Microsoft 365/Entra ID e ambienti Kubernetes.

AWS — Sessione federata persistente. Partendo da credenziali API compromesse (access key + secret key), è possibile creare una sessione federata che sopravvive alla revoca delle chiavi originali:

aws sts get-federation-token --name attacker-session --policy '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"","Resource":""}]}' --duration-seconds 43200

Il risultato è un set di credenziali temporanee valide fino a 12 ore. Per simulare l'assunzione di ruolo cross-account, dove i permessi IAM lo consentano:

aws sts assume-role --role-arn arn:aws:iam::ACCOUNT_ID:role/TARGET_ROLE --role-session-name red-team-test

Entrambi i comandi generano eventi CloudTrail distinti (GetFederationToken, AssumeRole) che il blue team deve rilevare.

Microsoft 365 — Abuso di refresh token OAuth. Con ROADtools (open source), il penetration tester può importare un refresh token sottratto e accedere a Microsoft Graph senza credenziali interattive. Il toolkit consente di enumerare utenti, caselle email e permessi delegati attraverso le API REST di Entra ID. Un'alternativa per ottenere token in modo controllato è TokenTacticsV2 (open source), che implementa flussi OAuth device code e permette di acquisire refresh token per tenant Microsoft durante ingaggi autorizzati.

Kubernetes — Service account token. Lo strumento Peirates (open source) è progettato per ambienti Kubernetes e consente di utilizzare token di service account rubati per autenticarsi verso l'API server del cluster. Una volta caricato un token valido, Peirates permette di switchare tra service account diversi, enumerare secret, e tentare movimenti laterali tra namespace. In alternativa, il comando nativo:

kubectl --token= --server= get secrets --all-namespaces

dimostra immediatamente il raggio d'azione del token compromesso.

Per l'intera catena d'attacco è consigliabile utilizzare Burp Suite (freemium) come proxy per intercettare e manipolare i flussi OAuth durante le fasi di autorizzazione, verificando se l'applicazione target valida correttamente scope e redirect URI.

La detection di token rubati è insidiosa perché le chiamate API risultano tecnicamente legittime. L'approccio vincente è comportamentale: non cercare il token in sé, ma le anomalie nel contesto d'uso.

IaaS — CloudTrail come sorgente primaria. Le analytic AN0526 indicano di monitorare gli eventi AssumeRole, GetFederationToken e GetSessionToken in AWS CloudTrail. La regola deve correlare tre dimensioni: il principal che richiede il token (è un account che normalmente esegue assunzioni di ruolo?), la regione di origine (parametro di tuning GeoIPDistanceThreshold — distanza anomala tra creazione del token e utilizzo delle risorse), e lo scope del ruolo (RoleScope — l'account sta assumendo un ruolo fuori dal proprio perimetro abituale). Un alert efficace in un SIEM come Splunk (a pagamento) o Elastic Security (freemium) filtra gli eventi eventName=AssumeRole dove sourceIPAddress non appartiene ai CIDR aziendali noti e il ruolo assunto non compare nella baseline storica dell'account.

Identity Provider — Token senza login. L'analytic AN0527 si concentra su azure:signinlogs e m365:unified: il segnale chiave è un token OAuth o SAML utilizzato in una sessione dove non esiste un evento di login interattivo precedente o dove manca il contesto MFA. Il tuning MFAEnforcement verifica che ogni emissione di token sia preceduta da autenticazione multifattore, mentre TokenReuseWindow definisce la finestra temporale massima accettabile per il riutilizzo di un refresh token — oltre quella soglia, l'alert deve scattare.

SaaS e Office 365. Per Google Workspace e Salesforce (AN0528), monitorare chiamate API eseguite senza login interattivo, con scope elevati o non presenti nella allowlist aziendale (ApplicationScopeAllowlist). Per Exchange Online e SharePoint (AN0529), il campo ClientAppId nei log unificati M365 è il discriminante: mantenere una whitelist di applicazioni autorizzate (ClientAppIDWhitelist) e generare alert per qualsiasi client ID sconosciuto che accede alle API.

Container. L'analytic AN0530 segnala token di service account montati in pod Kubernetes e riutilizzati per chiamate API esterne al namespace previsto. I log dell'API server Kubernetes, correlati con CloudTrail se il cluster è su EKS, permettono di rilevare movimenti laterali tra namespace. Il tuning NamespaceScope limita l'uso atteso del token a workload specifici.

La gestione dei falsi positivi ruota attorno alla costruzione di una solida baseline: automazioni legittime, pipeline CI/CD e service principal noti devono essere esclusi progressivamente nelle prime due settimane di tuning.

L'analisi forense di un abuso di token applicativi si svolge quasi interamente su log cloud e identity provider — gli artefatti endpoint tradizionali sono marginali, perché il token opera a livello API senza toccare il filesystem della vittima.

AWS CloudTrail — Ricostruzione della catena. L'indagine parte dagli eventi GetFederationToken e AssumeRole. Ogni record CloudTrail contiene il campo userIdentity.arn (chi ha richiesto il token), requestParameters.roleArn (quale ruolo è stato assunto), sourceIPAddress e userAgent. La timeline si costruisce correlando l'istante di creazione della sessione federata con le successive chiamate API effettuate con le credenziali temporanee: queste ultime avranno un userIdentity.type pari a FederatedUser o AssumedRole e un accessKeyId diverso da quello originale. Lo strumento CloudTrail Lake (a pagamento, incluso in AWS) permette query SQL dirette sugli eventi archiviati; in alternativa, l'export verso Athena (a pagamento, pay-per-query) consente analisi su grandi volumi.

Entra ID e Microsoft 365. I sign-in log di Entra ID registrano ogni emissione di token con il campo authenticationDetails, che indica se è avvenuta un'autenticazione interattiva o un rinnovo silenzioso via refresh token. L'audit log unificato di M365 mostra le operazioni successive: ricerche email, accesso a SharePoint, modifiche a permessi. Il forensic analyst deve cercare sessioni dove il tokenIssuerType è AzureAD ma l'ipAddress non corrisponde a quelle dell'utente legittimo, o dove il clientAppId appartiene a un'applicazione OAuth non aziendale — segnale diretto di un consenso OAuth malevolo, tecnica documentata per APT28.

Kubernetes. Nei cluster compromessi, il file di audit dell'API server (--audit-log-path) contiene ogni richiesta autenticata con service account token. L'analista deve estrarre le richieste dove il campo user.username corrisponde a un service account noto ma l'IP sorgente è esterno al cluster o appartiene a un pod non previsto. Lo strumento kube-forensics (open source) facilita la cattura dello stato dei pod per analisi post-incidente.

Correlazione con la campagna SolarWinds Compromise (C0024). Durante quell'operazione, gli attaccanti utilizzarono service principal compromessi per manipolare l'ambiente Office 365 delle vittime. Il pattern forense da cercare è la modifica di permessi applicativi (eventi Update application o Add app role assignment nei log Entra ID) seguita da accesso API a caselle email senza login interattivo. Questa sequenza — elevazione di permessi del service principal, poi esfiltrazione via API — rappresenta un indicatore forte di compromissione tramite token.

L'abuso di token applicativi è un tratto distintivo di gruppi che operano primariamente contro infrastrutture cloud e SaaS, con obiettivi di spionaggio a lungo termine.

APT28 (G0007), attribuito all'intelligence militare russa, ha utilizzato applicazioni OAuth malevole per ottenere accesso persistente a caselle Gmail e Yahoo Mail delle vittime. Il pattern operativo è caratteristico: anziché sottrarre la password, APT28 induce la vittima a concedere il consenso OAuth a un'applicazione controllata dall'attaccante, ottenendo un refresh token di lunga durata che sopravvive a qualsiasi cambio di password. Questa tecnica si integra con le operazioni di spear-phishing per le quali il gruppo è noto, creando una catena dove il phishing serve unicamente a ottenere il consenso OAuth.

HAFNIUM (G0125), associato alla Cina, ha sfruttato service principal con permessi amministrativi per esfiltrare dati da ambienti cloud. Il profilo è diverso da APT28: qui l'abuso non passa da un consenso utente, ma dall'appropriazione di identità applicative già privilegiate nell'ambiente target. Questo approccio richiede un accesso iniziale più profondo all'infrastruttura, coerente con lo sfruttamento di vulnerabilità server-side per cui HAFNIUM è conosciuto.

La campagna SolarWinds Compromise (C0024), condotta tra agosto 2019 e gennaio 2021 e attribuita all'SVR russo, rappresenta il caso più sofisticato di abuso di token in una supply chain operation. Gli attaccanti compromisero service principal per apportare modifiche all'ambiente Office 365, inserendosi in un flusso che coinvolgeva password spraying, token theft e API abuse come vettori complementari. Le vittime abbracciavano settori governativi, tecnologici e di consulenza tra Nord America, Europa, Asia e Medio Oriente. L'industria ha etichettato questa attività come StellarParticle.

Sul fronte degli strumenti, il malware CreepyDrive (S1023) dimostra come un agente malevolo possa sfruttare refresh token OAuth legittimi per autenticarsi su OneDrive, utilizzando lo storage cloud come canale C2 in modo quasi indistinguibile dal traffico utente normale. Il tool Peirates (S0683), pensato per ambienti Kubernetes, mostra invece la dimensione container di questa tecnica: token di service account rubati vengono riutilizzati per muoversi tra workload.

Il trend emergente è chiaro: i gruppi APT stanno spostando le operazioni di persistenza dal filesystem endpoint ai livelli di identità cloud. La difesa deve seguire questa migrazione, investendo in token binding (come Azure AD Token Protection e OAuth Proof of Possession), audit continuo dei consensi OAuth e monitoraggio delle assunzioni di ruolo IAM.

Framework MITRE ATT&CK: T1550.001, TA0005, TA0008, G0007, G0125, S0683, S1023, C0024, M1036, M1047, M1021, M1013, M1041. Detection: DET0185 (AN0526–AN0530). Integrato con conoscenza professionale per tool e procedure operative.