How to Configure Microsoft Defender for Identity (MDI) to Detect Active Directory DCSync Attacks

In traditional on-premises Microsoft Active Directory environments, domain controllers replicate password hashes with each other to maintain consistency. When an attacker compromises an account with sufficiently high privileges (such as a Domain Admin or an account with Replicating Directory Changes rights), they can exploit this native functionality using a DCSync attack.

By mimicking the behavior of a legitimate domain controller, the attacker’s machine requests Active Directory to sync the password hashes of all users—including the critical krbtgt account. Once the attacker possesses the krbtgt hash, they can forge Golden Tickets, achieving total, persistent domain dominance. Because DCSync relies on a legitimate Windows API (IDL_DRSR Domain Controller Replication), it does not trigger standard antivirus or EDR malware alerts.

To detect and mitigate this, organizations must deploy Microsoft Defender for Identity (MDI). MDI utilizes deeply integrated network packet inspection and Active Directory event logging to identify anomalous replication behavior.

This guide explains the architecture of a DCSync attack and how to configure MDI sensors to detect and alert on it instantly.

Understanding DCSync Architecture

A DCSync attack (most commonly executed via the Mimikatz lsadump::dcsync module) operates via the Directory Replication Service Remote Protocol (MS-DRSR).

The workflow is simple:

1. The attacker authenticates to a legitimate Domain Controller using compromised credentials possessing the DS-Replication-Get-Changes and DS-Replication-Get-Changes-All extended rights.
2. The attacker’s machine binds to the RPC endpoint on the Domain Controller.
3. The attacker’s machine issues an NCReplicaPull request, asking for the secret attributes (password hashes) of specific users.
4. The Domain Controller, seeing the valid permissions, obliges and sends the NTLM hashes over the network.

Because the attacker is not injecting code into lsass.exe on the Domain Controller itself, traditional EDR sensors on the DC see nothing malicious. The attack occurs entirely over the network.

Step 1: Deploying the MDI Sensor on Domain Controllers

To detect the MS-DRSR network traffic, the Microsoft Defender for Identity sensor must be installed directly on all Domain Controllers. The MDI sensor acts as a packet capture (PCAP) engine, silently monitoring all incoming RPC and Kerberos traffic to the DC without requiring port mirroring or spanning.

1. Navigate to the Microsoft Defender portal (security.microsoft.com).
2. Go to Settings > Identities > Sensors.
3. Click Add sensor and download the installer and the Access Key.
4. Install the sensor on every Domain Controller in the forest.

Step 2: Configuring Advanced Audit Policies (Windows Event Forwarding)

While the network sensor detects the RPC traffic, MDI requires specific Windows Event Logs to accurately correlate the network traffic with the exact user account performing the attack, eliminating false positives.

You must configure the Default Domain Controllers Group Policy to enforce Advanced Audit Policies.

1. Open Group Policy Management on a DC.
2. Edit the Default Domain Controllers Policy.
3. Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration.
4. Configure the following critical subcategories to Success and Failure:
   • Audit Directory Service Access (Required to track who is requesting replication).
   • Audit Logon and Audit Logoff.
   • Audit Special Logon.

Apply the Group Policy (gpupdate /force). The MDI sensor automatically ingests these local Event Viewer logs and correlates them with the network traffic.

Step 3: Simulating and Detecting the DCSync Attack

With the MDI sensor active, you can safely test the detection logic in a lab environment using Mimikatz or the PowerShell Invoke-DCSync module.

From a domain-joined workstation, logged in as a Domain Admin, execute the Mimikatz DCSync command targeting the krbtgt account:

mimikatz.exe "lsadump::dcsync /domain:internalcorp.local /user:krbtgt" "exit"

Almost instantly, the MDI sensor detects the NCReplicaPull RPC request originating from an IP address that is not a known, registered Domain Controller in the forest.

In the Microsoft Defender portal, a high-severity alert will trigger:

Alert Title: Suspected DCSync attack (replication of directory services)

The alert details will explicitly outline:

• Source IP: The exact IP address of the attacker’s workstation.
• Compromised Account: The Domain Admin credentials used to authorize the replication.
• Targeted Accounts: The specific accounts (e.g., krbtgt) whose hashes were requested.

Step 4: Automating Remediation via MDE Integration

Detecting the attack is only half the battle. If an attacker has DCSynced the krbtgt account, they have the keys to the kingdom. You must respond instantly.

Because Microsoft Defender for Identity (MDI) integrates natively with Microsoft Defender for Endpoint (MDE), you can configure automated response playbooks.

1. In the Defender portal, go to Settings > Endpoints > Advanced features.
2. Ensure Microsoft Defender for Identity integration is enabled.

When the DCSync alert triggers, the integrated XDR engine can automatically issue a Device Isolation command to the Source IP (the attacker’s workstation), completely cutting it off from the network and preventing the exfiltration of the stolen hashes or the subsequent deployment of a Golden Ticket. Furthermore, the compromised user account can be instantly marked as “High Risk” in Entra ID, automatically revoking their cloud sessions via Continuous Access Evaluation (CAE).

Conclusion

The DCSync attack leverages the foundational architecture of Active Directory against itself, making it invisible to standard endpoint security. By deploying Microsoft Defender for Identity sensors directly on Domain Controllers, organizations gain deep RPC protocol inspection capabilities, ensuring that any unauthorized directory replication is detected and instantly isolated before domain dominance is achieved.