The power of Data Collection Rules: Collecting events for advanced use cases in Microsoft USOP

Monitoring Windows security events is important for the security of any organization. Security events can reveal a lot of information that can lead to the discovery of attacks, persistent attempts to access an organization’s network, and many other threats that are detrimental to the organization.

Using Microsoft Sentinel to collect Windows events via Azure Monitor Agent (AMA), you can easily configure and filter the events of interest. In this blog post, we will discuss some attacks and how to find them using KQL queries for analysis, custom detection, hunting queries, etc.

Setting up data collection rules to detect account searches

Microsoft Sentinel lets you collect event IDs and use built-in analytics rules (detections) and hunting queries to detect threats in your environment. Now, you can not only filter on the exact event IDs you want to collect from your Windows computers, but also define different sets of events for different servers thanks to the Azure Monitor Agent and Data Collection Rules (DCR). For more information, see: Collect and transform custom data in Microsoft Sentinel | Microsoft Learn.

On top of that, we now have the MITRE ATT&CK dashboard feature, so you can see how our analytics and hunting rules help with different tactics and techniques (see). View your organization’s MITRE coverage in Microsoft Sentinel | Microsoft Docs).

The goal of this series is to showcase different types of attacks and the events they generate, and provide the artifacts needed to handle these scenarios in Microsoft Sentinel.

In our article, you will find the relevant xPath queries to collect the required event IDs and the scheduled analysis rules or hunting queries for detection. See: Filtering events using xPath queries For more details.

Setting up security events using AMA

First, let’s take a look at the steps you need to take to properly configure your environment. You may also want to refer to: Finding Connectors – Windows Security Events via AMA (Documentation).

1. In the Unified SOC Operations portal, USOP, select Microsoft Sentinel, then select Content hub under Content Management. Locate Windows Security Events and install the solution.

2. Once the installation is complete, select Configure, Data Connectors, locate Windows Security Events via AMA, and then click Open Connector Page.

3. + Select Create Data Collection Rule, give it a name, and then select the resource from which you want to collect events (for non-Azure computers). Onboard me to Azure Arc. First) Select Custom in Collection. You need to enter an xPath query to represent the events you want to collect.

This example uses the following xPath query:

Security!*[System[(EventID=4798) or (EventId=4799)]]

This xPath query can be used to collect event IDs 4798 and 4799 from the security event log.

Finally, click Create. This will create a DCR, associate it with the selected machines, and install the AMA extension on any machines that don’t already have it installed.

memo: If you create another DCR on the same machine that collects the same event ID, or if you include the same event multiple times in one DCR, the events will be duplicated. Event ID 4799 is already part of the minimal event ID selection, while 4798 is part of the generic event. If you are already collecting minimal events, you only need to add event 4798. We recommend that you use only one DCR per workspace, or carefully monitor what you are collecting. See: Best practices for creating and managing data collection rules in Azure Monitor – Azure Monitor | M….

To learn more about the Azure Monitor Agent (AMA), see:

Detecting potential Discovery attacks

This article explores potential find In particular, attacks against two specific MITRE ATT&CK techniques: T1087 account found and T1069 Permission Group Found. Both fall into the enumeration category, and can be used by adversaries to gain additional information about potential victims and accounts, which can then be leveraged for lateral movement access and escalation..

This series of blog articles focuses on detecting suspicious behavior using only event IDs.

Microsoft Defender for Endpoint (MDE) can detect a variety of detection methods, but does not raise alerts for script execution, as discussed in this article. This is because querying generic accounts and groups generates the same events. Alerting on every access to many account or group properties can generate a lot of informational alerts.

Therefore, the detections described in this document are not 100% perfect and should be adjusted to fit your environment. Every environment is different and users behave differently depending on their roles. However, defining baselines and detections is a good starting point to better protect your infrastructure.

When an attacker gains access to a corporate device (e.g., through a phishing attack), the goal is often to compromise other accounts and move laterally to gain control of the entire environment. Therefore, the logical first step is discovery: finding out what accounts and groups are present in order to plan the next phase of the attack.

We can detect Account Found (T1087) By evaluating Event ID 4798 (“The user’s local group memberships are listed.”). Search for permission groups (T1069) can be analyzed using Event ID 4799 (“Enumerates local group memberships that have security enabled.”). Both event IDs can be found in . Windows Security Event Log.

There are many ways to view accounts and groups in your environment, and enumerating accounts is not necessarily malicious. Below you will find a script that enumerates Active Directory groups and their memberships using: Ad Finder:

This script first enumerates the active group memberships and adds all enumerated user accounts and their group memberships to a PSCustomObject that the script returns.

This script is part of the book “PowerShell Automation and Scripting for Cybersecurity: Hacking and defense for red and blue teamers” by Miriam C. Wiesner and can also be found here. https://raw.githubusercontent.com/PacktPublishing/PowerShell-Automation-and-Scripting-for-Cybersecur…

If you want to learn more about PowerShell in a security context, you can purchase the book here. https://aka.ms/mw-book

The following list of users is returned:

When you use the Microsoft Management Console (MMC) console to view accounts and group memberships, event IDs 4798 and 4799 may also be generated. When an adversary enumerates accounts and groups, multiple accounts are typically enumerated simultaneously.

So we added a threshold to the query. If there are more than 5 events that represent enumerations during the same time frame, we will get a result. When copying and reusing this query, adjust the threshold to suit your environment to get useful results. While we have suggested a static value as an example threshold, it is important to recognize that for enterprises or large organizations, you will need to calculate a historical baseline. This baseline can often be a fairly large number, reflecting the scale and complexity of your environment.

let enumeration_threshold = 5;
SecurityEvent
| where EventID == "4798" or EventID == "4799"
| summarize make_set(TargetAccount) by bin(TimeGenerated, 1h),EventID,SubjectAccount,SubjectUserSid,CallerProcessName
| extend Count = array_length(set_TargetAccount),EventID,SubjectAccount,SubjectUserSid,set_TargetAccount,CallerProcessName
| where Count > enumeration_threshold;

This concludes Part 1 of our blog series on how to collect events using DCR for advanced use cases. Join us for Part 2 of our three-part blog series where we will learn how to detect possible execution policy bypasses. We welcome your feedback and questions about this or any other part of this blog article series, and look forward to hearing from you.

Miriam Wiesner (@miriamxyra) – Senior Security Research PM, Microsoft Defender XDR Incidents | Maria de Sousa-Valadas Castaño – Senior Product Manager, USOP | Shirley Kochavi – Senior Product Manager, USOP