Rogue Domain Controller

DCShadow comes late in an intrusion. The authors say it requires domain or enterprise admin privileges, and MITRE lists either Administrator rights (domain or local to the DC) or the KRBTGT hash. By the time DCShadow fires, the attacker has usually dumped credentials already, with OS Credential Dumping such as DCSync (T1003.006) as the close cousin, and is looking for access that survives a password reset. Treat a hit as proof that the domain is already compromised.

What gets injected is persistence. MITRE highlights SID-History Injection (T1134.005) and edits to accounts, ACLs and schema objects that leave backdoors. The authors name SIDHistory and password history values as examples, and replication metadata and schema signature info as traces the tool can erase. A typical payload gives an ordinary account the SID of a privileged group through SID history, so a normal-looking user carries domain admin rights that group membership reports never show.

On the ATT&CK map, T1207 now sits under Defense Impairment, one of the two tactics that ATT&CK v19 created by splitting Defense Evasion into Stealth and Defense Impairment, so older write-ups file it elsewhere. The label fits: the point of the technique is to change the directory without the controls that would normally record or block the change.

The loudest false positive is a legitimate promotion. Install-ADDSDomainController and dcpromo create the same server and nTDSDSA objects, register the same SPNs and start replication from the new machine, so a freshly built DC looks like a non-DC to any network rule until it is added to your DC list. The short-lived pairing filters most of this out, because a real promotion leaves its objects in place, but a failed promotion that rolls back can leave the same create-then-delete trace. Demotions delete the objects, though only the deletion event fires.

Keep the DC inventory current and wired into the detection. The Splunk network analytic depends on Assets and Identities categories for exactly this reason. Pair the rules with change management: a build ticket for the host, a known admin, a maintenance window. Lab and test forests that share a SIEM deserve their own tag, because rebuilt test DCs produce the same pattern every week. Anything that survives those filters, especially from a workstation or a member server, deserves immediate escalation.

Escalate as a domain compromise. DCShadow needs domain admin or the KRBTGT hash, so the question is less what this host did than who controls the domain. Take the logon ID from the 5137 and 5136 events, resolve it in the matching 4624 logon on the DC, and identify the account, the source host and the source IP. Preserve the DC security logs and the Zeek data before anything is rotated, and treat the account as burned.

Then find out what was pushed. Replication metadata records which DC originated each attribute change, so repadmin /showobjmeta against sensitive objects shows changes whose originating server is the rogue machine. Start with privileged groups, AdminSDHolder and the ACLs on the domain root. MITRE warns the actor can alter or delete that metadata, so a clean result does not clear you. Compare against a known-good source instead, and list every account that carries SID history with Get-ADUser -Filter {SIDHistory -like "*"} -Properties SIDHistory. Explain each one.

Recovery follows the usual playbook for a domain-level compromise: remove the malicious objects and SID history, reset the KRBTGT password twice with the interval your replication needs, rotate privileged and service credentials, and review the DCs for other persistence. Build the detections you were missing before you close the case: the audit policy, the Configuration-partition SACL and a DC list the SIEM can trust.