A rogue server is a bad dream for any system administrator. But when that server turns out to be a domain controller, now you have a nightmare situation on your hands. A DCShadow attack is this exact scenario.
In this post, we will break down exactly what happens during a DCShadow attack, ways you can defend against it, and ultimately prevent yourself from waking up in cold sweats.
What is a DCShadow attack?
DCShadow is a post-exploitation attack where an attacker leverages privileged credentials to mimic a domain controller and make malicious changes to Active Directory.
DCShadow was first introduced at BlueHat IL and by Black Hat in 2018. In their presentations, Vincent Le Toux and Benjamin Delpy (gentilkiwi) introduced a new attack method that simulates the creation of a domain controller (DC) and leverages its synchronization to inject malicious changes into Active Directory (AD). Changes made in this way simply blend in as regular domain replication. DCShadow is a feature included in gentilkiwi’s tool Mimikatz.
How DCShadow attacks work
A DCShadow attack is primarily used to create persistence. For attackers to leverage DCShadow, they need access to Domain Administrator (DA) credentials. For the purpose of this article, we will focus specifically on DA access, but there are also ways around DA credentials, which Nikhil “SamratAshok” Mittal covers in a separate blog.
Using the DA account, an attacker registers a fake domain controller by creating two objects in the CN=Configuration partition. Next, the SPNs of the attacking computer account must be modified. This step effectively makes the attacker’s computer a temporary domain controller.
To understand the next concept, it is important to first understand DC replication at a high level. A typical Active Directory environment is configured with multiple DCs. When a user logs into a computer, the computer automatically connects to one of these DCs. The same thing occurs when an administrator makes changes to Active Directory. For example, an administrator connects to one DC, and adjusts a user’s group membership. That change is then replicated to all other DCs.
Attackers leverage this replication to sneakily make changes to Active Directory. The fake DC is used to stage the desired changes to AD and then replication is triggered. The other (real) DCs simply view this as typical replication.
The attack concludes by cleaning up the changes made to demote the fake DC, as if it was never there at all.
Getting DCShadow to operate is just the beginning. This attack is based on how you use it.
What can attackers do?
As mentioned previously, the DCShadow attack is used to create a foothold and maintain persistence. A simple and easily detectable example of this would be for the attacker to create a new AD account and grant it privileges. That way, when the original account is disabled, has its password changed, or is otherwise detected, an attacker can simply move to the newly-created account. A DCShadow attack has the ability to perform similar persistence techniques, but under the guise of normal directory synchronization.
Attackers won’t go through all this trouble to simply create a backdoor account. If they have been this sneaky so far, they are bound to do more harm using more creative techniques. Some example user attributes that can be modified are sIDHistory, ntpwdHistory, PrimaryGroupID, and whenChanged. Other attack methods may include making schema changes, attacking trusted domains, attacking KRBTGT, or modifying DACLs.
Attacks on SID History
To briefly explain using SID History, Mimikatz is run from a domain joined workstation as an administrator. The hacker account is staged to have its value for SIDHistory set to the SID of an account granted Domain Admin rights. With no further permissions applied, the next time the hacker account logs in, the SIDs associated with the account are evaluated. Because the account is associated with a DA account, this effectively grants the hacker account the same permissions. Sean Metcalf has a great article that fully explains the exploitation of SID History.
What makes this attack even more scary is the account modifications are made without generating any of the typical logs.
Defense and detection
The DCShadow attack is not a vulnerability that can simply be patched. The attack leverages Microsoft protocols in a way they were never intended to be used and therefore, this would be considered a “no-fix” vulnerability.
While this might sound like a dire situation, there are ways to defend against a DCShadow attack. As stated previously, DCShadow is a post-compromise attack, so a critical step to defend against it is never allowing it to happen in the first place. Each step an attacker must take before gaining DA is another opportunity for prevention. Having good Active Directory hygiene is the best defense against DCShadow.
It is true that DCShadow does bypass most logs collected by a SIEM or monitored by a SOC, but it is far from undetectable. Network traffic is a high-fidelity detection method. Modifications of the CN=Configuration object and DC replication should only ever occur from a DC so network traffic originating from other IPs would be deemed suspicious or should even be blocked.
Diagram from DCShadow.com
Benjamin Delpy has also provided a splunk script for detection of event logs that indicate a DCShadow attack. This includes checks for the addition of the SPNs.
Reduce your AD attack surface.
Seeing as the DCShadow attack just had its 5th birthday, many detection tools have caught up and are able to detect possible attacks. Quest On Demand for Audit is able to detect DCShadow and Quest Recovery Manager for Active Directory Disaster Recovery Edition can assist in restoring impacted objects back to their original configuration.
Conclusion
Why use DCShadow at all? If an attacker already has DA, isn’t it already game over? Mostly yes, but with good Active Directory hygiene and a strong detection team, that access may be short lived. The best defense is to prevent an attacker from getting this far.
Traditional protection methods such as account tiering, least privilege, and good password hygiene make it significantly more difficult for an attacker to be in position to perform a DCShadow attack. While it is no consolation, it is important to mention that if an attacker were to gain DA in your environment, there would be different attacks that are much more common. DCShadow has come out of the shadows and is far less scary.
Next on the agenda, I will be covering the boogeyman known as DCSync, stay tuned.
