Domain server

Rogue Domain Controller Detection – DCShadow Attack

In our previous blog post on protecting against Active Directory DCSync attacks, we saw how attackers can replicate permissions and completely control the Active Directory (AD) infrastructure using DCSync attacks. Another devastating technique attackers are exploring against AD is the DCShadow attack. It is a method of manipulating AD data, including objects and schemas, by registering itself (or reusing an inactive registration) and simulating the behavior of a legitimate domain controller (DC).

A DCShadow attack allows an attacker with domain or enterprise administrator privileges to create a rogue DC in networks. Once registered, an unauthorized DC is used to inject domain objects (such as accounts, ACLs, schemas, credentials, or access keys) and replicate changes to AD infrastructure.

How does a DCShadow attack work?

The DCShadow attack shares similarities with the DCSync attack, which is already present in the lsadump module of an open source tool Mimikatz. A post-exploit attack requires Domain Administrator or Enterprise Administrator privileges on an endpoint. The following attack flow was demonstrated with detailed steps at the Bluehat IL 2018 conference by Vincent LE TOUX and Benjamin Depy.

  1. Registering the DC by creating two objects in the CN=Configuration partition and modifying the SPN of the computer used.
  2. Push data, triggered using DrsReplicaAddKerberos Credentials Collector (KCC) or other internal AD events.
  3. Removed the previously created item to downgrade the DC.

Attackers can perform a DCShadow attack by installing Mimikatz on a compromised Windows endpoint and starting the mimidrv service. To act as a fake domain controller, an attacker can run the following commands to register and start a service with the appropriate privileges.

!+
!processtoken
token::whoami

Let’s take a scenario and see how an attacker attempts a persistent attack by modifying the Primary Group ID attribute. An attacker can run the lsadump::dcshadow command to change the value of Primary Group ID at 512.

The following command can cause standard domain users to be members of the domain administrators group.

lsadump::dcshadow /object:POC User5 /attribute:primaryGroupID /value:512

First, let’s check the Primary Group ID value before passing the AD data. As shown in the image below, we can use the net group command to verify and confirm that the user POC User5 is not part of the Admin group.

We will replicate changes from the rogue domain controller to the legitimate controller by running the following command.

lsadump::dcshadow /push

Let’s check again net group command output. As you can see, the same user POC User5 will be part of the Domain Administrator group.

net group "Domain Admins" /domain

It’s as simple as shown above. Once an endpoint is a member of a domain administrator or privileged group, it gains higher privileges in the domain and can compromise the entire domain.

TrickBot is an example of modular malware that used Mimikatz’s lsadump module to collect valuable information and carry out attacks, such as DCSync, DCShadow, and the Kerberos Golden Ticket compromise.

Detection of a DCShadow attack

The DCShadow technique can avoid detections and bypass SIEM logging mechanisms since changes from an unauthorized domain controller are not captured. The technique alters or removes replication and other associated metadata to hinder forensic analysis. SentinelOne Singularity™ Identity detects DCShadow attacks targeting AD and identifies suspicious user behavior. The solution also triggers high-fidelity alerts and reports on rogue domain controllers that may pose a serious risk to the organization’s domain information.

Mitigation strategies

Security administrators can consider what is a real or rogue DC as a mitigation strategy. Delete the computer object that is not a real domain controller. It is also important to check for computer objects in the domain controller OU and nTDSDSA objects in the AD configuration partition.

The following investigative steps can also help security administrators mitigate DCShadow attacks.

  • Capture network traffic and analyze packets associated with data replication (such as calls to DrsAddEntry, DrsReplicaAddand particularly GetNCChanges) between domain controllers as well as to/from non-DC hosts.
  • Examine Directory Service (DRS) Replication events 4928 and 4929 using Event Viewer on the domain controller. Observe the distinguished name (DN) of the destination DRA and the source DRA and validate the legitimate DN from Active Directory Users and Computers. Discover any unauthorized DRA replication between domain controllers.
  • Monitor the use of the Mimikatz command, for example, lsadump::dcshadow.
  • Monitor the use of SPN analysis tools. For example, the simple command setspn -Q HTTP/* allows an attacker to find HTTP SPNs.
  • Investigate the use of Kerberos Service Principal Names (SPNs). Two types of SPNs can clearly indicate a DCShadow attack. An SPN beginning with “GC/” is associated with services by computers not present in the DC organizational unit (OU) and an SPN associated with the Directory Replication Service (DRS) remote protocol interface (GUID E3514235–4B06–11D1-AB04–00C04FC2DCD2).

Conclusion

Attackers can use the DCShadow technique and perform more advanced attacks to establish backdoors for persistence. The organization should implement continuous monitoring solutions, regularly review system activities such as monitoring AD object creation/replication, and alert the security team to take necessary mitigating actions .

For more information, visit Singularity™ Identity.

Get a Demo of SentinelOne’s Identity Suite

Bring Identity to XDR. Ready to experience the market-leading identity security suite?