DCShadow: Attacking Active Directory with Rogue DCs

If you’re familiar with Mimikatz, you’ve already seen some of the ways it exposes weaknesses in Active Directory security (if you’re not, read up!).  Recently, a new feature was added to Mimikatz titled DCShadow and was presented by its authors Benjamin Delpy and Vincent LeToux at the Bluehat IL 2018 conference.

DCShadow enables Mimikatz to make changes to Active Directory by simulating a domain controller.  We’ve seen this in the past from Mimikatz, with the DCSync feature, which allows you to replicate password data from domain controllers.  But just replicating all of your passwords wasn’t enough, and now DCShadow enables attackers to make changes to Active Directory while avoiding common detection techniques.  In this series my goal is to provide a summary of how DCShadow works and to look at particular attack paths that are now possible leveraging DCShadow.   We’ll also cover how to protect yourself from attacks like these and how to detect if this is happening.   Let’s start with the basics: what does DCShadow actually do?

What Does DCShadow Do?

The authors of DCShadow have already provided an excellent overview of how this feature works and what it does on the DCShadow website.  I’ll summarize at a high level here:

1. An attacker obtains Domain Admin rights and wants to make changes that will not be detected to create persistence. Enter DCShadow.
2. DCShadow will register the computer it is run from (such as a workstation) as a domain controller in Active Directory by making changes to the Configuration schema and the workstation’s SPN values. Now AD thinks this workstation is a domain controller and it is trusted to replicate changes!
3. A change is crafted by the attacker. The workstation makes this change available to a legitimate domain controller through replication.
4. Replication is triggered by DCShadow and the change is replicated and then committed by a legitimate domain controller

There are two important things to note about this attack:

1. Because the changes are committed through replication, these changes are not logged to the event log how other changes would be. That is normally done on the domain controller where the changes originated, but in this case there is no actual DC where the changes originated from.  This is what makes this very difficult to detect.
2. This uses native features of Active Directory so it is not a vulnerability and cannot be patched. This makes it difficult to natively prevent this from occurring.

So you can imagine why this is a scary attack for most security defenders.  DCShadow provides the capability to make critical changes to Active Directory’s security, and these changes cannot be detected or prevented.

Getting It Working

DCShadow relies on having Domain Admin rights within the domain, so it should not be considered a privilege escalation tactic.  Rather, it is a means of creating persistence through changes to the environment without detection.  We’ll get in to some of those changes in a bit, but let’s start by getting this attack working.

The first step is creating a change you wish to push to AD.  The tricky part here is you must run the process which will create the change as the SYSTEM account, rather than a domain user account.  This is so that the change is coming from the computer which is going to be registered as a domain controller, not from a user.  If you fail to do this you may see this error code:

ERROR kuhl_m_lsadump_dcshadow_force_sync_partition ; IDL_DRSReplicaAdd DC=JEFFLAB,DC=local 0x80090322 (2148074274)

As seen here:

So we need to run as SYSTEM.  There are several ways to run the process as SYSTEM within Mimikatz, but for my test I used PSExec and the following command to get it working:

PsExec.exe –i –s cmd.exe

Once you launch Mimikatz through PSExec in this manner you should be able to see what context you are running under with token::whoami and then use token::elevate to be sure all threads will run as SYSTEM.

Now you should be able to push a change set without issue.  Let’s craft a simple change to start, such as setting the description of the Administrator account.  This will just illustrate the attack, then we’ll get into the actual attack scenarios which involve more complex changes.

Here is a command to change the description of the Administrator account:

lsadump::dcshadow /object:CN=Administrator,CN=Users,DC=JEFFLAB,DC=local /attribute:description /value:”DCShadow was here!” 

Now you should be able to run that and see that it is ready to push this change:

Now, we need to run another Mimikatz window to actually trigger the replication.  This time we will not run as SYSTEM but rather as our domain administrator account.  All we have to do is issue the following command to trigger the replication:

 lsadump::dcshadow /push 

Once issued you should see your original window update with the status of the change being pushed successfully:

Now we can go to the domain controller and check out our description field:

We did it!  That was surprisingly easy.  In our next post we will look at how this attack can be used to push changes to AD which can create persistence for an attacker while avoiding common detection techniques.

Don’t miss a post! Subscribe to The Insider Threat Security Blog here: