This chapter covers Microsoft Defender for Identity (MDI) attack detections, a core component of the Microsoft 365 Defender stack. SC-200 exam domain 'Defender XDR' (Objective 1.2) expects you to understand how MDI detects advanced identity-based attacks such as pass-the-hash, golden ticket, and DCSync. Approximately 15-20% of exam questions in this domain focus on interpreting MDI alerts and understanding the underlying detection mechanisms. Mastery of this topic is critical because identity compromise is the root cause of many breaches, and MDI is Microsoft's primary tool for detecting these attacks in hybrid environments.
Jump to a section
Imagine a large office building with multiple floors, each floor having its own set of rooms. The building has a main entrance where everyone swipes their badge to enter. A security guard sits at a console that shows a live floor plan of the entire building. Every time someone swipes their badge, the guard sees a green dot appear at the entrance. If the same person swipes again at a different entrance 30 seconds later, the guard sees two dots appearing impossibly far apart — this is like a 'impossible travel' alert. The guard also has a list of which employees are allowed on which floors. If someone swipes into a restricted floor, the guard flags it. Additionally, the guard watches for patterns: if an employee who usually works on floor 2 suddenly accesses the server room on floor 5 at 3 AM, the guard investigates. The guard doesn't just watch badges; he also monitors the internal phone system. If an employee calls multiple people in a short time asking for their passwords, the guard notes that as a 'suspicious activity' — like a reconnaissance attempt. The guard's console is connected to a central security operations center (SOC) that correlates all building alerts. This is exactly how Microsoft Defender for Identity works: it ingests signals from Active Directory, network traffic, and event logs to detect lateral movement, privilege escalation, and credential theft. The 'floor plan' is the Active Directory topology, and the 'badge swipes' are authentication events. The guard's ability to correlate dots across time and space is the detection logic that generates security alerts.
Overview of Microsoft Defender for Identity
Microsoft Defender for Identity (MDI) is a cloud-based security solution that identifies, detects, and investigates advanced threats targeting on-premises Active Directory (AD) environments. It leverages machine learning, behavioral analytics, and known attack patterns to detect suspicious activities. MDI does not require agents on domain controllers; instead, it uses a sensor that monitors domain controller traffic (port mirroring) or reads Windows Event Logs (via Event Tracing for Windows - ETW). The sensor forwards parsed activities to the MDI cloud service for analysis.
How MDI Works: The Detection Pipeline
Data Collection: The MDI sensor installed on a domain controller (or dedicated server) captures network traffic (via port mirroring) and/or reads Windows Event Logs (e.g., Event ID 4624 for logon, 4672 for special privileges, 4776 for NTLM authentication). It also ingests ETW events for Kerberos and NTLM activities.
Parsing and Enrichment: The sensor parses raw packets and event logs to extract entities such as users, computers, IP addresses, and authentication types. It enriches this data with Active Directory information (e.g., group memberships, service principal names).
Cloud Analysis: The parsed data is sent securely to the MDI cloud service. The service applies machine learning models, anomaly detection algorithms, and signature-based rules to identify suspicious behavior. Alerts are generated based on thresholds and patterns.
Alert Generation: When a detection is triggered, MDI creates a security alert with a severity level (Low, Medium, High). The alert includes details like the affected entities, attack timeline, and recommended actions.
Integration with Microsoft 365 Defender: Alerts are automatically ingested into the Microsoft 365 Defender portal (security.microsoft.com) and can be correlated with other signals (e.g., Microsoft Defender for Endpoint alerts).
Key Attack Detections and Their Mechanisms
#### 1. Reconnaissance (LDAP, SAM-R) - LDAP reconnaissance: Attackers enumerate AD objects using LDAP queries. MDI detects anomalous LDAP query patterns, such as rapid enumeration of users or groups. The sensor monitors LDAP traffic and flags queries that deviate from baseline behavior (e.g., a workstation suddenly querying all domain admin accounts). - SAM-R (Security Account Manager Remote): Used to enumerate local users and groups. MDI detects SAM-R attempts from non-administrative machines. The detection leverages Event ID 4661 (A handle to an object was requested) for SAM objects.
#### 2. Compromised Credentials (Brute Force, Password Spray) - Brute Force: MDI detects multiple failed logon attempts (Event ID 4625) from a single source IP to multiple accounts within a short window. Default threshold: 10 failed attempts within 5 minutes triggers an alert. - Password Spray: A single password is attempted against many accounts. MDI identifies this by observing a high number of logon failures with the same password across different usernames. The detection uses behavioral baselines; an alert is generated when the number of failures exceeds 3 standard deviations from the mean.
#### 3. Lateral Movement (Pass-the-Hash, Pass-the-Ticket, Overpass-the-Hash) - Pass-the-Hash (PtH): An attacker uses an NTLM hash to authenticate as another user. MDI detects PtH by correlating NTLM authentication events (Event ID 4776) with network activity. The sensor looks for a mismatch between the source machine that initiated the authentication and the machine that owns the hash. For example, if UserA's hash is used from MachineB, but UserA never logged into MachineB, an alert is generated. - Pass-the-Ticket (PtT): Similar to PtH but uses Kerberos tickets. MDI detects PtT by analyzing Kerberos service ticket requests (TGS-REQ). If a service ticket is used from a machine that did not request it (i.e., the machine's IP differs from the original requester), an alert fires. - Overpass-the-Hash (OPtH): The attacker converts an NTLM hash into a Kerberos ticket. MDI detects this by observing a Kerberos authentication (AS-REQ) from a machine that previously had only NTLM activity for that user, or by detecting a Kerberos request with an unusual encryption type (e.g., RC4 instead of AES).
#### 4. Privilege Escalation (DCSync, Golden Ticket, Silver Ticket) - DCSync Attack: An attacker impersonates a domain controller and requests replication of sensitive credentials (hashes) from a real DC. MDI detects DCSync by monitoring Directory Replication Service (DRS) requests (MS-DRSR protocol). The sensor looks for replication requests from non-DC machines. The detection uses Event ID 4662 (An operation was performed on an object) with access mask '0x100' (DS-Replication-Get-Changes) or '0x200' (DS-Replication-Get-Changes-All). - Golden Ticket Attack: The attacker forges a Kerberos TGT (Ticket Granting Ticket) using the KRBTGT account hash. MDI detects golden tickets by analyzing the Kerberos TGT lifetime. A normal TGT has a maximum lifetime of 10 hours (default). If a TGT has a lifetime exceeding 10 hours or contains unusual authorization data (e.g., extra groups like Domain Admins), an alert is generated. Also, the sensor checks for TGTs that are not issued by a domain controller (e.g., the issuer field is missing). - Silver Ticket Attack: The attacker forges a service ticket (TGS) using a service account's hash. MDI detects silver tickets by monitoring service ticket usage. If a service ticket is used from a machine that is not the authorized client (i.e., the client IP doesn't match the original requester), or if the ticket's encryption type is weak (RC4), an alert fires.
#### 5. Domain Dominance (Skeleton Key, Directory Dumping) - Skeleton Key Attack: A malware injects a backdoor password into the LSASS process on a domain controller, allowing authentication with any user credentials. MDI detects this by monitoring for anomalous behavior on DCs, such as unexpected process creation (e.g., lsass.exe spawning cmd.exe) or unusual authentication patterns (e.g., successful logons with invalid passwords). The sensor uses Event ID 4688 (Process creation) and behavioral baselines. - Directory Dumping (NTDS.dit extraction): Attackers dump the NTDS.dit file to steal all hashes. MDI detects this by monitoring for processes accessing the NTDS.dit file (e.g., ntdsutil.exe, vssadmin.exe) or by detecting Volume Shadow Copy (VSS) creation events. The sensor uses Event ID 4656 (A handle to an object was requested) for file access.
Configuration and Verification
MDI is configured via the Microsoft 365 Defender portal under 'Settings > Identities'. Key settings include: - Sensor settings: Specify which domain controllers to monitor, configure port mirroring, and set health alert notifications. - Detection tuning: Adjust sensitivity for specific detections (e.g., reconnaissance, lateral movement). You can exclude known legitimate activities (e.g., password changes from a specific admin tool). - Alert exclusion: Suppress alerts for specific entities (e.g., a vulnerability scanner).
To verify MDI is working, check the sensor health status in the portal. Also, monitor the 'Identity' timeline for a specific user to see logged activities. Common verification commands include:
- Get-MDISensor (PowerShell module) to list sensors and their status.
- Test-MDIConnectivity to test connectivity to the MDI cloud.
Interaction with Related Technologies
MDI integrates deeply with: - Microsoft Defender for Endpoint (MDE): MDI alerts appear in the Microsoft 365 Defender portal alongside MDE alerts. If MDE detects a process that MDI flags as suspicious (e.g., lsass.exe dump), the alerts are correlated. - Microsoft Defender for Cloud Apps (MDCA): MDI shares identity signals with MDCA to detect cloud app anomalies (e.g., impossible travel). - Azure AD Identity Protection: MDI on-premises detections can be fed into Azure AD Identity Protection for hybrid risk scoring. - Microsoft Sentinel: MDI alerts can be streamed into Sentinel for advanced hunting and automation.
Default Thresholds and Timers
Impossible Travel: Alert if the time between two logons from different locations is less than the travel time (calculated using straight-line distance and typical travel speed). Default minimum time is 5 minutes.
Brute Force: 10 failed logons within 5 minutes.
Password Spray: 30 failed logons with same password across 10+ accounts within 1 hour.
Golden Ticket: TGT lifetime > 10 hours (configurable).
DCSync: Replication request from non-DC machine; alert severity is High.
Exam Tip: Interpreting Alerts
The SC-200 exam will present MDI alert details and ask you to identify the attack type. Focus on the 'suspicious activity' description and the affected entities. For example, 'A user account was used to authenticate from a different location within an impossible time frame' indicates impossible travel. 'A user account attempted to access a resource using a Kerberos ticket with an abnormal lifetime' suggests a golden ticket. Remember that MDI alerts are always based on observed behavior, not just a single event.
Install MDI Sensor on Domain Controller
Download the MDI sensor installer from the Microsoft 365 Defender portal. Run the installer on a domain controller (or dedicated server with port mirroring). The sensor requires .NET Framework 4.7 or later and network access to the MDI cloud service (endpoint: *.atp.azure.com, port 443). During installation, you provide an access key generated from the portal. The sensor captures network traffic via a virtual network adapter (if using port mirroring) or reads Windows Event Logs via ETW. After installation, verify the sensor appears as 'Healthy' in the portal.
Configure Data Collection Sources
In the MDI settings, choose the data collection method: port mirroring (recommended for full visibility) or Windows Event Logs. If using port mirroring, configure the network switch to mirror traffic from the domain controller to the sensor's dedicated port. For Event Logs, ensure the sensor has access to read security logs (Event IDs 4624, 4625, 4672, 4776, etc.). The sensor also requires ETW providers for Kerberos and NTLM. Verify that the collected events are being forwarded to the cloud by checking the sensor health dashboard.
Monitor Sensor Health and Data Flow
In the Microsoft 365 Defender portal, navigate to Settings > Identities > Sensors. Check the status of each sensor: Healthy, Unhealthy, or Stopped. A healthy sensor shows green with no errors. Monitor the 'Data flow' metric to ensure events are being sent. If the sensor is unhealthy, common causes include network connectivity issues, outdated sensor version, or insufficient permissions. Use the 'Test connectivity' feature to diagnose. The sensor sends heartbeats every 5 minutes; missing heartbeats trigger a health alert.
Review Alerts in Microsoft 365 Defender
After MDI generates an alert, it appears in the Microsoft 365 Defender portal under Incidents & Alerts > Alerts. Filter by 'Identity' source. Each alert includes: title, severity (Low, Medium, High), affected entities (users, computers, IPs), attack timeline, and recommended actions. Click on an alert to see the full investigation details, including related events and evidence. For example, a 'Pass-the-Hash' alert shows the source machine, target account, and the NTLM authentication events.
Investigate and Remediate Using Alert Details
Use the alert details to determine the scope of the attack. For a 'DCSync' alert, identify the source machine (non-DC) and the user account used. Check if the account has replication rights (e.g., is a member of Domain Admins). Recommended remediation: disable the compromised account, reset the KRBTGT password twice (to invalidate golden tickets), and investigate the source machine for malware. For 'Impossible Travel', check the user's recent logon locations and times. If the user denies traveling, force a password reset and enable MFA.
Enterprise Scenario 1: Detecting Pass-the-Hash in a Large Enterprise
A multinational corporation with 50,000 users and 200 domain controllers deploys MDI to protect its on-premises Active Directory. The security team configures port mirroring on all DCs to send traffic to MDI sensors. One day, MDI generates a 'Pass-the-Hash' alert: a user account (jdoe) is used to authenticate from a server (SRV-APP01) that jdoe never logs into. Investigation reveals that SRV-APP01 has a vulnerability (EternalBlue) and an attacker has dumped LSASS memory, obtaining jdoe's NTLM hash. The attacker used that hash to move laterally to a file server. The security team isolates SRV-APP01, resets jdoe's password, and uses MDI's timeline to trace the attacker's movements. The alert's high severity and clear evidence (mismatch between user's usual logon and the source machine) enable a swift response.
Enterprise Scenario 2: DCSync Attack on a Government Agency
A government agency with strict compliance requirements uses MDI to detect DCSync attacks. An attacker compromises a workstation with local admin rights and uses Mimikatz to issue DCSync commands. MDI's sensor on the domain controller detects the replication request from the workstation (non-DC) and generates a 'DCSync' alert with severity High. The security analyst sees the alert and immediately identifies the workstation IP. The workstation is isolated, and the attacker's session is terminated. The agency then resets all privileged account passwords and reviews the KRBTGT password. The MDI alert provided the exact time of the attack and the account used (a service account with replication rights). The agency later configures an exclusion for legitimate replication tools to reduce noise.
Scenario 3: Golden Ticket Attack in a Financial Institution
A financial institution suffers a golden ticket attack. MDI detects a Kerberos TGT with a lifetime of 24 hours (default is 10 hours). The alert also shows that the TGT contains extra groups (e.g., Enterprise Admins) not normally assigned. The security team investigates and finds that the KRBTGT account hash was stolen via a DCSync attack earlier. They reset the KRBTGT password twice (to invalidate existing tickets) and force a domain-wide password reset for all accounts. MDI's alert provided the critical clue: the abnormal TGT lifetime. Without MDI, the golden ticket would have gone undetected for days.
Common Misconfigurations
Insufficient network bandwidth: Port mirroring can saturate the sensor if the DC handles high traffic. Solution: use event log collection instead.
Missing event logs: If the sensor cannot read security logs (due to permissions or log size), detections are incomplete. Ensure the sensor runs as NETWORK SERVICE and that security log size is adequate (e.g., 1 GB).
Excluding too many entities: Overly broad exclusions can miss attacks. Use exclusions sparingly and only for known legitimate activities.
SC-200 Exam Focus: Defender for Identity Attack Detections
This topic is tested under Objective 1.2: 'Analyze attack detections in Microsoft Defender for Identity'. The exam expects you to:
Identify the type of attack based on alert descriptions.
Understand the detection mechanism (e.g., what event IDs are used).
Know the default thresholds and timers.
Recognize integration points with other Microsoft 365 Defender components.
Common Wrong Answers
Confusing Pass-the-Hash with Pass-the-Ticket: Both involve lateral movement, but PtH uses NTLM hash, PtT uses Kerberos ticket. Exam questions often describe the authentication protocol used (NTLM vs Kerberos). If the alert mentions 'NTLM authentication', it's PtH. If it mentions 'Kerberos service ticket', it's PtT.
Misidentifying DCSync as Golden Ticket: DCSync involves replication requests (DRS), while Golden Ticket involves forged TGTs. If the alert mentions 'replication' or 'Directory Replication Service', it's DCSync. If it mentions 'TGT with abnormal lifetime', it's Golden Ticket.
Thinking MDI requires agents on all endpoints: MDI only requires a sensor on domain controllers (or dedicated servers). It does not need agents on workstations or servers.
Assuming MDI works without port mirroring: While event logs can be used, port mirroring is required for full network-level visibility (e.g., detecting pass-the-ticket via IP mismatches). The exam may state that port mirroring is optional but recommended.
Specific Numbers and Terms
TGT lifetime default: 10 hours. Any TGT with lifetime > 10 hours is suspicious.
Brute force threshold: 10 failed logons within 5 minutes.
Password spray threshold: 30 failed logons with same password across 10+ accounts within 1 hour.
Event IDs: 4624 (logon), 4625 (failed logon), 4672 (special logon), 4776 (NTLM authentication), 4662 (directory service access), 4688 (process creation).
DRS access masks: 0x100 (Get-Changes), 0x200 (Get-Changes-All).
Edge Cases and Exceptions
Service accounts: MDI can generate false positives for service accounts that perform legitimate replication (e.g., Microsoft DPM). Use exclusions to suppress these.
VPN logons: Impossible travel alerts can be triggered if a user logs in from a VPN with a different IP. MDI uses the client IP from the authentication event; if the VPN IP is in a different geographic region, it may flag as impossible travel. The exam may test that you need to configure trusted IP ranges or VPN integration.
RC4 encryption: Overpass-the-hash uses RC4 encryption for Kerberos requests. If an environment normally uses AES, an RC4 request from a non-DC machine is suspicious.
How to Eliminate Wrong Answers
Read the alert title and description carefully: The alert title often names the attack (e.g., 'Pass-the-Hash'). Don't overthink.
Identify the protocol: NTLM = PtH or Overpass-the-Hash; Kerberos = PtT or Golden/Silver Ticket.
Check the affected entities: If the alert involves a domain controller, it's likely DCSync or Golden Ticket. If it involves a workstation, it's likely lateral movement.
Look for time anomalies: Impossible travel alerts always mention two different locations and a time gap that is too short.
MDI detects identity attacks using sensors on domain controllers; no agents on endpoints required.
Default TGT lifetime is 10 hours; any TGT exceeding this triggers a Golden Ticket alert.
DCSync detection relies on Event ID 4662 with access masks 0x100 or 0x200 from non-DC machines.
Pass-the-Hash is detected by NTLM authentication from an unexpected source IP (Event ID 4776).
Impossible travel alerts require two logons with travel time less than geographic distance allows.
Brute force threshold: 10 failed logons in 5 minutes; password spray: 30 failures with same password across 10+ accounts in 1 hour.
MDI integrates with Microsoft 365 Defender, Sentinel, and Azure AD Identity Protection for unified detection.
Overpass-the-Hash converts NTLM hash to Kerberos ticket; detected by RC4 encryption requests.
Silver ticket detection uses service ticket lifetime and encryption type; weak encryption (RC4) is suspicious.
Skeleton key detection monitors LSASS process anomalies on domain controllers.
These come up on the exam all the time. Here's how to tell them apart.
Pass-the-Hash (PtH)
Uses NTLM hash for authentication.
Detected by correlating NTLM logon events (Event ID 4776) with source IP.
Attackers obtain hash from LSASS dump or Mimikatz.
Commonly used for lateral movement within the same network.
MDI alert: 'Suspected Pass-the-Hash attack'.
Pass-the-Ticket (PtT)
Uses Kerberos service ticket for authentication.
Detected by analyzing Kerberos TGS requests (Event ID 4769) for IP mismatch.
Attackers obtain ticket from LSASS dump or ticket theft.
Can be used to access specific services (e.g., CIFS) without password.
MDI alert: 'Suspected Pass-the-Ticket attack'.
Mistake
MDI can detect all attacks without additional configuration.
Correct
MDI requires proper configuration of data sources (port mirroring or event logs) and may need tuning to reduce false positives. It cannot detect attacks that do not generate the monitored events (e.g., encrypted traffic without decryption).
Mistake
MDI replaces the need for a SIEM like Microsoft Sentinel.
Correct
MDI focuses on identity attacks on-premises. It integrates with Sentinel for broader correlation and automation, but Sentinel provides additional capabilities like custom analytics and threat intelligence.
Mistake
MDI sensors must be installed on all domain controllers.
Correct
MDI sensors can be installed on a subset of domain controllers if port mirroring is configured to forward traffic from all DCs to the sensor. However, for full coverage, each DC should have a sensor or traffic must be mirrored.
Mistake
MDI only works with on-premises Active Directory.
Correct
MDI primarily protects on-premises AD but integrates with Azure AD Identity Protection to extend coverage to cloud identities. It can also monitor hybrid environments where on-premises AD syncs to Azure AD.
Mistake
A golden ticket can be detected by MDI even if the attacker uses a short TGT lifetime.
Correct
MDI also checks for unusual authorization data (e.g., extra SIDs) and TGTs not issued by a domain controller. However, if the attacker uses a normal lifetime and normal data, detection is harder. The exam focuses on the lifetime anomaly.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Pass-the-Hash (PtH) uses an NTLM hash directly to authenticate via NTLM protocol. Overpass-the-Hash (OPtH) converts the NTLM hash into a Kerberos TGT or TGS, allowing Kerberos authentication. MDI detects PtH by correlating NTLM logon events (Event ID 4776) with source IP mismatches. OPtH is detected by observing Kerberos AS-REQ (Event ID 4768) with RC4 encryption (instead of AES) from a machine that previously only used NTLM for that user. The exam may present an alert that says 'Overpass-the-Hash' and you need to know it involves Kerberos.
MDI detects Golden Ticket attacks primarily by analyzing the Kerberos TGT lifetime. A legitimate TGT has a maximum lifetime of 10 hours (default). If a TGT has a lifetime exceeding 10 hours, MDI generates an alert. Additionally, MDI checks for unusual authorization data (e.g., extra group memberships like Domain Admins) and TGTs that are not issued by a domain controller (e.g., missing issuer field). The detection uses Event ID 4768 (Kerberos TGT request) and the ticket's ticket. The exam expects you to know the 10-hour threshold.
Yes, MDI can detect many attacks using Windows Event Logs alone, but port mirroring provides additional network-level data that improves detection accuracy. For example, pass-the-ticket detection relies on IP address mismatches, which require network traffic visibility. Without port mirroring, MDI uses the source IP from the event log (which may be the DC's IP if the event is collected on the DC). The exam may state that port mirroring is recommended for full detection capabilities.
DCSync is an attack where an attacker impersonates a domain controller to request replication of sensitive credentials (password hashes) from a real DC. MDI detects DCSync by monitoring Directory Replication Service (DRS) requests. The sensor looks for Event ID 4662 (An operation was performed on an object) where the object is the domain or a domain controller, and the access mask is 0x100 (DS-Replication-Get-Changes) or 0x200 (DS-Replication-Get-Changes-All). The alert triggers if the request originates from a non-DC machine. The exam tests that you recognize the access masks and that the source is not a DC.
You can configure exclusions in the MDI settings under 'Detection tuning'. For example, if a vulnerability scanner performs reconnaissance, you can exclude its IP address or user account. To exclude a specific type of alert, go to Configuration > Exclusions and add the entity (user, computer, IP). You can also create custom detection rules to suppress alerts for known legitimate behaviors. However, be cautious: over-excluding can blind you to real attacks. The exam may test that exclusions are configured per detection type.
A Golden Ticket is a forged Kerberos TGT that grants the attacker domain admin privileges. It is created using the KRBTGT account hash. A Silver Ticket is a forged TGS service ticket that grants access to a specific service (e.g., CIFS, HTTP) using the service account's hash. MDI detects Golden Tickets by abnormal TGT lifetime (>10 hours) and Silver Tickets by unusual service ticket usage (e.g., client IP mismatch) or weak encryption (RC4). The exam expects you to know that Golden Tickets affect the entire domain, while Silver Tickets target specific services.
MDI primarily monitors on-premises Active Directory. However, it integrates with Azure AD Identity Protection to provide a hybrid view. For example, if MDI detects a compromised on-premises account that syncs to Azure AD, the risk score in Azure AD Identity Protection is updated. MDI does not directly monitor Azure AD events; that is done by Azure AD Identity Protection and Microsoft Defender for Cloud Apps. The exam may ask about integration points.
You've just covered Defender for Identity Attack Detections — now see how well it sticks with free SC-200 practice questions. Full explanations included, no account needed.
Done with this chapter?