Mitigate Threats Using Microsoft Defender for Identity

Sensor architecture

Defender for Identity sensors install directly on domain controllers. The sensor captures and analyzes authentication traffic, LDAP queries, DNS lookups, Kerberos ticket requests, NTLM authentication attempts, and Active Directory replication traffic. This gives it visibility into identity-layer activity that no other Defender product can see.

The sensor runs as a lightweight service on the domain controller, using port mirroring or direct capture to inspect traffic without modifying AD configuration. Captured data is sent to the Defender for Identity cloud service for analysis, where machine learning models compare observed activity against baseline patterns for each user and device. The learning period for behavioral baselines is typically five days after installation. During this period, behavioral detections may produce false positives because the product has not yet established what normal looks like for your environment.

Key data sources the sensor analyzes: Kerberos authentication (AS-REQ, TGS-REQ, AP-REQ), NTLM authentication, LDAP bind operations and search queries, DNS queries (especially zone transfers and reverse lookups used in reconnaissance), Active Directory replication (DCSync detection), and ETW events from the domain controller. The sensor also ingests Security event log data including event IDs 4624 (logon), 4625 (failed logon), 4672 (special privileges assigned), 4720 (account created), and 4768/4769 (Kerberos ticket operations). For v3.x sensors, enabling RPC audit tags through device inventory unlocks additional detection categories for advanced identity attacks.

In Advanced Hunting, identity data populates three tables: IdentityLogonEvents (authentication events including source device, logon type, protocol, and success/failure), IdentityQueryEvents (LDAP, DNS, and SMB queries with target objects and query types), and IdentityDirectoryEvents (group membership changes, password resets, directory modifications). These tables are how you correlate identity activity with endpoint and email events using KQL. The join key is typically AccountUpn or AccountName, linking identity events to the same user across DeviceLogonEvents, EmailEvents, and CloudAppEvents.

Detection categories

Defender for Identity organizes detections along the Active Directory kill chain. The stage tells you where the attacker is in their progression, which directly determines response urgency.

Reconnaissance detections fire earliest, often days or weeks before active exploitation. The product catches LDAP enumeration (an attacker querying user accounts, service accounts, and group memberships), DNS zone transfers (mapping network topology by requesting the full DNS zone from a domain controller), and security principal reconnaissance (targeted queries for Domain Admins, Enterprise Admins, or sensitive service accounts). These detections rely on behavioral analysis: a help desk account that suddenly runs thousands of LDAP queries against every user deviates from its five-day baseline. The same queries from a directory synchronization service account are normal. Reconnaissance alerts are medium urgency because the attacker is still in the planning phase, but they provide an early warning window to investigate before credential theft begins.

Credential theft detections cover techniques for harvesting credentials after initial access. Kerberoasting requests Kerberos service tickets for accounts with SPNs, then cracks them offline to obtain passwords. The detection identifies abnormal ticket requests using RC4 encryption from accounts that do not normally request those tickets. AS-REP roasting targets accounts configured without Kerberos pre-authentication. DCSync is the most dangerous technique: the attacker requests Active Directory replication from a non-domain-controller source, which returns password hashes for every account in the domain including KRBTGT. A successful DCSync means the attacker can forge golden tickets and access any resource in the forest.

Lateral movement detections identify how attackers traverse the network toward higher-value targets. Pass-the-hash authenticates using a stolen NTLM hash without knowing the password, which works because NTLM authentication uses the hash directly rather than the plaintext. Pass-the-ticket uses a stolen Kerberos ticket to impersonate a user on other systems, bypassing the need for the user's password entirely. Overpass-the-hash converts an NTLM hash into a Kerberos ticket, gaining wider acceptance across services. NTLM relay forwards captured authentication to gain unauthorized access to another service. The product also detects non-standard Kerberos implementations because offensive tools like Mimikatz and Rubeus produce protocol characteristics (encryption types, ticket flags, request patterns) that differ from legitimate Windows authentication.

Privilege escalation detections catch modifications to sensitive directory objects. Unauthorized additions to Domain Admins are the obvious indicator, but subtler techniques include SID-history injection (adding a privileged SID to a normal user's SID history attribute, granting admin access without visible group membership change) and AdminSDHolder modification (changing the security descriptor that propagates to all protected objects, giving persistent admin-equivalent access that survives password resets).

Lateral Movement Paths

Lateral Movement Paths (LMPs) are a visualization unique to Defender for Identity. An LMP traces the sequence of accounts and devices an attacker could chain together to reach a high-value target, using cached credentials on intermediate devices as stepping stones.

The visualization works like this: if admin_a logged on to workstation_1, and user_b also has a session on workstation_1, then an attacker who compromises user_b can extract admin_a's cached credentials from that workstation. The LMP draws this chain from any starting user to any reachable admin account, through every device where credentials overlap. The longer the path (more hops), the more devices the attacker needs to compromise. The shorter the path, the more urgent the remediation.

You access LMPs from the user entity page in the portal. Select a user, then select the Lateral Movement Paths tab. The visualization shows each hop as a node (device or account) with connecting lines showing credential overlap. Red nodes indicate confirmed compromised entities. During an active investigation, the LMP tells you exactly which additional devices and accounts are at risk based on the compromise you've already confirmed.

// Admin accounts logging on to standard workstations \u2014 lateral movement risk
IdentityLogonEvents
| where Timestamp > ago(7d)
| where Application == "Active Directory"
| where LogonType == "Interactive"
| where AccountUpn has "admin"
| summarize DeviceCount = dcount(DeviceName),
    Devices = make_set(DeviceName)
    by AccountUpn
| where DeviceCount > 3

Admin accounts logging on interactively to standard user workstations create lateral movement paths that attackers exploit. If any of those workstations are compromised, the admin credentials cached in memory can be extracted using tools like Mimikatz. The remediation is operational: enforce tiered administration where admin accounts only log on to dedicated Privileged Access Workstations, deploy LAPS to ensure each device has a unique local admin password, and review LMP data regularly to identify new paths created by operational drift.

Investigating identity alerts

When an identity alert fires, the triage approach differs from endpoint alerts. Read the alert narrative first. Defender for Identity provides plain-language descriptions explaining why the activity is suspicious. A Kerberoasting alert states that a service ticket was requested using RC4 encryption from an account that has not previously requested tickets for that service, linking the specific behavior to the attack technique.

Check the lateral movement path if the alert involves credential theft. The LMP shows which accounts and devices are in the attack chain, defining your investigation scope. Then correlate with the other products in the XDR incident: a Kerberoasting alert often coincides with an endpoint alert for the tool that performed the attack. A pass-the-ticket alert may follow a phishing email that delivered the credential-theft tool.

Assess the target urgency. A Kerberoasting attempt against a standard service account is concerning but manageable. The same technique targeting KRBTGT, Domain Admins, or Enterprise Admins requires immediate escalation. If DCSync succeeds against any of these, the attacker has the keys to the entire forest.

For confirmed identity compromise, the response sequence is: disable the compromised account in Active Directory (or use the Disable user action in the portal), force a password reset for the account and for any accounts in the same lateral movement path, investigate the source device (it is certainly compromised since the attack tool had to execute somewhere), and review the account's activity in IdentityLogonEvents and IdentityDirectoryEvents for the past 30 days to determine what the attacker accessed and whether they modified any directory objects.

If the compromised account is a service account with SPNs (the target of Kerberoasting), the password change must be coordinated with the application owners because the service will break when the password changes. Document the current SPN configuration, coordinate a maintenance window, change the password, update the service configuration, and verify the service resumes. Attackers target service accounts precisely because organizations are reluctant to change their passwords, leaving cracked credentials valid for months.

Attack disruption can act automatically on identity threats. When the correlation engine detects a high-confidence pattern (Kerberoasting followed by lateral movement, or DCSync from a non-DC), it can automatically disable the compromised account. The disable action works through the Defender for Identity sensor on the domain controller for on-premises accounts, through both AD and Entra ID for hybrid accounts, and directly against Entra ID for cloud-only accounts. Review disruption actions in the incident timeline and reverse them if the activity was authorized.

Hybrid versus cloud-only environments

Defender for Identity's relevance depends on your identity architecture. Hybrid environments (Active Directory synced to Entra ID via Entra Connect) are where the product provides the most value, because this is where the on-premises attack surface exists. Kerberos ticket manipulation, NTLM attacks, and domain controller exploitation all happen in the on-premises identity layer below the cloud.

Cloud-only environments (Entra ID with no on-premises AD) do not benefit from Defender for Identity because there are no domain controllers to monitor. Identity threat detection in cloud-only environments relies on Entra ID Protection (risky sign-ins, leaked credentials, token anomalies) and Defender for Cloud Apps (anomalous cloud app behavior).

Many organizations operate in a transitional state: primarily cloud but with legacy applications still authenticating against on-premises AD. In these environments, the on-premises domain controllers are often overlooked for security investment because leadership views them as "almost decommissioned." This creates a dangerous gap. Attackers know that hybrid environments expose the weakest authentication protocols (NTLM, Kerberos with RC4) on the least-monitored infrastructure. Deploy Defender for Identity sensors on every domain controller regardless of how close you are to full cloud migration.

To determine your architecture: check for the Entra Connect sync service in the Entra admin center under Hybrid management. If Entra Connect is active, you have a hybrid environment and Defender for Identity should be deployed on every domain controller.