QOMPLX Knowledge: DCShadow Attacks Explained

This is the latest in a series of posts we’re calling “QOMPLX Knowledge.” These posts are intended to provide basic information and insights about the attack activity and trends that are driving malicious campaigns and that QOMPLX researchers encounter in our forensic work with customers. In this post, we’re going to talk about DCShadow attacks, a popular tool for attackers to maintain persistence within compromised environments.

As we noted in our recent “ManyKatz” report, attacks on Active Directory are a common thread in many of the most high-profile breaches in recent years. That is due, in part, to the emergence of open-source tools such as MimiKatz, which serves as a kind of “Swiss Army Knife” of sophisticated attack tools that can be used against both Active Directory and the underlying Kerberos authentication protocol.

In fact, many of these attacks owe their existence to MimiKatz. In our last post, we profiled one: so-called DCSync attacks. In this post, we’re going to talk about a close cousin of the DCSync attack: the DCShadow attack. These are attacks in which an adversary seeks to manipulate an Active Directory environment by simulating an Active Directory domain controller. DCShadow attacks are a popular tool for attackers to maintain persistence within compromised environments, and need to be on the radar of any serious network defender.

Key Points

• A DCShadow attack is a post-exploitation attack technique in which attackers register a rogue Active Directory Domain Controller and use that to inject malicious Active Directory objects (e.g. credentials) to other Domain Controllers that are part of the same Active Directory infrastructure.
• DCShadow attacks were introduced in 2018 as a feature of the MimiKatz attack tool. They require attackers to first have local administrator access to a Domain Controller, or domain administrator credentials.
• DCShadow attacks facilitate lateral movement (for example via privilege escalation). They can also be used for persistence, leveraging SID-History Injection, or modifying AD objects like accounts or access control lists to establish backdoors within compromised environments.
• DCShadow abuses core Active Directory’s technical specification and protocols such as the Directory Replication Service (DRS) Remote Protocol [MS-DRSR]. As such, they can be difficult for organizations to detect using event logging and security monitoring tools.
• Spotting DCShadow attacks requires close monitoring of network traffic within an Active Directory environment, with special focus on monitoring data replication requests between known Domain Controllers and non-Domain Controller network hosts.

How DCShadow Attacks Work

The DCShadow attack was first unveiled at Microsoft’s invitation-only Blue Hat Conference in early 2018 by security researchers Benjamin Delpy, the creator of the MimiKatz tool, and Vincent Le Toux. It was later presented at the Black Hat Briefings in Las Vegas, Nevada in August 2018.

The attack is a close cousin of DCSync, an attack technique Delpy introduced in 2015. As we noted, DCSync allows an attacker to impersonate a domain controller and request password hashes from other domain controllers. Simply put: DCShadow inverts the attack path of DCSync, pushing Active Directory objects that benefit the attacker out into an Active Directory environment rather than pulling sensitive Active Directory objects from other domain controllers.

Like the DCSync attack, DCShadow is attractive to malicious actors because it is difficult to detect. Many of the steps to create and configure a rogue Domain Controller are not logged. Executed properly, a DCShadow attack can evade detection by SIEMs and other security monitoring tools.

Elements of a DCShadow Attack

Here’s how a DCShadow attack works:

1. DCShadow is a post-exploitation attack. That means adversaries must first have  access to the environment and control an account with sufficient permissions such as AD admin rights or a KRBTGT account password hash.
2. An attacker runs the MimiKatz tool and launches a DCShadow attack (lsadump::dcshadow).
3. Mimikatz creates a new server and nTDSDSA objects in the Active Directory forest Configuration partition. Next, it updates the SPN (Service Principal Name) of the computer hosting the rogue domain controller to “GC” (Global Catalog) and “E3514235-4B06-11D1-AB04-00C04FC2DCD2” (Active Directory Replication). The rogue domain controller is now registered and capable of replicating data to other domain controllers.
4. An attacker stages the malicious Active Directory objects she wishes to replicate. For example, she might create a new user account in the Administrators group for later use, modify a DACL (Discretionary Access Control List) to create a backdoor for a compromised account or modify a compromised account to include a SID history and facilitate access to another (trusted) domain.
5. Next, the attacker needs to replicate the malicious Active Directory objects to other domain controllers. To do that, an attacker can simply wait for other domain controllers to initiate replication using the Knowledge Consistency Checker (KCC) process, which happens every 15 minutes by default. Alternatively, an attacker could force an immediate replication using the DrsReplicaAdd feature.
6. After replication completes, MimiKatz cleans up signs of the compromise: deleting the rogue domain controller and other objects from the Configuration partition.

Detection, Prevention, Mitigation of DCShadow

As we noted, DCShadow attacks provide advantages for attackers who hope to maintain persistent access to a compromised environment because they leave few clues for monitoring tools or forensic investigators to detect. Still, that doesn’t mean that the attacks are impossible to spot. Firms have a number of tools at their disposal to identify DCShadow attacks at the network or host level.

Keep an eye on elevated permissions

As we noted, DCShadow attacks are post-exploitation behavior. The best defense against becoming a victim of one of these attacks is to keep a tight lid on user permissions. Specifically, your organization should monitor the permissions present in the Configuration partition on any domain controllers, making sure that only legitimate administrators are able to alter that partition. Auditing DACLs for permissions granting a non-administrator access to the Configuration partition may indicate a DCShadow attack is in the works or has taken place.

Watch for API calls from non domain controllers

At the network level, DCShadow attacks are identifiable if organizations are on the lookout for domain controller behavior coming from ordinary systems. For example, function calls related to replication such as DrsAddEntry or DrsReplicaAdd should only come from known domain controllers. Those calls originating from non-domain controller systems are suspicious and a red flag that a rogue DC may be operating on your network.

Investigate unusual Domain Controllers

Any nTDSDSA objects in the sites container for your Active Directory environment should be able to be matched with a list of known domain controllers in your environment. A domain controller object in the sites container that does not match a known domain controller should be investigated immediately.

Monitor system logs for telltale behavior

Locally, DCShadow attacks can be spotted as soon as new objects are added to the Configuration partition or when the computer object is changed. Organizations should create a baseline for the Configuration partition of their Active Directory schema and periodically audit that partition, noting the creation of nTDSDSA objects.

However, such detections are problematic. First: DCShadow attacks via Mimikatz remove the rogue DC immediately after illegitimate Active Directory objects are replicated from it. That means detection at the moment of creation of the rogue DC is key. However, domain controllers do not replicate those changes immediately, while enterprising attackers may choose to reuse a demoted domain controller, avoiding the creation of a new DC altogether.

Monitor the replication of AD objects

Organizations should monitor their environment for the replication of Active Directory Objects. Alerting on any Audit Detailed Directory Service Replication Events (4928 and 4929) may alert you to efforts to push malicious Active Directory objects like new or modified user permissions to your Active Directory environment.

Monitor use of SPNs

Use of Kerberos Service Principal Names (SPNs) by computers that are not part of the DC organizational unit (OU) is one indicator of DCShadow attacks, especially those beginning with "GC/" and the SPN associated with the Directory Replication Service (DRS) Remote Protocol interface (GUID E3514235–4B06–11D1-AB04–00C04FC2DCD2).

Additional Reading

• https://qomplx.com/kerberos_dcsync_attacks_explained/
• https://qomplx.com/qomplx-knowledge-golden-ticket-attacks-explained/
• https://qomplx.com/qomplx-knowledge-silver-ticket-attacks-explained/
• https://qomplx.com/qomplx-knowledge-responding-to-a-golden-ticket-attack/
• https://attack.mitre.org/techniques/T1207/
• https://www.dcshadow.com/
• https://blog.alsid.eu/dcshadow-explained-4510f52fc19d
• https://adsecurity.org/?page_id=1821
• https://ired.team/offensive-security-experiments/active-directory-kerberos-abuse/t1207-creating-rogue-domain-controllers-with-dcshadow
• https://medium.com/@maarten.goet/dcshadow-detecting-a-rogue-domain-controller-replicating-malicious-changes-to-your-active-1e22440df9ad
• https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/d2435927-0999-4c62-8c6d-13ba31a52e1a
• https://social.technet.microsoft.com/wiki/contents/articles/717.service-principal-names-spn-setspn-syntax.aspx