In this series, we’ve learned about DCShadow and covered attack scenarios to demonstrate how this can be used for an attacker to create persistence as well as elevate privileges across forests. Now that we know the risks involved with DCShadow, let’s cover what you can do to detect this in your environment.
First, let’s recap the basics:
- The purpose of DCShadow is to make changes that will not be detected by event logs, so you will not be able to see what changes DCShadow is making
- An attacker must have Domain or Enterprise Admin rights to perform the DCShadow attack, so the most effective protections against this attack are the same that you would use to prevent any attack that requires Domain Admin rights
But even if you cannot see the changes that DCShadow is making, you can find signs that it is happening using the event logs. In this post we will explore what events to look for to catch DCShadow.
Computer SPN Changes
One of the requirements for DCShadow to work is for two particular service principal name (SPN) values to be added to the computer which will be impersonating the domain controller. This will be the computer from which the attacker is executing the DCShadow attack, and can be any domain-joined computer.
Those two SPNS are:
- The Global Catalog server SPN which has the format
"GC/<DNS hostname>/<DNS forest name>"
- The Directory Replication Service (DRS) SPN which has the format
"<DRS interface GUID>/<DSA GUID>/<DNS domain name>"were the <DRS interface GUID> is always
So we are looking for the addition of two particular SPNs to a computer which is not a domain controller, followed by the removal of those SPNs (note: in my lab, DCShadow only removes the Global Catalog SPN and leaves the DRS SPN but I imagine that will be changed eventually).
We can use Event ID 4742 to monitor these computer change events. You can see within this event what user initiated the change, so you know which Domain Admin account is being used to perform the attack.
Domain Controller Created and Deleted
One part of the DCShadow attack is to create a DC inside of the Configuration Namespace, within the Sites container. This is done by creating a server and NTDS settings for that server. You can see these objects for my legitimate domain controller below:
DCShadow will create this object, and then after the change is replicated it will immediately delete it to cover any tracks. This will leave behind a strange sequence of events where you will see a new DC being added and then removed.
The addition can be tracked with Event ID 5137, which contains the name of the rogue DC and the account responsible for creating it.
Event ID 5141 will show the same information for the deletion of this event.
It is also possible to monitor replication for detecting DCShadow. While there will be several replication events triggered, many may be difficult to differentiate from genuine replication events.
However, Event ID 4929 can be a useful indicator, which will identify that a source naming context has been removed, and it will point to the rogue DC as the source. Seeing this event for a computer which is not a recognized domain controller should raise red flags.
I also have noticed a reliable pair of 4935/4936 events indicating a replication failure which I am investigating to see if it can be reliably tied to DCShadow. But even without that, there are plenty of useful events to help build a detection ruleset around DCShadow in your environment.
Blog posts in the series:
- Post #1 – DCShadow: Attacking Active Directory with Rogue DCs
- Post #2 – Creating Persistence with DCShadow
- Post #3 – Privilege Escalation with DCShadow
- Webinar – DCShadow: Attacking Active Directory with Rogue DCs
Sign up for the full blog series to be notified when each new installment posts, here.