DC Shadow attacks: There's a new DC in town

Written by Jean-Camille LOISEAU & Anup Tripathi | Published 30 July 2021

Domain controllers (DC) are among the most important servers for your organization. They handle authentication requests and verify users on computer networks. Domains Controllers sit at the top of (and enable) the IT hierarchy where your company organizes and secure all its users, servers and computers within the network.

Because they hold keys to the Active Directory (AD) kingdom, they are obviously a prime target for attack and DCShadow (MITRE: T1207) is a method of manipulating Active Directory by changing attributes of a system to register it as a new DC on the network. Once this "rogue" DC in place, use it to inject and replicate changes into the victim's AD.

DCShadow was first presented in 2018, and subsequently packaged into Mimikatz toolset making it very easy to execute for an attacker. Cyber security teams must therefore make sure to prevent, detect and mitigate any DCShadow attacks on their network.

What it a DCShadow attack?

Like it's elder "brother" DCSync, DCShadow is categorized as a a late-stage kill chain attack where the attacker must first have access to your network and already escalated enough privileges to acquire and compromise an enterprise or domain admin account. It thus means that the attacker already has a pretty strong foothold in your network and you should worry about fixing that too.

DCShadow was designed to "fix" the main shortcoming of the DCSync attack which can "only" sync with and copy info from existing DC but cannot inject new objects in the victim's domain. Instead DCShadow turns the table and outrights "creates" a new DC that can then start injecting its own malicious changes on the victim's domain.

This has multiple obvious advantages over DCSync. First, the attacker own DC is certainly not going to share its logs with the target organization SIEM. Second, As soon as the Shadow DC has injected its malicious changes to replicate a backdoor of malicious AD objects, Attacker can then unregister the rogue DC within seconds thus further complicating detection.

Why should I care about DCShadow attack?

Once an attacker successfully completed a DCShadow attack, they have injected and replicated onto the victim domain a backdoor or any malicious change they want on an account they control such as its group membership, account details, SIDHistory, Passwords, etc.

With such access they can then do whatever they want such as steal password data, access accounts such as the Kerberos KRBTGT that handles, encrypts and signs every single Kerberos ticket requests for your domain. The attacker now has the ability to leverage golden ticket attack. In other words, if he's not the captain yet, he's to about be.

Worse is that a lot of this is very hard to detect, because the rogue shadow DC that replicated these changes onto the whole domain did of that in mere seconds from a machine that obviously wont share its logs thus making the attack extra stealthy.

In summary, this late-stage kill chain attack requires a compromised admin account. However, once set it is extremely difficult to prevent as it leverages and abuses MS protocols that simply cannot be which cannot be turned off or disabled.

It is very difficult to detect and track as it originates from a system that is typically "hidden" from most monitoring mechanism and once it has done its bad deeds will simply unregister and vanish. Finally because it hits at the heart of AD Domain, it has the massive implication of enabling the attacker access to a golden ticket.

How does a DCShadow attack unfold?

It's important to repeat that for the DCShadow attack to occur, the attacker already entered your network, performed recon to understand its structure and has managed to elevate its privileges to a very high level (they have an account with domain replication rights) already either through account compromise or privilege escalation.

The attacker first takes control of a system, be it a computer or a server and runs commands to make 2 critical changes to the machine enabling it to foul genuine DCs into believing that their rogue machine is a DC. The reason lies in the [MS-ADTS]: Active Directory Technical Specification which specifies the core functionality of Active Directory.

DCShadow's cleverness is identifying how genuine DCs recognize and acknowledge one another by checking their class and location. To be a DC a server must register as nTDSDSA object located in the Configuration or Domain naming context (NC).

DCShadow first change is therefore to leverage the permissions granted to the compromised admin account to change the particular machines attributes of the attacking system and enable it to fulfil the bare minimum to "register" as a DC when probed by genuine DC.

DCShadow second change is to leverage the DRSAddEntry RPC function to modify 2 service principal names (SPN) used by Kerberos authentication to associate a service instance with a service logon account and authorize genuine DCs to initiate replication process between them:

• Global Catalog service class

• DRS service class (GUID E3514235–4B06–11D1-AB04–00C04FC2DCD2)

Once this is done, the attacker's machine is both recognized by other genuine DCs as one of their own and "shows" the attributes enabling it to launch a replication round on the domain with its own set of malicious changes, or just wait for next periodic replication round and then push them as part of the round.

From there the goal is to push a variety of attacks that enable the attacker to further their control on victim's domain which can take plenty of forms such as:

• Create new backdoor (ntpwdHistory, SIDHistory, account group membership, etc.)

• Erase the attacker traces (replication metadata, schema signature info. etc.)

With all that done, the attacker now has their own backdoor and they can unregister their rogue Shadow DC and remove any further trace that they were there in the first place. It is important to note that with Mimikatz automating much of the process, all of the above steps will happen within mere seconds of one another.

How do I prevent a DCShadow attack?

DCShadow is very challenging to prevent from as is based on the abuse of system features that are difficult to mitigate with preventive controls. The best prevention method that apply to DCShadow is to maintain discipline and proper control of your privileged accounts:

1. Follow least privilege access model and maintain an up-to-date list of all domain admin, enterprise admin accounts.

2. Set up rule to forbid the use of such accounts on any system unless it is absolutely necessary and monitor that IT staff follows it.

3. Use Privilege Account Solution (PAM) to track and monitor the use of any privileged account and implement controls for any usage of these account bypassing your PAM solution.

4. Ensure that all privileged account have complex, unique rotating passwords across all systems on the network (ideally managed within separate PAM solution safes).

5. Implement tiered administration model to separate accounts supporting administration of high-risk systems from other valuable assets like domain controllers.

How do I detect a DCShadow attack?

Pre-Requisite: Your Active Directory Team must establish and maintain a list of genuine and active known Domain Controllers that are authorized to operate on the domain and share it with Cyber Security/Blue Team.

Below steps explain the basic use case logic to detect DCShadow attack:

Step 1: Collect Windows Event logs from your organization's registered DC(s) related to Event ID(s) 4928: An Active Directory replica source naming context was established and 4929: An Active Directory replica source naming context was removed

Step 2: Create UC/Rule with below conditions:

Event ID: 4928 OR 4929

AND

SourceHostname and/or Source Object GUID is NOT a known Domain Controller

Below fields are required to be captured in the alert to identify and investigate DCShadow attack details:

• DestinationDRA

• SourceDRA

• DestinationAddress

• SourceAddress

• SourceHostname

If the SourceHostname is not itself captured, you can extract it by parsing it from below 2 fields:

• SourceDRA (from CName value)

• SourceAddress (using Object GUID and resolving it via ping command)

Sometimes, Source Object GUID is captured within the SourceAddress field and it can also be used to match with the organization's list of known genuine DC Object GUID(s).

Step 3: Exclude all of your organization's known DC hostname(s)/Object GUID(s) from SourceHostname field to avoid false positives and avoid capturing legitimate activity.

How do I respond to a DCShadow attack alert?

Once an alert triggers, your response team must first check if the source hostname is captured in the alert. If yes, it can be verified with your Active Directory Team if the unknown host is a legitimate new DC or a potentially rogue DC addition attempt.

In case, instead of the SourceHostname if ObjectGUID is captured in the logs, a manual action would be needed to resolve the hostname/IP address from the ObjectGUID using ping or past month's service replication logs in SIEM.

Finally, if the SourceHostname was obtained and identified as new/exiting DC, it can be added to the whitelist of known DC(s). If the hostname was still not resolved or found in past month's replication logs and your Active Directory Team is unaware of this host, it's most likely a DCShadow attack.

In case of true positive, proceed Containment/Neutralization steps and isolate the rogue host from the network. Urgently determine the last accounts that logged on the source rogue DC and lock out all of them. In addition, Work with AD Team to ensure reversal any changes initiated for replication by the rogue DC.

Related content:

• https://attack.mitre.org/techniques/T1207/

• https://stealthbits.com/blog/what-is-a-dcshadow-attack-and-how-to-defend-against-it/

• https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/t1207-creating-rogue-domain-controllers-with-dcshadow

• https://blog.alsid.eu/dcshadow-explained-4510f52fc19d

• https://www.lepide.com/blog/what-are-dcsync-and-dcshadow-active-directory-attacks/

• https://medium.com/@maarten.goet/dcshadow-detecting-a-rogue-domain-controller-replicating-malicious-changes-to-your-active-1e22440df9ad