Introducing StealthAUDIT 11.5! Complete your cloud security puzzle. LEARN MORE

Detecting DCShadow with Event Logs

Blog >Detecting DCShadow with Event Logs

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 E3514235–4B06–11D1-AB04–00C04FC2DCD2

For more details, read the TechNet article here or this DCShadow overview.

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.

Detecting DCShadow through SPN changes to the specific SPN values required to impersonate a domain controller for this 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:

Sites container within the Configuration Namespace where rogue DCs will be created and deleted.

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.

Detecting the creation of a server in the Configuration Namespace.

Event ID 5141 will show the same information for the deletion of this event.

Detecting the deletion of a server in the Configuration Namespace indicating a rogue DC is being removed through DCShadow.

Replication Monitoring

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.

Identifying a rogue domain controller through replication event log 4929

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:

Don’t miss a post! Subscribe to The Insider Threat Security Blog here:


Featured Asset

Leave a Reply

Your email address will not be published. Required fields are marked *




© 2022 Stealthbits Technologies, Inc.

Start a Free Stealthbits Trial!

No risk. No obligation.