Microsoft Defender for Identity

Microsoft Defender for Identity (MDI) is a cloud-based security solution that leverages your on-premises Active Directory (AD) signals to identify, detect, and investigate advanced threats, compromised identities, and malicious insider actions directed at your organization. It was formerly known as Azure Advanced Threat Protection (Azure ATP) and is part of the Microsoft 365 Defender suite. MDI uses machine learning and behavioral analytics to profile normal user and entity behavior and then identifies suspicious activities that deviate from those baselines.

Traditional perimeter defenses are insufficient against modern identity attacks. Attackers often compromise a single user credential and then move laterally across the network, escalating privileges until they reach domain admin. MDI fills the gap by monitoring AD traffic, Windows Event Logs, and other signals to detect attacks that traditional antivirus or firewalls miss. It provides a dedicated identity threat detection and response (ITDR) capability.

MDI consists of sensors installed on domain controllers (DCs) or on dedicated servers that monitor network traffic and Windows events. The sensors forward parsed data to the MDI cloud service for analysis. Here is the step-by-step mechanism:

1. Sensor Installation and Configuration: You install the MDI sensor on each domain controller or on a dedicated server (standalone sensor) that receives mirrored traffic from DCs via port mirroring. The sensor requires .NET Framework 4.7 or later and at least 2 cores and 6 GB RAM for DCs with up to 100,000 users. 2. Data Collection: The sensor captures network traffic using Windows Packet Filter (WinPcap) or Npcap. It listens on port 88 (Kerberos), 389 (LDAP), 445 (SMB), and others. It also collects Windows Event IDs from the security log: 4624 (successful logon), 4625 (failed logon), 4672 (special privileges assigned), 4776 (credential validation), and others. Additionally, it queries AD for entity attributes like group memberships and trust relationships. 3. Parsing and Filtering: The sensor parses the raw packets to extract authentication requests, Kerberos tickets, NTLM authentications, and SMB sessions. It filters out noise and sends only security-relevant events to the cloud service over HTTPS (port 443) using certificate-based authentication. 4. Cloud Analysis: The MDI cloud service receives the data and applies behavioral analytics, machine learning models, and threat intelligence from Microsoft. It builds a baseline of normal behavior for each user and device over a period (typically 14-30 days). Then it compares real-time events against that baseline. 5. Alert Generation: When an event deviates significantly from the baseline, MDI generates an alert. Examples include: - Suspicious Kerberos activity: e.g., unusual Kerberos ticket requests that could indicate a Golden Ticket attack. - Pass-the-Hash: detection of NTLM authentication using a hash that was previously observed on a different machine. - Privilege escalation: e.g., a standard user suddenly adds themselves to the Domain Admins group. - Honeytoken activity: MDI supports setting fake accounts or groups (honeytokens) that should never be used; any activity on them triggers a high-severity alert. 6. Investigation and Response: Security analysts can investigate alerts in the Microsoft 365 Defender portal (security.microsoft.com). MDI provides a timeline of entity activities, lateral movement paths, and related alerts. It integrates with Microsoft Defender for Identity's automatic response actions, such as disabling a compromised user account or initiating an investigation with Microsoft 365 Defender's automated investigation and response (AIR).

To verify sensor health, you can use PowerShell cmdlets from the MDI sensor module:

Get-MDISensorStatus

This returns the sensor health, last activity time, and configuration status.

To check if the sensor is receiving traffic:

Get-MDINetworkActivity

This shows recent network captures.

In the Microsoft 365 Defender portal, navigate to Settings > Identities > Sensors to view sensor status (green=healthy, yellow=warning, red=error).

MDI integrates deeply with: - Microsoft 365 Defender: Alerts from MDI appear in the unified incident queue alongside alerts from Microsoft Defender for Endpoint, Microsoft Defender for Office 365, and Microsoft Defender for Cloud Apps. - Azure Active Directory (Azure AD): MDI can trigger conditional access policies via risk detection. For example, if MDI detects a suspicious logon, it can signal Azure AD Identity Protection to enforce MFA on the next login. - Microsoft Defender for Cloud Apps: MDI alerts can be correlated with cloud app activities to detect hybrid attacks. - Windows Defender Firewall: MDI can automatically block IP addresses associated with malicious activity on the network. - SIEM integration: MDI forwards alerts to Azure Sentinel or third-party SIEMs via CEF or Syslog.

A large enterprise with 50,000 users and 200 domain controllers deploys MDI sensors on all DCs. One day, MDI detects a series of NTLM authentications where the same NTLM hash is used from multiple workstations that have no administrative relationship. This is a classic pass-the-hash attack. The alert includes the source IPs and the compromised account. The SOC team immediately disables the account and investigates the workstations. MDI's lateral movement path graph shows that the attacker used the compromised account to access a file server and then attempted to dump credentials. The integration with Microsoft 365 Defender allows the SOC to isolate the affected machines automatically. The attack is contained within 15 minutes, preventing privilege escalation to domain admin.

A financial institution with strict compliance requirements uses MDI to monitor Kerberos activity. MDI detects an unusual Kerberos ticket request where the ticket's validity period is set to 10 years (default is 10 hours) and the ticket contains elevated privileges for a standard user. This is a Golden Ticket attack. MDI generates a high-severity alert. The SOC reviews the alert and confirms that the domain controller's KRBTGT account hash was compromised. They reset the KRBTGT password twice (as per Microsoft best practice) and revoke all existing Kerberos tickets. MDI's integration with Azure Sentinel allows them to create a custom analytics rule for future detection.

A mid-size company deploys MDI but fails to configure port mirroring for the standalone sensor. As a result, the sensor only captures events from the Windows Event Log, missing crucial network-level indicators like SMB sessions and Kerberos ticket requests. MDI generates fewer alerts, and a lateral movement attack goes undetected for weeks. When the company finally enables port mirroring, MDI immediately detects multiple suspicious activities. This highlights the importance of proper network traffic capture for full detection coverage. Additionally, the company did not configure honeytokens, missing an easy detection opportunity for attackers probing the environment.