Using Active Directory Replication Metadata for hunting purposes


This blog post is meant for AD Admins and Security Professionals to look for suspicious activities in Active Directory by using it’s replication metadata.

What is Replication?
Replication is an important functionality in Active Directory, because it allows changes that happens on one Domain Controller to be transferred on other Domain Controllers in a forest.

Every Domain Controller holds at least three NC replica’s, which is another term for ”variable of objects”;

  • Domain Naming Context
  • Configuration Naming Context
  • Schema Naming Context

We are not going to discuss all of them in-depth, but explaining everything on a high-level is enough to get started.

A Domain Naming Context holds all the objects in Active Directory like users, computers, group policies, organizational units, and much more. It has something that’s called a writable ”replica”. This is a directory partition that contains all the attributes of objects. Meaning that every read/write operation can be made on every Domain Controller in a forest.

A Configuration Naming Context holds relevant information in Active Directory itself, which includes what Domain Controllers & subnets exists. This includes configuration information about services as well that are tightly integrated with Active Directory, like Microsoft Exchange for example.

A Schema Naming Context defines the types of objects and attributes that can be created in Active Directory. This includes what attributes are replicated between Domain Controllers.

What attributes are replicated?

We previously discussed that the Schema Naming Context contains information about which attributes are replicated between Domain Controllers.

There is a LDAP attribute named systemflags that exposes this information about which attributes are replicated or not. Good thing is that we can recognize the difference due to the ATTR_NOT_REPLICATED property that is set on certain attributes.

First, let’s get an overview on all the attributes that are replicated. In this example, we are going to use the repadmin utility to find it out.

repadmin /showattr * CN=schema,CN=configuration,dc=contoso,dc=com /subtree /filter:"(&(objectClass=attributeSchema)(!(systemFlags:1.2.840.113556.1.4.803:=1)))" /attrs:attributeSchem

Let’s now find all the attributes that are NOT replicated.

repadmin /showattr * CN=schema,CN=configuration,dc=contoso,dc=com /subtree /filter:"((&(objectClass=attributeSchema)(systemFlags:1.2.840.113556.1.4.803:=1)))" /attrs:attributeSchema

Hunting with Replication metadata

Replication metadata of Active Directory does not immediately helps you to find all the ”suspicious” activities in your environment. However, I do believe it can point you to a certain direction.

There are tons of Active Directory based attacks, so covering all of them is a bit unnecessary. We will discuss a few examples, such as DCShadow, Resource Based Constrained Delegation, Group Membership modification, Security Descriptor modification, and Kerberos Pre-Auth disabled

  • Group Membership Modification

We are going to take the Domain Admins group as an example. There are 4 security principals being a member of this group.

Now let’s look at the replication metadata of this specific object, which is in this case the Domain Admins group.

In order to do this, we can use the /showobjectmeta parameter in repadmin.

repadmin /showobjmeta * "CN=Domain Admins,CN=Users,DC=contoso,DC=com"

There are two interesting things that we should look at. One is the absent of a Domain Admin and the second thing is the nTSecurityDescriptor attribute. We will discuss the nTSecurityDescriptor later on.

Absent means that the user has been removed, but who has actually removed Masvidal from the Domain Admins group?

We can filter on event 4729, which indicates that a user has been removed from a security-enabled group. Since it is about the user Masvidal. I will include that in a parameter for a more accurate result.

Get-EventLog -ComputerName DC -LogName 'Security' -InstanceId 4729 -Message 'Masvidal' | Format-List *

Here we can see that the security principal ”Jones” has removed a user from the Domain Admins group.

A periodic reminder is that Windows event logs are only kept for 10/14 days on a machine, so if you don’t have proper logging. It can be very difficult to find out, who has modified an object from an hunting perspective.

  • Security Descriptor ModificationAdminSDHolder

We can see in the image that it shows a version 7 at the ntSecurityDescriptor attribute. Meaning that this attribute has probably been modified six times. It’s very rarely that someone is going to modify the DACL of the AdminSDHolder container, so let’s investigate further.

repadmin /showobjmeta * CN=AdminSDHolder,CN=System,DC=contoso,DC=com

If we use the /showattr parameter in repadmin, we can see the specific values behind those attributes. I’m interesting in the nTSecurityDescriptor and whenChanged attribute.

repadmin /showattr * CN=AdminSDHolder,CN=System,DC=contoso,DC=com /attrs:nTSecurityDescriptor,whenchanged

What I always like to do is, look at all the Security Identifiers (SID) and then exclude every SID that ends with 5. Because these are usually Built-in ACE’s. Like for example a SID that ends with 519 is Enterprise Admins, while a SID that ends with 561 is the Builtin\Terminal Server License Servers.

In this case, we can see a SID that ends with 1122. This looks interesting, so let’s translate the SID to a username.

  • DCShadow

DCShadow is a post-exploitation technique that an adversary could use to manipulate it’s Active Directory data by creating a ”rogue” Domain Controller in order to push changes via replication.

We have performed a DCShadow attack on a workstations that’s called Client.

When looking at the replication metadata of this machine account. There’s a LDAP attribute named servicePrincipalName that has been modified a couple of times.

repadmin /showobjmeta * "CN=Client, CN=computers,DC=contoso,DC=com"

Let’s now look at the value behind the servicePrincipalName attribute.

repadmin /showattr * "CN=Client, CN=computers,DC=contoso,DC=com" /atts:servicePrincipalName

Every time we execute a DCShadow attack. It will register a SPN to a non-DC machine account. The SPN prefix; E3514235-4B06-11D1-AB04-00C04FC2DCD2* will be added. This is the DRS RPC Interface GUID, and since DRS is a RPC protocol in AD that is responsible for replication. You would only find this SPN on machine accounts that are Domain Controllers.

Let’s proof that this is the case. We are going to use the /filter parameter to run a LDAP query that looks for machine accounts that contains this SPN.

repadmin /showattr * dc=contoso,dc=com /subtree /filter:"((&(servicePrincipalName=E3514235-4B06-11D1-AB04-00C04FC2DCD2*)(objectCategory=computer)(objectClass=computer)))" /attrs:servicePrincipalName,cn

What we notice here is that we can see two machine accounts that are Domain Controllers, while the Client machine is not a DC. That’s strange isn’t it?

Let’s dive in the logs to see which user was responsible for executing this attack. Since a new SPN has been added to a machine account. We have to filter on event 4742 (A computer account was changed). Besides of that, we are going to filter on the SPN prefix as well.

Get-EventLog -ComputerName DC -LogName 'Security' -Message "*E3514235-4B06-11D1-AB04-00C04FC2DCD2*" -InstanceId 4742 | Format-List *
  • Resource Based Constrained Delegation

Not going to explain the entire attack around this, since there’s tons of write-ups on how to execute it. To keep it short; if an ACE has write permissions on the msDs-AllowedToActOnBehalfOfOtherIdentity attribute of a machine account. It is possible to take-over that machine, because this attribute is an OBJECT_SECURITY_DESCRIPTOR, which means that it can be modified.

Here we are modifying these specific attribute on a machine account that is called Server$

The reason why this attack is so difficult to detect is, because it doesn’t show up in the logs that we changed this specific attribute. Yes, we will receive an event 4742 (An computer was changed), but with very limited information. Making it a good opportunity to hunt for this in our own environment.

Let’s look at the replication metadata of the Server$ machine account.

repadmin /showobjmeta * "CN=Server, CN=computers,DC=contoso,DC=com"

We can see that the msDS-AllowedToActOnBehalfOfOtherIdentity attribute has been modified

The only relevant information that might be useful is the date 2020-11-09. Since we modified an attribute on a machine account. It will receive event 4729, but our goal is to find out who did it.

$Begin = Get-Date -Date '9/11/2020'
$End = Get-Date -Date '9/11/2020'
Get-EventLog -ComputerName DC -LogName 'Security' -InstanceId 4742 -After $Begin -Before $End -Message "*Server$*" | Format-List *

It’s not the best way to find out who modified this object, but it can point towards a direction.

Let’s now run a LDAP query against all the Domain Controllers to see if we have other machine accounts that have a value behind the msDS-AllowedToActOnBehalfOfOtherIdentity attribute.

repadmin /showattr * DC=contoso,DC=com /subtree /filter:"((&(objectClass=computer)(msDS-AllowedToActOnBehalfOfOtherIdentity=*)))" /attrs:cn,msDs-AllowedToActOnBehalfOfOtherIdentit
  • Kerberos Pre-Authentication Disabled

This will be the last example, but here we will also explain how you should approach things, when you want to find ”suspicious” stuff in your environment.

We’ll start with finding users that don’t require Kerberos Pre-Authentication. In order to do this, we will use LDAP to query all the Domain Controllers. The first tip I can give is to define what you think is suspicious. (e.g. Domain Admins with SPN, Server configured for Unconstrained Delegation, Kerberos Pre-Authentication disabled on user, etc)

repadmin /showattr * dc=contoso,dc=com /subtree /filter:"((&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=4194304)))" /attrs:samAccountName,memberof,whenChanged,distinguishedName

There is one user that has been configured for not requiring Kerberos Pre-Authentication.

Since this is an insecure configuration and rarely used. We want to find out when this setting has been configured for the last time.

repadmin /showobjmeta * CN=Testing,CN=Users,DC=contoso,DC=com

When looking what kind of setting was applied on this user. We can run the following command:

repadmin /showattr * CN=Testing,CN=Users,DC=contoso,DC=com /attrs:samAccountName,useraccountcontrol

Ok, so we can see that ”Do not require Kerberos Pre-Authentication” was set and it was done on 2020-11-09. We can filter on all this information. FYI; 0x10010 is the UAC value for Kerberos Pre-Authentication disabled.

$Begin = Get-Date -Date '9/11/2020'
$End = Get-Date -Date '9/11/2020'
Get-EventLog -ComputerName DC -LogName 'Security' -InstanceId 4738 -After $Begin -Before $End -Message "*0x10010*" | Format-List *


Looking in Replication metadata can be very valuable, but IMO it’s more efficient when you also have proper logging of your Domain Controllers. This helps you to identify which user did what, that perhaps is defined as ”suspicious”.

Start with defining what you think is bad and use LDAP to query for it. From there, you should go further by looking at the replication metadata.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: