Skip to content

DC Shadow

Theory

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. Be registered as a DC in the domain**: this is done by;
    1. modifying the computer's SPN (ServicePrincipalName) to GC/$HOSTNAME.$DOMAIN/$DOMAIN
    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. 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. Register the workstation that will act as the shadow DC
    1. add the required entry in CN=Configuration
    2. modify the workstation's SPN
  2. Prepare the changes to be pushed onto the domain (with calls to DRSAddEntry)
  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. 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"

Practice

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.

Talk

LeHack 2023 - Un conseil, brulez tout.pdf

Resources

https://www.dcshadow.com/

https://tools.thehacker.recipes/mimikatz/modules/lsadump/dcshadow

https://stealthbits.com/blog/creating-persistence-dcshadow/

https://blog.netwrix.com/2022/09/28/dcshadow_attack/

https://www.netwrix.com/how_dcshadow_persistence_attack_works.html

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/d2435927-0999-4c62-8c6d-13ba31a52e1a

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-drsr/f977faaa-673e-4f66-b9bf-48c640241d47