Module 22 · DCShadow — Stealth Domain Replication Abuse

Why this module exists. DCShadow is the textbook example of “stealth persistence”. An attacker with sufficient privileges does not need to keep dropping files, scheduling tasks, or modifying registry keys — they push the change into the directory itself via the replication protocol, and the change is now part of the canonical AD state. Defender tooling that audits “modifications via LDAP” misses it. This module is the practitioner-level walkthrough of how it works and how to catch it.

What DCShadow actually does

AD replication works between DCs over the Directory Replication Service (DRS) protocol. When DC1 has a change DC2 has not seen, DC2 pulls the change via DRS. The change is applied locally and audited as a replication event — not as a directory modification. DCShadow exploits this by making the attacker’s machine briefly act as if it were a DC: it registers an SPN, accepts a single replication pull from a real DC, pushes the change, and deregisters. The real DC applies the change and propagates it onward — believing it came from a legitimate replication partner.

What you need to run DCShadow

• Membership in the right groups. Historically: Domain Admins. Modern Mimikatz can do it with just Server Operators + the rights to write to specific configuration container objects, but the practical threshold is still high-privilege.
• Two processes on the attacker’s machine. One running as SYSTEM (registers the DC SPN, accepts the replication pull); one running as the privileged user (initiates the push). Mimikatz orchestrates both.
• Network reachability to a real DC for the replication handshake.

The canonical attack walkthrough

# Open two Mimikatz windows on a Windows host with DA-level credentials.

# Window 1 — runs as SYSTEM (psexec -s -i cmd.exe; then mimikatz):
mimikatz # !+
mimikatz # !processprotect /process:lsass.exe /remove   # so the next step works
mimikatz # lsadump::dcshadow /object:CN=Bob,OU=Users,DC=corp,DC=local \
            /attribute:userAccountControl /value:512   # 512 = normal enabled
# This window is now waiting, registered as a "DC".

# Window 2 — runs as the DA user:
mimikatz # lsadump::dcshadow /push
# Push completes within seconds. Window 1 deregisters automatically.

# Result: Bob's userAccountControl is now 512 in the directory.
# Every real DC has the change via legitimate replication.

What just happened: the attacker pushed a directory change without ever opening an LDAP session, without ever calling Set-ADObject, without leaving the standard “directory was modified” audit trail. The change is real, propagated, and durable.

Why this is harder to detect than ordinary AD modifications

Standard AD auditing — events 5136, 5137, 5141 — captures modifications via LDAP. DCShadow’s modifications come via DRS replication. The DC applies them and logs them as replication events (event 5137 in some cases, with attribution to the rogue DC) but the rogue DC’s hostname is the attacker’s machine, which is not in any DC inventory. By the time the SIEM is reviewing, the rogue DC’s SPN is gone.

What an attacker uses DCShadow for

• SID History persistence (Module 19). Write the Enterprise Admins SID into a low-privilege user’s sIDHistory without leaving an LDAP modification trail.
• AdminSDHolder ACL modification (Module 18). Same persistence, harder to find.
• Password hash replacement. Write a known NT hash for a service account, then use Pass-the-Hash against it.
• Group membership manipulation. Add an account to a privileged group without it appearing in the modifying-user audit trail.
• Schema modification. Add a custom attribute to a class, then use it to stash data. Extremely stealthy.

Detection 1: monitoring for replication partners

The signature of DCShadow is a new replication partner that appears, replicates once, and disappears. Real DCs appear, stay, and replicate continuously. Monitor for SPN registrations of the form GC/<hostname> and E3514235-4B06-11D1-AB04-00C04FC2DCD2/<hostname> (the replication services SPNs) from hosts not in the canonical DC list.

# PowerShell — list all principals registered with the DRS SPN
Get-ADObject -LDAPFilter "(servicePrincipalName=E3514235-4B06-11D1-AB04-00C04FC2DCD2/*)" \
  -Properties servicePrincipalName |
  Select-Object Name,servicePrincipalName

# Compare against your DC inventory. Anything else is an active or recent DCShadow.

Detection 2: event 4742 on the rogue computer object

To register as a DC, the attacker must temporarily modify a computer object’s userAccountControl to include SERVER_TRUST_ACCOUNT. This generates event 4742 (“computer account changed”) on a real DC, with the new UAC value visible. Alert on any 4742 where the new UAC contains the SERVER_TRUST_ACCOUNT flag (bit 0x2000) and the affected computer is not in your DC inventory.

Detection 3: replication metadata anomalies

Every replicated object has metadata about which DC originated each attribute change. repadmin /showobjmeta exposes it. A DCShadow change shows up with the rogue DC’s invocation ID as the originator — and that invocation ID does not match any real DC. Periodic export and diff catches old DCShadow events even if you missed them in real time:

# Pull metadata for a sensitive object
repadmin /showobjmeta <DC> "CN=Domain Admins,CN=Users,DC=corp,DC=local"

# The "Originating DC" column should always be a recognised DC name.
# Anything else needs investigation.

Detection 4: high-signal Sysmon events on the attacker machine

Mimikatz running DCShadow on the attacker’s box leaves Sysmon evidence: process creation of two mimikatz.exe instances (Event ID 1), one of them as SYSTEM, and DRS-related RPC traffic (Event ID 3, network connections to the DC on port 49152+ or whatever the dynamic RPC port is). The detection logic on a typical EDR catches the Mimikatz process; the DRS traffic from a non-DC is the corroborating signal.

Defender’s playbook — assume DCShadow has happened

1. Audit privileged-object metadata. Use repadmin /showobjmeta on every Tier-0 object monthly. Investigate any non-DC originator.
2. Tighten Tier-0. The single highest-value defence is reducing the number of accounts with Domain Admin / equivalent. DCShadow requires DA-level privilege; tightening that reduces opportunity.
3. Hunt for stale Server Operators. Modern Mimikatz needs less than DA; Server Operators is sufficient with specific ACEs. Audit that group’s membership.
4. SIEM rule on 4742 with SERVER_TRUST_ACCOUNT. Should be vanishingly rare.
5. SIEM rule on new SPN registrations matching DRS GUIDs. Should be never except during legitimate DC promotion.
6. Krbtgt password rotation if DCShadow is suspected. The same playbook as Golden Ticket suspicion — twice, 8-10 hours apart.

Mindset takeaway

DCShadow is not an exploit. It is the legitimate replication protocol used by an attacker who already has high privilege. The defence is therefore not “patch DCShadow” — there is no patch — but to treat the replication channel as Tier-0 trust. Anything that can speak DRS to your forest is, by definition, as trusted as a DC. The smaller the set of principals with that capability, the smaller the DCShadow attack surface.

Key takeaways

• DCShadow registers a temporary rogue DC, pushes a change via DRS, deregisters — without LDAP-modification audit trails.
• Requires DA or near-DA privileges; modern Mimikatz lowers the bar but the threshold is still high.
• Uses include SID History injection, AdminSDHolder ACL changes, password hash replacement, schema modification.
• Detection signatures: new SPN registrations matching DRS GUIDs, event 4742 with SERVER_TRUST_ACCOUNT bit set, anomalous originator in repadmin /showobjmeta.
• There is no patch — the defence is minimising the set of principals with DRS privileges.