Compromissione dell'identity provider — il playbook di incident response Entra ID / Okta

Usa questo playbook quando ci sono indicatori credibili che sia compromesso il control plane dell'identità stesso — non un singolo end-user vittima di phishing, ma la directory che emette i token di tutti. Le condizioni di trigger includono:

• Un account amministrativo del tuo tenant Entra ID, org Okta, deployment ADFS o Ping è confermato o fortemente sospettato come compromesso.
• Un reset MFA o password dell'help desk è confermato come oggetto di social engineering (il pattern Scattered Spider — voice phishing all'help desk IT per resettare l'MFA, documentato nell'advisory CISA AA23-320A).
• Cambi anomali di federazione o applicazioni compaiono nell'audit log: un nuovo identity provider federato, una nuova app registration o service principal con credenziali fresche, una nuova assegnazione di ruolo admin, o un consent grant OAuth illecito.
• Furto o replay di token è osservato — incluso l'abuso di classe Actor-token CVE-2025-55241 che bypassa MFA e Conditional Access.
• Enumerazione di massa delle applicazioni SSO da un singolo principal.

NON usare questo playbook per: la compromissione di un singolo account end-user senza accesso al piano IdP (esegui IR standard di account-compromise), malware su endpoint senza pivot d'identità, o una compromissione di Active Directory solo on-prem senza esposizione di IdP cloud (sovrapposta ma distinta — lì dominano il tiering AD e l'hunting di DCSync).

Una compromissione IdP corre contro due clock indipendenti, e devi guidarli entrambi dal minuto zero.

Il clock di containment. Mentre l'attaccante tiene il piano d'identità, il dwell time si converte direttamente in espansione laterale — ogni minuto è una nuova app entrata, un nuovo token coniato, un nuovo meccanismo di persistenza piantato. Qui non c'è deadline statutaria; la deadline è operativa. Target: tutte le sessioni e i token degli account privilegiati revocati entro la prima ora, sfratto completo della persistenza entro 24 ore.

I clock di notifica. Nel momento in cui stabilisci che dati personali erano accessibili o che un servizio essenziale/importante è impattato, i clock regolatori scattano — e sono più corti di quanto richiederà l'eradication:

• DORA (entità finanziarie): notifica iniziale entro 4 ore dalla classificazione — vedi il playbook DORA 4h/72h/1-mese.
• NIS2 (entità essenziali/importanti): early warning entro 24 ore — vedi la timeline incidenti NIS2 Title 13.
• GDPR: notifica all'autorità di controllo entro 72 ore dalla conoscenza, dove è probabile una violazione di dati personali.

Una compromissione IdP quasi sempre qualifica come violazione di dati personali, perché l'attaccante deteneva le chiavi di sistemi contenenti dati personali — stabilisci la postura di notifica in parallelo al containment, non dopo.

Obiettivo: fermare il conio di token e tagliare l'accesso live dell'attaccante senza distruggere le evidenze che serviranno per i report di notifica.

Preserva prima di cambiare. Esporta sign-in log (interattivi e non interattivi), directory audit log e risk detection *per primi* — i cambi di remediation di massa inondano l'audit log e parte della telemetria ha retention breve.

Checklist di containment:

• Revoca sessioni e refresh token prima di resettare le password. Un reset password da solo non invalida un refresh token già emesso né un token di classe Actor. In Entra, revoca le sessioni di sign-in e appoggiati a Continuous Access Evaluation; in Okta, azzera le sessioni utente e revoca i token OAuth. Fallo per gli account noti come compromessi *e* per ogni account privilegiato.
• Resetta le credenziali e ri-enrolla MFA phishing-resistant (FIDO2 / passkey / basata su certificato) per tutti gli account privilegiati. Non ri-fidarti di SMS o push — sono esattamente ciò che è stato social-engineered.
• Congela i flussi di reset dell'help desk ad alto rischio. Sospendi i reset MFA e password via telefono per account privilegiati e VIP; richiedi conferma out-of-band in presenza o verificata dal manager per la durata dell'incidente.
• Disabilita la persistenza ovvia aggiunta durante la finestra: qualsiasi identity provider federato nuovo (federazione inbound/Org2Org), nuove app registration o service principal, e nuove assegnazioni di ruolo admin. Annota i timestamp prima di disabilitare.
• Definisci il blast radius: quale tenant/org, quali account admin, quali applicazioni il principal compromesso poteva raggiungere.

Caveat: revocare le sessioni non ferma un abuso di emissione token a livello di tenant (la classe Actor-token). Se quel vettore è sospettato, la remediation deve avvenire a livello di configurazione del tenant e di API legacy, non a livello di sessione utente.

Obiettivo: rimuovere ogni backdoor che l'attaccante ha piantato così che revocare le sessioni ponga effettivamente fine all'accesso. Questa è la fase che i team saltano, ed è il motivo per cui le intrusioni IdP ricorrono in pochi giorni. Un attaccante che ha tenuto la directory non si affida all'account che hai appena resettato — lascia un rientro self-service.

Caccia e rimuovi, in ordine di priorità:

• Federazione rogue. Un nuovo identity provider federato o una federazione di dominio permette all'attaccante di coniare i propri token validi. Scattered Spider specificamente aggiunge un IdP federato e attiva l'account linking per elevarsi dentro il tenant SSO. Rivedi ogni trust relationship; rimuovi qualsiasi aggiunta durante la finestra.
• App registration e service principal. Enumera le app con client secret o certificati aggiunti durante la finestra. Un service principal con la propria credenziale è una backdoor non-umana che sopravvive a ogni reset utente.
• Consent grant OAuth illeciti. Caccia le applicazioni con consenso recente, specialmente scope Graph/API ad alto privilegio concessi ad app controllate dall'attaccante.
• Indebolimento delle policy. Fai il diff delle policy Conditional Access / sign-on — cerca nuove esclusioni MFA, aggiunte di trusted-location, o policy disabilitate.
• Nuove identità privilegiate. Nuovi Global Admin, nuove assegnazioni di ruolo PIM-eligible, account break-glass abusati, nuovi inviti B2B/guest.
• Persistenza su mailbox (dove la compromissione ha fatto pivot sulla posta): regole inbox, forwarding, delega.

Ruota tutto ciò che l'attaccante poteva raggiungere: credenziali admin, client secret e certificati delle applicazioni, certificati di firma token (ADFS), e API token (Okta). Un segreto leggibile durante il dwell è un segreto compromesso.

Obiettivo: confermare l'eradication, ripristinare le operazioni normali sotto controlli irrigiditi, e chiudere il loop regolatorio.

• Conferma l'eradication via diff di configurazione. Confronta lo stato di federazione, app, service principal, ruoli e policy contro una baseline known-good. Se non puoi produrre una baseline known-good, quel gap è esso stesso un finding per le lessons-learned.
• Ruota i segreti downstream. Segreti, chiavi e token delle applicazioni raggiungibili *attraverso* l'IdP durante il dwell devono essere ruotati anche senza evidenza diretta del furto — l'attaccante ne aveva i mezzi.
• Ripristina i flussi dell'help desk sotto verifica irrigidita. Riabilita i reset solo con l'identity-proofing rafforzato che hai eretto in Fase A, reso permanente.
• Finalizza i report di notifica. Valuta quali dati personali erano accessibili per dimensionare la breccia, e fila o aggiorna le submission DORA / NIS2 / GDPR dalla singola base evidenze.
• Lessons learned e controlli: imponi MFA phishing-resistant, irrigidisci l'identity-proofing dell'help desk, allerta su ogni cambio di federazione/app-registration/consent, applica admin least-privilege con PIM, e attiva Continuous Access Evaluation. Poi prova lo scenario come tabletop così che la prossima response sia memoria muscolare.

Cattura ogni artefatto con i timestamp originali preservati e la chain-of-custody intatta, perché la stessa base evidenze alimenta le decisioni di containment *e* i report al regolatore:

• Sign-in log — interattivi e non interattivi — sulla finestra incidente più 30 giorni precedenti.
• Directory audit log — cambi di directory, creazione di app registration e service principal, cambi di configurazione federazione, assegnazioni di ruolo, consent grant.
• Export di risk detection / risky sign-in e qualsiasi telemetria di emissione token disponibile.
• Storico dei cambi di policy Conditional Access / sign-on.
• Ticket e registrazioni delle chiamate dell'help desk per l'evento di reset che ha abilitato l'initial access.
• Inventario di federazione, applicazioni e ruoli privilegiati — diff prima/dopo.
• Timeline incidente firmata — detection, ogni azione di containment, completamento eradication — senza edit manuali retroattivi.

Il problema strutturale che un IdP compromesso espone è che il log autoritativo è la superficie che l'attaccante controlla. CVE-2025-55241 emetteva token che bypassavano MFA e Conditional Access lasciando traccia di audit minima; il playbook di Scattered Spider indebolisce deliberatamente il logging. Una volta che il log dell'IdP è inaffidabile, l'unica ground truth rimasta è il traffico sul filo. La posizione ingegneristica che il team Zero Hunt prende qui è il rail di AI Traffic Analysis: un modello deep-learning proprietario con quattro inference head — traffico sospetto, classificazione malware, identificazione tipo di attacco, fingerprinting applicazioni — che gira sulla GPU dell'appliance senza callback cloud, così che l'attività anomala che un attaccante genera una volta che l'IdP è suo (replay di token contro applicazioni on-prem, autenticazione service-to-service inattesa, enumerazione di massa) emerge indipendentemente da ciò che l'audit log dell'IdP registra o non registra.

Cinque anti-pattern osservati tra organizzazioni peer che rispondono a compromissioni IdP:

1. Resettare la password ma non revocare le sessioni. Un refresh token rubato o un token di classe Actor continua a funzionare dopo un cambio password. La revoca di sessioni e token deve venire prima — il reset password è secondario.

2. Sfrattare l'utente, non la persistenza. Resettare l'account compromesso lasciando in piedi l'IdP federato rogue, il service principal dell'attaccante, o il consent grant illecito significa che l'attaccante rientra alle proprie condizioni in poche ore. La Fase B non è opzionale.

3. Fidarsi dell'audit log dell'IdP come completo. L'abuso di token che bypassa MFA e Conditional Access lascia traccia minima, e un attaccante con controllo della directory può indebolire il logging. Corrobora dal traffico di rete e dalla telemetria delle applicazioni downstream; non dichiarare l'eradication sulla forza di un audit log pulito da solo.

4. Lasciare aperto il path di reset dell'help desk. Se la via di vishing che ha concesso l'initial access è ancora viva, l'attaccante ri-compromette dalla stessa porta mentre stai ancora ripulendo. Congela i reset ad alto rischio per la durata.

5. Ri-fidarsi di MFA SMS o push dopo l'incidente. La fatigue da push-bombing e il SIM-swap battono esattamente i fattori appena abusati. Sposta gli account privilegiati su FIDO2 / passkey phishing-resistant prima di dichiarare chiuso l'incidente.

Una compromissione IdP raramente fa scattare un singolo obbligo. Poiché l'attaccante deteneva le chiavi di sistemi contenenti dati personali, è quasi sempre una violazione di dati personali, e per le entità regolate si somma ai regimi settoriali e orizzontali di cyber-incident:

• Entità finanziaria UE: reporting DORA art. 19 4h/72h/1-mese, più NIS2 Title 13 se anche entità essenziale/importante, più art. 33 GDPR (72h), più notifiche settoriali.
• Entità essenziale/importante UE (non-finanza): early warning NIS2 Title 13 24 ore + art. 33 GDPR (72h).
• Qualsiasi organizzazione che detiene dati personali: art. 33 GDPR (72h) come minimo, con notifica individuale art. 34 se rischio elevato per gli interessati.

Costruisci una base evidenze ed esporta per regime; non lasciare che team separati redigano narrative separate, perché i supervisori le confrontano. Infine, aspettati che la compromissione IdP sia il *primo* stadio, non l'intero incidente — Scattered Spider e simili fanno regolarmente pivot dal controllo della directory al furto di dati e all'estorsione, quindi esegui la response al ransomware exfiltration-only in parallelo non appena vedi staging o egress di massa.