Why Most Organizations Still Can’t Defend against DCShadow
DCShadow is a readily available technique that allows an attacker to establish persistent privileged access in Active Directory (AD).
Specifically, DCShadow allows an attacker with privileged access to create and edit arbitrary objects in AD without anyone knowing. This allows the attacker to create backdoors all over AD that can’t be detected, even if the original privileged access is.
Much has been written about DCShadow, yet most organizations still can’t defend against it.
While that’s a huge concern, it shouldn’t come as a complete surprise given that DCShadow is specifically designed to circumvent existing security measures. So, what can you do about it?
What is DCShadow:
DCShadow is a feature of the open-source Mimikatz utility (available for download here). Mimikatz is the leading post-exploitation tool for Windows credential-based attacks and has been used in many of today’s most destructive cyberattacks, including LockerGoga, NotPetya, WannaCry, SamSam, and no doubt more to come.
How DCShadow works:
DCShadow circumvents existing security measures in several different ways:
- Exploits the normal replication mechanism in AD. DCShadow is not related to a Windows vulnerability, so there’s no security patch you can apply to eliminate your exposure. It’s also not related to AD configuration, so there’s no setting you can change close a loophole.
- Evades detection by bypassing Windows security event logging. DCShadow allows any Windows server to impersonate a domain controller (DC) and inject changes directly into the AD replication stream. Such changes aren’t recorded in security event logs, and there’s no audit setting you can adjust to change that.
As a result, SIEM systems and most AD change tracking tools don’t see – and can’t alert you to – changes made by the attacker to maintain privileged access (such as creating a new user and making it a member of the Domain Admins group).
- Allows an attacker to inject any change into AD. For example, an attacker can add the SID of an enterprise or domain admin to the SID History of a regular user account and get privileged access via that account. So, even if you restrict changes to the Enterprise Admins and Domain Admins groups, an attacker can still get enterprise or domain admin rights. And, if you monitor changes to sensitive security groups, you won’t catch an attacker with privileged access via SID History.
DCShadow is also incredibly efficient: an attacker only has to use their original privileged access once and can create any number of untraceable backdoors in just a second or two.
In one Mimikatz console, the attacker queues up all the backdoors they want to create in AD (new user accounts, group memberships, SID History) etc.:
In this example, the attacker has queued up just one change (adding a domain admin’s SID to a regular user’s SID History), but the attacker could easily queue up 15 or 20 or more changes.
In a second Mimikatz console, the attacker “pushes” the changes into the AD replication stream:
The injection of changes happens in just a second or two, including the time it takes to register and unregister the fake DC.
What you can do about DCShadow:
In part 2 of this blog post, I’ll talk about steps you can take to defend against DCShadow.
As you might guess, one way is to monitor changes in the AD replication stream. If you’d like a sneak peek at that approach – or a demo of a DCShadow attack – you can view a short (8-minute) video that I recorded recently. The video is available here.
The post Why Most Organizations Still Can’t Defend against DCShadow appeared first on Semperis.
*** This is a Security Bloggers Network syndicated blog from Semperis authored by Darren Mar-Elia. Read the original post at: https://www.semperis.com/blog/why-most-organizations-still-cant-defend-against-dcshadow/
