Testing the Recovery from DCShadow Attacks

MITRE ATT&CK reports that a “rogue” domain controller could be used to manipulate data in Active Directory. This attack, known as a DCShadow attack, requires you to have administrative rights, but also allows the actions that are modified to be hidden, as the changes are not made directly through the Local Security Authority Subsystem Service (LSASS) but through replication.

In testing DCShadow, I was a little concerned because of a statement made directly at dcshadow.com. It states, “Beware that pushing data using replication can brick your domain (although we never did it while developing DCShadow).”

While I would never advocate to try to brick your domain in production, I did want to test it in my lab environment. Fortunately, I work for a software company that allows me to backup and restore Active Directory and decided I would do a little testing with our products to detect this activity, as well as recover the environment. While I do have my own local virtual machines, I opted to perform the testing in one of our production labs.

I decided to play around with one of my test user accounts. I’m a big fan of Arrested Development and have a test account named Bob Loblaw. I decided that I would change the primarygroupID of this account to 512.  Here is the first look at the account attributes and group membership:

 Testing a DCShadow attack

In our production lab, I have an old Windows 7 box with Mimikatz. I wanted to use Windows 7 because DCShadow is much easier to get installed on this version of Windows. You can still easily install it on Windows 10, but I wanted to take the route with the least amount of effort.

Next, I opened a cmd prompt running as administrator and executed Mimikatz. I then loaded the Mimidrv service (last I saw on Twitter, this is also signed with Windows 11) and then elevated my token.

 

I then cleared the screen and executed this command:

Lsadump::dcshadow /object:bobloblaw /attribute:primarygroupid /value:512

Now that this attribute had been set, I needed to push it to Active Directory. In order to do that, I had to open another CMD prompt.

This process requires having a user who has access to make this change:

 

In the second window, I executed the command shown below. I like to have the two command prompts side by side in order to see the data change in the first window:

Lsadump::dcshadow /push


After I hit enter, the left pane changed first.

DCShadow can now be detected with Quest On Demand for Audit. We can do this with our on-premises auditing tools as well, but the likelihood of your on-premises being affected if your Active Directory is affected means that on-premises tools may not have a copy of these events if they are encrypted. So, SaaS is a great place to store this data to see what is going on:

Drilling down, I could see a domain controller was moved to a site. This is indicative of DCShadow, but it can also happen legitimately. New domain contollers are, hopefully, not a frequent occurrence, so every event should be investigated:

Unfortunately, traditional logging tools can’t reveal exactly what changed, just that replication activity occurred.

Looking at the Active Directory object, I could see some changes:

The attribute changed to 512, which equates to domain admin privileges. Other attribute changes can occur using DCShadow and determining what has changed can be problematic. Some auditing/recovery tools won’t work. For example, some people use Microsoft native APIs to rewrite the previous value into that attribute, but when you attempt do that, you will get this error:

This is where Quest Recovery Manager for Active Directory Disaster Recovery Edition can add value if you are trying to restore your Active Directory from these attribute level changes. First, it can compare your live Active Directory to the last known good backup of those attributes and determine what is different:

This is extremely valuable because auditing tools wouldn’t write this change on a domain controller since the change doesn’t go through LSASS (they are added via rogue replication). Instead, I can see what has changed and view the primary group ID. Since I didn’t want to have any issues in this production lab environment, I continued the recovery process. Because I was not just re-writing the attribute back via native API’s and was invoking our restore agent instead, I was able to successfully restore this attribute to its previous state. If you’re using DCShadow, this means an attacker already has elevated rights and wants to create a backdoor to persistently have access to an environment. If DCShadow has been detected, this is a great way to identify what happened and correct the attributes to a good state so that you don’t brick your Active Directory.

Related Content