🛡️ Executive Summary
- Mandiant dimostra una tecnica che recupera la chiave privata di firma di ADFS direttamente dal Machine DPAPI, evitando l’accesso alla memoria di LSASS.
- La tecnica sfrutta una deriva di configurazione causata dalla rotazione manuale dei certificati quando AutoCertificateRollover è disabilitato.
- Una chiave compromessa consente attacchi Golden SAML, con impersonificazione di utenti privilegiati e bypass di MFA e Accesso Condizionale.
I ricercatori di Mandiant hanno illustrato una nuova tecnica che modifica il modo in cui può essere compromessa un’infrastruttura Active Directory Federation Services (ADFS). Il metodo consente infatti di recuperare la chiave privata di firma attiva direttamente dal Machine DPAPI, evitando le tecniche tradizionali che prevedono il dumping della memoria del processo LSASS o l’interazione con il servizio ADFS in esecuzione. La scoperta nasce da un’attività di red teaming e interessa un particolare scenario di configurazione piuttosto comune negli ambienti enterprise, dove la rotazione automatica dei certificati è stata disabilitata a favore di una gestione manuale. In queste condizioni un attaccante con privilegi SYSTEM sul server ADFS può ottenere la chiave utilizzata per firmare le asserzioni SAML, aprendo la strada a sofisticati attacchi Golden SAML contro Microsoft Entra ID, Microsoft 365 e tutte le applicazioni federate che si affidano ai token emessi dal servizio.
Cosa leggere
La deriva di configurazione che apre la strada all’attacco
La tecnica sfrutta una configurazione specifica di ADFS nella quale il parametro AutoCertificateRollover è impostato su False. In molti ambienti aziendali questa scelta viene adottata per mantenere un controllo diretto sulla sostituzione dei certificati di firma, ma può introdurre una discrepanza tra la configurazione del servizio e il database interno Windows Internal Database (WID). Quando il certificato viene sostituito manualmente senza aggiornare correttamente tutte le componenti di ADFS, il database conserva informazioni riferite al certificato precedente mentre il servizio utilizza già la nuova chiave privata. Questa condizione viene normalmente segnalata attraverso l’Event ID 385, che rappresenta un importante indicatore di configurazione non allineata. Secondo Mandiant, proprio questa situazione consente di recuperare la chiave attiva senza dover estrarre informazioni direttamente dalla memoria del processo ADFS.
Machine DPAPI custodisce la chiave di firma
Il cuore della tecnica risiede nel funzionamento del Machine Data Protection API (Machine DPAPI), il sistema di protezione utilizzato da Windows per conservare segreti crittografici associati al computer anziché a un singolo utente. La chiave privata di firma di ADFS viene memorizzata nel keystore situato all’interno del percorso C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys e risulta protetta dal segreto DPAPI_SYSTEM conservato all’interno del sottosistema LSA insieme alle master key associate al SID S-1-5-18, corrispondente all’account Local System. Diversamente dalla variante User DPAPI, la protezione Machine DPAPI continua a funzionare indipendentemente dai riavvii del sistema, dalla sostituzione dell’account di servizio o dalla rotazione degli account gMSA, garantendo continuità operativa ma aumentando contemporaneamente l’esposizione della chiave a qualsiasi processo che riesca a ottenere privilegi SYSTEM sul server.
SharpDPAPI permette di recuperare la chiave
Una volta ottenuti privilegi amministrativi sul sistema, strumenti come SharpDPAPI, utilizzato con il parametro /machine, consentono di enumerare le chiavi presenti nel Machine DPAPI e procedere alla loro decifratura. L’operazione non richiede il dumping della memoria di LSASS, una delle attività maggiormente monitorate dalle moderne soluzioni Endpoint Detection and Response (EDR), né l’accesso diretto al processo di ADFS. Questa caratteristica riduce sensibilmente le possibilità di rilevamento dell’attacco, poiché molte piattaforme di sicurezza concentrano ancora gran parte delle proprie regole di detection proprio sulle tecniche di estrazione della memoria o sull’accesso anomalo ai processi sensibili. L’approccio illustrato da Mandiant dimostra invece che un attaccante può ottenere lo stesso risultato sfruttando esclusivamente i meccanismi previsti dal sistema operativo per la gestione delle chiavi locali.
Dal recupero della chiave agli attacchi Golden SAML
Il possesso della chiave privata di firma consente la creazione di asserzioni SAML completamente arbitrarie ma perfettamente valide dal punto di vista crittografico. I token generati vengono accettati senza ulteriori verifiche da Microsoft Entra ID e da tutte le applicazioni federate che si affidano ad ADFS per l’autenticazione. Un aggressore può quindi impersonare qualsiasi identità presente nell’organizzazione, inclusi gli amministratori globali, ottenendo accesso diretto ai servizi cloud e alle applicazioni aziendali senza dover conoscere password o superare sistemi di autenticazione multifattore (MFA). Anche le policy di Accesso Condizionale basate esclusivamente sull’identità risultano inefficaci, poiché il token viene considerato autentico dall’infrastruttura di federazione. Il risultato è un classico attacco Golden SAML, reso ancora più pericoloso dal fatto che non richiede tecniche di compromissione particolarmente rumorose.
Server ADFS sempre più centrali nella sicurezza Tier 0
La ricerca di Mandiant conferma ancora una volta come i server ADFS debbano essere considerati componenti Tier 0, allo stesso livello dei Domain Controller. Chiunque riesca a ottenere privilegi SYSTEM su questi sistemi acquisisce infatti la possibilità di compromettere l’intera infrastruttura di autenticazione federata. Il vantaggio operativo offerto dal Machine DPAPI, progettato per garantire resilienza durante cambi di account di servizio, riavvii o aggiornamenti, si trasforma in un elemento di rischio quando il server viene compromesso localmente. La tecnica dimostra inoltre come l’eliminazione della dipendenza da LSASS renda più complesso individuare le attività dell’attaccante attraverso gli strumenti tradizionali di monitoraggio della memoria.
Come mitigare il rischio secondo Mandiant
Per ridurre l’esposizione, Mandiant raccomanda innanzitutto di verificare la configurazione di ADFS mediante il comando Get-AdfsProperties, controllando che il parametro AutoCertificateRollover sia configurato correttamente rispetto alle procedure operative adottate dall’organizzazione. Quando la gestione manuale dei certificati è indispensabile, la sostituzione deve avvenire utilizzando il comando Set-AdfsCertificate, evitando di limitarsi all’installazione del nuovo certificato nello store LocalMachine\My, pratica che può generare la deriva di configurazione descritta dai ricercatori. È inoltre consigliabile monitorare sistematicamente la comparsa dell’Event ID 385, che può indicare la presenza di certificati non correttamente sincronizzati con il database di ADFS. La misura più efficace rimane comunque l’adozione di un Hardware Security Module (HSM), che impedisce la memorizzazione software della chiave privata e rende impossibile il recupero attraverso il Machine DPAPI. Insieme a un rigoroso controllo degli accessi privilegiati e a un monitoraggio continuo dei server ADFS, queste contromisure consentono di ridurre significativamente il rischio di compromissione delle chiavi di firma e degli attacchi Golden SAML che potrebbero derivarne.
Iscriviti alla Newsletter
Non perdere le analisi settimanali: Entra nella Matrice Digitale.
Matrice Digitale partecipa al Programma Affiliazione Amazon EU. In qualità di Affiliato Amazon, ricevo un guadagno dagli acquisti idonei. Questo non influenza i prezzi per te.
