How do you investigate an Active Directory environment? are you also analyzing the metadata or just investigating an event log on each DC? If you investigate only the event logs, in some cases, it’s not good enough, and you should investigate Active Directory Metadata.

When it comes to Active Directory metadata, it always reminds me of the phrase “I know what you did last summer.” This is nailed into the fact that Active Directory metadata saves the information from his first days and as long the way while it’s live.

So, let’s assume that you’re investigating the Active Directory metadata. What about taking the relevant event logs from each DC? and then correlating each indicator from event logs with metadata. In an enterprise environment, it could take a lot of time too much time.

But wait, while you’re working on your Microsoft Sentinel, you can take the investigation to the next level! How do you achieve this goal? It’s simple than you think.

Metadata & things

A brief about Active Directory, Metadata, and others related to AD investigation.

Despite all the other systems and applications that have come out in recent years, Active Directory is a core and essential system more than the others by far! Active Directory is still one of the most critical systems in every environment and includes many sensitive resources. Once you’re connecting Active Directory to Microsoft Sentinel, you can monitor, detect and identify adversary movement.

Active Directory Domain Services

Active Directory Domain Services Overview is a directory with a hierarchical structure that stores information about objects on the network. A directory service, such as Active Directory Domain Services, provides the methods for storing directory data and making this data available to network users and administrators. For example, AD DS stores information about user accounts, such as names, passwords, phone numbers, etc. It enables other authorized users on the same network to access this information.

Active Directory is often the core of the IT infrastructure. It’s installed on Domain Controllers fulfilling the following roles:

• LDAP directory
• DNS service
• NTP service
• Authentification services (Kerberos and NTLM)
• Windows client configuration with GPOs
• And more

AD Metadata

Active Directory is a multi-master environment. You can modify an object on any domain controller. The changes will be propagated everywhere in the forest (of course, there are some exceptions, but in general, that’s the drift). What do we replicate? Objects and attributes.

The replication is attribute-based. So if you modify the password of a user on a domain controller in site b and at the same time some provisioning tool is changing the phone number of the same user on a domain controller in site b, both changes are effective, and there is no replication conflict.

Each attribute has a metadata set that helps domain controllers know the most recent difference to keep track of the changes. As long as an attribute needs to be replicated, Active Directory will need replication metadata.

The reason why I mentioned this is that some attributes are not being replicated. It is either irrelevant to replicate them or because replicating them will cause too much replication traffic on the network. For that reason, the good old attribute lastLogon is not replicated. What if an attribute changes every two minutes? The domain controllers will spend their lives replicating it and ensuring it is the correct value everywhere. So it better be for a good reason.

Metadata #0 – What is it, and why do we care? | Microsoft Docs

So how does the magic of Active Directory investigation come to Microsoft Sentinel? Let’s take a look at some scenarios.

AD Investigation

Many DCs in each domain replicate the various partitions of the NTDS database. Replication can be intradomain, intra forest, or via Global Catalog. A DC GUID and a USN identify a change in the Active Directory database.

AD replication metadata – msDS-ReplAttributeMetaData. A constructed attribute in XML format:

• It gives you the time when each attribute for a given object was last changed.
• It applies only to replicated attributes.

For each replicated attribute msDS-ReplAttributeMetaData contains: (some example)

• pszAttributeName : The attribute name.
• ftimeLastOriginatingChange : Time the attribute was last changed.
• usnOriginatingChange: USN on the originating server at which the last change to this attribute was made.
• pszLastOriginatingDsaDN : DC on which the last change was made to this attribute.
• usnLocalChange : USN on the destination server (the server your LDAP bind is made), at which the last change to this attribute was applied.

Replication metadata for linked attributes: Pairs of attributes in which the system calculates the values of one attribute (the backlink, e.g., MemberOf) based on the values set on the other attribute (the forward link, e.g., Member) throughout the forest.

I can run the following command to return the replication metadata for one or more objects.

Get-ADuser eadmin2 | Get-ADReplicationAttributeMetadata -Server DC1 | Out-GridView

Another example is to show a user’s group memberships and the dates they were added to those groups with the following command.

$username = “eadmin2”
$userobj = Get-ADUser $username

Get-ADUser $userobj.DistinguishedName -Properties memberOf |
Select-Object -ExpandProperty memberOf |
ForEach-Object {
Get-ADReplicationAttributeMetadata $_ -Server localhost -ShowAllLinkedValues |
Where-Object {$_.AttributeName -eq ‘member’ -and
$_.AttributeValue -eq $userobj.DistinguishedName} } | Out-GridView

The examples above are basic and simple examples for Active Directory investigation, and I can play with these command variations all day.

Ingesting MetaData to Microsoft Sentinel

The example below is a manual process but can be done automatically with Azure Logic App.

Now that we’ve seen a few commands, we can pull out any data that we want, and in this example, we’re taking the admin user and exporting all data to a CSV file with the following command:

Get-ADuser eadmin2 | Get-ADReplicationAttributeMetadata -Server localhost | export-csv C:\Temp\ad1.csv

Once that CSV is ready, we can ingest the data to Microsoft Sentinel with the following command.

Import-Csv .\ad.csv | Upload-AzMonitorLog.ps1 -WorkspaceId “Azure Log Analytics Workspace ID” -WorkspaceKey “Azure Log Analytics Workspace Key” -LogTypeName ADDS_Metadata -AddComputerName -AdditionalDataTaggingName “AD Forensics” -AdditionalDataTaggingValue “ADDS”

The script takes the following parameters:

• WorkspaceId – The Workspace ID of the workspace that would be used to store this data
• WorkspaceKey – The primary or secondary key of the workspace used to store this data. It can be obtained from the Windows Server tab in the workspace Advanced Settings.
• LogTypeName – The name of the custom log table that would store these logs. This name will be automatically concatenated with “_CL.”
• AddComputerName – If this switch is indicated, the script will add to every log record a field called Computer with the current computer name
• TaggedAzureResourceId – If it exists, the script will associate all uploaded log records with the specified Azure resource. This will enable these log records for resource-context queries and adhere to resource-centric role-based access control.
• AdditionalDataTaggingName – If it exists, the script will add to every log record an additional field with this name and the value that appears in AdditionalDataTaggingValue. This happens only if AdditionalDataTaggingValue is not empty.
• AdditionalDataTaggingValue – If it exists, the script will add field with this value to every log record. The field name would be as specified in AdditionalDataTaggingName. If AdditionalDataTaggingName is empty, the field name will be “DataTagging.”

More information for Upload-AzMonitorLog at Microsoft Sentinel: Creating Custom Connectors – Microsoft Tech Community

Note: This name will be automatically concatenated with “_CL. 👇

How to Investigate

Once we’ve got the tables and all Microsoft Sentinel data, we can search for the relevant data and investigate the Active Directory.

A simple query below can provide helpful information for nTSecurityDescriptor.

ADDS_Metadata_CL

| where AttributeName_s contains “nTSecurityDescriptor”

| project Object_s, Version_s

What is nTSecurityDescriptor, and why is it a significant value? When objects are added or removed from groups or ACL modifications within a timeframe. This table focuses on the Member and nTSecurityDescriptor attributes, which can help detect an elevation of privilege for a specific account or a backdoor set up by the attacker, the DistinguishedName value of the Member, and the time the Member was added or removed from the group is given in that table.

Another example can be the investigation DCShadow.  DCShadow is a post-exploitation technique that an adversary could use to manipulate its Active Directory data by creating a rogue Domain Controller to push changes via replication. The first query can be the following one.

// DCShadow Basic query

union *

| where AttributeName_s contains “ActonBehalf”

| where ServicePrincipalName contains “*” and EventID == “4729,4742”

| project Object_s, Version_s, Name