In the DCShadow: How to Become a Domain Controller

I have always been fascinated by lateral movement attacks possible within Windows Active Directory environments. Hosts are compromised; credentials extracted; lateral movement achieved until the final price for Windows Domain domination is captured: the credentials of one of the members of the Domain Admin Group. All these are techniques used most commonly by Red Teamers in large enterprises.

One of the most common tools used by Red Teamers is Mimikatz – https://github.com/gentilkiwi/mimikatz – brought to us by the genius Benjamin Delpy. This tool – in the form of a Windows executable or memory injectable dll – helps penetration testers extract among other things LSASS password hashes, passwords in clear from memory, Kerberos golden tickets from a compromised host, including the domain controller.

As part of the mimikatz toolkit, Delpy just released another method called “DCShadow”, which is more of a stealth persistence method within the domain than a privilege escalation one.

Let’s see how it works.

DCShadow is a new feature in mimikatz located in the lsadump module. The attack and module work by simulating the behavior of a Domain Controller (using protocols like RPC used only by DC) to inject its own data, and bypassing most of the common security controls including logging. It also shares some similarities with the DCSync attack, which is already part of the mimikatz lsass module. One of the major limitations of the “DCSync” attack is the inability for an attacker to inject new objects in the targeted AD domain. Of course, an attacker could take ownership of an administrative account using the good old Pass-The-Hash technique and inject objects afterward, but that requires more effort, additional steps, and has a higher probability of being busted by blue teams. The “DCShadow” attack removes this limitation by reversing the “DCSync” attack paradigm.

DCShadow was recently presented at the Bluehat IL 2018 conference by Vincent LE TOUX and Benjamin Delpy.

With “DCShadow”, attackers no longer try to replicate data but will register new domain controllers in the targeted infrastructure to inject Active Directory objects or alter existing ones (by replacing the attributes’ content).

The “DCShadow” attack is done using the following steps:

• Registering the “DC” by creating 2 objects in the CN=Configuration partition and altering the SPN of the computer used.
• Pushing the data – triggered using DrsReplicaAdd, Kerberos Credentials Collector (KCC) or other internal AD events
• Removing the object previously created to demote the DC

The “DCShadow” attack relies on the addition of a new nTDSDSA object in the Configuration partition to register itself as a new member of the replication process. However, adding this sole object is not enough to allow our rogue server to initiate replication. In fact, to be part of the replication process we need to take care of two requirements:

• Be trusted by other servers, meaning that we need to have valid authentication credentials
• Provide authentication support to let other DCs connect to our rogue server when we need to replicate data

By using a valid computer account, a rogue server can be treated as a trustworthy AD server. The Kerberos SPN attributes will provide authentication support for other DCs. Therefore, every nTDSDSA object is linked to the computer object through the serverReference attribute.

The “DCShadow” attack will use a legitimate computer account to authenticate to other DCs in the forest. Although the computer object and the nTDSDSA object will bring the ability to authenticate to other DCs, the “DCShadow” attack still needs to let other DCs connect to the rogue server to replicate illegitimate information from it.

This last requirement is fulfilled using the Kerberos Service Principal Name (SPN). As extensively explained in several publications, SPNs are used by Kerberos service (KDC) to encrypt the Kerberos ticket with the computer account associated with the SPN. In our case, the “DCShadow” attack will add SPNs on the regular computer object used to authenticate.

To serve illegitimate data, the rogue domain controller will have to implement the minimal set of RPC functions required by the MS-DRSR specifications: IDL_DRSBind, IDL_DRSUnbind, IDL_DRSGetNCChanges, and IDL_DRSUpdateRefs. The Interactive Data Language (IDL) of these functions are provided by Microsoft in its open specifications and are now implemented into Benjamin Delpy’s Mimikatz tool.

The final step of the “DCShadow” attack is to trigger the replication process. To do so, two strategies can be conducted:

• Wait for the KCC process of another DC to initiate the replication process (requires 15 minutes delay)
• Force the replication by invoking the DRSReplicaAdd RPC function. It will change the content of the repsTo attribute which will start an immediate data replication.

The following chart describes the different steps achieved during the DCShadow attack.

On the defensive side, blue teams in charge of AD security monitoring usually rely on event log collection. Computers that are members of a domain are configured to push their logs to a central Security information and event management (SIEM) to be analyzed.

During the “DCShadow”, the event logs related to the injection of new data are only created on the attacker’s machine, which will obviously not signal itself by sending events to the SIEM. In this way, the “DCShadow” attack can be stealthy as only a few event logs will be generated by legitimate computers.

Blue teams need a complete redesign of their strategy and shift their focus from log analysis to AD configuration analysis. The naïve approach would be to monitor replications (DrsGetNCChanges RPC changes).

“DCShadow” is not a vulnerability but an innovative way to inject illegitimate data into an AD infrastructure.

No unprivileged attacker will ever be able to use it to escalate their privileges and gain administrative access to your AD using “DCShadow”. Bottom-line is: if your AD is properly configured and secured, you do not need to take any urgent actions.

“DCShadow” does not require any urgent patching campaign nor special configuration to be applied, this has nothing to do with WannaCry/NotPetya incident response.

Not being a vulnerability, “DCShadow” will not be patched by a Microsoft update. Trying to counter it would require changes to the way AD works, and hence break the system.

However, the fact that a new attack method is publicly available for anyone to use needs to be considered. It offers an extremely stealthy way for privileged attackers to perform actions, so detection strategies should be updated to reflect this new threat. Traditional event log analysis methods will probably fail to detect “DCShadow” usage. To efficiently detect this attack technique, it requires being able to continuously monitor the AD database to isolate illegitimate changes.

At the technical level, DCShadow is a game-changer because:

• The modifications done are made without any logging
• Modifications are done only by a DC such as setting the SID History or WhenChanged can be done without logging
• Partial changes such as changing only the previous password without the new one can be done without logging
• Modifications not compliant with the AD data such as a very long sAMAccountName (< 16 characters) can be done without logging

FAQ

Q: Is DCShadow a permanent domain controller?
A: No, it transforms itself as a DC only the time the changes are pushed (a few seconds)

Q: Does DCShadow deals with the KCC?
A: No, it only adds a single branch to the replication topology and removes it afterward. It deals with KCC only if the configuration records stay for long and in this case, it does not break the topology.