Active Directory PentestingPersistence
DC Shadow
Theory
The idea behind this persistence technique is to have an attacker-controlled machine act as a domain controller (a "shadow DC") to push changes onto the domain by forcing legitimate domain controllers to replicate from it.
Two requirements must be met for a machine to act as a domain controller:
- Be registered as a DC in the domain, by:
- modifying the computer's SPN (
servicePrincipalName) toGC/$HOSTNAME.$DOMAIN/$DOMAIN, and registering the DRS GUID SPNE3514235-4B06-11D1-AB04-00C04FC2DCD2/$HOSTNAME.$DOMAIN - adding an entry
CN=$HOSTNAME,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=$DOMAINwithobjectClass: server,dNSHostName: $HOSTNAME.$DOMAINandserverReference: CN=$HOSTNAME,CN=Computers,DC=$DOMAIN
- modifying the computer's SPN (
- Be able to issue and respond to the replication RPC calls:
DRSBind,DRSUnbind,DRSCrackNames,DRSAddEntry,DRSReplicaAdd,DRSReplicaDel,DRSGetNCChanges.
The attack workflow (steps 1 and 2 can be swapped):
- Register the workstation as a shadow DC (add the
CN=Configurationentry, modify its SPN). - Prepare the changes to push (
DRSAddEntry). - Push them by forcing a legitimate DC to replicate from the workstation (
DRSReplicaAdd, which triggers aDRSGetNCChangesfrom the legitimate DC to the shadow DC). - Unregister the workstation (
DRSReplicaDel, and revert theCN=Configurationentry and the SPN).
DC Shadow is a "meta" technique: because it can push any attribute change into the domain, it can be used to deliver other persistence primitives such as SID History, Delegation to KRBTGT and DACL abuse while blending in as legitimate replication traffic.
Practice
There is currently no UNIX-native tool to perform DC Shadow; the replication-server side of the attack has yet to be implemented outside of Windows.