DCShadow Attack Detection — Rogue Domain Controller & AD Replication Abuse

MITRE ATT&CK

Security Relevance

DCShadow is the attacker-controlled inverse of DCSync. DCSync steals what's already in AD; DCShadow writes what the attacker wants into AD. The fundamental danger is that AD changes pushed via DCS replication are treated as authoritative — they bypass the normal LDAP-write audit chain that generates events like 4720 (user created), 4728 (group changed), or 4738 (user modified). From the DC's perspective, those changes arrived from a peer DC as part of normal replication, so the source is logged as the rogue DC's computer object rather than the attacker's user account. Most detection stacks alert on LDAP write events tied to user accounts — DCShadow specifically bypasses this by masquerading as replication traffic. The only reliable detection path is monitoring for unexpected 4928/4929 replication events from non-DC hosts, and using Microsoft Defender for Identity, which maintains a baseline of legitimate DC topology and alerts on any deviation.

Indicators of Malicious Use

• ⚑Event 4928 (AD replica source naming context established) from a source IP that is not a known domain controller — rogue DC registering as a replication partner
• ⚑Event 4929 (AD replica source naming context removed) from the same non-DC source shortly after 4928 — the register/replicate/deregister sequence completes within seconds to minutes
• ⚑Event 4742 (computer account changed) where the machine's servicePrincipalName gains E3514235-4B06-11D1-AB04-00C04FC2DCD2/... (DRS service SPN) — the machine is being promoted to act as a DC
• ⚑Event 4688 or 4104: Mimikatz lsadump::dcshadow, or the sequence lsadump::dcshadow /object: followed by lsadump::dcshadow /push
• ⚑AD attribute changes (SIDHistory, adminCount, userAccountControl, msDS-AllowedToDelegateTo) with no corresponding 4720/4728/4738 events attributable to an admin account — changes arrived as replication, not LDAP writes
• ⚑New computer object in AD with DC-class attributes (msDS-AdditionalDnsHostName, GC SPN) that does not correspond to a known server in your environment
• ⚑Net Logon service events (EventID 5805 — machine account authentication failure) on DCs from the rogue host during the DRS negotiation phase

Example Log Entry

-- Attacker runs two Mimikatz sessions simultaneously --

Session 1 (triggers rogue DC registration):
Event ID: 4688 — A new process has been created
  Process Name:  mimikatz.exe
  Command Line:  lsadump::dcshadow /object:CN=backdoor,CN=Users,DC=corp,DC=local
                 /attribute:SIDHistory /value:S-1-5-21-...-512
  ← prepares the change to push (Domain Admins SID into SIDHistory)

Session 2 (triggers replication push):
  Command Line:  lsadump::dcshadow /push
  ← forces the rogue DC to replicate the change to real DCs

-- On the Domain Controller --

Event ID: 4928 — An AD replica source naming context was established
  Destination DC:    DC01.corp.local
  Source DC Address: 10.10.5.88    ← NOT a known DC IP — this is the rogue host
  Naming Context:    DC=corp,DC=local

Event ID: 4929 — An AD replica source naming context was removed
  Source DC Address: 10.10.5.88   ← rogue DC deregisters seconds later

[No 4728 or 4738 for the SIDHistory change — it arrived as replication data]

Investigation Steps

1. 1.Identify the source IP in Event 4928. Compare against your authoritative list of domain controller IPs and computer names. Any 4928 from a host not on that list is an unauthorized replication partner — the rogue DC. Pivot to that host immediately.
2. 2.Establish the timeline: find the 4928 (registration), the replication window (seconds to a minute or two), and the 4929 (deregistration). Everything the attacker pushed into AD happened in that window. The changes are now in AD regardless of how quickly you respond.
3. 3.Audit what changed: query AD for recently modified objects using Get-ADObject -Filter * -Properties WhenChanged | Where-Object { $_.WhenChanged -gt (Get-Date).AddHours(-1) }. Pay special attention to: SIDHistory populated on any account, adminCount=1 on accounts not in admin groups, userAccountControl changes, servicePrincipalName additions on non-server accounts.
4. 4.Check for SIDHistory injection — the most common DCShadow payload: Get-ADUser -Filter * -Properties SIDHistory | Where-Object { $_.SIDHistory -ne $null }. Any account with SIDHistory containing a high-privilege group SID (512 = Domain Admins, 519 = Enterprise Admins) has been escalated.
5. 5.On the rogue host, examine Event 4688 (process creation) for mimikatz.exe or any process with lsadump::dcshadow in its command line. Also check Event 4673 (privileged service called) — DCShadow requires SeImpersonatePrivilege or SYSTEM-level access.
6. 6.Determine persistence scope: has the modified account been used since the DCShadow push? Check Event 4624 (logon) and 4769 (Kerberos service ticket) for the backdoor account. If SIDHistory grants Domain Admin access, treat every system that account touched as compromised.
7. 7.DCShadow requires at minimum two simultaneous sessions on the rogue host and network connectivity to the DC on port 135 (RPC endpoint mapper) and dynamic high RPC ports. Check firewall logs for unusual RPC traffic from the identified rogue host to your DCs.

Common False Positives

• ◎Legitimate AD migration tools (Quest Migration Manager, Microsoft ADMT) use DRS replication for object migration — these will generate 4928/4929 events from migration servers. These servers should appear in a maintained allowlist of expected replication sources.
• ◎Azure AD Connect and other hybrid identity tools communicate with DCs using the DRSUAPI protocol — they are legitimate replication consumers and should be excluded from alerting by IP/hostname.
• ◎Lab or test environments where admins manually test DC promotion may generate 4928/4929 from servers being promoted. These should be associated with documented change tickets.
• ◎Is DCShadow the only way to modify AD without triggering standard change events? No — attackers with sufficient AD rights can modify the schema, ACLs, or use AdminSDHolder abuse, which also bypasses standard change monitoring. DCShadow is the replication-based approach; ACL-based persistence requires different detection.

Remediation

• ✓Immediately remove the SIDHistory, adminCount, or other malicious attributes pushed by DCShadow: use Set-ADUser or ADSI Edit to clear the injected values. Verify against a known-good AD snapshot.
• ✓Disable and investigate the rogue host: the machine used as a rogue DC was running as SYSTEM. Treat it as fully compromised — isolate, image for forensics, and rebuild.
• ✓Audit and restrict who can register computer accounts in AD: by default, any authenticated user can register up to 10 computer objects. Restrict this with the ms-DS-MachineAccountQuota attribute (set to 0) and require admin approval for all computer account creation.
• ✓Deploy Microsoft Defender for Identity — it maintains a real-time map of domain controller topology and detects any machine attempting to act as an AD replication source that is not a known DC. This is the most reliable automated DCShadow detection available.
• ✓Monitor and alert on Event 4928 and 4929 from non-DC IPs: create a SIEM rule that compares the Source DC Address in these events against a maintained allowlist of known DC IPs. Any deviation is a critical alert.
• ✓Apply the AdminSDHolder protection review: DCShadow may be used to modify the AdminSDHolder object itself, which propagates permissions to all protected accounts every 60 minutes. Audit the AdminSDHolder ACL immediately after a suspected DCShadow event.
• ✓Consider implementing AD tiering and Privileged Access Workstations (PAWs): DCShadow requires SYSTEM-level access on a domain-joined machine plus network access to the DC. Restricting which machines can communicate with DCs on RPC ports limits the attack surface significantly.

Related Event IDs

Related Detection Guides

Frequently Asked Questions

What is the difference between DCShadow and DCSync?

DCSync pulls data out of Active Directory — it impersonates a DC to request password hashes for any account without touching the DC's disk. DCShadow pushes data in — it registers a rogue DC, injects malicious changes (SIDHistory, privilege escalation, backdoor accounts), and deregisters. DCSync is credential theft; DCShadow is AD tampering. Both use the DRS replication protocol, but in opposite directions.

Why doesn't DCShadow trigger the normal AD change events like 4720 or 4728?

Events 4720 (user created), 4728 (group member added), and 4738 (user modified) are generated when changes arrive via LDAP writes from a user session. DCShadow bypasses LDAP entirely — it delivers changes via the DRS replication protocol, which Active Directory treats as peer-DC synchronization. The DC accepts and applies those changes without generating the standard audit events, because from its perspective the changes came from another DC, not from a user action.

How does SIDHistory injection via DCShadow work?

Every AD user has a SIDHistory attribute, originally intended for domain migrations: when an account migrates from one domain to another, the old domain SID is stored in SIDHistory so the account retains access to old resources. DCShadow abuses this by injecting any SID — including Domain Admins (S-1-5-21-...-512) or Enterprise Admins (S-1-5-21-...-519) — into a low-privileged account's SIDHistory. Windows includes SIDHistory SIDs in the account's access token, granting the privileges of that group without the account appearing in any admin group. The account looks normal in the AD Users and Computers console.

Can I detect DCShadow if I don't have Microsoft Defender for Identity?

Yes, but it requires specific event log coverage. Enable auditing of 'Directory Service Changes' and 'Directory Service Replication' in Advanced Audit Policy on all domain controllers. This generates Events 4928 and 4929 for replication partner changes. Create a SIEM rule that alerts when 4928 appears with a Source DC Address not in your maintained list of authorized DC IPs. Additionally, enable Process Creation auditing (4688) with command-line logging — the Mimikatz lsadump::dcshadow syntax has a distinctive pattern. MDI is more reliable because it baselines DC topology automatically, but event-log-based detection is achievable with proper auditing policy.