DC Shadow

They told me I could be anything I wanted ... So I became a domain controller


The idea behind this persistence technique is to have an attacker-controlled machine act as a domain controller (shadow DC) to push changes onto the domain by forcing other domain controllers to replicate.
There are two requirements for a machine to act as a domain controller:
  1. 1.
    Be registered as a DC in the domain: this is done by
    1. 1.
      modifying the computer's SPN (ServicePrincipalName) to GC/$HOSTNAME.$DOMAIN/$DOMAIN
    2. 2.
      adding an entry like CN=$HOSTNAME,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=$DOMAIN with the following attribute values:
      • objectClass: server
      • dNSHostName: $HOSTNAME.$DOMAIN
      • serverReference: CN=$HOSTNAME,CN=Computers,DC=$DOMAIN
  2. 2.
    Be able to request and/or respond to specific RPC calls: DRSBind, DRSUnbind, DRSCrackNames, DRSAddEntry, DRSReplicaAdd, DRSReplicaDel, DRSGetNCChanges.
Below is the attack workflow (step 1 & 2 can be switched if need be):
  1. 1.
    Register the workstation that will act as the shadow DC
    1. 1.
      add the required entry in CN=Configuration
    2. 2.
      modify the workstation's SPN
  2. 2.
    Prepare the changes to be pushed onto the domain (with calls to DRSAddEntry)
  3. 3.
    Push the changes by forcing another legitimate DC to replicate from the workstation with a DRSReplicaAdd call, which automatically makes a DRSGetNCChanges call from the legitimate DC to the shadow DC.
  4. 4.
    Unregister the workstation so it is not longer considered to be a DC (by a DRSReplicaDel call and by reverting changes made to CN=Configuration and the workstation's SPN).
(step 1.1) add the entry to CN=Configuration
(step 1.2) modify the workstation's SPN
An example of DRSUAPI traffic for a successful DC Shadow attack
It is important to note that this technique can be used as a "meta" one, in the sense that it permits to use other persistence techniques, such as SID History , Delegation to KRBTGT and even DACL abuse.
For instance, a DC Shadow attack can be conducted to register a controlled workstation as a domain controller, and then use that to push changes to the domain that would expose it to DACL abuse.
"leHack 2023 - Un conseil, brûlez tout" by Charlie Bromberg and Volker Carstein


July 27th 2023 : There is currently no way to exploit this technique purely from a distant UNIX-like machine, as it requires some tools that have yet to be made.
DC Shadow can be performed by using Mimikatz. It works in every 64-bits Windows Server version up to 2022 (included). Everything happens on the workstation that will act as the shadow DC.
Two Mimikatz shells are required:
  • one with domain admin privileges (called the trigger shell from now on)
  • one as NT-AUTHORITY\SYSTEM (called the RPC shell from now on)

Preparing shells

# In a mimikatz shell, launched with DA rights
# This will be the trigger shell
# The following command will open a new mimikatz shell as NT-AUTHORITY\SYSTEM
# This will be the RPC shell
# On both shell, run the following command to confirm permissions
# On the trigger shell, it will return the domain admin account name (used to lauch the first mimikatz shell)
# On the RPC shell, it will return NT-AUTHORITY\SYSTEM

Preparing changes to push

# (RPC shell)
lsadump::dcshadow /object:ObjectToModify /attribute:AttributeToModifyOnTargetedObject /value:NewValueOfTargetedAttribute

Pushing changes

# (Trigger shell)
# The command below will register the shadow DC, push the changes, and unregister
lsadump::dcshadow /push
See the lsadump::dcshadow at The Hacker Tools for more info.


LeHack 2023 - Un conseil, brulez tout.pdf