Getting Inside the Mind of an Attacker: After the Breach - Achieving Persistence with Domain Replication Abuse

In part one of this series, we discussed how attackers may attempt to gain persistence in Active Directory by forging Kerberos tickets, as well as ways to detect these efforts. In this part, we’ll discuss another method attackers may use: domain replication abuse.

The DCSync Attack

Domain replication, or DCSync, is a feature that was first intended to be used by Domain Controllers. Requesting a Get-NCChanges RPC operation to another Domain Controller initiates a data transfer operation through SMB, including the entirety or parts of the domain database with the NTLM password hashes of the Domain Accounts. This is then applied to its own data table with the goal of keeping the data consistent across all the computers in the domain. The DCSync operation enables Domain Controllers to keep their databases up-to-date.

However, this operation is not exclusive to Domain Controllers. By design, other domain administrator accounts also typically have the permission to request this operation. This is why the first step attackers usually take after gaining domain admin privileges is requesting a replication operation to dump the entire password hash table in the domain. On the other hand, more skilled attackers may avoid generating this huge network traffic and choose the stealthier option of only requesting KRBTGT's hash, or even the hash for the particular service owner that they are targeting, which can be later used to sign forged Kerberos tickets.

The DCSync attack is a great improvement in terms of avoiding easy detection, as it is less noisy than other techniques, such as abusing the Volume Shadow Copy Service. This is because it doesn't require effective system compromise. In this case, this means an attacker doesn’t need to touch either the disk or memory.

Detecting DCSync Attacks

Though there are differences in the size of the traffic generated by less skilled and more skilled attackers, all these bad actors do have the audit event generated in common. A Domain Account different from a Domain Controller machine account requesting a domain replication operation could be considered suspicious, and this operation should be fully examined. Event 4662 may provide some assistance in detecting these attacks. However, note that it is not logged by default because of the high volume of events that it could generate.

Image

We can check all the events with the property field containing this very notorious set of values, shown in the above image in the Properties field, which could be translated to DS-Replication-Get-Changes or DS-Replication-Get-Changes-All. From there, we can check the SubjectUserName field to verify if a Domain Controller account has made the request. If the requester was not a Domain Controller account, we may be in the presence of an attacker premiering their newly gained Domain Admin privileges.

Since this is typically the next step immediately after exploitation, it might not be too late to kick out the malicious actor and avoid major consequences.

Shadow Administrators

Examining Event 4662 may also provide insights on whether other virtual Domain Administrators exist in the Active Directory. Look for accounts that are not part of the Domain Admin groups, but also have replication privileges in the organization, as they can retrieve NTLM hashes for any account in the domain, including KRBTGT and other Domain Admins. For example, on-prem exchange servers accounts are usually granted replication privileges. One of these machine accounts, once compromised, may serve as Domain Admin for an attacker. Further, DS-Replication-Get-Changes and DS-Replication-Get-Changes-All privileges can be granted in the domain access control list by an end user with adequate privileges (for example, a Domain Admin), effectively converting them into virtual Domain Admins until this privilege is revoked.

Detecting Shadow Administrators

Luckily, we can detect random accounts being granted these privileges. While it’s possible to spot this by passively watching and examining events, programmatically querying the domain access control list is a more effective way to detect virtual admins in your schema.

Image

The above image shows an example of a regular Domain Account, which is the only member of the generic accounting group, which cannot perform an administrative operation, such as reading the privileged C$ share in a Domain Controller seen above. However, for some reason, this account could request a DCSync operation.

Image

In this second image, we can see that the attacker could use Mimikatz to leverage the account’s replication privilege.

DCShadow Attack

Attackers looking to take one step further from just replicating DCSync may utilize the DCShadow attack. The preferred tool for executing such an attack is Mimikatz. In a DCShadow attack, the attacker will not only look to replicate information from the schema, but to also propagate changes to it through replication. For this, the attacker will need to register either their own device or a compromised machine account in the domain as a rogue Domain Controller. Once Domain Controller status is gained, the attacker can attempt to trigger or wait for a domain replication operation to introduce whatever changes to the domain they want. For example, they may want to elevate the privileges of a regular account.

Detecting DCShadow Attacks

Changes introduced by DCShadow cannot be monitored, as they are generated in the attacker's machine, which won't send any events to your SIEM. However, it is still possible to actually detect a domain machine self-registering as a rogue Domain Controller.

First, the attacker's machine would need to register itself as an entry in the domain's configuration namespace. Once the desired changes are propagated to the domain, it is standard practice to erase this entry. In fact, this is the default behavior of Mimikatz. This will trigger a sequence of audit events, first the event 5137 for creation and then event 5141 for deletion. Both of these events include the name of the offending machine in the object field.

Second, the attacker will attempt to register the service principal names for the Global Catalog (GC) and Directory Replication Services (DRS). This will trigger event 4742, which signifies that a computer account was changed. This includes the services within the change attributes field.

Lastly, it is even possible to monitor the offending replication by looking at the source address field of event 4929 (which indicates that a replica source has been removed) once the rogue Domain Controller is removed after the attack.

Image

The screenshots above are an example of a sequence of registration and deletion of the GC service principal name for a regular machine, which can be used to detect the use of DCShadow.

Image

The image above is from the point of view of an attacker and shows how Mimikatz is used to execute this attack. First, the changes are prepared in a template. In this case, the attacker wants to modify the description attribute of a regular account to include an arbitrary value. And then such changes are pushed to the real Domain Controller using the same tool.

Image

Finally, this last image shows that the operation was successful, as the description of the affected account now roots the value pushed by the attacker.

Now that we understand how persistence is gained through domain replication abuse, we can move on to a few other techniques that attackers may use. In the next part of the series, we’ll cover AdminSDHolder and SDProp attacks, SID History attacks, and skeleton key attacks, as well as strategies for detecting these strategies before it’s too late.