DCShadow

From enterprise
Jump to: navigation, search
DCShadow
Technique
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

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).12 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.12

Examples

  • Mimikatz’s LSADUMP::DCShadow module can be used to make AD updates by temporarily setting a computer to be a DC.43

Mitigation

This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of AD design features. For example, mitigating specific AD API calls will likely have unintended side effects, such as preventing DC replication from operating properly. Efforts should be focused on preventing adversary tools from running earlier in the chain of activity and on identification of subsequent malicious behavior.

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.512 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.67

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.