DCShadow Attack Rogue Domain Controller Registration: How It Bypasses AD Change Auditing

The DCShadow attack rogue domain controller registration technique — publicly disclosed by Benjamin Delpy and Vincent Le Toux (creators of Mimikatz) at BlueHat IL in January 2018 — lets an attacker with sufficient rights temporarily register a compromised machine as a domain controller and push Active Directory object changes to the rest of the domain through the normal replication protocol, instead of through a standard write API. MITRE ATT&CK catalogues it as T1207 — Rogue Domain Controller.

This article covers the mechanism, why it evades the logging that normally catches privileged AD changes, and concrete detection and remediation steps. For the more common replication-abuse technique — reading secrets instead of writing changes — see ACL Abuse and DCSync: The Silent Paths to Domain Admin and Active Directory Monitoring: Security Event IDs That Matter for the broader replication-auditing baseline this technique is built to slip past.

The DCShadow Attack Rogue Domain Controller Registration Explained

Every domain controller in Active Directory is represented in the directory itself: a server object and a child nTDSDSA object under the Configuration naming context (CN=Sites), the same class of objects created whenever a real DC is promoted. DCShadow abuses the fact that any principal holding the right replication-related permissions can create that same pair of objects on a machine that isn't actually a domain controller — then use the legitimate Directory Replication Service (DRS) RPC protocol to have the rest of the domain pull "changes" from it as if it were a trusted peer.

DCShadow is distinct from DCSync. DCSync (DS-Replication-Get-Changes) abuses replication rights to read secrets — most commonly to dump password hashes from a legitimate DC's perspective. DCShadow abuses a different, adjacent set of replication rights to write — it fabricates a rogue replication source and injects changes into the directory. The two are often confused because they share the same underlying protocol family (MS-DRSR) and the same class of "who has DCSync-adjacent rights" audit question, but they are separate attack primitives with separate detection surfaces.

How It Works

Step 1 — Acquire the Rights

Per independent minimal-permissions research published by Lab of a Penetration Tester in April 2018, DCShadow does not strictly require Domain Admin or Enterprise Admin membership — that is the common path, but the technique can also work with a narrower set of grants directly on the domain object: the extended rights DS-Install-Replica ({9923a32a-3607-11d2-b9be-0000f87a36b2}, per Microsoft's ADSchema reference), DS-Replication-Manage-Topology, and DS-Replication-Synchronize ({1131f6ab-9c07-11d1-f79f-00c04fc2dcd2}, per Microsoft's ADSchema reference) — plus enough WriteProperty on the attacking machine's own computer object (see Active Directory Computer Objects Attack Surface for the broader risk class) to set its Service Principal Names. This is why EtcSec's catalogue tracks who holds Server Trust Account rights as a distinct, critical finding: it is the precondition that makes registering a rogue DC possible in the first place, independent of whether that account is also a Domain Admin.

Step 2 — Register the Rogue DC

Using the lsadump::dcshadow module, Mimikatz (running with SYSTEM privileges on the attacking machine) sets two Service Principal Names on the compromised computer account, then creates the server and nTDSDSA objects in the Configuration partition. Per MITRE's DET0276 detection strategy, the SPNs used are the Global Catalog SPN (GC/<hostname>/<domain>) and the Directory Replication Service interface SPN (E3514235-4B06-11D1-AB04-00C04FC2DCD2/<guid>/<domain>) — the same SPN classes a legitimate DC carries, which is precisely what lets the machine impersonate one for replication purposes.

Step 3 — Push the Change

With the rogue DC registered and the SPNs in place, a second lsadump::dcshadow /push command triggers an outbound replication event: the fabricated object or attribute change (an ACL rewrite, a group membership, a msDS-KeyCredentialLink, a schema attribute — DCShadow can target essentially any writable AD data) is replicated from the attacker's machine to a real DC via IDL_DRSReplicaAdd/GetNCChanges, exactly as if it had come from a peer DC.

Step 4 — Deregister and Vanish

The attacker removes the rogue server and nTDSDSA objects, restores the original SPNs, and the machine reverts to looking like an ordinary domain-joined computer. The malicious change, however, has already replicated to every real DC in the domain and persists in the directory.

Detection

The registration and de-registration steps are the detectable window — the pushed change itself, once replicated, looks like any other directory attribute.

Remediation

1. Audit Who Holds Server Trust Account and Replication-Write Rights

The precondition for a DCShadow attack is a principal holding DS-Install-Replica, DS-Replication-Manage-Topology, and DS-Replication-Synchronize on the domain object — or broader rights to set a computer account's SPNs. Enumerate this the same way you would audit DCSync-capable accounts, but for the write-side extended rights:

# Enumerate non-default principals with replication extended rights on the domain object
$domainDN = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:\$domainDN"
$acl.Access |
  Where-Object { $_.ActiveDirectoryRights -match "ExtendedRight" } |
  Select-Object IdentityReference, ActiveDirectoryRights, ObjectType

Cross-reference every result against your expected Domain Admin / Enterprise Admin membership — anything else is an undocumented grant worth investigating.

2. Enable Configuration Partition Auditing

Configuration NC changes are not audited by default. Apply a SACL to CN=Sites,CN=Configuration,DC=<domain> (and ideally the Configuration NC root) so that nTDSDSA and server object creation/deletion generate Directory Service Changes events (5136/5137), and enable the "Audit Detailed Directory Service Replication" subcategory domain-wide so 4928/4929 are captured.

3. Minimize and Tier Privileged Access

Follow a tiered administration model — see Hardening Active Directory: What to Lock Down First — so that the accounts capable of holding replication-write rights are the same small, monitored set you already treat as Tier 0, with no standing membership beyond what's actively needed. This is the same discipline that prevents privileged access drift more broadly.

4. Alert on the 4928/4929 Pair Correlated to Known DCs

Build a detection rule that flags any 4928 (and its paired 4929) whose Source DRA does not match your maintained inventory of legitimate domain controllers. Because a DCShadow registration window is typically brief, near-real-time log forwarding matters more here than for most AD detections — a daily batch review will usually run after the rogue DC has already deregistered.

How EtcSec Detects This

EtcSec's AD vulnerability catalogue flags this exposure through two checks: DCSHADOW_EVIDENCE, which looks for direct evidence of a DCShadow rogue domain controller registration having occurred, and SERVER_TRUST_ACCOUNT_RIGHT, which flags accounts and groups holding the rights to set a server trust account — the precondition that makes the technique viable regardless of whether Domain Admin membership is also present. Environments that have already reviewed their DCSync-capable accounts should treat this as the companion audit: the read-path and write-path replication rights are usually granted by the same delegation mistakes, but rarely reviewed together.

Primary References

• Delpy & Le Toux — DCShadow official technique reference
• MITRE ATT&CK T1207: Rogue Domain Controller
• MITRE ATT&CK DET0276: Detection Strategy for Rogue Domain Controller (DCShadow) Registration and Replication Abuse
• Lab of a Penetration Tester: DCShadow — Minimal Permissions, Active Directory Deception, Shadowception and More
• SentinelOne: Detecting a Rogue Domain Controller — DCShadow Attack
• Microsoft Learn: 4928(S, F) An Active Directory replica source naming context was established
• Microsoft Learn: 4929(S, F) An Active Directory replica source naming context was removed
• Microsoft Learn: 4742(S) A computer account was changed
• Microsoft Learn: DS-Install-Replica extended right
• Microsoft Learn: DS-Replication-Synchronize extended right