How to Detect DCSync Attacks Against Active Directory

Normal AD replication happens between domain controllers. Legitimate replication requests:

• Source: a domain controller computer account (ending in $)
• Destination: another domain controller
• Scheduled automatically by the KCC (Knowledge Consistency Checker)

DCSync attack:

• Source: a non-DC account (a user, workstation, or service account)
• The source initiates replication using Mimikatz, Impacket's secretsdump.py, or similar tools
• From any machine that has network connectivity to a DC on port 135 (RPC endpoint mapper)

DCSync with Mimikatz (what it looks like to an attacker):

# Dump all hashes from the domain
mimikatz# lsadump::dcsync /domain:corp.local /all /csv

# Dump a specific account (most valuable: krbtgt, Administrator)
mimikatz# lsadump::dcsync /domain:corp.local /user:krbtgt

# Output includes:
# [DC] 'corp.local' will be the domain
# [rpc] Service : ldap
# [rpc] AuthnSvc : GSS_NEGOTIATE (9)
# Object RDN          : krbtgt
# Hash NTLM: 9b3e7d8a5c2f4e1b6d0a8c3f7e2b4d9a
# ntlm-0: 9b3e7d8a5c2f4e1b6d0a8c3f7e2b4d9a
# lm-0: (not set)

Impacket secretsdump.py (Linux-based):

# From any machine with network access to the DC
python3 secretsdump.py corp.local/attackeraccount:password@dc01.corp.local
# Or using a hash directly (after Pass-the-Hash)
python3 secretsdump.py -hashes :NTLM_HASH corp.local/attackeraccount@dc01.corp.local

DCSync generates Event ID 4662 on domain controllers: 'An operation was performed on an object': when the replication rights are exercised. The key is filtering on the specific GUIDs that identify directory replication operations.

The replication GUIDs to watch:

1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 : Replicating Directory Changes
1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 : Replicating Directory Changes All (the dangerous one)
89e95b76-444d-4c62-991a-0facbeda640c : Replicating Directory Changes In Filtered Set

Prerequisite: Event 4662 requires the "Audit Directory Service Access" policy to be enabled:

Computer Configuration > Windows Settings > Security Settings >
Advanced Audit Policy > DS Access > Audit Directory Service Access > Success

Microsoft Sentinel KQL: DCSync detection:

SecurityEvent
| where EventID == 4662
| where ObjectType contains "domainDNS"
| where Properties has_any (
    "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2",
    "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2",
    "89e95b76-444d-4c62-991a-0facbeda640c"
  )
| where AccountName !endswith "$"  // Exclude DC machine accounts (legitimate replication)
| where AccountName != "MSOL_*"    // Exclude Azure AD Sync service accounts
| project
    TimeGenerated,
    SubjectAccount = AccountName,
    SubjectDomain = SubjectDomainName,
    SourceComputer = Computer,
    Properties
| sort by TimeGenerated desc

Splunk SPL: DCSync detection:

index=wineventlog EventCode=4662
| where ObjectType="domainDNS"
| where (Properties LIKE "%1131f6aa-9c07-11d1-f79f-00c04fc2dcd2%"
      OR Properties LIKE "%1131f6ad-9c07-11d1-f79f-00c04fc2dcd2%"
      OR Properties LIKE "%89e95b76-444d-4c62-991a-0facbeda640c%")
| where NOT match(Security_ID, ".*\$@?$")  /* Exclude machine accounts */
| where NOT match(Account_Name, "MSOL_.*")  /* Exclude Azure AD Sync */
| table _time, Account_Name, Account_Domain, Logon_ID, host, Properties
| sort -_time

Tuning out false positives:

• Azure AD Connect / MSOL_ accounts perform legitimate directory replication: add them to an exclusion list
• Third-party AD sync tools (Okta AD agent, etc.) may also generate these events: identify legitimate sync accounts and exclude by name
• Remaining events after exclusion are very high confidence

The best DCSync prevention is ensuring only domain controller machine accounts have replication rights. Audit this regularly.

PowerShell: Find all principals with replication rights:

# Check who has replication permissions on the domain NC
$domainDN = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:\$domainDN"

# Filter for Replicating Directory Changes (All)
$replicationGuids = @(
    "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2",  # Replicating Directory Changes
    "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2"   # Replicating Directory Changes All
)

$acl.Access | Where-Object {
    $_.ObjectType.ToString() -in $replicationGuids -and
    $_.AccessControlType -eq 'Allow'
} | Select-Object IdentityReference, ObjectType, AccessControlType | Sort-Object IdentityReference

Expected legitimate entries:

NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS
NT AUTHORITY\SYSTEM
CORP\Domain Controllers
CORP\Enterprise Read-only Domain Controllers
CORP\MSOL_<guid>  (Azure AD Connect: only if used)
CORP\Administrators  (by default: consider removing if not needed)

Remove replication rights from a non-DC account:

# If a non-DC account has been granted replication rights, remove it
$domainDN = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:\$domainDN"

$accountToRemove = "CORP\compromised-service-account"

$acl.Access | Where-Object {
    $_.IdentityReference -eq $accountToRemove
} | ForEach-Object {
    $acl.RemoveAccessRule($_)
}

Set-Acl "AD:\$domainDN" $acl

Regular audit schedule: Run the permission audit monthly and alert on any changes to the ACL of the domain NC object: a new entry granting replication rights is a critical incident indicator.

DCSync detection is a critical incident: by the time the alert fires, the attacker likely has NTLM hashes for privileged accounts including potentially krbtgt.

Immediate response steps:

1. Identify the source account: Which account triggered the Event 4662? This is the compromised credential.

2. Disable the source account immediately:

Disable-ADAccount -Identity "compromised-account"
Get-ADUser "compromised-account" -Properties * | Select-Object Enabled, LastLogonDate

1. Assess what was extracted: Correlate the DCSync event timestamp with the account's privileges. Was it a domain admin? Could krbtgt have been targeted?

2. If krbtgt may have been extracted: double-rotate krbtgt:

# Rotate krbtgt password TWICE with 10-hour gap between rotations
# This is required because Kerberos tickets are valid for 10 hours by default
# First rotation invalidates current tickets after they expire
# Second rotation invalidates any new tickets issued with the first hash

# First rotation (use Microsoft's New-KrbtgtKeys.ps1 script)
# https://github.com/microsoft/New-KrbtgtKeys.ps1
.\New-KrbtgtKeys.ps1
# Wait 10+ hours
.\New-KrbtgtKeys.ps1

1. Rotate all domain admin passwords: Any account whose hash was potentially extracted should have its password rotated immediately: especially any privileged accounts.

2. Hunt for Golden Tickets: Check for Event ID 4769 with ticket encryption type 0x17 and ticket options that do not match normal patterns: these may indicate Golden Ticket use.