Recently, I came across a post outlining how companies CANNOT effectively defend against a DCShadow attack but instead need to take a reactive approach to identify when it may have occurred by monitoring their environment, and rolling back any unwanted changes once they were identified. Unfortunately, reacting to an incident could mean the damage is already done and a malicious actor has run off with the ‘keys to the kingdom’. The best control to get a handle on a potential DCShadow attack would be to prevent one in the first place.
In this blog I will be covering the following topics:
To start, let’s take a step back and identify what a DCShadow attack is, how it works, and why that matters to an organization. Jeff Warren already did a great post on how to attack Active Directory with DCShadow. At a high-level, a malicious actor gains access to a privileged account and wants to make some changes to persist in your environment. Directly making changes to group membership, permissions or the AdminSDHolder container would raise some red flags and set off the alarms, but with DCShadow, an attacker can make some changes and push them through with replication, circumventing most monitoring products and native event logs. If you’re not aware, DCShadow is actually a feature of the tool Mimikatz. What the tool does under the covers is register a computer as a ‘rogue’ Domain Controller in Active Directory. This is done by modifying the service principal name of a computer account, and creating a server object in the configuration partition within a Site, tricking Active Directory into thinking this is, in fact, a Domain Controller that should be trusted to replicate changes from. If you want to see a demo of this attack, be sure to check out the DCShadow attack page! This would require some pretty high privileges, if not using an account that is a member of something like Domain Admins, the account would need write access to a computer object, or more specifically ‘Write servicePrincipalName’ and ‘Create all child objects’ on the ‘Servers’ container within a Site.
Thanks to my colleague Joe Dibley, I was provided some knowledge on how you can set up policies in StealthINTERCEPT to actually prevent a DCShadow attack from Mimikatz.
As you can see in the video above, a Domain Admin, who has Full Control on the Site object and a computer object is failing to execute a DCShadow attack. How is this possible? Within StealthINTERCEPT we’re locking down the capability to create new objects in a site and to modify servicePrincipalNames of computers to one Active Directory group. StealthINTERCEPT allows you to block changes made to Active Directory, so even though Domain Admins have full control on the objects through permissions, if they’re not a part of the group we’re telling StealthINTERCEPT to allow, the change will be blocked.
Potentially your organization isn’t ready to block Active Directory changes, or perhaps you want to just understand what permissions exist even though you’re locked down with StealthINTERCEPT. In comes StealthAUDIT Active Directory Permissions Analyzer. With StealthAUDIT, you’re able to collect and report on all of the Active Directory permissions that exist within your environment. Specifically highlighting permissions that may be used to escalate privileges, persist, or move laterally throughout your organization. That includes executing a DCShadow attack:
The report above is highlighting what users in the environment have the capability to write the servicePrincipalName attribute on a computer object through various permissions such as:
The capability to create an object within the serversContainer on a Site through:
Having one permission from both sets of permissions above could lead to the capability to execute a DCShadow attack. Being aware of what users have this access, and monitoring the actions those accounts take or removing that access, is also an effective way of stopping a DCShadow attack.
In the instance your organization isn’t ready to block changes made to Active Directory using StealthINTERCEPT and auditing the permissions that exist in Active Directory isn’t enough, StealthDEFEND can help you identify and respond to a DCShadow attack. Not only will StealthDEFEND identify a successful DCShadow attack, but an unsuccessful one would be identified as well. This would give you the capability to respond to and shut down an account that failed to execute DCShadow. As I mentioned above, Lee Berg has a blog post that goes into detail on how to respond to a DCShadow attack using StealthDEFEND.
As you can see, by no means is it impossible for an organization to prevent a DCShadow attack. An organization may need to adapt and adhere to new policies to effectively mitigate the attack once StealthINTERCEPT is preventing specific changes in Active Directory, but it is definitely possible. If your organization isn’t ready to block changes, you’re still capable of identifying what privileged accounts you should be monitoring through StealthAUDIT and responding to a potential DCShadow attack with StealthDEFEND.
Kevin Joyce is a Senior Technical Product Manager at Stealthbits – now part of Netwrix. He is responsible for building and delivering on the roadmap of Stealthbits products and solutions.
Kevin is passionate about cyber-security and holds a Bachelor of Science degree in Digital Forensics from Bloomsburg University of Pennsylvania.
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.
Leave a Reply