Microsoft Defender for Identity è il componente di Microsoft Defender XDR dedicato all’Active Directory Domain Services on-premises. Analizza il traffico di autenticazione che transita sui domain controller e lo correla con eventi di sicurezza e attività di rete, trasformando segnali “grezzi” (Kerberos, NTLM, LDAP, DNS) in avvisi mappati sulle fasi della kill chain.

Architettura a sensori

Il sensore è un servizio installato direttamente sul server da proteggere: non serve port mirroring né appliance dedicate. I ruoli supportati sono:

Server Cosa raccoglie Perché serve
Domain Controller (anche RODC) Traffico Kerberos/NTLM/LDAP/DNS, event log, chiamate SAMR Copertura core delle detection
AD FS Eventi di autenticazione federata Password spray e brute force verso il federation service
AD CS Richieste ed emissioni di certificati Abusi dei template (ESC1–ESC8), autenticazione via certificato
Entra Connect Operazioni di sincronizzazione Compromissione dell’account di sync, ponte hybrid identity

Il sensore comunica in HTTPS/443 in uscita verso il servizio cloud (endpoint *.atp.azure.com) e usa la Network Name Resolution (NNR) — NTLM over RPC, NetBIOS, RDP su 3389 e DNS inverso — per risolvere un indirizzo IP nel nome del computer. Senza NNR affidabile gli avvisi perdono l’attribuzione del dispositivo di origine. La configurazione e gli avvisi vivono nel Microsoft Defender portal (security.microsoft.com), sezione Settings → Identities, dove la pagina Health issues segnala sensori scollegati o event log mancanti.

Prerequisiti: account di servizio ed eventi

  • Directory Service Account (DSA): obbligatorio per l’enumerazione LDAP degli oggetti di dominio. La modalità raccomandata è un gMSA (Group Managed Service Account), con sole permission di lettura sul dominio più la lettura del container Deleted Objects (necessaria per alcune detection di ricognizione).
  • Action account: account separato, con delega esplicita, richiesto per le response action (disabilita utente, reset password, disabilita computer) direttamente dal portale.
  • Advanced audit policy: vanno abilitate le sottocategorie che generano gli eventi consumati dal sensore — tra cui 4726, 4728/4729, 4732/4733, 4738, 4740, 4762, 7045 e, per NTLM, l’evento 8004, che richiede le policy Restrict NTLM: Audit incoming NTLM traffic e Audit NTLM authentication in this domain.
  • SACL sugli oggetti AD, per rilevare modifiche a gruppi sensibili e attributi.
  • Licenza per utente: Microsoft 365 E5 / E5 Security / EMS E5 o Defender for Identity standalone.

Fasi d’attacco coperte

Fase Esempi di detection
Reconnaissance Enumerazione account via SAMR, ricognizione attributi AD via LDAP, mappatura rete via DNS (AXFR), enumerazione sessioni SMB
Compromised credentials Password spray, brute force, Kerberoasting, AS-REP roasting, attività su honeytoken
Lateral movement Pass-the-Hash, Pass-the-Ticket, Overpass-the-Hash, NTLM relay, esecuzione remota di codice
Domain dominance DCSync (richiesta di replica malevola), DCShadow, Golden Ticket, Skeleton Key, modifiche sospette a gruppi privilegiati

Esempio operativo: un Pass-the-Hash emerge quando lo stesso hash NTLM viene presentato da un computer diverso da quello abituale dell’utente; il DCSync viene rilevato quando un host che non è un domain controller invia una richiesta di replica (DRSUAPI GetNCChanges) a un DC — segnale quasi sempre di compromissione a livello di dominio. Entrambi confluiscono come incident correlato in Defender XDR, dove si uniscono ai segnali di Defender for Endpoint sull’host di origine.

Postura e secure score

Oltre alle detection, Defender for Identity produce le identity security posture assessments (delegazioni Kerberos non sicure, protocolli legacy, Print Spooler attivo sui DC, account con PasswordNeverExpires, entità dormienti in gruppi sensibili). Queste raccomandazioni alimentano il Microsoft Secure Score, quindi la remediation della postura AD è misurabile e tracciabile nel tempo.

Trappole tipiche d’esame

  • Scenario: serve rilevare sign-in rischiosi e leaked credentials di utenti cloud-only → risposta: Microsoft Entra ID Protection, non Defender for Identity, che copre solo l’AD on-premises.
  • Scenario: i sensori sono installati solo su 3 DC su 6 e alcuni attacchi non vengono visti → risposta: installare il sensore su tutti i domain controller (RODC inclusi); una copertura parziale lascia percorsi di autenticazione ciechi.
  • Scenario: subito dopo il deployment le entity page mostrano poche informazioni e mancano gli avvisi comportamentali → risposta: è il periodo di learning (fino a circa 30 giorni per le detection basate su baseline); non è un malfunzionamento.
  • Scenario: gli avvisi NTLM non compaiono benché i sensori siano “healthy” → risposta: mancano gli eventi 8004; abilitare l’auditing NTLM via Group Policy.
  • Scenario: l’analista deve disabilitare un account compromesso dal portale ma l’azione fallisce → risposta: configurare l’Action account con le permission delegate; il DSA in sola lettura non basta.