DCSync and DCShadow are two of the highest-impact techniques in Active Directory attacks. Both abuse the replication protocol that domain controllers use to synchronise with each other. Neither requires the attacker to log on to a domain controller directly. Both can be performed from any machine in the domain by an account with sufficient permissions, and “sufficient permissions” is lower than most administrators realise.<\/p>\n
The AD replication protocol (MS-DRSR, Directory Replication Service Remote Protocol) allows domain controllers to request credential data from each other. An account with the “Replicating Directory Changes All” permission can initiate this replication from any machine, not just a domain controller. Mimikatz’s lsadump::dcsync module does exactly this, requesting the NTLM hash, Kerberos keys, and password history for any account including krbtgt and Domain Admin accounts.<\/p>\n
\/\/ What DCSync looks like to the attacker\n\/\/ (Understanding the technique is essential for detection)\n\/\/ Mimikatz: lsadump::dcsync \/user:krbtgt \/domain:corp.local\n\/\/ Impacket: secretsdump.py DOMAIN\/user:password@DC_IP\n\n\/\/ What this returns:\n\/\/ krbtgt NTLM hash (used to forge Golden Tickets)\n\/\/ All Domain Admin NTLM hashes\n\/\/ Password history for all accounts\n\/\/ Kerberos keys (AES128, AES256) for all accounts\n\n\/\/ The permissions required for DCSync (lower than expected)\n\/\/ - Replicating Directory Changes (GetNCChanges)\n\/\/ - Replicating Directory Changes All (GetNCChanges for all attributes including credentials)\n\/\/ These are granted to Domain Admins by default but can be granted to any account\n\/\/ This is a common misconfiguration in environments that use AD replication tools<\/pre>\nDCSync detection: Windows Event ID 4662<\/h3>\n
DCSync generates Windows Security Event ID 4662 (An operation was performed on an object) on the domain controller. The key is what Access Mask and Properties are logged. The GUIDs for “Replicating Directory Changes All” are well-documented and distinguishable from normal AD operations.<\/p>\n
\/\/ DCSync generates Event 4662 with these specific GUIDs\n\/\/ 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 = DS-Replication-Get-Changes\n\/\/ 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 = DS-Replication-Get-Changes-All\n\/\/ 89e95b76-444d-4c62-991a-0facbeda640c = DS-Replication-Get-Changes-In-Filtered-Set\n\n\/\/ Critical: the source of the 4662 event matters\n\/\/ A 4662 from a known domain controller = normal replication\n\/\/ A 4662 from a workstation or member server = DCSync attack\n\n\/\/ Splunk detection\nindex=wineventlog EventCode=4662 earliest=-24h\n| rex field=_raw \"Properties:\\s+(?P<props>[^\\r\\n]+)\"\n| where match(props, \"1131f6aa|1131f6ad|89e95b76\")\n| eval is_known_dc=if(match(ComputerName, \"DC01|DC02|DC03\"), \"yes\", \"no\")\n \/\/ Replace DC01|DC02|DC03 with your actual DC names\n| where is_known_dc=\"no\"\n| table _time, SubjectUserName, SubjectDomainName, ComputerName, props\n| sort -_time<\/pre>\n\/\/ PowerShell: check which accounts have DCSync rights\n\/\/ Run this in your environment to find unexpected grantees\nImport-Module ActiveDirectory\n\n$domain_dn = (Get-ADDomain).DistinguishedName\n$acl = Get-Acl \"AD:\\$domain_dn\"\n\n$dcsync_guids = @(\n \"1131f6aa-9c07-11d1-f79f-00c04fc2dcd2\", \/\/ DS-Replication-Get-Changes\n \"1131f6ad-9c07-11d1-f79f-00c04fc2dcd2\", \/\/ DS-Replication-Get-Changes-All\n \"89e95b76-444d-4c62-991a-0facbeda640c\" \/\/ DS-Replication-Get-Changes-In-Filtered-Set\n)\n\n$acl.Access | Where-Object {\n $_.ObjectType.ToString() -in $dcsync_guids -or\n $_.InheritedObjectType.ToString() -in $dcsync_guids\n} | Select-Object IdentityReference, ActiveDirectoryRights, ObjectType |\n Where-Object {\n # Exclude known legitimate grantees\n $_.IdentityReference -notmatch \"Domain Controllers|Domain Admins|Enterprise Admins\"\n } | Format-Table -AutoSize<\/pre>\nDCShadow: injecting objects into AD via a rogue DC<\/h3>\n
DCShadow is more sophisticated and significantly harder to detect. The attacker temporarily registers a machine they control as a domain controller in AD, uses that registration to push arbitrary objects and attribute modifications into the AD database via normal replication, then removes the registration. The changes appear to have come from a legitimate DC. If your audit policy is not specifically watching for new DC registrations, you will not see it.<\/p>\n
\/\/ DCShadow attack phases:\n\/\/ 1. Register a rogue DC in AD (requires Domain Admin or specific permissions)\n\/\/ - Modifies: CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration\n\/\/ - Modifies: CN=NTDS Settings in the rogue DC object\n\n\/\/ 2. Start a mini-DRS server on the attacker machine to serve replication requests\n\n\/\/ 3. Trigger replication from the rogue DC to a real DC\n\/\/ - The real DC pulls changes from the rogue\n\/\/ - Changes are committed to AD as if they came from a legitimate DC\n\n\/\/ 4. Remove the rogue DC registration\n\n\/\/ What can be pushed via DCShadow:\n\/\/ - New user objects with any properties\n\/\/ - Backdoor SIDHistory (persistence without password)\n\/\/ - Modified AdminSDHolder (propagates to all protected groups)\n\/\/ - New domain trusts\n\/\/ - Kerberos delegation settings<\/pre>\nDCShadow detection: monitoring DC registration changes<\/h3>\n
\/\/ Windows Event ID 4742 fires when a computer account is modified\n\/\/ A non-DC machine suddenly getting DC attributes is the DCShadow indicator\n\n\/\/ Also watch for changes to the AD Sites and Services configuration\n\/\/ New server objects appearing in CN=Sites is the registration step\n\n\/\/ Sigma rule for DCShadow detection\ntitle: DCShadow Rogue DC Registration\nstatus: experimental\nlogsource:\n product: windows\n service: security\ndetection:\n \/\/ Event 4742: Computer account changed\n selection_computer_change:\n EventID: 4742\n \/\/ Event 4662: Operation on AD replication configuration path\n selection_4662:\n EventID: 4662\n ObjectDN|contains:\n - 'CN=Sites,CN=Configuration'\n - 'CN=NTDS Settings'\n timeframe: 5m\n condition: selection_computer_change or selection_4662\nlevel: high\ntags:\n - attack.t1207\n - attack.defense_evasion<\/pre>\n\/\/ Real-time monitoring: watch for new DC registrations\n\/\/ Run this from a domain controller to monitor for DCShadow attempts\n\nImport-Module ActiveDirectory\n\n# Get current list of DCs for baseline\n$baseline_dcs = Get-ADDomainController -Filter * | Select-Object -ExpandProperty Name\n\n# Monitor loop\nwhile ($true) {\n $current_dcs = Get-ADDomainController -Filter * | Select-Object -ExpandProperty Name\n $new_dcs = $current_dcs | Where-Object {$_ -notin $baseline_dcs}\n\n if ($new_dcs) {\n Write-Warning \"NEW DOMAIN CONTROLLER REGISTERED: $($new_dcs -join ', ')\"\n # Alert, log, initiate IR\n Send-MailMessage -To \"security@corp.local\" -Subject \"DCShadow Alert\" `\n -Body \"New DC registered: $($new_dcs -join ', ')\" -SmtpServer \"smtp.corp.local\"\n }\n Start-Sleep -Seconds 30\n}<\/pre>\nNetwork-level detection via Zeek<\/h3>\n
\/\/ DCShadow generates unusual Kerberos and RPC traffic patterns\n\/\/ A workstation acting as a DC generates MS-DRSR traffic that Zeek can see\n\n\/\/ Zeek kerberos.log: look for non-DC machines requesting DC-specific Kerberos services\ncat kerberos.log | zeek-cut ts client service |\n grep \"GC\/\" | \/\/ Global Catalog requests only come from DCs\n grep -v \"dc01\\|dc02\\|dc03\" | \/\/ Filter known DCs\n head -20\n\n\/\/ DCSync and DCShadow both generate DRSUAPI RPC traffic\n\/\/ The DRSUAPI interface can be identified in network traffic\n\/\/ A non-DC machine initiating DRSUAPI connections to a DC is highly suspicious\n\n\/\/ Zeek dce_rpc.log: filter for DRSUAPI operations from non-DC sources\ncat dce_rpc.log | zeek-cut ts id.orig_h id.resp_h endpoint operation |\n grep \"drsuapi\\|dsaop\" |\n grep -v \"known_dc_ip_1\\|known_dc_ip_2\" |\n head -20<\/pre>\n","protected":false},"excerpt":{"rendered":"DCSync replicates every credential in Active Directory without logging on to a domain controller. DCShadow goes further — it creates a rogue DC and injects objects into AD. Both techniques have specific detection signatures that most environments are not watching for.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[13],"tags":[],"class_list":["post-302","post","type-post","status-publish","format-standard","hentry","category-threat-hunting"],"_links":{"self":[{"href":"https:\/\/justruss.tech\/index.php\/wp-json\/wp\/v2\/posts\/302","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/justruss.tech\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/justruss.tech\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/justruss.tech\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/justruss.tech\/index.php\/wp-json\/wp\/v2\/comments?post=302"}],"version-history":[{"count":1,"href":"https:\/\/justruss.tech\/index.php\/wp-json\/wp\/v2\/posts\/302\/revisions"}],"predecessor-version":[{"id":320,"href":"https:\/\/justruss.tech\/index.php\/wp-json\/wp\/v2\/posts\/302\/revisions\/320"}],"wp:attachment":[{"href":"https:\/\/justruss.tech\/index.php\/wp-json\/wp\/v2\/media?parent=302"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/justruss.tech\/index.php\/wp-json\/wp\/v2\/categories?post=302"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/justruss.tech\/index.php\/wp-json\/wp\/v2\/tags?post=302"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}