Updated Two infosec bods have demonstrated an attack on Microsoft's Active Directory software that lets them insert their own domain controller into an existing enterprise setup.
DCShadow allows an attacker to create a rogue domain controller in an Active Directory environment, and use it to push malicious objects. How? Le Toux tweeted a summary:
For those you want the magic explained, #DCShadow is using DrsReplicaAdd (DRSR 184.108.40.206) to trigger a replication.— Vincent Le Toux (@mysmartlogon) January 29, 2018
It modifies the replTo attribute of a DC and triggers and immediate replication.
ReplicaSync doesn't trigger a replication (cc:@gentilkiwi) because replTo is not set pic.twitter.com/ZxKNhYBZfQ
Delsalle explained: “The idea of a rogue domain controller is not new and has been mentioned multiple times in previous security publications but required invasive techniques (like installing a virtual machine with Windows Server) and to log on a regular domain controller (DC) to promote the VM into a DC for the targeted domain.”
That's easily spotted, so Delsalle wrote that the attack described by Delpy and Le Toux has to “modify the targeted AD infrastructure database to authorise the rogue server to be part of the replication process.”
He continued: “The main action made by the 'DCShadow' attack is to create a new server and nTDSDSA objects in the Configuration partition of the schema.” nTDSDSA objects are described by Microsoft as the replication agent responsible for processing the Directory Replication Service protocol.
That change happens in a privileged environment, though, so the attack needs a way around controls on creating servers and initiating replications. Delsalle explained that Delpy and Le Toux were able to “isolate the minimum set of SPNs required for the replication process to go through. The results of their studies show that two SPNs are required to let another DC to connect to the rogue server” – these being the DRS service class (which has the well-known GUID E3514235–4B06–11D1-AB04–00C04FC2DCD2), and the Global Catalog service class (which has the string 'GC')."
From there, the attackers registered a domain controller into the replication environment, and had it authenticated by another domain controller.
The final step is to force a last replication step, with the IDL_DRSReplicaAdd RPC, allowing the attacker to add backdoors into the domain “by adding new member on an administrative group, or by setting SID history on a controlled user account for example).”
Crucially, how bad is this? Delsalle noted:
What is most important to take away from this analysis is that “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.
Le Toux noted in a tweet a few technical points about Delsalle's writeup you should probably keep in mind, though... ®
Great article explaining the #DCShadow attack.— Vincent Le Toux (@mysmartlogon) January 29, 2018
- the ntdsa object is removed after the push - detecting its presence is not reliable
- replication is not triggered by KCC but by modification of replTo
- the DC SPN is set by AddEntry (220.127.116.11.3 CreateNtdsDsa) @gentilkiwi https://t.co/k20rZB7AUA
Updated to add
A website describing the attack is now live here if you want more information.