Zero-day AD FS CVE-2026-56155: un 7.8 che compra un Golden SAML

Il 14 luglio 2026 Microsoft ha rilasciato la correzione per CVE-2026-56155, una elevation of privilege in Active Directory Federation Services. CVSS 3.1 base score 7.8. Vettore di attacco: locale. Severity assegnata da Microsoft: Important. Scope: Unchanged. Lo stesso giorno CISA l'ha inserita nel catalogo Known Exploited Vulnerabilities con scadenza di remediation al 28 luglio, perché è già usata negli attacchi. Ogni numero di questo paragrafo suggerisce di rimandarla alla prossima finestra di manutenzione. Ognuno di quei numeri sta misurando la cosa sbagliata. Un server AD FS non è un server che per caso custodisce una chiave privata: è una chiave privata che per caso gira su un server. E "privilege escalation locale" su quella macchina è l'unica frase della catena d'attacco che conta davvero.

Cosa è davvero CVE-2026-56155

La descrizione tecnica è scarna. Secondo NVD si tratta di CWE-1220 — insufficient granularity of access control — e "allows an authorized attacker to elevate privileges locally". Il vettore CVSS è AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H: un attaccante che ha già accesso a basso privilegio sulla macchina, senza interazione utente, ottiene impatto pieno su confidenzialità, integrità e disponibilità. Le build interessate vanno da Windows Server 2012 a Windows Server 2025, più Windows 10 1607 e 1809.

Due dettagli della disclosure contengono più segnale del punteggio.

Il primo è chi ha segnalato. Secondo la copertura del Patch Tuesday di BleepingComputer, CVE-2026-56155 è accreditata a Jeremy Kingston e Scott Clark del Detection and Response Team di Microsoft. DART è l'unità di incident response. I bug accreditati a DART non nascono di norma da un ricercatore che fa fuzzing in laboratorio: nascono dentro la rete di qualcuno, durante la bonifica. Il che è coerente con l'inserimento in KEV come "sfruttata" fin dal giorno zero. Microsoft non ha pubblicato alcun dettaglio sulla metodologia di sfruttamento.

Il secondo è ciò che nota l'analisi di Rapid7: AV:L implica che l'attaccante "would need an existing toehold on the target system" da concatenare con l'escalation. È una precondizione reale, ed è il motivo per cui il base score è 7.8 e non 9.8. È anche la precondizione che ogni campagna di phishing, ogni credenziale VPN rubata e buona parte degli oltre 620 CVE corretti da Microsoft questo mese esistono per soddisfare. Scambiare un prerequisito per una mitigazione è esattamente il modo in cui questa vulnerabilità finisce dietro a un 9.8 più rumoroso su una macchina contro cui nessuno fa federazione.

Perché una escalation locale su AD FS non è un problema locale

AD FS è un identity provider SAML. Il suo mestiere è asserire, crittograficamente, che un utente è chi dichiara di essere, verso ogni applicazione che federa contro di lui: Microsoft 365, AWS, Salesforce, vSphere, qualunque cosa l'estate consideri affidabile. L'asserzione è firmata con il token-signing certificate di AD FS. I relying party non verificano l'utente. Verificano la firma.

Il controllo amministrativo del server AD FS espone quella chiave di firma. E una chiave di firma in mani sbagliate ha un nome, un proof-of-concept e nove anni di storia.

CyberArk Labs ha pubblicato la tecnica Golden SAML il 21 novembre 2017, rilasciando insieme il PoC shimit. I requisiti sono minimi: la chiave privata di token-signing è l'unico ingrediente obbligatorio. Con quella, un attaccante conia asserzioni SAML per qualsiasi utente, con qualsiasi privilegio, verso qualsiasi servizio che usi SAML 2.0 per il SSO — inclusi utenti che non esistono. I due punti di CyberArk che dovrebbero riscrivere la triage di questo CVE:

• La tecnica funziona anche con la 2FA attiva, perché l'asserzione forgiata è il risultato del processo di autenticazione. Non resta nulla da sfidare: il token dichiara che l'MFA è già avvenuta.
• Cambiare la password di un utente non ha effetto sul SAML generato. La forgiatura sta al livello della federazione, non a quello delle credenziali.

E la proprietà di persistenza: la chiave privata di token-signing "is not renewed automatically". Una chiave rubata oggi resta valida finché qualcuno non la sostituisce deliberatamente.

Ripercorriamo la catena all'indietro. Scope: Unchanged, dice il vettore — componente compromesso e componente impattato coincidono. Ma il componente impattato è il trust anchor di ogni applicazione federata dell'infrastruttura. La metrica di scope è tecnicamente corretta e praticamente rovesciata. Il punteggio descrive una macchina Windows. Il raggio d'azione è il tessuto delle identità.

Il precedente non è ipotetico

Questo è il playbook di SolarWinds. Nelle intrusioni del 2020, attribuite dal governo statunitense all'SVR russo — l'attore tracciato come APT29, NOBELIUM e Midnight Blizzard — gli operatori hanno fatto il pivot dagli appigli on-premises verso il cloud rubando i token-signing certificate da AD FS e forgiando token per utenze privilegiate. CISA ha documentato il problema di rilevamento nell'advisory AA21-008A, Detecting Post-Compromise Threat Activity in Microsoft Cloud Environments, complementare all'alert principale su SolarWinds.

Il motivo per cui quell'advisory è dovuto esistere è la parte da interiorizzare:

Il token forgiato non è un falso in alcun senso che il relying party possa verificare. È un'asserzione ben formata e correttamente firmata dall'identity provider che l'applicazione è stata configurata a considerare affidabile. L'applicazione non viene ingannata. L'applicazione ha ragione. La fiducia che le è stata imposta è semplicemente finita in mano a qualcun altro.

Gli operatori hanno lavorato dentro Microsoft 365 senza lasciare tracce di autenticazione on-premises, perché l'autenticazione on-premises non è mai avvenuta. È questa la forma di ciò che CVE-2026-56155 mette a portata di chiunque possieda già un appiglio a basso privilegio su un server di federazione.

Cosa la patch non risolve

Applicate l'aggiornamento di luglio e il percorso di escalation si chiude. Nient'altro.

Se la chiave ha lasciato l'edificio prima della patch, avete chiuso una porta di cui l'attaccante non ha più bisogno. I token forgiati continuano a validare, perché il certificato che li firma è ancora il certificato di cui i vostri relying party si fidano. È la stessa proprietà che fa fallire le bonifiche da credenziali rubate e da webshell piantate: la vulnerabilità e la persistenza sono due oggetti distinti, e solo uno dei due viene toccato da una patch.

CISA sembra volerlo dire con inconsueta franchezza. La required action della voce KEV cita BOD 26-04 e i Forensics Triage Requirements: standard. Ma il campo note linka anche la guida Microsoft alla dismissione di AD FS. Una voce KEV il cui materiale di riferimento include le istruzioni per rimuovere il prodotto non è un messaggio sottile. La documentazione Microsoft spinge da anni i clienti in federazione verso Entra ID con password hash sync o autenticazione basata su certificati; e i passi finali della guida di dismissione impongono di re-imagare i server AD FS con formattazione completa del disco e di ripulire il DN CertificateSharingContainer. Quei passi esistono per via di ciò che la macchina custodisce.

Il problema di detection: un login senza autenticazione

Qui sta l'asimmetria che rende Golden SAML degno di un articolo e non di un ticket di patching. Un token forgiato produce un login applicativo riuscito con nessun evento di autenticazione corrispondente sull'identity provider — perché l'identity provider non è mai stato coinvolto.

La ricerca di threat hunting su AD FS di Hunters ne fa il segnale primario: un login registrato nei log del relying party senza un corrispondente evento AD FS 1200 (che rappresenta un'autenticazione effettiva contro AD FS) indica che il token è probabilmente forgiato. Non state cercando un evento anomalo. State cercando un evento assente, e solo correlando due fonti di log che quasi nessuno mette in join.

Livello	Come appare un accesso legittimo	Come appare un accesso forgiato
Server AD FS (evento 1200)	Token emesso, utente autenticato	Niente. Nessuna traccia.
Relying party / app cloud	Accesso federato riuscito	Accesso federato riuscito — identico
Sistema MFA	Challenge emessa e superata	Nessuna challenge; il token dichiara l'MFA già avvenuta
Validazione della firma	Valida	Valida — stessa chiave, autenticamente corretta
Rete	Sessione dalla popolazione client attesa	Sessione da dove si trova l'attaccante

Quattro righe su cinque sono identiche o strutturalmente cieche. Il livello identity non può dirvi la differenza, per costruzione: sta facendo esattamente ciò per cui è stato progettato. L'ultima riga è dove la differenza esiste.

Remediation

Trattatela come due lavori distinti: chiudere il percorso di escalation, poi stabilire se la chiave è già uscita. È il secondo a decidere se avete finito.

1. Sono affetto?

Rientrate nel perimetro se eseguite il ruolo AD FS su una qualsiasi build supportata di Windows Server (dal 2012 al 2025). Verificate presenza del ruolo e installazione dell'update di luglio:

# Questa macchina è un federation server?
Get-WindowsFeature ADFS-Federation | Where-Object Installed

# Conferma che il cumulative update del 14 luglio 2026 sia installato
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5 HotFixID, InstalledOn

# Enumerare i relying party: è il vostro raggio d'azione, inventariatelo adesso
Get-AdfsRelyingPartyTrust | Select-Object Name, Identifier, Enabled

Attenzione al terzo comando. Prima di decidere quanto sia urgente, enumerate cosa si fida di quella macchina. Quella lista è la severity reale.

2. Patch — versioni corrette esatte

Installate il cumulative update del 14 luglio 2026 per la vostra build di Windows Server. CVE-2026-56155 è corretta negli aggiornamenti Windows e Windows Server rilasciati quel giorno, che coprono Server 2012, 2012 R2, 2016, 2019, 2022 e 2025 incluse le installazioni Server Core, più Windows 10 1607 e 1809. Prendete il numero di KB per la vostra build specifica dalla voce del Security Update Guide Microsoft per CVE-2026-56155 e non da un riassunto di terze parti: la KB cambia da build a build, e un numero sbagliato significa un server non patchato che risulta a posto. La scadenza KEV per le agenzie federali è il 28 luglio 2026.

3. Non potete patchare subito? Controlli compensativi

• Trattate i server AD FS come Tier 0. Sono equivalenti a un domain controller, perché comprometterne uno produce lo stesso risultato. Accesso amministrativo solo da privileged access workstation; nessun login generalista, niente navigazione, niente posta.
• Togliete l'appiglio. AV:L è tutta la precondizione. Rimuovete i local admin, rimuovete i diritti di login interattivo, rimuovete ogni servizio che non deve stare su un federation server.
• Mai esporre direttamente il server AD FS. L'accesso passa dal WAP; il federation server non ha alcun motivo di ricevere traffico da internet.
• Mettete un alert sulla lista dei relying party trust. Un relying party che non avete creato voi è un attaccante che federa la propria applicazione contro il vostro identity provider.

4. Caccia alla compromissione

Assumete che l'appiglio ci fosse. Mappatura MITRE ATT&CK:

• T1552.004 / T1649 — furto o forgiatura di certificati di autenticazione. L'obiettivo centrale. Cercate query LDAP inattese verso i domain controller da contesti di processo sconosciuti sul server AD FS: è la firma dell'estrazione della DKM tramite tooling come ADFSDump, secondo la ricerca di Hunters.
• T1078 — valid accounts. Logon type non di servizio contro il service account di AD FS. Quell'account dovrebbe eseguire solo logon type 5 (service) nell'evento 4624. Un logon type 10 (RDP) sul service account di AD FS è un finding, non una curiosità.
• T1606.002 — forge web credentials: SAML tokens. La tecnica Golden SAML in sé. La query che conta: eventi di accesso su relying party e cloud senza evento AD FS 1200 corrispondente. Se non avete mai messo in join quelle due fonti, non siete mai stati in grado di rilevarlo.
• T1068 — exploitation for privilege escalation. Il CVE stesso. Modifiche ai privilegi locali sul federation server nella finestra di sfruttamento.
• T1550.001 — application access tokens. Accessi ad app federate da ASN, geografie o popolazioni client mai viste prima, per utenze che non mostrano alcuna autenticazione on-premises.

Estraete i log eventi di AD FS e i sign-in log cloud sull'intera finestra, fino alla data in cui l'appiglio potrebbe plausibilmente essere stato stabilito — non solo dal Patch Tuesday in poi.

5. Eradicare e verificare

Se emergono indizi che la chiave fosse accessibile a un attaccante, la patch è il primo di cinque passi:

1. Ruotate il token-signing certificate — e poi ruotatelo di nuovo. La remediation standard per Golden SAML è la doppia rotazione, perché AD FS pubblica un certificato secondario per il rollover e una rotazione singola può lasciare nell'insieme dei validi una chiave che l'attaccante possiede ancora. Ruotate, lasciate che i relying party assorbano i nuovi metadata, poi ruotate una seconda volta così chi detiene un vecchio certificato resta tagliato fuori. Verificate che ogni relying party abbia consumato i nuovi metadata: uno che non l'ha fatto è insieme un disservizio e un buco.
2. Re-imagate il server. La guida di dismissione Microsoft prescrive la formattazione completa del disco, e per un buon motivo: non potete dimostrare pulita una macchina che ha custodito una chiave privata rubata.
3. Auditate relying party trust e claim rule cercando aggiunte o modifiche. Una claim rule malevola può concedere ruoli elevati a un'identità scelta dall'attaccante senza alcuna forgiatura di token.
4. Ruotate le credenziali raggiungibili dalla macchina AD FS, incluso il service account e il materiale della chiave DKM.
5. Verificate dopo la patch, non prima. Un relying party abusivo, una claim rule modificata e un certificato copiato sopravvivono tutti all'aggiornamento.

Se la vostra infrastruttura può abbandonare del tutto la federazione, questo CVE è un ragionevole forcing function — che è, a quanto pare, anche la lettura di CISA.

Dove si colloca Zero Hunt

La domanda operativa dell'articolo non è "è patchato". È: la chiave è uscita, e potete dimostrarlo? Il livello identity non può rispondere, perché un token forgiato è indistinguibile da uno vero a ogni livello che verifichi firme. Quattro righe su cinque della tabella sono cieche per costruzione. Quella che non lo è, è la rete.

È esattamente ciò per cui è costruita l'AI Traffic Analysis di Zero Hunt. Un modello di deep learning proprietario addestrato su miliardi di sequenze PCAP gira sulla GPU dell'appliance con quattro inference head paralleli — traffico sospetto, classificazione malware, identificazione del tipo di attacco, fingerprinting applicativo — con un baseline di 2.7+ Gbit/s, interamente on-prem. Non chiede ad AD FS se ha emesso un token, perché AD FS non lo sa. Osserva cosa il token fa: sessioni federate che compaiono da ASN e fingerprint client mai visti nel baseline, per utenze prive di traffico di autenticazione verso il federation server; le query LDAP da un contesto di processo inatteso che precedono l'estrazione della DKM; l'asserzione riprodotta contro un relying party mentre accade, non nel digest SIEM del mattino dopo. Il token forgiato è crittograficamente perfetto. Il traffico che lo trasporta non è il traffico che la vostra rete produce normalmente, e quella discrepanza esiste sul filo a prescindere da quanto sia corretta la firma.

La metà complementare è validare la precondizione. AV:L sta reggendo un peso enorme dentro quel 7.8, e la risposta onesta a "un attaccante ha un appiglio che arriva a local admin sul nostro federation server?" non si ricava da un vettore CVSS o da un report di patching: è una domanda empirica sul vostro ambiente. Lo swarm di 10 agenti di Zero Hunt (Recon, Exploit, Web, Credential, Post-Exploit, Pivot, Tactic, Report, sotto un AI Controller) scrive codice d'attacco per-target con un LLM locale invece di pescare un PoC, lo esegue in container Docker effimeri con hardening gVisor opzionale, e backtesta ogni skill nell'AI Gym prima che tocchi la produzione. Puntato su un federation server in premessa di assumed breach, gli agenti Post-Exploit e Pivot rispondono alla domanda che il punteggio non può: partendo dall'appiglio che realmente esiste nella vostra infrastruttura, il percorso verso la chiave di firma si chiude davvero? E ogni finding è firmato ECDSA con chain-of-custody, mappato sui 32 framework di compliance: così "abbiamo verificato che la chiave non fosse raggiungibile dopo la patch" diventa un artefatto da consegnare a un auditor, non un'affermazione da sostenere.

Patchare CVE-2026-56155 richiede un pomeriggio. Sapere se è servito richiede prove.