Loading
October 13 2026

Know your enemy: How DCShadow uses your own Active Directory against you

Inside the identity attack that hijacks AD's own replication to push malicious changes and how directory-level detection can thwart them.

DC Shadow

Cybersecurity Awareness Month continues with a look at DCShadow, an attack that turns Active Directory's own replication against itself to push malicious changes that blend in as routine. This is part two of a three-part series on the most destructive identity attacks, and how identity and security teams can mitigate their impact. Part one of this series covered Golden Ticket attacks, which exploit the trust Kerberos depends on.   
 

DCShadow was first demonstrated at BlueHat IL in 2018 but has since shown up as one of the most common techniques (MITRE ATT&CK T1207) used by attackers in ransomware events today. Nation-state actors have frequently used DCShadow to target public sector and critical infrastructure. 

This post breaks down how DCShadow attacks work, how they avoid log-based detection, and how to stop them.

Anatomy of a DCShadow attack

During a DCShadow attack, the attacker briefly creates an illegitimate domain controller (DC) that exists long enough to replicate a malicious change across all other DCs. Because DCShadow uses AD’s own replication capabilities, malicious changes look benign and aren’t flagged.

Figure 1: One AD forest contains multiple Domains which are controlled by domain controllers. Each DC often consists of multiple Organization Units (OUs) which contain AD objects and allow you to link Group Policy Objects (GPO) to users. If one DC pushes a change, it can be legitimately replicated across all DCs and therefore across the entire AD environment. This is a built-in capability of AD meant to make system updates across the entire AD environment easy. DCShadow uses this capability for malicious purposes.  

Attackers use DCShadow in the following sequence:

  1. Initial access: The attacker gains a foothold via phishing or a stolen low-privilege credential.
  2. Privilege escalation: The attacker obtains Domain Admin or Enterprise Admin-equivalent rights through a separate compromise path (for example, Kerberoasting, ACL/delegation abuse, or GPO abuse).
  3. Rogue DC registration: The attacker registers the compromised machine as a temporary domain controller by creating servers and other critical internal components in AD.
  4. Malicious replication push: The attacker uses AD's own replication protocol to inject a single attribute change—for example, a shadow credential or group membership—directly into production domain controllers, disguised as routine synchronization.
  5. Cleanup: The attacker deregisters the rogue DC, removing the traces of the attacker’s actions.
  6. Persistence and exploitation: The injected change is now live, indistinguishable from a legitimate directory attribute, and survives normal remediation attempts like password resets or account disablement.

By step 4, the change is already indistinguishable from routine AD synchronization.

Why most security tooling is blind to DCShadow 

Many security teams believe a DCShadow attack can be stopped by looking for flagged behavior in Windows Security Event Logs. That instinct is reasonable for almost every other attack. However, native Windows auditing was never built to log DC-to-DC replication as a potentially problematic event. Under normal circumstances, there’s nothing suspicious.

There’s another avoidance mechanism at play. SOC analysts watch for alerts that flag like replication traffic arriving from an IP that isn't on the known DC list, or an unexpected DRS bind request. But these notifications depend on having those alerts already configured. Even then, these alerts only fire when it's too late. 

The solution? Intervene at step 3—the rogue DC registration itself.

How Cohesity Identity Resilience thwarts DCShadow attacks

Cohesity Identity Resilience alerts in real time on unauthorized domain controller registrations and unexpected changes within AD. The anomalies are flagged the moment the rogue servers or objects appear in the directory, independent of whether that change would ever be visible in Windows Event Log. For example, if an attacker creates a fake DC to push a malicious replication, Cohesity Identity Resilience observes the appearance of that directory-level object and notifies you immediately.

Figure 2: Inside Cohesity Identity Resilience, you can configure a variety of rules that not only notify you but automatically undo a malicious change.  

This use case is part of a broader capability: Cohesity Identity Resilience's ITDR continuously monitors 220+ Indicators of Exposure (IOE) and Indicators of Compromise (IOC) across AD and Entra ID, including known DCShadow indicators. The product detects these changes at the directory layer even when the attack is specifically engineered to leave no standard audit trail. 

Here's a deeper look at how Cohesity Identity Resilience detects and responds to a DCShadow attack*.

  1. An attacker, having already escalated to Domain Admin-equivalent rights through an earlier compromise, registers the compromised machine as a rogue domain controller.
  2. Cohesity Identity Resilience flags the unauthorized domain controller registration in real time, the moment the object appears in the directory. 
  3. The alert routes to the security team with full context: which machine registered as a DC, when, and why it's anomalous (for example, it doesn't match the organization's known, approved DC inventory).
  4. Automated rollback removes the rogue DC registration and reverts any replicated attribute change it already pushed, closing the window before the attacker can deregister the fake DC and erase the evidence.
  5. The security team completes triage, confirms containment, and begins a forensic review of how the attacker obtained the privileged rights needed to register a DC in the first place.

*Note: The walkthrough above is illustrative, a representative sequence. Not every DCShadow attack follows these exact steps.

Start catching advanced identity attacks now

A DCShadow attack rarely leaves a trace that can be caught by standard logging. If you start by catching rogue objects created in your AD, the rest of the attack never gets a chance to happen.

  • Coming up in part three, we’ll go inside a Kerberoasting attack. 
  • Read part one.

Want to see how Cohesity Identity Resilience detects and stops attacks like DCShadow in your environment? Watch the demo below: 

Written By