10,000-foot view:
Many of us are familiar with the variety of tools, attacks, and adversaries that focus on breaching Active Directory. With the release in 2018 of DCShadow, another highly effective vector was added to that ever-increasing list. To the credit of the research team, along with the exploit, they discussed how to understand and potentially mitigate the attack with increased monitoring and management OF the Active Directory. However, as with many of the attacks, it’s not only understanding HOW you got shot… but from where. This is where the Semperis research team focused some recent efforts. We can now provide a much more accurate picture of the enterprise landscape and clearly and accurately identify client-side machines that have been, or are using the attack tool against your organization’s Active Directory.
Background:
Mimikatz, the credential exploitation tool, provides a feature called “DCShadow.” You can think of DCShadow as doing the opposite of the DCSync command. Where DCSync can force Active Directory (AD) to synchronize user accounts and their password hashes to an attacker, DCShadow allows an attacker to inject changes into AD. It does this by simulating the behavior of a domain controller, which is essentially any compromised machine within an Active Directory domain. It is worth noting that DCShadow is a domain persistence tool. It requires that the attacker already have Domain Admin, or equivalent, access on an AD domain before it can be used. However, once that level of access has been achieved, it’s a powerful and silent tool for creating and updating objects in AD for the purposes of creating backdoors, elevating access on regular accounts, and otherwise establishing a foothold and executing control within the targeted environment.
Detectability
The difficult part about DCShadow is that, because it bypasses the normal mechanisms by which changes to AD are audited (i.e. normally done via the Windows security event log on domain controllers), you can’t easily detect when it’s being used. And, if the attacker is performing stealthy changes that you don’t happen to be looking for (e.g. injecting the Enterprise Admins SID into the sidHistory attribute on an otherwise unprivileged user) it can be very difficult to detect these backdoors. You can see breadcrumbs that may point to its usage—for example, when DCShadow is executed, an object of class server is temporarily added to the configuration naming context in a given forest, to make other domain controllers think the fake server is a real DC. But that object is quickly removed when DCShadow completes its run. Fortunately for the defender, it turns out that DCShadow leaves some fingerprints behind when it’s run on a host.
Discovering DCShadow Usage
First, a little background. A “normal” domain controller registers a number of Kerberos Service Principal Names (SPNs) when it’s promoted to a DC. One of these is a GUID-based SPN, as shown here:
That GUID-based SPN has an interesting characteristic. If we look at it closely, we see that there are actually two GUIDs in the SPN. The first, namely, E3514235-4B06-11D1-AB
04-00C04FC2DCD2, is what’s known as a Well-Known GUID (WKGUID) and is registered by every domain controller across every AD forest the same way. The second GUID, in our example here: 8b699bb0-d35e-4199-8dd4-6a296c5fc7db, is unique to a particular DC.
[semperis-mid-scroll-cta]
So how does this help us with DCShadow detection? Well, it turns out that when DCShadow runs on a given host, it adds a couple of SPNs to that machine to make other DCs think it’s a DC. One of those is the WKGUID-based SPN. Unfortunately, what it doesn’t do is clean up after itself when it’s finished running (Thankfully, a messy DCShadow). The result is that any host that has run DCShadow continues to store the WKGUID SPN in the servicePrincipalName attribute on its machine account.
You can see an example of that in the second screenshot below. In this example, we’ve run DCShadow repeatedly from this host—notice how many of the WKGUID SPNs appear in the list:
The good news here, is that we can use this information to distinguish hosts in AD that have run DCShadow. First, we know that only *legitimate* DCs should have this WKGUID SPN on their machine account. That’s easy enough to search for, but we can further narrow our search by also searching for another SPN that we know SHOULD NOT be on any machine other than a legitimate DC. The result that we came up with is the following LDAP Query:
“(&(objectClass=computer)(servicePrincipalName=E3514235-4B06-11D1-AB04-00C04FC2DCD2*)(!(servicePrincipalName=ldap*)))”
This query looks for all computer objects, whose SPN attribute contains the WKGUID SPN (We’re using a wildcard here to exclude the unique GUID part of that SPN) AND, does not include the LDAP SPN, which every legitimate DC contains.
In keeping with the stealthy nature of DCShadow, the act of adding this WKGUID SPN to the fake DC’s machine account is not logged in the security event log on the real DC that takes the replication request from the fake DC.
Summary
Assuming DCShadow doesn’t “clean up its act” any time soon, this detection allows us to quickly get to any machines that are being used to host DCShadow injections, appropriately quarantine them, and run full forensics and IR processes BEFORE they can do more damage.
DCShadow attack demonstration
DCShadow exploits a switch in the Mimikatz utility that enables privileged users to inject malicious changes into Active Directory without detection. Watch this video presentation to learn how to detect rogue domain controllers, quickly roll back unwanted changes, and restore sight to your SIEM. If you have any questions, please don’t hesitate to contact the folks at Semperis.
