In this module

1.5 Mitigate Threats Using Microsoft Defender for Identity

10-14 hours · Module 1 · Free

Operational Objective

This subsection covers mitigate threats using microsoft defender for identity — a core operational skill for security teams working in Microsoft 365 environments. Every concept is demonstrated through practical scenarios from the Northgate Engineering environment.

Deliverable: Working proficiency with the techniques and operational patterns covered in this subsection.

Estimated completion: 25 minutes

Figure 1.5 — Operational workflow from input through documented output.

Figure — Mitigate Threats Using Microsoft Defender for Identity. Applied to security operations at Northgate Engineering.

Mitigate Threats Using Microsoft Defender for Identity

Introduction

Required role: Security Reader (minimum for portal navigation). Security Administrator for configuration changes.

Defender for Identity monitors on-premises Active Directory environments by analyzing traffic directly from domain controllers. It detects reconnaissance, credential theft, lateral movement, privilege escalation, and domain dominance attacks that target Active Directory — the identity backbone of most enterprise environments.

// Find identity-based lateral movement detections
IdentityLogonEvents
| where Timestamp > ago(7d)
| where Application == "Active Directory"
| where LogonType == "Interactive"
| where AccountUpn has "admin"
| summarize DeviceCount = dcount(DeviceName),
    Devices = make_set(DeviceName),
    LogonCount = count()
    by AccountUpn
| where DeviceCount > 3
| order by DeviceCount desc

// Investigate all identity events for a specific account during an incident
let targetAccount = "admin.t.clark";
let timeWindow = 7d;
union
    (IdentityLogonEvents
        | where Timestamp > ago(timeWindow)
        | where AccountUpn has targetAccount
        | project Timestamp, EventType = "Logon",
            Detail = strcat(LogonType, " to ", DeviceName, " from ", IPAddress),
            Result = ActionType),
    (IdentityDirectoryEvents
        | where Timestamp > ago(timeWindow)
        | where AccountUpn has targetAccount
        | project Timestamp, EventType = "DirectoryChange",
            Detail = strcat(ActionType, " on ", TargetAccountUpn),
            Result = "Success"),
    (IdentityQueryEvents
        | where Timestamp > ago(timeWindow)
        | where AccountUpn has targetAccount
        | project Timestamp, EventType = "Query",
            Detail = strcat(QueryType, " for ", QueryTarget),
            Result = ActionType)
| order by Timestamp asc

Expand for Deeper Context

While Entra ID Protection handles cloud identity threats (risky sign-ins, leaked credentials, impossible travel), Defender for Identity handles the on-premises identity layer: Kerberos ticket manipulation, NTLM relay attacks, LDAP enumeration, and domain controller exploitation. In hybrid environments — which describes most enterprises — both products feed alerts into the unified XDR incident queue, giving you a complete view of identity threats across cloud and on-premises infrastructure.

This subsection teaches you how Defender for Identity sensors work, what attack categories the product detects across the cyber kill chain, how to read and investigate identity alerts in the XDR portal, how to use Lateral Movement Paths to understand attacker progression, and how to take response actions on compromised identities. If your environment is entirely cloud-native (Entra ID with no on-premises Active Directory), Defender for Identity is less relevant to your daily operations — but most organizations taking the SC-200 exam will encounter hybrid identity scenarios.

---

Sensor architecture

Defender for Identity sensors install directly on domain controllers (or on dedicated standalone sensors in older environments). 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 deep visibility into identity-layer activity that no other Defender product can see.

The sensor is lightweight — it runs as a service on the domain controller and uses port mirroring or direct network capture to inspect traffic without requiring changes to Active Directory configuration. Captured data is sent to the Defender for Identity cloud service for analysis, where machine learning models and behavioral analytics compare observed activity against baseline patterns for each user and device in the environment.

Key data sources the sensor analyzes include 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 Event Tracing for Windows (ETW) events from the domain controller. The sensor also ingests Windows event log data from the domain controller, including Security event IDs 4624 (logon), 4625 (failed logon), 4672 (special privileges assigned), 4720 (account created), and 4768/4769 (Kerberos ticket operations).

In Microsoft Defender XDR, identity data from Defender for Identity populates the IdentityLogonEvents, IdentityQueryEvents, and IdentityDirectoryEvents tables in Advanced Hunting. These tables are how you query identity-layer activity using KQL alongside endpoint and email data.

Deployment prerequisite

Defender for Identity requires at least one sensor installed on a domain controller in each Active Directory forest you want to monitor. In multi-domain environments, every domain controller that handles authentication traffic should have a sensor. The sensor requires .NET Framework 4.7 or later and approximately 4-6 GB of RAM. For environments where installing directly on domain controllers is not permitted by policy, a standalone sensor can be deployed on a separate server with port mirroring configured from the domain controllers.

---

What Defender for Identity detects

Defender for Identity organizes its detections along the cyber-attack kill chain. This mapping is important because it tells you not just what happened, but where the attacker is in their progression — which directly affects your response urgency and containment strategy.

Reconnaissance and discovery. These are the earliest indicators of attack activity, often occurring days or weeks before active exploitation. Defender for Identity detects account enumeration (an attacker using LDAP or SAM-R queries to discover user accounts, service accounts, and group memberships), network mapping (DNS zone transfer requests or reverse DNS lookups used to map the network topology), and security principal reconnaissance (queries targeting sensitive accounts, admin groups, or specific service accounts). These detections use behavioral analysis — a help desk account that suddenly runs thousands of LDAP queries against every user in the directory is exhibiting reconnaissance behavior that deviates from its baseline.

Credential theft. Once an attacker has a foothold, they attempt to harvest credentials from the compromised system or from network traffic. Defender for Identity detects Kerberoasting (requesting Kerberos service tickets for service accounts with SPNs, then cracking them offline to obtain plaintext passwords), AS-REP roasting (requesting authentication for accounts that do not require pre-authentication, then cracking the response), DCSync attacks (requesting Active Directory replication from a non-domain-controller source, which extracts password hashes for all accounts in the domain), and NTLM relay attacks (forwarding captured NTLM authentication to another service to gain unauthorized access).

Attack phase	Technique	Detection method	Urgency
Reconnaissance	LDAP enumeration, DNS zone transfer, account enumeration via SAM-R	Unusual query volume or patterns from non-standard sources	Medium — investigate within 4 hours
Credential theft	Kerberoasting, AS-REP roasting, DCSync, NTLM relay	Abnormal Kerberos/NTLM requests, replication from non-DC	High — investigate within 1 hour
Lateral movement	Pass-the-hash, pass-the-ticket, overpass-the-hash	Auth anomalies: NTLM where Kerberos expected, ticket reuse from different IPs	High — investigate within 1 hour
Privilege escalation	SID-history injection, AdminSDHolder modification, GPO abuse	Unauthorized changes to sensitive group memberships or directory objects	Critical — investigate immediately
Domain dominance	Golden ticket, skeleton key, DCShadow, rogue certificate	Forged Kerberos tickets, rogue DC registration, unauthorized CA operations	Critical — assume full domain compromise

Lateral movement. After obtaining credentials, attackers move through the network to reach higher-value targets. Defender for Identity detects pass-the-hash attacks (using a stolen NTLM hash to authenticate without knowing the plaintext password), pass-the-ticket attacks (using a stolen Kerberos ticket to impersonate a user on other systems), and overpass-the-hash attacks (using an NTLM hash to obtain a Kerberos ticket, then using the ticket for authentication). The product also detects unusual Kerberos protocol implementations — attackers using tools like Mimikatz or Rubeus often produce Kerberos requests with non-standard protocol characteristics that differ from legitimate Windows authentication.

Privilege escalation. Attackers escalate their access level by modifying directory objects or exploiting misconfigurations. Defender for Identity detects unauthorized modifications to sensitive groups (adding a compromised account to Domain Admins), SID-history injection (adding a privileged SID to a normal user's SID history to grant them admin access without changing group membership), and exploitation of domain controller vulnerabilities such as PrintNightmare (CVE-2021-34527) and ZeroLogon (CVE-2020-1472).

Domain dominance. The final stage of an Active Directory attack, where the attacker has persistent, unrestricted access to the entire domain. Defender for Identity detects golden ticket attacks (using a forged Kerberos TGT created with the stolen KRBTGT hash, which grants access to any resource in the domain), skeleton key attacks (injecting a master password into the domain controller's LSASS process that works for any account), DCShadow attacks (registering a rogue domain controller to inject unauthorized changes into AD replication), and rogue certificate attacks (compromising the Certificate Authority to generate backdoor certificates). If you see a domain dominance alert and it is a true positive, assume the entire domain is compromised — the attacker has the keys to everything.

---

Lateral Movement Paths

Lateral Movement Paths (LMPs) are one of the most valuable features in Defender for Identity. An LMP is a visual map showing how an attacker could move from a compromised non-sensitive account to a sensitive target (domain admin, service account with broad access, or a domain controller) through a series of credential-sharing relationships.

The LMP works by analyzing which users have logged on to which devices. If UserA (a standard employee) has logged on to ServerX, and AdminB (a domain admin) has also logged on to ServerX, then ServerX is a stepping stone in a lateral movement path: an attacker who compromises UserA's workstation can extract AdminB's cached credentials from ServerX and use them to reach the domain controller.

LMPs appear in two places in the portal. First, on the identity entity page for any user, you can view all lateral movement paths that lead to or from that identity. Second, and more importantly, when a lateral movement alert fires (such as pass-the-hash or pass-the-ticket), the alert evidence includes the specific LMP that the attacker exploited. The evidence lists the source account (compromised), the intermediate devices (stepping stones), and the destination account (the sensitive target the attacker reached or attempted to reach).

This visual representation is powerful for both investigation and prevention. For investigation, it shows you exactly how the attacker reached the high-value target and which intermediate systems need investigation. For prevention, it identifies credential hygiene problems: if a domain admin logged on to a shared workstation, that workstation is now a stepping stone. The remediation is operational — enforce the tiered administration model (admin accounts only log on to admin workstations, never to standard user devices) and implement Local Administrator Password Solution (LAPS) to prevent credential reuse across devices.

Expected Output — Admin Accounts with Wide Device Footprint

AccountUpn	DeviceCount	Devices	LogonCount
admin.t.clark@northgateeng.com	8	["DC01","SRV-FILE01","DESKTOP-NGE003","DESKTOP-NGE017",...]	47
admin.s.patel@northgateeng.com	5	["DC01","DC02","SRV-SQL01","SRV-EXCH01","DESKTOP-NGE042"]	23

Security posture insight: Admin accounts logging on interactively to standard user desktops (DESKTOP-NGE003, DESKTOP-NGE042) create lateral movement paths. If any of those desktops are compromised, the admin credentials cached in memory can be extracted and reused. This is a credential hygiene issue that should be escalated to the identity team.

---

Investigating identity alerts

When Defender for Identity fires an alert, it appears in the unified XDR incident queue alongside alerts from other Defender products. Identity alerts contain specific information that other alert types do not provide: the source account (who performed the suspicious action), the source device (where the action originated), the target account or resource (what the attacker was trying to reach), and the MITRE ATT&CK technique mapping.

Alert triage for identity alerts. Identity alerts require a different triage approach than endpoint alerts. Many identity detections have learning periods — the product needs time (typically five days after sensor installation) to establish baseline behavior for each user and device. During the learning period, detections based on behavioral deviation may produce false positives. After the learning period, alert fidelity improves significantly.

When triaging an identity alert, follow this process:

Step 1 — Read the alert narrative. Defender for Identity provides a plain-language description of what was detected, including the specific entities involved and the evidence that triggered the detection. The narrative explains why this activity is suspicious — for example, "A Kerberos service ticket was requested for account SVC-SQL using RC4 encryption from device DESKTOP-NGE042. This device has not previously requested tickets for this service account, and the use of RC4 instead of AES encryption is consistent with offline password cracking (Kerberoasting)."

Step 2 — Check the lateral movement path. If the alert involves lateral movement, the evidence includes the LMP showing how the attacker reached the current position. This tells you the scope of compromise — which accounts and devices are in the attack chain.

Step 3 — Correlate with other products. Identity alerts rarely exist in isolation. A Kerberoasting alert often coincides with an endpoint alert (the tool that performed the Kerberoasting, such as Rubeus or Invoke-Kerberoast, triggers Defender for Endpoint). A pass-the-ticket alert may follow an email alert (the phishing email that delivered the credential-theft tool). Check the parent incident for correlated alerts from other products.

Step 4 — Assess the target. If the targeted account is a domain admin, service account with broad permissions, or a member of a highly privileged group, the urgency escalates immediately. A Kerberoasting attempt against a standard user's service ticket is less urgent than the same attempt against the KRBTGT service account.

Step 5 — Response actions. For confirmed identity compromise: disable the compromised account in Active Directory (or use the "Disable user" action in the portal), force a password reset for the account and all accounts that share credentials or are in the same lateral movement path, investigate the source device (it is likely compromised), and review the account's activity for the past 30 days to determine the extent of unauthorized access.

Expected Output — Complete Identity Activity Timeline

Timestamp	EventType	Detail	Result
Mar 14 08:02	Logon	Interactive to DC01 from 10.0.1.5	LogonSuccess
Mar 14 08:15	Query	LDAP for CN=Domain Admins	Success
Mar 14 08:16	Query	LDAP for CN=Enterprise Admins	Success
Mar 14 08:22	Logon	Interactive to SRV-FILE01 from 10.0.2.17	LogonSuccess
Mar 14 08:45	DirectoryChange	GroupMembershipChange on Domain Admins	Success

Kill chain in progress: This timeline shows reconnaissance (LDAP queries for privileged groups), lateral movement (logon to file server from a different IP than the initial logon), and privilege escalation (adding a member to Domain Admins). This is a classic Active Directory attack progression. The account should be immediately disabled, the group membership change should be reverted, and both the source workstation (10.0.1.5) and the file server (SRV-FILE01) need investigation.

---

Automatic attack disruption for identity threats

Defender XDR's automatic attack disruption feature can automatically disable compromised user accounts when it detects a high-confidence attack pattern involving identity compromise. When attack disruption triggers, it suspends the compromised account to prevent additional damage such as lateral movement, malicious mailbox access, or malware execution on additional devices.

The disable action behaves differently depending on where the account is hosted. For accounts hosted in on-premises Active Directory, the Defender for Identity sensor on the domain controller executes the disable action. For hybrid accounts (AD synced to Entra ID), both the on-premises account and the Entra ID account are disabled. For cloud-only accounts (Entra ID native), the disable action is executed directly against Entra ID.

Attack disruption operates at the incident level and only triggers when the AI model correlates signals from multiple products into a high-confidence attack pattern. You can review disruption actions in the incident timeline and reverse them if the activity was benign. However, in practice, the confidence threshold for automatic disruption is set high enough that false positive rates are very low — the system requires multiple corroborating signals before taking automatic containment action.

---

Defender for Identity in hybrid vs cloud-only environments

The relevance of Defender for Identity to your SOC operations depends entirely on your identity architecture.

Hybrid environments (Active Directory synced to Entra ID via Entra Connect) are where Defender for Identity provides the most value. Most enterprises still run hybrid identity because on-premises applications, file servers, and legacy systems require Active Directory authentication. In these environments, Defender for Identity detects attacks that Entra ID Protection cannot see — 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. In these environments, identity threat detection relies entirely on Entra ID Protection (risky sign-ins, leaked credentials, token anomalies) and Defender for Cloud Apps (anomalous cloud app behavior). If you are studying for the SC-200 exam, expect questions about Defender for Identity in hybrid scenarios — the exam assumes enterprise environments with on-premises infrastructure.

Assessing your environment. Check whether your organization runs on-premises domain controllers by looking for the Entra Connect sync service in your Entra ID portal (Entra admin center → Hybrid management → Entra Connect). If Entra Connect is active, you have a hybrid environment and Defender for Identity should be deployed. If there is no sync service and all identities are cloud-native, Defender for Identity is not applicable.

Try it yourself

In the Defender portal, navigate to Settings → Identities. If your organization has Defender for Identity deployed, you will see the sensor health page showing which domain controllers have sensors installed and their status. If you are using a developer tenant without on-premises infrastructure, you can explore the identity investigation pages by navigating to Assets → Identities and selecting any user — the identity entity page shows the same investigation tabs (Overview, Incidents and alerts, Observed in organization, Timeline) regardless of whether Defender for Identity sensors are deployed.

What you should observe

The identity entity page is the hub for investigating any user in your environment. The "Observed in organization" tab shows which devices the user has logged on to, which is directly related to lateral movement path analysis. The "Incidents and alerts" tab aggregates alerts from all identity sources — Defender for Identity, Entra ID Protection, and Defender for Cloud Apps — providing a unified view of identity-based threats for that specific user.

Knowledge check

Compliance mapping

NIST CSF: DE.AE-1 (Baseline of operations established), PR.DS-1 (Data-at-rest is protected). ISO 27001: A.8.15 (Logging), A.8.16 (Monitoring activities). SOC 2: CC7.2 (Monitor system components). Every configuration in this subsection contributes to the logging and monitoring controls that auditors verify.

Compliance Myth: "Enabling all Defender products means you are protected"

The myth: Enabling all Defender products means you are protected

The reality: Licensing a product is not deploying a product. Defender for Endpoint requires onboarding devices, configuring policies, and validating telemetry. Defender for Office 365 requires configuring anti-phishing policies, safe links, and safe attachments for your specific domains and VIPs. An enabled-but-unconfigured Defender product provides less protection than a properly configured open-source alternative. Configuration is the capability — the license is just the starting point.

Check your understanding

1. Defender for Identity fires a "Suspected DCSync attack" alert. The source account is a standard user workstation, not a domain controller. What does this mean and how urgent is it?

Critical. DCSync requests Active Directory replication data, which includes password hashes for every account in the domain — including KRBTGT and all admin accounts. A replication request from a non-domain-controller is always malicious. The source device is fully compromised and the attacker has tools like Mimikatz running. Assume all domain credentials are exposed. Immediately disable the source account, isolate the source device, and initiate domain-wide password reset planning.

Medium priority. DCSync is a common administrative operation and may be a false positive.

Low priority. This is likely a misconfigured backup tool attempting AD replication.

DCSync from a non-domain-controller is one of the highest-severity alerts in Defender for Identity. Legitimate Active Directory replication only occurs between domain controllers. A non-DC device requesting replication means an attacker is using tools like Mimikatz's "lsadump::dcsync" command to extract password hashes for the entire domain. This provides the attacker with the KRBTGT hash, which enables golden ticket attacks and persistent domain access. This alert demands immediate response — not hours, but minutes.

2. A Lateral Movement Path shows that an attacker could reach Domain Admins through the following chain: compromised user → shared workstation → admin cached credentials → domain controller. What is the root cause of this exposure?

The domain admin account logged on interactively to a shared workstation, leaving cached credentials. The fix is enforcing tiered administration: admin accounts should only log on to hardened admin workstations, never to standard user devices.

The shared workstation is missing antivirus — install Defender for Endpoint on it.

The domain controller needs additional firewall rules to block lateral movement.

Lateral Movement Paths exist because privileged accounts leave credential artifacts on devices they log on to. When a domain admin interactively logs on to a shared workstation, their NTLM hash and Kerberos tickets are cached in memory on that device. Any compromise of that workstation exposes the admin credentials. The tiered administration model — where Tier 0 (domain admin) accounts only authenticate to Tier 0 devices (domain controllers and admin jump boxes) — eliminates these paths.

3. You see two correlated alerts in an XDR incident: a Defender for Endpoint alert for Mimikatz execution on a workstation, and a Defender for Identity alert for Kerberoasting targeting the SVC-SQL service account. How are these related?

The attacker ran Mimikatz on the compromised workstation (detected by MDE) to request Kerberos service tickets for the SQL service account (detected by MDI). They will attempt to crack the ticket offline to obtain the SVC-SQL password. If the service account password is weak, the attacker gains access to the SQL server. Immediate actions: reset the SVC-SQL password to a strong random value, investigate the compromised workstation, and check whether the attacker already authenticated to the SQL server.

These are two separate, unrelated alerts that were incorrectly correlated.

Mimikatz only steals local passwords; it cannot perform Kerberoasting.

This is exactly how cross-product correlation works in XDR. Defender for Endpoint sees the tool (Mimikatz) executing on the device. Defender for Identity sees the effect of the tool (Kerberoasting request hitting the domain controller). Neither product alone tells the complete story — together they confirm that an attacker is actively harvesting service account credentials from a compromised endpoint.

4. Your organization runs a cloud-only environment with Entra ID and no on-premises Active Directory. Is Defender for Identity relevant to your security operations?

No. Defender for Identity requires sensors on domain controllers to function. In a cloud-only environment, identity threat detection is handled by Entra ID Protection (risky sign-ins, leaked credentials) and Defender for Cloud Apps (anomalous cloud application behavior).

Yes. Defender for Identity protects all identity types regardless of infrastructure.

Partially. It monitors Entra ID sign-ins as a cloud-only backup.

Defender for Identity is specifically designed for on-premises Active Directory monitoring. Its sensors install on domain controllers and analyze AD-specific traffic (Kerberos, NTLM, LDAP, replication). Without domain controllers, there is nothing for the sensors to monitor. Cloud identity protection in Entra ID is handled by a different product — Entra ID Protection — which is covered in the Microsoft Learn learning path "Manage Microsoft Entra Identity Protection."

Decision point

You manage NE's M365 security stack. Microsoft releases a new Defender feature in preview. The feature promises to reduce AiTM risk by 80%. Do you enable it immediately?

Not in production. Enable in a test tenant or for a pilot group first. Preview features may: change behavior before GA, have undocumented interactions with existing CA policies, or produce unexpected results in specific tenant configurations. The deployment sequence: (1) enable in a test tenant and validate against NE's CA policy set, (2) enable for a pilot group of 10 users for 2 weeks, (3) monitor for FPs and operational impact, (4) roll out to all users after successful pilot. Microsoft's '80% reduction' claim is based on their telemetry across all tenants — NE's specific configuration may produce different results.

You've set up your M365 tenant and learned the Defender XDR unified portal.

Module 0 got your M365 developer tenant configured with sample data. Module 1 took you through the Defender XDR unified incident queue across endpoint, email, identity, and cloud apps. Now you investigate every major M365 attack type and deploy the detections that catch them next time.

15 investigation and configuration modules — Defender for Endpoint, Purview, Defender for Cloud, Security Copilot, Sentinel workspace design, log ingestion, analytics rules, and threat hunting
5 named attack investigations — AiTM credential phishing, BEC and financial fraud, consent phishing and OAuth grant abuse, token replay and session hijacking, insider threat
KQL from fundamentals through advanced hunting — dedicated modules on query language, cross-table joins, statistical analysis, and threat hunting queries
SC-200 exam objectives fully covered — every module maps to the January 2026 SC-200 update. The certification is the side effect of operational competence, not the goal
Production artefacts per module — detection rules, investigation playbooks, and hardening checklists you deploy to your own tenant

Unlock the full course with Premium See Full Syllabus

← Previous Next →