Register to stream ATT&CKcon 2.0 October 29-30

DCShadow

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 Domain Controller (DC). [1] [2] 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. [3]

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] [2]

ID: T1207
Tactic: Defense Evasion
Platform: Windows
Permissions Required: Administrator
Data Sources: API monitoring, Authentication logs, Network protocol analysis, Packet capture
Defense Bypassed: Log analysis
Contributors: Vincent Le Toux
Version: 1.0

Mitigations

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

Examples

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

Detection

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. [5] [1] [2] DC replication will naturally take place every 15 minutes but can be triggered by an attacker or by legitimate urgent changes (ex: passwords). [2] 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. [6] [7]

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

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. [7] A rogue DC must authenticate as a service using these two SPNs for the replication process to successfully complete.

References