Rogue Domain Controller

Adversaries may register a rogue Domain Controller to enable manipulation of Active Directory data. DCShadow may be used to create a rogue Domain Controller (DC). DCShadow is a method of manipulating Active Directory (AD) data, including objects and schemas, by registering (or reusing an inactive registration) and simulating the behavior of a DC. [1] Once registered, a rogue DC may be able to inject and replicate changes into AD infrastructure for any domain object, including credentials and keys.

Registering a rogue DC involves creating a new server and nTDSDSA objects in the Configuration partition of the AD schema, which requires Administrator privileges (either Domain or local to the DC) or the KRBTGT hash. [2]

This technique may bypass system logging and security monitors such as security information and event management (SIEM) products (since actions taken on a rogue DC may not be reported to these sensors). [1] The technique may also be used to alter and delete replication and other associated metadata to obstruct forensic analysis. Adversaries may also utilize this technique to perform SID-History Injection and/or manipulate AD objects (such as accounts, access control lists, schemas) to establish backdoors for Persistence. [1]

ID: T1207
Sub-techniques:  No sub-techniques
Tactic: Defense Evasion
Platforms: Windows
Permissions Required: Administrator
Defense Bypassed: Log analysis
Contributors: Vincent Le Toux
Version: 2.1
Created: 18 April 2018
Last Modified: 08 March 2022

Procedure Examples

ID Name Description
S0002 Mimikatz

Mimikatz’s LSADUMP::DCShadow module can be used to make AD updates by temporarily setting a computer to be a DC.[3][2]


This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.


ID Data Source Data Component
DS0026 Active Directory Active Directory Object Creation
Active Directory Object Modification
DS0029 Network Traffic Network Traffic Content
DS0002 User Account User Account Authentication

Monitor and analyze network traffic associated with data replication (such as calls to DrsAddEntry, DrsReplicaAdd, and especially GetNCChanges) between DCs as well as to/from non DC hosts. [4] [1] DC replication will naturally take place every 15 minutes but can be triggered by an adversary or by legitimate urgent changes (ex: passwords). Also consider monitoring and alerting on the replication of AD objects (Audit Detailed Directory Service Replication Events 4928 and 4929). [1]

Leverage AD directory synchronization (DirSync) to monitor changes to directory state using AD replication cookies. [5] [6]

Baseline and periodically analyze the Configuration partition of the AD schema and alert on creation of nTDSDSA objects. [1]

Investigate usage of Kerberos Service Principal Names (SPNs), especially those associated with services (beginning with "GC/") by computers not present in the DC organizational unit (OU). The SPN associated with the Directory Replication Service (DRS) Remote Protocol interface (GUID E3514235–4B06–11D1-AB04–00C04FC2DCD2) can be set without logging. [6] A rogue DC must authenticate as a service using these two SPNs for the replication process to successfully complete.