DCShadow

Also calledrogue domain controller, rogue DC

Poses as a DC for a moment, so real DCs replicate the directory changes it holds.

Technique: MITRE ATT&CK T1207: Rogue Domain Controller (opens in a new tab)
Needs: Domain Adminorkrbtgt Key
Gives: Directory Write

How the Attack Works

Domain controllers accept changes that arrive by replication from any server registered as a DC in the configuration partition. With Domain Admin rights, a machine can register itself as a DC for a moment, with a DC's objects and replication SPNs. A real DC then pulls changes from it through the Directory Replication Service, and the registration is removed. The changes land as replicated changes, so the real DC writes none of the change events an ordinary edit would.

How It Plays Out

The attack step by step. Each step shows which machines take part, what travels, the keys and tickets each side now holds, what is logged and what a defender can see.

With Domain Admin rights, ws-017, dana's workstation, registers as a domain controller for a moment and has dc-01 replicate a change from it.Step through it

ws-017 Foothold

dc-01 Domain controller

Step 1 of 5, DC Registered, ws-017 to dc-01
Step 2 of 5, Replica Added, ws-017 to dc-01
Step 3 of 5, Changes Requested, dc-01 to ws-017
Step 4 of 5, Changes Replicated, ws-017 to dc-01
Step 5 of 5, DC Removed, ws-017 to dc-01

Step 1 of 5: DC Registered
ws-017 Foothold to dc-01 Domain controller
Request to register a new DC IDL_DRSAddEntry DRS RPC
WS-017 is added to the configuration partition as a DC, with a server object, an nTDSDSA object and replication SPNs on its account.
Logged
- 5137 A directory service object was created
  On dc-01, in the Security log When enabled
  The server and nTDSDSA objects created under the site.
- 4742 A computer account was changed
  On dc-01, in the Security log
  WS-017$ given a GC/ SPN. The directory replication SPN may log no 4742.
What Defenders See
The Security log on dc-01 shows event 5137 for the new objects and event 4742 for WS-017$ gaining a GC/ SPN. Defender for Identity also raises its DC promotion alert.
Step 2 of 5: Replica Added
ws-017 Foothold to dc-01 Domain controller
Request to add a replication source IDL_DRSReplicaAdd DRS RPC
WS-017 asks dc-01 to take it as a replication source, as a new DC would.
Logged
- 4928 An Active Directory replica source naming context was established
  On dc-01, in the Security log When enabled
  A replica source established whose source DRA is WS-017.
What Defenders See
The Security log on dc-01 shows event 4928 naming WS-017 as the source DRA. Defender for Identity also raises its replication request alert.
Step 3 of 5: Changes Requested
dc-01 Domain controller to ws-017 Foothold
Request for its changes IDL_DRSGetNCChanges DRS RPC
dc-01 asks WS-017 for its changes, exactly as it asks a real DC.
What Defenders See
Network data shows replication traffic from dc-01, a DC, to ws-017, a workstation.
Step 4 of 5: Changes Replicated
ws-017 Foothold to dc-01 Domain controller
Reply with the changes DRS_MSG_GETCHGREPLY DRS RPC
WS-017 returns the changes it holds, and dc-01 applies them as replicated changes from another DC.
What Defenders See
The Security log on dc-01 shows no event 5136, since replicated changes write none. The replication metadata names an origin that the rogue DC, ws-017, supplied itself.
Step 5 of 5: DC Removed
ws-017 Foothold to dc-01 Domain controller
The server and nTDSDSA objects are deleted, so the rogue DC is gone from the configuration partition.
Logged
- 5141 A directory service object was deleted
  On dc-01, in the Security log When enabled
  The server and nTDSDSA objects deleted.
- 4929 An Active Directory replica source naming context was removed
  On dc-01, in the Security log When enabled
  The replica source removed. Source DRA may be blank, so match its Source Address.
What Defenders See
The Security log on dc-01 shows event 5141 for the deleted objects and event 4929 as the replica source goes. WS-017$ can keep the replication SPN, which is a lasting sign.

Needs First

What the attacker must already hold for this attack to be possible.

Domain Admin Rights or The krbtgt KeyDomain Admin rights, or the krbtgt key to forge them, to register a DC.

Comes From

Domain Admin: Golden Ticket, Diamond and Sapphire Tickets, Certificate Services Abuse, noPac (sAMAccountName Spoofing) every attack that gives it: Domain Admin Rights
krbtgt Key: NTDS.dit Theft, DCSync

Gives the Attacker

What running it hands the attacker to use next.

Write Access to a Directory ObjectAny attribute of any object changed by replication, with none of the usual change events.

Leads To

Directory Write: Kerberos Delegation Abuse, Shadow Credentials, Delegated Managed Service Account Abuse, AdminSDHolder and SID History every attack that uses it: Write Access to a Directory Object

What Defenders See

What this attack leaves for a defender to find, and what to read in each. None of it is proof on its own, so treat each as a lead and confirm it against the rest.

Event and Log	Written On	Look For	Switch It On
5137 `A directory service object was created` (opens in a new tab) Security log	Domain controllers, for objects with a matching audit entry	A server or nTDSDSA object created in the configuration partition that no planned DC promotion explains.	Audit Directory Service Changes, and an audit entry (SACL) on the parent container
4742 `A computer account was changed` (opens in a new tab) Security log	Domain controllers	A computer that is not a DC gaining a GC/ SPN. The replication SPN may log no 4742, but can stay on the account afterwards.	Audit Computer Account Management
4928 `An Active Directory replica source naming context was established` (opens in a new tab) Security log	Domain controllers	A replica source established on a real DC whose source DRA names a machine that is not a DC.	Audit Detailed Directory Service Replication
4929 `An Active Directory replica source naming context was removed` (opens in a new tab) Security log	Domain controllers	The same replica source removed soon after, matched on Source Address, a DC that existed only long enough to replicate.	Audit Detailed Directory Service Replication
5141 `A directory service object was deleted` (opens in a new tab) Security log	Domain controllers, for objects with a matching audit entry	The server and nTDSDSA objects deleted soon after they were created.	Audit Directory Service Changes, and an audit entry (SACL) on the object

What It Looks Like

One event from the worked example, decoded field by field, so you can see what to read in it and what each value means.

4742 A computer account was changed

In the Security log on dc-01, 28 Oct 2026, 23:02:51 UTC

A workstation's computer account gaining a global catalogue SPN on dc-01.

A workstation's computer account, not a domain controller. No DC build was planned for it.
As Windows writes it: Account Name (computer changed) WS-017$
A global catalogue SPN on a workstation, which only DCs register. Look for 5137 and 4928 naming WS-017 next.
As Windows writes it: Service Principal Names GC/ws-017.corp.example/corp.example
The account that made the change, a Domain Admin. Find where it signed in from, since its rights did this.
As Windows writes it: Account Name (subject) Administrator

Defender for Identity Alerts

Where Defender for Identity runs, its sensors raise these from what they read on the servers they are installed on, domain controllers above all. Each names what it flags, which is a lead to confirm, not proof on its own.

Blind Spots

Where this attack leaves little or nothing to see, so a quiet log is not read as an all-clear.

Changes arrive by replication, so the real DC writes no 5136 for them. The registration, in 5137 and 4928, is the trail to follow.
The replication metadata on each changed attribute comes from the rogue itself, so an origin no DC explains is a lead, but a clean one proves nothing.

Hunt It

The query to run in each tool, and how well each one sees this attack. Pick the tool you use, and the others load their query when you open them.

Sees It DirectlyAlertEvidence (Defender for Identity alerts)

Needs Defender for Identity sensors on every DC, which watch the registration and the replication itself. An alert shows a machine acting as a DC, not which attributes it changed. Read their replication metadata.

KQLDefender XDR, Advanced hunting

// Defender for Identity DCShadow alerts: rogue DC promotion and replication requestsAlertEvidence| where Timestamp > ago(30d)| where Title contains "DCShadow"| summarize FirstSeen = min(Timestamp), Accounts = make_set_if(AccountName, isnotempty(AccountName)), Devices = make_set_if(DeviceName, isnotempty(DeviceName)), Addresses = make_set_if(RemoteIP, isnotempty(RemoteIP)) by AlertId, Title| order by FirstSeen desc

How to Prevent It

The controls that break this attack, each with how it helps here and, where the Registry topic has it, where to check it on a machine.

Least-privilege administration (opens in a new tab)
Keep Domain Admins and Enterprise Admins nearly empty, since registering a DC needs their rights.
Tiered administration (opens in a new tab)
Use those accounts only from privileged access workstations, so their credentials never sit on everyday machines.
Replication rights reviewed (opens in a new tab)
Review who holds replication rights, and treat any change to them as an incident to explain.

How the Attack Works

How It Plays Out

Step 1 of 5: DC Registered

Step 2 of 5: Replica Added

Step 3 of 5: Changes Requested

Step 4 of 5: Changes Replicated

Step 5 of 5: DC Removed