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:
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.
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:
"GC/<DNS hostname>/<DNS forest name>"
"<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.
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:
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
Start a Free Stealthbits Trial!
No risk. No obligation.