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?
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:
There are two important things to note about this attack:
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.
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.
Jeff Warren is Stealthbits’ General Manager of Products. Jeff has held multiple roles within the Technical Product Management group since joining the organization in 2010, initially building Stealthbits’ SharePoint management offerings before shifting focus to the organization’s Data Access Governance solution portfolio as a whole. Before joining Stealthbits – now part of Netwrix, Jeff was a Software Engineer at Wall Street Network, a solutions provider specializing in GIS software and custom SharePoint development.
With deep knowledge and experience in technology, product and project management, Jeff and his teams are responsible for designing and delivering Stealthbits’ high quality, innovative solutions.
Jeff holds a Bachelor of Science degree in Information Systems from the University of Delaware.
Learn why Active Directory security should be a priority for your organization and ways to mitigate against a data breach with this free white paper!
Read more© 2022 Stealthbits Technologies, Inc.
Nice Article!
Do not have the labtime to test it myself.
So my question: Will the changes which are made on the fake DC be visible on the auditlog of the realDCs?
IMHO the auditlogging is done per DomainController where the Change has been done. So i guess this technique will evade the AD auditlogging?
That’s exactly right, normally this would be logged on the domain controller where the change was made but in this case that isn’t an actual domain controller so it bypasses detection that relies on event logs making it very difficult to know what was changed even if you can detect the attack occurred.
Hello, I want to know, can I copy the normal DC to the DC we created?
In the DC Shadow attack, a new DC isn’t really created. Entries are added to force replication from a non-DC and a change set is staged so when the replication is triggered a change will be retrieved and committed to the domain. This attack is focused on leveraging the minimal rights and changes needed to perform this replication event, and not create an entire new domain controller which is part of what makes it so clever/scary.