DCSync Attack Detection — Mimikatz Replication & AD Credential Dumping

MITRE ATT&CK

Security Relevance

DCSync is the domain-level equivalent of dumping the entire credential database. Unlike LSASS dumping, it requires no code execution on the DC — it runs entirely over the network using legitimate AD replication protocol (DRSUAPI). Once an attacker has the krbtgt hash, they can forge Golden Tickets granting themselves Domain Admin access for up to 10 years, surviving password resets and account deletions. Domain Admin hash extraction enables immediate lateral movement to every system in the domain.

Indicators of Malicious Use

• ⚑Event 4662: Properties field contains GUID 1131f6ad-91a1-11d0-9ca0-00c04fd8d5cd (DS-Replication-Get-Changes-All)
• ⚑Event 4662: Properties field contains GUID 1131f6aa-91a1-11d0-9ca0-00c04fd8d5cd (DS-Replication-Get-Changes)
• ⚑Event 4662: Object Type is domainDNS and Object Name matches the domain root (DC=corp,DC=local)
• ⚑Event 4662: Subject Account Name is a user account, not a machine account (no trailing $)
• ⚑Process execution (4688): mimikatz, secretsdump, impacket, lsadump in command line or process name
• ⚑Event 4624 Logon Type 3 from a workstation to a DC immediately before 4662 events — attacker authenticating before replicating

Example Log Entry

Log Name: Security
Event ID:  4662
Level:     Information

An operation was performed on an object.

Subject:
  Account Name:  jsmith
  Account Domain: CORP
  Logon ID:      0x7B3A91

Object:
  Object Server: DS
  Object Type:   domainDNS
  Object Name:   DC=corp,DC=local
  Handle ID:     0x0

Operation:
  Properties:
    1131f6ad-91a1-11d0-9ca0-00c04fd8d5cd
      (DS-Replication-Get-Changes-All)
    1131f6aa-91a1-11d0-9ca0-00c04fd8d5cd
      (DS-Replication-Get-Changes)
  Access Mask: 0x100

Investigation Steps

1. 1.Check the Subject Account Name in Event 4662 — machine accounts (ending in $) are legitimate DC-to-DC replication. Any user account (jsmith, svc-backup, administrator) performing replication is an immediate escalation.
2. 2.Confirm whether the source host is a domain controller — check your DC list against the computer account. A member server or workstation generating 4662 with replication GUIDs is a confirmed DCSync.
3. 3.Search for Mimikatz or Impacket indicators: Event 4688 for processes named mimikatz, secretsdump, lsadump, or impacket within 30 minutes of the 4662 event. Also check PowerShell script block logs (4104) for 'dcsync', 'lsadump', or 'drsuapi'.
4. 4.Identify what accounts were targeted — if krbtgt was replicated, assume Golden Ticket capability and initiate a double krbtgt password reset (must be done twice, 10 hours apart, to invalidate all existing tickets).
5. 5.Check for prior privilege escalation — DCSync requires Replicating Directory Changes All, granted to Domain Admins and SYSTEM by default. Look for recent group membership changes (4728/4732) or token abuse (4672) for the subject account.
6. 6.Review Event 4624 for the subject account on domain controllers in the hour before the 4662 events — this is the attacker's authentication step and may reveal the originating workstation and lateral movement path.
7. 7.Contain immediately — rotate all privileged account passwords, perform double krbtgt reset, and audit what the compromised account had access to. Assume all domain account hashes are compromised.

Common False Positives

• ◎Azure AD Connect — uses a service account with DS-Replication-Get-Changes-All to sync identities with Azure AD. This is the most common false positive. The account name is typically MSOL_xxxxxxxx. Baseline and exclude this account.
• ◎Veeam and other backup solutions — some backup agents replicate AD objects for backup/recovery purposes. Verify the account name matches a known backup service account.
• ◎Quest Migration Manager, ADMT, and other AD migration tools — legitimately request replication rights during domain migration projects. Verify against change windows.
• ◎AD monitoring tools (e.g. Semperis Directory Services Protector) — monitor AD replication as part of their threat detection. Known tool accounts should be baselined.

Remediation

• ✓Double-reset the krbtgt password immediately — reset it once, wait 10 hours (maximum ticket lifetime), then reset it again. This invalidates all existing Kerberos tickets including any forged Golden Tickets.
• ✓Rotate all privileged account passwords — Domain Admins, service accounts, and built-in Administrator. Assume any account hash that could have been replicated is compromised.
• ✓Audit DS-Replication-Get-Changes-All grant assignments — run 'Get-ADObject -Filter * -Properties nTSecurityDescriptor' to find all non-DC principals with replication rights. Remove any that are unexpected.
• ✓Enable 'Audit Directory Service Access' under Advanced Audit Policy Configuration → DS Access — this is required to generate Event 4662. Many organizations have it disabled by default.
• ✓Deploy Protected Users group for all privileged accounts — prevents NTLM authentication and Kerberos delegation, limiting the usefulness of extracted hashes.
• ✓Investigate the attacker's initial access and privilege escalation path — DCSync requires Domain Admin or equivalent. Determine how the attacker gained those privileges and close the vector.

Related Event IDs

Related Detection Guides

Frequently Asked Questions

Why am I seeing Event ID 4662 on my domain controller?

Domain controllers log many 4662 events from legitimate replication — Azure AD Connect (MSOL_ accounts), Veeam, ADMT, and Quest are common sources. Malicious DCSync is indicated when the Source Network Address is a non-DC machine and the access rights include GUID 1131f6ad-91a1-11d0-9ca0-00c04fd8d5cd (DS-Replication-Get-Changes-All). Filter by source IP to separate known replication partners from anomalous hosts.

Can DCSync be detected without Sysmon?

Yes. Event ID 4662 in the Windows Security log captures DCSync operations if 'Audit Directory Service Access' policy is enabled. No Sysmon required. The key fields are Access Rights (look for the replication GUIDs) and Subject Account Name (should be a DC computer account or known sync account, not a workstation or user account).

Does Microsoft Defender detect DCSync?

Microsoft Defender for Identity (cloud-based, requires sensor on DCs) detects DCSync by analyzing replication traffic. Windows Defender Antivirus alone does not detect DCSync — it may flag Mimikatz by signature, but the underlying replication request is a legitimate Windows protocol. Assume a motivated attacker using custom tooling can evade AV.

What is the difference between DCSync and NTDS.dit dumping?

DCSync simulates a domain controller replication request over the network, pulling hashes without touching the DC's disk — it requires domain replication rights but only network access to the DC. NTDS.dit dumping copies the credential database file directly from the DC's disk via VSS shadow copy or direct access, requiring local DC access. Both yield the same result: all domain account hashes.