Falsificazione Token SAML: Forge Web Credentials - SAML Tokens (T1606.002)

In un esercizio red team autorizzato, la simulazione di T1606.002 parte dal presupposto di aver già compromesso il server AD FS o di aver estratto il certificato di firma dal Distributed Key Manager (DKM) in Active Directory. Il tool di riferimento è AADInternals (open source), un modulo PowerShell mantenuto da Nestori Syynimaa che replica fedelmente le operazioni descritte in S0677.

L'estrazione del certificato di firma richiede accesso amministrativo sul server AD FS. Il comando tipico in AADInternals è Export-AADIntADFSSigningCertificate, che salva chiave privata e certificato in formato PFX. In alternativa, con accesso al DKM in AD, si utilizza Export-AADIntADFSCertificates per recuperare la chiave master e derivare il certificato senza toccare il server AD FS, tecnica nota come Golden SAML.

Una volta ottenuto il materiale crittografico, la forgiatura del token avviene con New-AADIntSAMLToken, che accetta parametri come -ImmutableID, -Issuer e -PfxFileName. Il token risultante può dichiarare qualsiasi UPN, inclusi Global Administrator di Entra ID. L'iniezione avviene poi tramite Get-AADIntAccessTokenForAADGraph -SAMLToken $token, ottenendo un OAuth access token spendibile su Microsoft Graph.

Una catena d'attacco tipica in laboratorio prevede:

• Compromissione iniziale del dominio con credenziali di Domain Admin (simulata via Mimikatz open source o Rubeus open source).
• Enumerazione del server AD FS con Get-AADIntADFSConfiguration.
• Esfiltrazione della chiave DKM tramite accesso LDAP al container CN=ADFS,CN=Microsoft,CN=Program Data.
• Generazione offline del token SAML su macchina attaccante.
• Autenticazione verso Microsoft 365, Azure Portal o applicazioni SaaS federate.

Per test più realistici su piattaforme cloud, ROADtools (open source) di Dirk-jan Mollema permette di enumerare Entra ID post-compromissione con roadrecon gather e verificare i privilegi effettivi dell'identità forgiata. Su ambienti AWS federati, il token SAML può essere consumato tramite aws sts assume-role-with-saml per pivotare da identità Entra a ruoli IAM cloud.

È fondamentale che l'esercizio si svolga in un tenant di laboratorio dedicato: la rotazione del certificato di firma AD FS in produzione ha impatti operativi rilevanti e va coordinata con il blue team. Documentare tutti gli ImmutableID utilizzati facilita la pulizia post-test.

La detection di token SAML forgiati è particolarmente insidiosa perché il token, dal punto di vista crittografico, è perfettamente valido. La strategia difensiva DET0148 si basa quindi su correlazioni comportamentali e sull'analisi di anomalie nei claim, non sulla verifica della firma.

Sul piano dell'Identity Provider (AN0418), l'indicatore principale è l'assenza degli eventi di autenticazione Kerberos che dovrebbero precedere una asserzione SAML legittima. In un flusso normale, un utente che accede a un'app federata genera prima un TGS request (EventCode 4769) sul domain controller e successivamente eventi 1200 (token issued) e 1202 (token validated) sul server AD FS. Un token forgiato offline produce direttamente l'evento 1200 senza il corrispondente 4769, oppure viene consumato dal service provider senza alcuna traccia lato IdP. Le log source chiave sono azure:signinlogs e WinEventLog:Security, integrate con i log ADFS.

Parametri di tuning suggeriti dalla strategia:

• TokenLifetimeThreshold: alert quando la durata del token supera l'ora standard, indicativo di un AccessTokenLifetime manipolato.
• TrustedIssuerList: whitelist dei thumbprint dei certificati di firma legittimi; qualsiasi issuer non presente è sospetto.
• ClaimAnomalyThreshold: soglia sul numero di claim privilegiati inusuali (es. Global Admin per un account normalmente standard user).

In ambienti SaaS (AN0421), il segnale più forte è un login federato che risulta MFA satisfied via previous session o by claim in the token senza che l'utente abbia effettivamente completato una challenge MFA recente. La correlazione geografica (GeoVelocityThreshold) rileva lo stesso assertion ID SAML consumato da IP in continenti diversi entro pochi minuti.

Su Office Suite (AN0422), monitorare accessi a mailbox privilegiate (executive, legal, finance) via m365:exchange senza un evento di login interattivo precedente entro la finestra di validità del token. Il replay dello stesso token verso Outlook, SharePoint e Teams in rapida successione è pattern tipico di ricognizione post-forgery.

In ambienti IaaS (AN0419), un AssumeRoleWithSAML su AWS CloudTrail senza una corrispondente asserzione loggata dall'IdP di riferimento è un red flag critico, specialmente se il ruolo assunto ha permessi amministrativi.

I falsi positivi principali derivano da applicazioni legacy che estendono legittimamente la durata dei token, da test di penetration autorizzati e da migrazioni di tenant. Mantenere un baseline dei pattern di autenticazione per ogni applicazione federata è essenziale per ridurre il rumore.

L'analisi forense di un incidente T1606.002 è complessa perché il materiale crittografico compromesso spesso non lascia tracce evidenti al momento del furto, e i token forgiati sono generati offline. L'investigazione deve quindi ricostruire due timeline parallele: quella dell'esfiltrazione del certificato e quella dell'utilizzo dei token.

Sul server AD FS, gli artefatti prioritari sono:

• Log operativi in Applications and Services Logs\AD FS\Admin e AD FS Tracing\Debug se il tracing è abilitato.
• Eventi Security 4662 (operazioni su oggetti AD) che tracciano accessi al container DKM in CN=ADFS,CN=Microsoft,CN=Program Data,DC=domain,DC=com.
• Evento 307 (configurazione modificata) e 510 (dettagli configurazione) nel log ADFS/Admin.
• Esportazioni sospette del certificato loggate come 1000 o 1102 con riferimento al thumbprint del token-signing certificate.

La mitigazione M1047 raccomanda di abilitare l'Advanced Auditing su AD FS tramite Group Policy Object, attivando sia Success che Failure nell'AD FS Management snap-in e il Audit Application Generated events. Senza questa configurazione, molti eventi critici non vengono generati e l'investigazione retrospettiva diventa quasi impossibile.

Sul lato Entra ID / Microsoft 365, i Unified Audit Log e i Sign-in Logs mostrano per ogni autenticazione il campo AuthenticationDetails con l'indicazione del metodo. Token forgiati appaiono spesso con AuthenticationMethod: Federated e MFA: satisfied by claim in the token senza record MFA correlato in Azure AD. Il campo IssuerType e il TenantId dell'issuer vanno confrontati con la configurazione federata legittima.

La timeline della SolarWinds Compromise (C0024) illustra il pattern: APT29 ha esfiltrato i certificati di firma da server AD FS compromessi tramite l'accesso privilegiato ottenuto via backdoor SUNBURST, poi ha utilizzato i token forgiati per mesi accedendo a mailbox Exchange Online e SharePoint di target selezionati, con particolare attenzione a evitare mailbox già monitorate.

Artefatti di rete utili includono capture del traffico verso endpoint federati (/adfs/ls/ e /adfs/services/trust/) e, sul client, cache di token in %LOCALAPPDATA%\Microsoft\TokenBroker e nei WAM plugin. La correlazione tra thumbprint del certificato osservato nelle asserzioni SAML consumate e i thumbprint storici dei certificati AD FS (recuperabili dai backup di AdfsFarmInformation.xml) permette di distinguere token legittimi da forgiati anche a posteriori.

La procedura di remediation richiede, come indicato in M1015, la doppia rotazione rapida del certificato di firma AD FS per invalidare qualsiasi token generato con il materiale compromesso.

Il panorama di threat intelligence relativo a T1606.002 è dominato da un singolo attore documentato e da una singola campagna di portata storica, ma le implicazioni geopolitiche e tecniche sono estese.

La SolarWinds Compromise (C0024), attribuita dai governi di Stati Uniti e Regno Unito nell'aprile 2021 al Servizio di Intelligence Estero russo (SVR) e operativamente riconducibile ad APT29 (noto anche come Cozy Bear, The Dukes, e nelle prime fasi dell'incident come UNC2452, NOBELIUM, Dark Halo, SolarStorm), rappresenta il caso di studio definitivo per la forgiatura di token SAML. L'operazione, attiva da agosto 2019 a gennaio 2021 e scoperta a metà dicembre 2020, ha combinato una supply chain injection nel processo di build di SolarWinds Orion con tecniche di credential access avanzate, tra cui password spraying, token theft, abuse di API e appunto Golden SAML.

Dei circa 18.000 clienti pubblici e privati raggiunti dall'update malevolo, un numero significativamente inferiore ha subito attività follow-on da parte di APT29. Le vittime confermate includono agenzie governative statunitensi (Treasury, Commerce, State Department, DHS), aziende di consulenza, tecnologia, telecomunicazioni e organizzazioni in Nord America, Europa, Asia e Medio Oriente. Il pattern operativo prevedeva la compromissione dei server AD FS, l'esfiltrazione dei certificati di firma e la generazione di token SAML per accedere selettivamente a Microsoft 365, con priorità su mailbox di executive, personale legale e team di sicurezza.

Il profilo TTP di APT29 in questa campagna evidenzia un livello di sofisticazione operativa raramente osservato: OPSEC estrema, tempi di dwell superiori a un anno, uso di infrastruttura dedicata per singolo target e cura nell'evitare artefatti che potessero attivare telemetria EDR. La scelta di forgiare token SAML riflette un approccio strategico: bypassare completamente MFA, evitare interazioni con Kerberos loggabili sui domain controller e ottenere persistenza cloud indipendente dalla postura di sicurezza on-premise della vittima.

Sul piano degli strumenti, AADInternals (S0677) resta il tool pubblico di riferimento sia per attività offensive che per validazioni difensive. Sebbene nato come progetto di ricerca, la sua completezza funzionale lo rende adottato anche da attori meno sofisticati, con un abbassamento della barriera d'ingresso per attacchi Golden SAML.

Il trend osservato successivamente alla SolarWinds Compromise vede un crescente interesse degli attori state-sponsored verso attacchi all'identity layer e alle federation trust, considerati choke point strategici. Le organizzazioni con AD FS on-premise federato a Entra ID rimangono target prioritari, mentre la migrazione a pure cloud identity riduce ma non elimina la superficie di attacco.

Dati tecnici e mappature da MITRE ATT&CK (tecnica T1606.002, mitigazioni M1015, M1018, M1026, M1047, detection strategy DET0148 con analytics AN0418-AN0422). Software di riferimento AADInternals (S0677). Campagna documentata SolarWinds Compromise (C0024) attribuita ad APT29/SVR. Insight difensivi derivati da MITRE D3FEND per la mappatura dei digital artifacts. Alcuni dettagli su procedure operative e sintassi dei tool provengono da conoscenza professionale di cybersecurity verificabile su repository pubblici e documentazione ufficiale dei prodotti citati.