What are the effective ways to identify an adversary in Active Directory infrastructure? There are many ways to identify Active Directory incidents, whether through Event IDs, network traffic, or other logs. The logs are often missing or don’t have accurate data to provide a full attack chain. My favorite way to identify Active Directory incidents is via the Microsoft Defender for Identity and required event IDs in some scenarios.

This post, Spotting the Adversary with Microsoft Defender for Identity, will take you from the classic mindset of collection and hunting event IDs to the Microsoft Defender for Identity and how to hunt the correct actions and show a specific way to look and hunt the required data.

There is a point in the journey of every security analyst who tells everyone with satisfaction and gazes proudly, “I’ve added all the data sources – we’re covered.” Then, the smile will falter as his cyber demons claw their way up to the surface. He’ll hear them shout out, But what am I supposed to search for? Ever since immemorial, I have heard, “What should I search for?”

The mindset of collecting all information from the Active Directory within all Domain Controllers won’t provide the result, and many times, we saw how specific logs were missing in each and every incident. The behavior of putting some agent on all Domain Controller servers, collecting data, and forwarding to SIEM can be good, but if you aren’t using it wisely to find baddies, it’s just expensive bits and bytes in the cloud SIEM.

With that in mind, I thought I would take a moment and possibly give out some “MDInspiration” I shared often with customers. This time, it’s from a logs perspective and how MDI can be helpful for threat-hunting, investigation, and other attack scenarios.

Event ID’s for All

While I searched for “Spotting the Adversary in Active Directory”, I found many articles and guides, but non of them was dedicated to Active Directory. The internet has many articles and ways to hunt or investigate via specific attack scenarios or specific event id’s. None comes as a condensed document, and the closest documentation for this is the Mindmap, etc.

Windows Events ID’s been here for a long time (three decades?). Searching for an Event ID or investigating a specific incident is not new at all, and when you’ve got massive data, it can take a while (even with a great PowerShell tool). You can find endless information when looking for Event IDs and code numbers on Google, ChatGPT, etc. What will be the best? Depends on your conditions.

I found a helpful article that can be good for endpoints and some scenarios for Active Directory. Several years ago, the NSA released a recently updated paper. This paper is called “Spotting the Adversary with Windows Event Log Monitoring.” The relevant information is in a section on page 14, where the NSA provides a table of all the exciting event codes for detecting baddies in your Windows network. A table like this one can be found in many places, but the rest of the paper provides the ways to handle this event id’s.

Below are the screenshots from page 14.

Note: if you search for event IDs and common hunting and attacks, you will probably find hundreds of dedicated papers.

Those event IDs are good, but there are more, and in recent years, we have seen more event IDs and sub-events while investigating incidents.

---

Classic Mindset

What should be good event id’s for Active Directory to collect? What could be the other event IDs? The following event IDs can be helpful in many security incidents. While the one in the upper table is good in some scenarios, the following event IDs can be much better while hunting and investigating.

TIP: When investigating a security incident, you can find more events and sub-events that belong to that incident.

Let’s Collect 4624…

What is the best way to detect password spray or brute force? Event ID’s 4624 and 4625 are good enough? Do we need other Event ID’s? Is a detection rule that detects many failed logins and successful login will do the work? Let’s take a quick look at this kind of scenario.

You often commonly see event IDs 4624 and 4634, successful logon, and logoff. These events have a field called logon ID. You can determine the session length if a logon and logoff event have the same logon ID. When looking at 4624 events, you must whitelist built-in executables like Desktop Windows Manager & Usermode Font Driver logons – this will considerably decrease the noise.

Many failed logons, which is 4625, can show for a potential attack or brute force activity. A large number of successful logons can indicate lateral movement activity.

When other credentials are used for tasks like process creation, network share, RDP, etc., A new event is raised, such as 4648; furthermore, be aware that this event can also generate false positives that must be whitelisted.

Additionally, Event ID 4672 can be part of a potential attack, and together with Event ID 4624, you can detect user logons with admin-level privileges. When monitoring these events, you should whitelist built-in Windows accounts like SYSTEM. If adversaries create new accounts, event 4720 will detect this.

The logon event has a field called logon type, which indicates how the logon occurred.

A potential flow

• 4624: Logon
• 4625: Failed Logon
• 4634,4647: Successful Logoff
• 4672: Account logon with special logon
• 4720: An account was created
• 4726: An account was deleted
• 4648: Logon using explicit credentials

Based on this scenario, investigating brute force and other actions, such as the initial attack, will be a big challenge.

Enumeration

Every attack starts with some enumeration. Tools like PowerView and Bloodhound are tools adversaries use to enumerate privileged users and groups. To enumerate your privileged users and groups, you can use these events to detect who is running what process.

Sometimes, adversaries don’t need external tools to enumerate the Active Directory and use built-in executable tools such as PowerShell, CMD, and others.

A potential flow

• Event ID 4798: A user’s local group membership was enumerated.
• Event ID 4799: A security-enabled local group membership was enumerated.

TIP: These events were added with Windows 10 and later. They allow you to detect reconnaissance activity in the network. You will need to whitelist MMC, services, tasklist, and explorer.

Group Membership

What about group membership changes? Looking at the logs from Domain Controllers, you will need many event IDs.

Active Directory tracks these differently depending on the type of group. Event ID 4728 is when a user is added to a security-enabled global group. Then, you will have a different Event ID for a security-enabled local group. The same goes for group removals and so on.

A potential flow

Event ID 4728 – A member was added to a security-enabled global group
Event ID 4732 – A member was added to a security-enabled local group
Event ID 4756 – A member was added to a security-enabled universal group

More logs to Collect…

Do you need more logs? No problem. You’ve got plenty of logs for Active Directory. Below are additional of them.

Authentication

• Event ID 4776 is generated when the domain controller attempts to validate the credentials for an account.
• Event ID 4771 is generated when an event is logged on domain controllers only, and only failure instances of this event are logged (Kerberos pre-authentication failed).
• Event ID 4768 is generated on domain controllers only – success and failure instances are logged (A Kerberos authentication ticket TGT) was requested.
• Event ID 4769 is generated when Windows uses this event ID for successful and failed service ticket requests (A Kerberos service ticket was requested).

Sessions

• Event ID 4624 is generated when an account is successfully logged on.
• Event ID 4625 is generated when an account fails to log on.
• Event ID 4634 + 4647 is generated when the user initiates logoff an account.
• Event ID 4648 is generated when A logon is attempted using explicit credentials.
• Event ID 4672 is generated when Special privileges are assigned to a new logon.

Account Management

• Event ID 4720 is generated when a user account is created.
• Event ID 4722 is generated when a user account is enabled.
• Event ID 4724 is generated when an attempt is made to reset an account password.
• Event ID 4728/4732/4756 is generated when group membership changes.

Network Shares

• Event ID 5140 is generated when a network share object is accessed.
• Event ID 5145 is generated when the Network share object is checked to see whether a client can be granted desired access.
• Event ID 4769 – Search for attacks from user accounts used as service accounts (search for service accounts with a login on a client system and IP address).
• Event ID 4624 – Successful logins (search for users/service accounts that have logged in to systems that are TrustedforDelegation). Type 3 – Network Logon (searching for logons from remote systems)
• Event ID 4611 (often generated by mimikatz) A trusted logon process has been registered with the local System authority.
• Event ID 4673 (often generated by mimikatz) When the tool tries to assign itself missing permissions.
• Event ID 4675 – SIDs were filtered
• Event ID 5136 – A directory service object was modified
• Event ID 4662 An operation was performed on an object.

You probably forwarding those event IDs or part of them to your SIEM, or you are using dedicated PowerShell commands to collect those Event id’s. Suppose you are still forwarding those Event ID’s to your SIEM and using the classic way to spot an adversary. Can you ensure that SIEM isn’t missing some Event ID’s?

There are more specific events to collect, which is the main problem and not a challenge!. You cannot collect each and every log and forward it to the SIEM platform. Instead, map the Active Directory Attacks and use behavior that isn’t based on event id’s.

OK. We got the point, and there are multiple scenarios in Windows Event ID’s. The questions are: do you have the time, effort, and resources to develop detection rules for scenarios that are based on Windows Event ID’s? even if we take the top 25 attack scenarios. Probably not!

Those questions take us to the Event ID’s Map. The MDI vs AD Event IDs are the way to know precisely which Event IDs are needed and which are covered by the Microsoft Defender for Identity (MDI). The goal here is to map every scenario and lower the needs with Event ID’s. Most of the scenarios are covered by the Microsoft Defender for Identity (MDI) monitored activities.

Below is a specific scenario from a very long map that takes all required Event ID’s for Active Directory and how to utilize them with Microsoft Defender for Identity (MDI).

---

Spotting the Adversary

There are many ways to collect, create a mindmap, or map the relevant Event ID’s for the Active Directory. The different mindset will be to take the Active Directory attacks and use them for each scenario. Microsoft Defender for Identity (MDI) does it for many attack scenarios.

Besides that, the Microsoft Defender for Identity (MDI) provides built-in attack scenarios, so we need to add more scenarios. Those scenarios can be based on Advanced Hunting Query (AHQ) and the part that Microsoft Defender for Identity (MDI) needs to cover. Below are some ways to take Microsoft Defender for Identity (MDI)  to the next level.

Note: As mentioned, many attack scenarios are covered by Microsoft Defender for Identity (MDI).  

DCShadow

A Domain Controller Shadow (DCShadow) attack is designed to change directory objects using malicious replication. This attack can be performed from any machine by creating a rogue domain controller using a replication process.

DCShadow is a late-stage kill chain attack that allows an adversary with compromised privileged credentials to register a rogue Active Directory Domain Controller and replicate malicious changes, such as modifications that help them establish persistence.

Active Directory replication synchronizes changes on one domain controller with other domain controllers. Given necessary permissions, attackers can grant rights to their machine account, allowing them to impersonate a domain controller. Attackers strive to initiate a malicious replication request, allowing them to change Active Directory objects on a genuine domain controller, which can give the attackers persistence in the domain. In this detection, an alert is triggered when a suspicious replication request is generated against a genuine domain controller protected by Defender for Identity. The behavior is indicative of techniques used in domain controller shadow attacks.

What does DCShadow look like? Here is a quick overview of the steps in a DCShadow attack:

1. An attacker obtains Domain Admin, Enterprise Admin permissions, or other privilege permissions.
2. The attacker uses DCShadow to register a computer object as a domain controller by changing the AD configuration schema and the workstation’s SPN. Active Directory thinks the workstation is a Domain Controller, so it’s trusted to replicate changes.
3. The attacker submits replication changes, such as password data, account details, or security group membership. Once replication is triggered, changes are published and committed by the other DCs.
4. To cover their activity, the attacker uses DCShadow to remove the rogue domain controller from the AD database.

To detect a DCShadow attack, you must closely monitor specific Event IDs.

• The Event IDs 4928 and 4929 pinpoint changes in Active Directory replica source naming contexts.
• Event ID 5136 reveals allowed connections by the Windows Filtering Platform.
• Event ID 5141 signals the deletion of a directory service object.

The Event IDs provide the following actions.

• Event ID 4928 – An Active Directory replica source naming context was established. Key Description Fields: Destination DRA, Source DRA, Source Address, Naming Context
• Event ID 4929 – An Active Directory replica source naming context was removed. Key Description Fields: Destination DRA, Source DRA, Source Address, Naming Context
• Event ID 5136 – The Windows Filtering Platform has allowed a connection. Key Description Fields: Security ID, Account Name, Account Domain, Logon ID 
• Event ID 5141 – A directory service object was deleted. Key Description Fields: Security ID, Account Name, Account Domain, Logon ID 

Microsoft Defender for Identity (MDI) covers two types of DCShadow:

• Suspected DCShadow attack (domain controller promotion)
• Suspected DCShadow attack (domain controller replication request)

While Microsoft Defender for Identity (MDI) is not taking all scenarios and not taking the potential, we need to cover those scenarios. Those attack scenarios and the potential can be developed from the Advanced Hunting Query and the custom action we can add.

While Microsoft Defender for Identity (MDI)  provides two types of detection, we need to add a potential and other types. How can it be from Advanced HUnting Query or Microsoft Sentinel?

DCShadow with AHQ

What must we know when detecting additional actions in a DCShadow attack? There are additional ways to improve the detection in Microsoft Defender for Identity. Below is a great way to add MDI queries and create detection rules.

Identify Unusual Replication Activity: DCShadow attacks involve replication from a domain controller that is often not a typical replication source. You can write a query to identify replication activities from unusual sources or at unusual times.

Note: Don’t use union in your detection rules. It is good only for testing purposes and to get the first details. 

Recon query

Monitor Schema Changes: DCShadow may involve changes to the Active Directory schema. Monitoring for unexpected schema changes can be a sign of such an attack.

Track Changes in Permissions or Group Memberships: Look for sudden changes in permissions or group memberships, especially elevation of privileges or additions to sensitive groups like Domain Admins.

Look for Signs of a Rogue DC: This includes monitoring for new domain controller registrations and deregistrations, which might occur quickly.

IdentityDirectoryEvents
| where Timestamp > ago(3h)
| where ActionType in (“Account Supported Encryption Types changed”,”Device Account Created”)
| join kind=inner (
IdentityQueryEvents
| where Timestamp >= ago(1d) | order by Timestamp
| where ActionType in (“SAMR query”,”SamrQuerySuccess”)
) on AccountDisplayName

union IdentityDirectoryEvents
| where Timestamp >= ago(1h) | order by Timestamp
| where Application != @”Microsoft 365″
| where ActionType in (“Account Delegation changed”, “Account Path changed”, “Credentials validation”)
//| extend TOAccountPath=parse_json(AdditionalFields)
//| where TOAccountPath contains “OU=Domain Controllers”

All hunting queries in this post available here PotentialShadow.kusto

In conclusion

Monitoring security event logs in Active Directory is good, but we need to change the mindset and monitor activities by the behavior and actions and not static Event ID’s that can be missing. The little sample below is one of many scenarios that can replace the Event IDs easily with MDI.

References

Microsoft Defender for Identity monitored activities

Most Common Windows Event IDs to Hunt – Mind Map – Security Investigation (socinvestigation.com)

Monitoring Active Directory for Signs of Compromise | Microsoft Learn

CYBERDOM – Just another day of DFIR & Threat Hunting

Advanced threat hunting within Active Directory Domain Services – Knowledge is power! – Microsoft Community Hub

DCShadow Attacks on Active Directory – QOMPLX

Other security alerts – Microsoft Defender for Identity | Microsoft Learn