How do you investigate an Active Directory environment? are you also examining metadata or investigate an event log on each DC? If you investigate just event logs, it’s not enough, and you should and even must also investigate Active Directory metadata.
So, let’s assume that you’re investigating the Active Directory metadata. What about taking the relevant event logs from each DC? and then correlate 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 Azure Sentinel, you can shorten the investigation time in half at least! How do you achieve this goal? It’s simple than you think.
The post Active Directory Forensics with Azure Sentinel is part of Azure Sentinel investigation and forensics for Microsoft 365, Azure, on-prem environment, and third-party products.

Active Directory, Metadata, Forensics, and things

A brief about Active Directory, Metadata, and other things related to AD forensics.
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 Azure Sentinel, you can monitor, detect and identify adversary movement.
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 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

Active Directory Metadata

Active Directory is a multi-master environment. You can basically 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 actually 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 because 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. It is actually for that reason that the good old attribute lastLogon is not replicated. What if an attribute changes every two minutes? The domain controllers will spend their life replicating it and making sure it is the correct value everywhere. So it better be for a good reason.
Metadata #0 – Metadata, what is it, and why do we care? | Microsoft Docs
So how the magic of Active Directory forensics come to Azure Sentinel? Let take a look at some scenarios.

Active Directory Forensics

Many DCs in each domain replicating the various partitions of the NTDS database. Replication can be intra domain, 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 at which 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 returns the replication metadata for one or more objects.

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

Another example, to shows 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 forensics, and I can play with these command variations all day.

Ingesting MetaData to Azure 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 admin user and export all data to 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 Azure 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 that would be 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 as well as 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 to every log record an additional field with this value. 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 Azure Sentinel: Creating Custom Connectors – Microsoft Tech Community
Note: This name will be automatically concatenated with “_CL. 👇

Azure Sentinel Investigation

Once we’ve got the tables and all Azure Sentinel data, we can search for the relevant data and investigate the Active Directory.
A simple query below can provide useful information for nTSecurityDescriptor.

What is nTSecurityDescriptor, and why is it an important 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 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

TIPS

• You can correlate the Active Directory metadata information with the SecurityEvent table (or any other tables) and know if you’ve got someone in your Active Directory environment.
• It will be better if you will have got an Azure Sentinel agent on each DC.
• You can create an Analytics rule to alert and create an incident.
• The process can be done automatically with PowerShell export and PowerShell upload via schedule task or via Azure Logic App that uploads the CSV.
• You can create a workbook based on this data to know who changes objects and to track for any unusual metadata changes.

For more Azure Sentinel KQL and AD PowerShell stuff, visit my GitHub profile.
More Azure Sentinel guides 👉 Azure Sentinel Archives – Elli Shlomo (eshlomo.us)