Update 19/02/2018 : Add a reference to Uncover-DCShadow, a proof of concept helping Blue teams to detect DCShadow attack.

On January 24th 2018, Benjamin Delpy and Vincent Le Toux, two security researchers, have released during the “BlueHat IL” security conference a new attack technique against Active Directory infrastructure. Named “DCShadow”, this attack allows an attacker having the appropriate rights to create a rogue domain controller able to replicate malicious objects into a running Active Directory infrastructure.

In this article, we will explain the technical foundations the attack relies on and discuss the consequences for the security of a running Active Directory infrastructure. Finally, we will shed a light on how blue teams could detect this kind of attack.

What is the DCShadow attack and why is it new?

The holy grail for red teamers or attackers willing to compromise an Active Directory infrastructure is to be able to obtain users and computers credentials without being noticed by detection countermeasures.

For this purpose, several attack techniques have been developed through time: LSASS injection, abusing Shadow Copy, NTFS volume parsing, ESE NT operations, sensitive attribute manipulation, etc. More details are available on the impressive synthesis from ADSecurity.org.

Among all these noisy attacks, one of them is connected to the “DCShadow” attack. Introduced in 2015, the “DCSync” attack relies on the ability for the members of the Domain Admins or Domain Controllers groups to ask a domain controller (DC) for data replication (to achieve this task, the GetChangesAll right, granted by default to administrative accounts and DCs, was necessary). In fact, as described in the MS-DRSR specification for domain controller replication, these groups can request the Domain Controller to replicate AD objects (including user credentials) through the GetNCChanges RPC. More technical details on the attacks are available on the ADSecurity.org blogpost.

DCSync attack with mimikatz tool

One of the main limitation of the “DCSync” attack is the impossibility for an attacker to inject new objects in the targeted AD domain. Of course, this attacker could take ownership of an administrative account using the good old Pass-The-Hash technique and inject objects afterwards, but it requires more efforts, more steps, meaning a greater probability of being busted by blue teams. The “DCShadow” attack removes this limitation by reversing the “DCSync” attack paradigm.

With “DCShadow”, attackers no longer try to replicate data but will register new domain controllers in the targeted infrastructure to inject Active Directory objects or alter existing ones (by replacing the attributes’ content). The idea of a rogue domain controller is not new and has been mentioned multiple times in previous security publications but required invasive techniques (like installing a virtual machine with Windows Server) and to log on a regular domain controller to promote the VM into a DC for the targeted domain. Not very discrete.

Eventlog generated during a regular DC promotion

In order to understand the genius ideas behind “DCShadow”, it is important to clearly grasp what a domain controller is and how it is registered in the Active Directory infrastructure.

Understanding what a domain controller is

As described in MS-ADTS (Active Directory Technical Specification), Active Directory is a multi-master architecture relying on dedicated services. The DC is the service (or the server hosting this service depending on your point of view) which hosts the data store for AD objects and interoperates with other DCs to ensure that a local change to an object replicates correctly across all DCs.

When a DC is operating as RW DC, the DC contains full naming context (NC) replicas of the configuration, the schema, and one of the domain naming context of its forest. In this way, every RW DC holds all objects of a domain, including credentials and any kind of secrets (like private or session keys). As such, there is no need to remind that DCs are the one and only elements blue teams should be focused on protecting (Administrative accounts or permissions are just two of the many ways to access a DC).

Services provided by a domain controller

Describing in detail the technical ways and means of a DC could be complex and will not help to understand the purpose of the “DCShadow” attack. To be concise, a server can be called a domain controller if it offers the following 4 key components:

a database engine able to replicate its information (meaning it must be accessible through LDAP protocols and implement several RPCs to follow MS-DRSR and MS-ADTS specifications)

an authentication provider accessible through Kerberos, NTLM, Netlogon or WDigest protocols

a configuration management system called GPO, relying on SMB and LDAP protocols

an (optional) DNS provider used by clients to locate resources and support authentication

Synthesize of services provided by a DC

Focus on Active Directory replication

In addition to hosting these services, a domain controller in the making should be registered in the directory infrastructure to be accepted by another DC as a replication source provider. The data replication is orchestrated by a built-in process (running on the NTDS service) called the Knowledge Consistency Checker (KCC).

The major function of the KCC is to generate and maintain the replication topology for replication within and between sites. In other words, the KCC process elects which DC will communicate to which other to create an efficient replication process. Within a site, each KCC generates its own connections. For replication between sites, a single KCC per site generates all connections. The following schema illustrates the two kinds of replication.

The two kinds of replication process

By default, the KCC initiates AD replication topology every 15 minutes to ensure consistent and regular propagation. Using the USN associated to every AD object, the KCC recognizes changes that occur in the environment and ensures that domain controllers are not orphaned in the replication topology. Fun fact, historically Active Directory replication process could have been made through RPC (like DrsAddEntry) but also through SMTP (for the Schema and Configuration partition only)!

Registry key defining the replication time period

One part of the great job made by the researchers behind “DCShadow” was to identify the minimal set of changes required to inject a new server in the replication topology and therefore inject malicious information abusing this process while remaining stealthy.

How DCShadow actually works

As explained in the following section of this article, the “DCShadow” attack aims to register new domain controllers to inject malicious AD objects and so create backdoors or any kind of illegitimate access or right. To reach this goal, “DCShadow” attack must modify the targeted AD infrastructure database to authorize the rogue server to be part of the replication process.

Register a new domain controller

As mentioned in the MS-ADTS specification, a domain controller is represented in the AD database by an object of class nTDSDSA that is always located in the configuration naming context of a domain. More precisely, each DC is stored in the sites container (object class sitesContainer), as a child item of a server object.

In blue, the containers storing the NTDS-DSA object. In red, the object itself.

A quick look at the schema shows that NTDS-DSA objects can only be created as children of server objects, which in turn can only be part of organization or server objects:

the server objects can only be stored in serversContainer objects which are only found in the Configuration NC.

the organization objects can only be stored in locality, country or domainDNS objects which can be found in the domain NC

The schema indicates where ntds-dsa objects can be created

In this way, domain controllers (nTDSDSA objects) can only be created in the Configuration or Domain NC. In practice, it seems only the nTDSDSA objects stored in the site container (sitesContainer object) are taken into consideration. As the KCC relies on the site information to compute its replication topology, it seems logical that only these objects are used. Note that creating an nTDSDSA object is not possible using the LDAP protocol.

You would have understood it, the main action made by the “DCShadow” attack is to create a new server and nTDSDSA objects in the Configuration partition of the schema. Doing so provides the ability to generate malicious replication data and inject them to other domain controllers.

Now that we understand what the “DCShadow” attack do, we need to understand what kind of privileges are required to create nTDSDSA objects in the Configuration partition. A quick look in the permissions show that only BUILTIN\Administrators, DOMAIN\Domain Admins, DOMAIN\Enterprise Admins and NT AUTHORITY\SYSTEM have control rights on the targeted containers.

The default access rights on the Server object.

This quick analysis allows us to conclude that the “DCShadow” attack is not a privileges escalation vulnerability, but a misappropriation of Active Directory mechanism. It doesn’t allow red teamers to gain privileges but give them another solution to become persistent or to make illegitimate actions in a directory infrastructure. It should thus be added in the category of another sneaky AD persistence trick and not as a vulnerability to fix.

Trust the new domain controller

As described in the previous paragraph, the “DCShadow” attack relies on the addition of a new nTDSDSA object in the Configuration partition to register itself as a new member of the replication process. However, adding this sole object is not enough to allow our rogue server to initiate replication. In fact, to be part of the replication process we need to take care of two requirements:

be trusted by other servers, meaning that we need to have valid authentication credential.

provide authentication support to let other DCs to connect to our rogue server when we need to replicate data.

By using a valid computer account, a rogue server can be treated as a trustworthy AD server. The Kerberos SPN attributes will provide authentication support for other DCs. Therefore, every nTDSDSA object is linked to the computer object through the serverReference attribute.

The serverReference attribute acts as the link between a nTDSDSA object and its related computer object

Despite the theoretical possibility to achieve this with a user account, it seems much easier and stealthy to use a computer account. In fact, it will be automatically registered in the DNS infrastructure (which will allow other DCs to locate our resource), will natively have the required attributes set and will have its authentication secret automatically managed.

In this way, the “DCShadow” attack will use a legitimate computer account to be able to authenticate to other DCs. Although the computer object and the nTDSDSA object will bring the ability to authenticate to other DCs, the “DCShadow” attack still needs to let other DCs to connect to the rogue server to replicate illegitimate information from it.

This last requirement is fulfilled using the Kerberos Service Principal Name (SPN). As extensively explained in several publications, SPNs are used by Kerberos service (KDC) to encrypt the Kerberos ticket with the account associated with the SPN. In our case, the “DCShadow” attack will add SPNs on the regular computer object used to authenticate.

One of the key findings of Benjamin Delpy and Vincent Le Toux was to isolate the minimum set of SPNs required for the replication process to go through. The results of their studies show that two SPNs are required to let another DC to connect to the rogue server:

the DRS service class (which has the well-known GUID E3514235–4B06–11D1-AB04–00C04FC2DCD2)

the Global Catalog service class (which has the string “GC”)

For example, the two SPNs required by our rogue server (named “roguedc” with the DSA GUID 8515DDE8–1CE8–44E5–9C34–8A187C454208 in the alsid.corp domain) are as follows:

E3514235–4B06–11D1-AB04–00C04FC2DCD2/8515DDE8–1CE8–44E5–9C34–8A187C454208/alsid.corp

GC/roguedc.alsid.corp/alsid.corp

A rogue computer account having the SPN of a DC

When triggering its attack, “DCShadow” will set those two SPNs to its targeted computer account. More precisely, the SPNs will be set using the DRSAddEntry RPC function as described in the CreateNtdsDsa function documentation (more details about MS-DRSR RPC are provided in the next section).

For now, we can register our rogue domain controller into the replication process and be authenticated by another DC. The remaining step is now to force the DC to initiate the replication process with our malicious data.

Injecting illegitimate objects

In the previous parts, we gathered all the requirements to register in the replication process, in this final chapter we will study how the “DCShadow” attack injects its illegitimate information into the DNS infrastructure.

To serve illegitimate data, the rogue domain controller will have to implement the minimal set of RPC functions required by the MS-DRSR specifications: IDL_DRSBind, IDL_DRSUnbind, IDL_DRSGetNCChanges, IDL_DRSUpdateRefs. The IDL of this function are provided by Microsoft in its open specifications and are now implemented into Benjamin Delpy’s Mimikatz tool.

The final step of the “DCShadow” attack is to trigger the replication process. To do so, two strategies can be conducted:

Wait for the KCC process of another DC to initiate the replication process (requires 15 minutes delay)

Force the replication by invoking the DRSReplicaAdd RPC function. It will change the content of the repsTo attribute which will start an immediate data replication.

Extract of the MS-DRSR specification describing the DRSReplicaAdd IDL

Forcing the replication with the IDL_DRSReplicaAdd RPC is the last step taken during a “DCShadow” attack. It allows to inject arbitrary data into a targeted AD infrastructure. Doing so, it becomes trivial to add any backdoor in the domain (by adding new member on an administrative group, or by setting SID history on a controlled user account for example).

Process summary

The following chart summarizes the different operations achieved during a “DCShadow” attack.