MITRE ATT&CK T1207 Rogue Domain Controller: Detecting and Preventing DCShadow

A rogue domain controller lets an attacker push changes into Active Directory through replication, so the edits can arrive on genuine domain controllers without the usual change events your SIEM watches for. MITRE ATT&CK T1207 Rogue Domain Controller describes adversaries registering a rogue domain controller, or reusing an inactive registration, to inject and replicate changes to any domain object, including credentials, keys, access control lists and schema. ATT&CK names DCShadow as the method. In ATT&CK v20 the technique sits in the Defense Impairment tactic (TA0112) and applies to Windows. This guide covers how the registration and replication steps leave evidence, the correlation ATT&CK recommends, the audit settings needed to see it, how to shrink the set of accounts that can do it, and how to respond. It is for AD administrators, detection engineers and incident responders. Domain-wide recovery is in the Active Directory Domain Compromise Response Playbook and general DC build controls are in the AD Domain Controller Hardening Guide; this page goes deeper on T1207 only.

Key takeaways

• It is a post-compromise technique. ATT&CK says registering a rogue DC needs Administrator privileges, either Domain or local to a DC, or the KRBTGT hash, so a T1207 alert means Tier 0 is already lost.
• Detect the registration, not just the change. New server and nTDSDSA objects in the Configuration partition, created by a host that is not a known DC, are the strongest signal.
• Replication from non-DCs is never normal. Directory replication RPC calls or replication service principal names used by a machine outside the Domain Controllers OU should alert every time.
• Default auditing will not see it. You need a SACL on the Configuration partition sites container and the directory service audit subcategories enabled on DCs.
• Treat replication rights as Tier 0. Microsoft's prevention guidance for its DCShadow alerts is to validate who holds Replicating Directory Changes and Replicating Directory Changes All.

How a rogue domain controller works

Active Directory trusts other domain controllers to send it changes. ATT&CK describes DCShadow as registering a machine and simulating the behaviour of a DC so that it can replicate changes into the directory. Microsoft's Defender for Identity documentation describes the same flow: RPC and LDAP are used to register the machine account as a domain controller using domain admin rights, then replication over DRSUAPI sends changes to directory objects.

ATT&CK lists what attackers use T1207 for: injecting SID History (T1134.005) and changing accounts, ACLs or schema to plant persistence. It also notes the technique may bypass SIEM visibility because actions taken on the rogue DC may not be reported to those sensors. ATT&CK records the Mimikatz LSADUMP::DCShadow module as the procedure example.

How T1207 relates to DCSync

DCSync (T1003.006) abuses the same replication protocol in the other direction: it requests secrets from a DC. T1207 pushes changes into the directory. Both depend on replication rights, so the same permission review protects against both. See the Golden Ticket, Silver Ticket and DCSync Guide.

Detection: the registration and replication correlation

ATT&CK v20 publishes detection strategy DET0276 with one Windows analytic (AN0770). It correlates four things, and says they are most suspicious in combination and from hosts outside the Domain Controllers OU.

ATT&CK's tunable elements are a TimeWindow between object creation and replication traffic from the same host (default 300 seconds), an AllowedReplicationPartners list of genuine DCs, the SuspiciousSPNs list, and an option to alert on object creation only by accounts outside Domain Admins and Enterprise Admins. In our view that last option should stay off for this technique: the attacker will normally be using exactly those groups.

Audit settings you need

• SACL on the sites container: our recommendation is to add auditing for object creation and deletion on CN=Sites under the Configuration partition, so that new server and NTDS Settings objects generate events. Microsoft documents that 4662 is generated only when the object has a matching SACL entry.
• Directory Service Access and Directory Service Changes: enable these advanced audit subcategories on all DCs through the Default Domain Controllers Policy or a dedicated GPO.
• Detailed Directory Service Replication: this subcategory generates 4928 to 4937. Microsoft warns it can create a very high volume of event data on domain controllers and says it is mainly used for replication troubleshooting. Our recommendation is to enable it only if your SIEM can filter at source to events whose source or destination is not on the DC allowlist.
• Network sensors: because the registration happens over RPC and LDAP from the rogue host, a network sensor or identity threat detection product watching DC traffic sees replication requests that host logs on the rogue machine will not.

The Active Directory Security Monitoring and Event IDs Guide covers the wider DC event set.

Product detections

Identity threat detection products ship detections for this behaviour. As an example, Microsoft Defender for Identity documents two classic alerts mapped to T1207: "Suspected DCShadow attack (domain controller promotion)", external ID 2028, raised when a machine tries to register as a rogue domain controller, and "Suspected DCShadow attack (domain controller replication request)", external ID 2029, raised when a suspicious replication request reaches a genuine DC. Both are High severity and Microsoft notes they are supported by its sensors only. Whatever product you use, confirm in its documentation that it inspects replication traffic, not just event logs.

Prevention: shrinking who can register a DC

ATT&CK v20 lists no mitigation objects for T1207, because the prerequisite is administrative control of the domain. Prevention therefore means protecting that control.

See the Tiered Administration and Enterprise Access Model Guide and the krbtgt account guide for the procedures.

Implementing T1207 coverage

1. Build the allowlist: export the list of DCs, their IP addresses and computer accounts, and any servers that legitimately hold replication rights (for example directory sync servers). Keep it under change control.
2. Enable auditing in a pilot: apply the sites container SACL and the directory service subcategories on two DCs, measure event volume for a week and confirm events appear when you add a test object in a lab.
3. Deploy the correlation: implement the AN0770 logic in your SIEM against the allowlist, starting with alerting on nTDSDSA creation by any non-allowlisted host.
4. Add network detection: alert on replication RPC traffic between DCs and anything not on the allowlist.
5. Validate: run an authorised DCShadow emulation in an isolated lab forest, never in production, and confirm every signal fires.
6. Roll back: if audit volume overwhelms ingestion, narrow the SACL to object creation only and keep the replication subcategory off, relying on the network signal instead.

Small organisations with a single site and a few DCs can rely on the SACL plus a product detection. Large multi-forest estates should automate the allowlist from their DC inventory, since DC builds and decommissions will otherwise generate false positives.

Responding to a rogue DC alert

1. Treat it as domain compromise: invoke the domain compromise playbook; the prerequisite rights mean the attacker already holds Tier 0.
2. Identify and isolate the host: find the machine that registered or replicated, isolate it from the network and preserve memory and disk.
3. Find what changed: compare object metadata and attribute values against a known-good backup or snapshot, focusing on SID History, privileged group membership, ACLs on the domain root and AdminSDHolder, and schema changes. ATT&CK warns that replication metadata may have been altered, so do not rely on metadata alone.
4. Remove the registration: delete any leftover server or NTDS Settings objects for the rogue host after evidence is captured.
5. Reset credentials: reset KRBTGT twice, Tier 0 account passwords and any accounts whose credentials or keys were changed.
6. Recover if needed: if changes cannot be fully enumerated, follow a forest recovery plan. See Recovering IAM and PAM After Ransomware or Domain Compromise.

Where identity fits

T1207 is an identity attack on the identity system itself. The machine account of the rogue host is used as a fake DC, and the end goal is usually changes to accounts, groups and keys that give lasting access. Service accounts that hold replication rights for synchronisation tools are non-human identities with Tier 0 power: keep them in an inventory, restrict where they can log on, and review them alongside human admins. See the AdminSDHolder, SDProp and Protected Groups Guide for related persistence checks.

Measuring it

• Replication rights holders: number of non-DC principals with replication rights, reviewed quarterly (target: only documented sync services).
• SACL coverage: share of domains and forests with auditing on the sites container (target 100 percent).
• Allowlist accuracy: number of rogue DC alerts caused by undocumented DC builds or decommissions per quarter.
• Emulation result: whether the latest lab emulation triggered each of the four signals.
• Time to isolate: minutes from rogue DC alert to network isolation of the registering host.

Common failure patterns

• No SACL on the Configuration partition: directory service auditing is enabled but no events appear for new server objects.
• Watching only the genuine DC's change events: attribute changes arrive by replication and do not look like an administrator edit.
• Stale replication rights: old sync tools or migration accounts keep Replicating Directory Changes All for years.
• Trusting replication metadata in the investigation: the attacker may have altered it.
• Responding at host level only: removing the rogue host without enumerating and reversing the directory changes it pushed.

Framework mapping

Practitioner checklist

• Audit object creation and deletion on the Configuration partition sites container.
• Alert on any nTDSDSA or server object created by a host not on the DC allowlist.
• Alert on replication RPC traffic or replication SPN use by non-DC machines.
• Review Replicating Directory Changes and Replicating Directory Changes All holders quarterly.
• Restrict replication RPC to DC-to-DC and documented sync servers at the firewall.
• Keep Tier 0 administration on privileged access workstations only.
• Test the detection with a DCShadow emulation in an isolated lab forest.
• On an alert, compare directory state with a known-good backup and reset KRBTGT twice.

Standards and references

• MITRE ATT&CK: Rogue Domain Controller (T1207)
• MITRE ATT&CK: SID-History Injection (T1134.005)
• Microsoft Learn: Defender for Identity classic security alerts
• Microsoft Learn: Audit Detailed Directory Service Replication
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Active Directory Domain Compromise Response Playbook · AD Domain Controller Hardening Guide · Golden Ticket, Silver Ticket and DCSync Guide · MITRE ATT&CK T1484 Domain or Tenant Policy Modification Guide · Tiered Administration and Enterprise Access Model Guide