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.
Don’t miss a post! Subscribe to The Insider Threat Security Blog here:
Jeff Warren is Stealthbits’ General Manager, Products. Jeff has held multiple roles within the 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, 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.