In part 1 of this blog post, I talked about the threat that DCShadow poses to organizations that use Microsoft Active Directory (AD). Here in part 2, I’ll talk about steps you can take to protect your organization.
(Quick recap: DCShadow is a feature of the Mimikatz post-exploitation tool that attackers use to silently create backdoors in AD by injecting changes directly into the AD replication stream.)
Limit testing to lab environments
Injecting changes into AD can corrupt or even brick your AD. So, if you want to simulate a DCShadow attack or otherwise experiment with DCShadow, only do so in an isolated lab environment.
Reinforce your defenses
Here are some steps you can take to defend your production environment against DCShadow:
Monitor privileged access
An attacker must have privileged access to use DCShadow. And once an attacker has privileged access, there’s really nothing you can do to stop them from using DCShadow.
Because Mimikatz is open-source software, an attacker can make a trivial modification to the code to change its signature and avoid detection by anti-virus and endpoint protection software. And while tools such as Windows Defender Credential Guard can stop Mimikatz from getting passwords out of memory, they don’t defend against the DCShadow feature (which doesn’t rely on passwords).
Therefore, restricting, monitoring, and managing privileged access (for example, with a PAM system) is fundamental to preventing a DCShadow attack.
Monitor changes to AD Sites and Services
New, transient server objects appearing under an AD site may indicate a DCShadow attack. I, therefore, recommend monitoring the AD configuration partition where these objects are stored for temporarily added DCs.
While changes injected by DCShadow into the AD replication stream are not captured in Windows security event logs, registration (and removal) of servers into the configuration partition by DCShadow is. So, for example, you can set up notifications in your SIEM system to alert on the creation of server objects under the CN=Sites, CN=Configuration container. Or if you’re using an AD change tracking tool like Semperis Directory Services (DS) Protector, you can set up notifications there:
(In this example, server has been selected as the Object Class, and a notification is sent when a server object is added to AD Sites and Services.)
Immediately disable compromised accounts
If a fake DC is detected, immediately disable the account that added it. Because DCShadow attempts to cover its tracks (by not leaving any), it’s not the kind of attack you should allow to unfold, watch, and then take action. In all likelihood, it’s too late, and the attacker has already created backdoors, but you should still disable the account to prevent further damage.
Shine a light on DCShadow
Even with the defensive actions above, you should assume that at some point, an outside intruder – or an insider gone rogue – will gain privileged access. And you should assume that the attacker has Mimikatz and knows how to use it.
To prevent your AD from being compromised in unknown – and therefore irreparable – ways, you need to be able to see changes made by DCShadow. Otherwise, you could be faced with having to rebuild AD from scratch, as outlined by Microsoft in Planning for Compromise.
The best and most direct way to see changes made by DCShadow is to monitor the AD replication stream.
In theory, you could expose changes made by DCShadow by dumping the contents of AD and comparing them to a backup. However, it’s cumbersome (if not impossible) to do so in practice. For example, I talked with an organization that attempted a “dump and diff” when their AD was compromised, and after three weeks of trying, they were still not confident they had found all the unauthorized changes.
Monitoring the AD replication stream also ensures visibility if an attacker circumvents security event logging in another way – for example, by turning logging off, disabling collection agents, deleting logs, etc.
Of course, monitoring is not enough – you also need a way to roll back unwanted changes immediately.
Both capabilities – monitoring the AD replication stream and immediately rolling back changes – are available in Semperis DS Protector. To illustrate, I recorded a short (8-minute) demo of a DCShadow attack and detection/remediation with Semperis.
The demo is available here.
Note that if you’re using an AD change tracking tool that monitors AD changes by injecting LSASS, you won’t see changes made by DCShadow unless the LSASS agent is also hooking replication events. (Typically, these agents only hook change events.)
Maintain a reliable last line of defense
I would be remiss if I didn’t include a reminder about the necessity of good backups and a proven recovery process. If an attacker gets in, gets permissions, and encrypts your systems, you don’t want to reward them (or the terrorists they’re working for) by paying the ransom. And if your systems are completely wiped, even that bad option isn’t available. So, keep backups out of harm’s way (i.e., offline) and test your recovery process for Active Directory at least once a quarter. (If quarterly DR testing sounds unreasonable, it’s time to look for a new backup/recovery system.)
Restoring sight to your SIEM system
When DCShadow was released, its creators warned that it could “make your million dollar SIEM go blind.” By monitoring the AD replication stream and forwarding change events to your SIEM system, you can restore sight to your SIEM system, protect investments in the system, and safeguard the integrity of Active Directory.
