Due piani, due motori di rilevamento

Quando un SOC parla di “identità compromessa” deve subito chiedersi quale identità. Microsoft Entra ID Protection valuta le identità cloud: firma i segnali di autenticazione contro il tenant Entra ID e produce risk detection. Microsoft Defender for Identity guarda l’Active Directory on-premises attraverso i sensor installati sui domain controller (e sui server AD FS/AD CS), e ragiona su Kerberos, NTLM, LDAP e DNS. Sono due telemetrie diverse che convergono nello stesso incident in Microsoft Defender XDR: la pagina entità dell’utente mostra insieme il risk level cloud e gli alert di dominio. Sbagliare il piano è l’errore più penalizzato all’esame: un’enumerazione di account su un DC non è un segnale di Entra ID Protection, e un impossible travel non è un alert di Defender for Identity.

Rischio utente, rischio di sign-in e cosa li chiude davvero

Entra ID Protection distingue due oggetti. Il sign-in risk è la probabilità che quella specifica autenticazione non sia dell’utente legittimo: anonymous IP address, impossible travel, unfamiliar sign-in properties, malicious IP. Il user risk è la probabilità che l’identità nel suo complesso sia compromessa: tipicamente leaked credentials, cioè credenziali trovate in circolazione, o segnali di threat intelligence. La risposta è coerente con l’oggetto: a un sign-in rischioso si risponde alzando l’assurance della sessione (MFA via Conditional Access), a un user risk si risponde sostituendo la credenziale esposta.

Qui sta il punto che le domande girano in ogni modo possibile. L’unica azione che rimedia un user risk è un cambio password sicuro: l’utente si autentica con un fattore forte (MFA) e cambia la password, oppure un amministratore forza un reset. La credenziale esposta diventa inutile e lo stato di rischio si chiude automaticamente (self-remediation). Confirm user compromised è tutt’altro: dichiara al modello che il rilevamento era un vero positivo, porta il rischio a High e alimenta il machine learning — non tocca la password, non chiude nulla. Dismiss user risk è la terza azione, amministrativa e distinta: azzera lo stato di rischio come falso positivo, senza alcuna bonifica. Usarla su una compromissione reale significa nascondere il problema. In ogni caso di compromissione confermata, la prassi è accompagnare il reset con la revoca esplicita delle sessioni attive, perché i token già emessi vanno invalidati insieme alla password.

Defender for Identity: ricognizione e movimento laterale

Sul dominio on-premises gli alert seguono la kill chain. In fase di reconnaissance compaiono enumerazione di account e di gruppi (SAMR), interrogazioni LDAP sugli attributi, network mapping via DNS: sono i primi segnali dopo che un endpoint è caduto. Seguono le compromised credentials (password spray, brute force, Kerberoasting e richieste sospette di service ticket), poi il lateral movement (pass-the-hash, pass-the-ticket, overpass-the-hash, esecuzione remota di codice) e infine la domain dominance (golden ticket, DCSync, DCShadow, skeleton key) — quest’ultima classe va trattata come emergenza, perché implica il controllo del dominio.

Defender for Identity aggiunge i lateral movement path, che mostrano in anticipo quali account non privilegiati portano a un amministratore di dominio: materiale per il hardening, non solo per l’indagine. In advanced hunting i dati stanno in IdentityLogonEvents, IdentityDirectoryEvents e IdentityInfo, correlabili con AlertInfo e AlertEvidence. Le response action sull’account on-premises (disable, forzatura del reset password) sono disponibili da Defender XDR, ma richiedono che il sensor abbia un action account configurato con i permessi in AD.

Risposta coordinata su un’identità ibrida

Con identità sincronizzate, contenere su un solo piano non basta. Disabilitare l’account in AD non revoca i refresh token già emessi in cloud; azzerare il rischio in Entra ID non ferma un attaccante che si muove con un ticket Kerberos. La sequenza operativa è: contenere (reset password su entrambi i piani, revoca sessioni, eventuale disable), poi verificare la persistenza (nuovi metodi MFA registrati, deleghe mailbox, app consent), poi chiudere lo stato di rischio.

Trappole tipiche d’esame

  • Rilevamento confermato come vero positivo, ma l’utente resta a rischio → Confirm user compromised non rimedia: etichetta il rischio per il modello e lo alza a High; solo il cambio password sicuro chiude lo stato.
  • “Serve l’azione che riporti l’utente in stato non a rischio” → cambio password sicuro dopo autenticazione forte: è la self-remediation prevista dalla user risk policy, non il dismiss.
  • Falso positivo accertato → Dismiss user risk: azione amministrativa distinta, appropriata solo quando l’indagine esclude la compromissione; su un incidente reale è insabbiamento.
  • Impossible travel o anonymous IP su una singola autenticazione → sign-in risk, non user risk: si risponde con MFA sulla sessione via Conditional Access, non con un reset password.
  • Enumerazione di account o DCSync su un domain controller → Defender for Identity: è AD on-premises; né Entra ID Protection né Defender for Endpoint sono la risposta corretta, anche se il server è un endpoint monitorato.
  • Password resettata ma l’attaccante è ancora dentro → revocare le sessioni: i refresh token già rilasciati vanno invalidati esplicitamente, e sull’utente ibrido l’azione va replicata su entrambi i piani.