Detecting DCSync and Domain Replication Attacks (T1003.006) with Sigma and KQL

DCSync is one of the most effective credential theft techniques in Active Directory environments, and it is regularly used by ransomware operators, state-sponsored actors, and red teams for the same reason: it extracts all domain credential hashes without touching the domain controller’s disk or running any executable on the DC itself. The technique abuses the legitimate Directory Replication Service Remote Protocol (DRSR), specifically the GetNCChanges RPC call that domain controllers use to synchronise with each other.

The attacker’s account needs one of three rights: DS-Replication-Get-Changes, DS-Replication-Get-Changes-All, or membership in Domain Admins, Enterprise Admins, or Domain Controllers. Once those rights are present, DCSync looks like a legitimate DC-to-DC replication request from the DC’s perspective — which is what makes it so powerful.

How DCSync Works

Mimikatz’s lsadump::dcsync is the most common implementation, but PowerShell and Python equivalents (Impacket’s secretsdump.py) are widely used. The sequence:

The attacker’s tool opens an authenticated connection to a domain controller
It identifies itself as a replication partner using the DRSR protocol
It calls DsGetNCChanges (GetNCChanges) to request a replication delta
The DC responds with the requested objects including unicodePwd (NTLM hash) and supplementalCredentials (Kerberos keys, historical hashes)
The tool extracts the credential material from the response

No code runs on the DC. No files are written. The only evidence is network traffic and the DC’s own replication audit logs — if those are enabled.

Log Sources

Detection requires Windows Event Logs from the domain controller itself, specifically:

Event ID 4662 — An operation was performed on an object. DCSync triggers this when it accesses directory objects with the replication permissions.
Event ID 4624 / 4625 — Logon events for the account performing replication, particularly when the source IP is unexpected.
Security audit: Directory Service Access must be enabled via Group Policy for Event 4662 to fire.

Event 4662 is essential but noisy by default. The filter is the GUID of the replication extended right in the Properties field:

{1131f6aa-9c07-11d1-f79f-00c04fc2dcd2} — Replicating Directory Changes (DS-Replication-Get-Changes)
{1131f6ab-9c07-11d1-f79f-00c04fc2dcd2} — Replicating Directory Changes All (DS-Replication-Get-Changes-All)
{89e95b76-444d-4c62-991a-0facbeda640c} — Replicating Directory Changes In Filtered Set

A GetNCChanges operation from a non-DC IP against these GUIDs is the core detection signal.

Sigma Rule: DCSync via DRSR Extended Rights (Event 4662)

title: DCSync Attack via Directory Replication Extended Rights
id: 1693f1e5-8a97-4c6e-bb42-7f0a25e4a9d2
status: stable
description: Detects DCSync attacks by identifying access to Active Directory replication extended rights from a non-domain-controller account.
author: SOC Analyst Hub
date: 2026-07-12
references:
  - https://attack.mitre.org/techniques/T1003/006/
  - https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-drsr/
tags:
  - attack.credential_access
  - attack.t1003.006
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4662
    Properties|contains:
      - '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2'
      - '1131f6ab-9c07-11d1-f79f-00c04fc2dcd2'
      - '89e95b76-444d-4c62-991a-0facbeda640c'
    AccessMask: '0x100'
  filter_legitimate_dcs:
    SubjectUserName|endswith: '$'
    SubjectUserName|contains:
      - 'DC'
  condition: selection and not filter_legitimate_dcs
falsepositives:
  - Legitimate domain controller accounts replicating (filter by known DC names)
  - AAD Connect and ADFS service accounts with replication permissions
  - Azure AD Connect (use ComputerName and account filters)
level: high

Tuning notes: The filter attempts to exclude machine accounts (those ending in $) from known DCs. In practice you should maintain an explicit allowlist of legitimate DC computer names and AAD Connect service account names. Any match from a workstation IP or a regular user account should be treated as high-confidence.

Sigma Rule: DCSync from Impacket (Network Signature)

Impacket’s secretsdump.py has a distinctive DRSR bind UUID that can be detected at the network level if you capture RPC traffic:

title: Impacket SecretsDump DCSync RPC Binding
id: 2d7f6c3a-18b4-4d12-93a1-bc7291e5f4e8
status: experimental
description: Detects Impacket secretsdump DCSync activity via DRSR RPC binding on unexpected source hosts.
author: SOC Analyst Hub
date: 2026-07-12
tags:
  - attack.credential_access
  - attack.t1003.006
logsource:
  product: zeek
  service: dce_rpc
detection:
  selection:
    endpoint: 'drsuapi'
    operation: 'DsGetNCChanges'
  filter_legitimate:
    id.orig_h|startswith:
      - '10.0.0.'  # Replace with DC subnet ranges
  condition: selection and not filter_legitimate
falsepositives:
  - Azure AD Connect running on non-DC hosts
  - Legitimate replication from trusted DC subnet
level: high

KQL Detection (Microsoft Sentinel / Defender for Identity)

Event 4662 — DCSync Replication Rights Access

SecurityEvent
| where EventID == 4662
| where Properties has_any (
    "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2",
    "1131f6ab-9c07-11d1-f79f-00c04fc2dcd2",
    "89e95b76-444d-4c62-991a-0facbeda640c"
)
| where AccessMask == "0x100"
// Exclude known DC machine accounts
| where SubjectUserName !endswith "$"
| project TimeGenerated, SubjectUserName, SubjectDomainName, 
          SubjectLogonId, AccessMask, Properties, Computer
| sort by TimeGenerated desc

Defender for Identity (MDI) — Built-in Alert Enrichment

MDI raises Domain controller replication requested alerts natively when it detects DCSync. If you have MDI deployed, the following Sentinel query surfaces these with enrichment:

IdentityDirectoryEvents
| where ActionType == "Directory replication"
| where Application != "Microsoft Azure Active Directory Connect"
// Filter out known DC hostnames
| where DeviceName !in~ (
    "DC01.corp.local",
    "DC02.corp.local"
    // add all your DC names here
)
| project Timestamp, AccountName, AccountDomain, DeviceName, 
          IPAddress, Application, AdditionalFields
| sort by Timestamp desc

Correlating with Preceding Enumeration

DCSync almost always follows LDAP enumeration (to identify high-value targets) and privilege escalation. This hunt query looks for the combination:

let DCSyncAccounts = 
    SecurityEvent
    | where EventID == 4662
    | where Properties has_any (
        "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2",
        "1131f6ab-9c07-11d1-f79f-00c04fc2dcd2"
    )
    | where SubjectUserName !endswith "$"
    | summarize by SubjectUserName, SubjectLogonId;
SecurityEvent
| where EventID in (4624, 4625, 4768, 4769)
| join kind=inner DCSyncAccounts on $left.TargetUserName == $right.SubjectUserName
| project TimeGenerated, EventID, TargetUserName, IpAddress, LogonType
| sort by TimeGenerated desc

Defender for Identity — Native Detection

Microsoft Defender for Identity (formerly Azure ATP) has a built-in detection for DCSync: Suspected DCSync attack (replication of directory services). If MDI is deployed with sensors on all domain controllers, this fires automatically when a non-DC account makes DsGetNCChanges calls.

MDI’s detection is highly reliable because its sensor observes network traffic directly at the DC rather than relying solely on event logs. However, organisations without MDI sensors on all DCs may have visibility gaps — particularly for read-only domain controllers or branch-site DCs.

Detection Engineering Considerations

False positive sources that need filtering:

Source	Behaviour	Filter
AAD Connect	Runs `secretsdump`-like replication to sync hashes	Filter by service account name and source IP
ADFS accounts	May have DS-Replication-Get-Changes	Filter by known ADFS server IP
Third-party IdP sync tools	Same DRSR calls for sync	Build explicit allowlist
Backup/recovery software	Some products read AD objects via DRSR	Verify with vendor

Enable DS Access auditing if you haven’t already:

Computer Configuration > Policies > Windows Settings > Security Settings
> Advanced Audit Policy Configuration > DS Access
> Audit Directory Service Access: Success, Failure

Without this, Event 4662 will not fire.

Response Actions

When DCSync is confirmed:

Immediate: Isolate the compromised account. Disable it, rotate its credentials, revoke any active sessions (Get-ADUser -Filter * | Disable-ADAccount).
Scope: Determine whether the NTLM hashes of privileged accounts were extracted. DCSync gives the attacker every hash in the domain — treat this as a full domain compromise until proven otherwise.
Remediate: Rotate the KRBTGT account password twice (Kerberos Golden Ticket invalidation), then rotate all privileged account passwords. Azure AD Connect and ADFS service accounts need rotation if they had replication rights.
AD Tiering review: DCSync from a non-DC account means replication rights were misconfigured. Audit the ACL on the domain root object (Get-ACL "AD:DC=corp,DC=local") and remove any non-DC principals holding replication extended rights.
Purple team: Run a controlled DCSync from a test account in a lab or staging environment to validate your detection stack fires as expected before the next real incident.