M
miriamwiesner
Monitoring Windows Security events is important to every organization's security. Security events can reveal a lot of information that might lead to the discovery of an attack, a sustained effort to access the organization's network and many other threats detrimental to the organization.
Using Microsoft Sentinel to collect Windows events via Azure Monitor agent (AMA) provides you with an easy way to configure and filter events of interest. In this blog post we will discuss some attacks and how to discover them using KQL queries for analytics, custom detections, hunting queries, etc.
Microsoft Sentinel allows you to collect event IDs and use out-of-the-box analytics rules (detections) and hunting queries to detect threats in your environment. Now, you can not only filter the exact event IDs that you want to collect from your Windows machines; you can also define different sets of events for different servers thanks to the Azure Monitor Agent and the Data Collection Rules (DCR).To see more on this, check Custom data ingestion and transformation in Microsoft Sentinel | Microsoft Learn.
On top of that, we now have the MITRE ATT&CK dashboard feature where you can view how your analytics and hunting rules are helping you with the different tactics and techniques (see View MITRE coverage for your organization from Microsoft Sentinel | Microsoft Docs).
The goal of this series is to show you different types of attacks and the events they generate, and we will provide you with the artifacts you need to cover these scenarios on Microsoft Sentinel.
In our articles, you will find the relevant xPath queries to collect the required event IDs and the scheduled analytic rules or hunting queries to make the detections. Please refer to Filter events using xPath queries for further information.
First let’s have a look at the steps that you need to take to configure your environment accordingly, you can also refer to Find your Connector - Windows Security Events via AMA (docs).
In this example - we use the following xPath query:
Using this xPath query you will be able to collect the event IDs 4798 and 4799 from the Security event log.
Finally, click on Create. This will create the DCR, it will associate it with the selected machines and it will trigger the installation of the AMA extension to those machines that still don’t have it installed yet.
NOTE: If you create different DCRs that collect the same event IDs from the same machines, or if you include the same events multiple times in one DCR, events will be duplicated. Event ID 4799 is already part of the Minimal Event IDs selection, whereas 4798 is part of Common events. If you are already collecting Minimal events, you only need to add event 4798. We advise you to either use only one DCR per workspace, or to supervise carefully what you are collecting. Please refer to Best practices for data collection rule creation and management in Azure Monitor - Azure Monitor | Microsoft Learn.
To learn more about the Azure Monitor Agent (AMA), please have a look at:
In this article, we will show a potential Discovery attack, particularly on two specific MITRE ATT&CK techniques: T1087 Account Discovery and T1069 Permission Groups Discovery. Both belong to the enumeration category, which adversaries use to get more information on potential victims and accounts to later take advantage for lateral movement access as well as escalation.
In this blog article series, we focus on detecting suspicious behaviors, using event ids only.
Although Microsoft Defender for Endpoint (MDE) can detect various discovery methods, it does not throw an alert for the execution of the script that we will discuss in this article. The reason is that by querying regular accounts and groups the same events are generated. Alerting whenever many account or group properties are accessed could generate many informational alerts.
Therefore, the detection we describe in this article is not 100% complete and needs to be adjusted for your environment – every environment is different, and users behave differently in their roles. However, it is a good starting point to define baselines and detections for you to better protect your infrastructure.
Once an attacker managed to get access to a corporate device – e.g., through a phishing attack – often the goal is to compromise other accounts and move laterally until they have control over the entire environment. Therefore, the logical first step is discovery: finding out which accounts and groups exist to plan the next steps of the attack.
We can detect account discovery (T1087) by evaluating event id 4798 (“A user's local group membership was enumerated”). Permission Group discovery (T1069) can be analyzed using event id 4799 (“A security-enabled local group membership was enumerated”). Both event ids can be found in the Windows Security event log.
There are different ways to view accounts and groups in an environment, and enumerating accounts is not necessarily malicious. Below you can find a script that enumerates Active Directory groups and their memberships using adsisearcher:
This script first enumerates Active group memberships and adds all enumerated user accounts and their group memberships into a PSCustomObject that is returned by the script.
This script is part of the book “PowerShell Automation and Scripting for Cybersecurity: Hacking and defense for red and blue teamers” written by Miriam C. Wiesner and can also be found here: https://raw.githubusercontent.com/P...ster/Chapter06/Get-UsersAndGroupsWithAdsi.ps1
If you are interested in learning more about PowerShell in a security context, you can get the book here: Amazon.com
This will return a list of users such as:
If accounts and group memberships are viewed using the Microsoft Management Console (MMC) console, event id 4798 and 4799 could be generated as well. When adversaries are enumerating accounts and groups, usually there are multiple accounts enumerated at the same time.
Therefore, we added a threshold for our query: if there are more than 5 events indicating enumeration during the same time frame you will get a result. When copying and reusing this query, please adjust the threshold to your environment to get useful results: while we suggested an example static value as a threshold, it is important to recognize that for enterprise or large organizations, a historical baseline needs to be calculated. This baseline can often represent a significantly larger number, reflecting the scale and complexity of such environments.
This concludes Part 1 of our blog series on how to collect events using DCRs for advanced use cases. Please join us for Part 2 of our 3 part blog series in which we discover ways on how to detect possible Execution Policy bypasses. We welcome your feedback and questions on this or any of the other parts of this blog article series and look forward to hearing from you.
Miriam Wiesner (@miriamxyra) – Senior Security Research PM for Microsoft Defender XDR Incidents | Maria de Sousa-Valadas Castaño – Senior Product Manager USOP | Shirley Kochavi – Senior Product Manager USOP
Continue reading...
Using Microsoft Sentinel to collect Windows events via Azure Monitor agent (AMA) provides you with an easy way to configure and filter events of interest. In this blog post we will discuss some attacks and how to discover them using KQL queries for analytics, custom detections, hunting queries, etc.
Setting up Data Collection rules to detect Account Discovery
Microsoft Sentinel allows you to collect event IDs and use out-of-the-box analytics rules (detections) and hunting queries to detect threats in your environment. Now, you can not only filter the exact event IDs that you want to collect from your Windows machines; you can also define different sets of events for different servers thanks to the Azure Monitor Agent and the Data Collection Rules (DCR).To see more on this, check Custom data ingestion and transformation in Microsoft Sentinel | Microsoft Learn.
On top of that, we now have the MITRE ATT&CK dashboard feature where you can view how your analytics and hunting rules are helping you with the different tactics and techniques (see View MITRE coverage for your organization from Microsoft Sentinel | Microsoft Docs).
The goal of this series is to show you different types of attacks and the events they generate, and we will provide you with the artifacts you need to cover these scenarios on Microsoft Sentinel.
In our articles, you will find the relevant xPath queries to collect the required event IDs and the scheduled analytic rules or hunting queries to make the detections. Please refer to Filter events using xPath queries for further information.
Setting up Security Events with AMA
First let’s have a look at the steps that you need to take to configure your environment accordingly, you can also refer to Find your Connector - Windows Security Events via AMA (docs).
- On the Unified SOC Operations portal, USOP, select Microsoft Sentinel and then select Content hub under Content Management. Look for Windows Security Events and install the solution:
- Once it is installed, select Configuration, Data Connectors and look for Windows Security Events via AMA, and click on Open connector page:
- Select + Create data collection rule, and give it a name, select the resources from where you want to collect the events (for non-Azure machines, please onboard them to Azure Arc first) and select Custom under Collect. You will need to enter an xPath query to indicate the events that you want to collect:
In this example - we use the following xPath query:
Security!*[System[(EventID=4798) or (EventId=4799)]]Using this xPath query you will be able to collect the event IDs 4798 and 4799 from the Security event log.
Finally, click on Create. This will create the DCR, it will associate it with the selected machines and it will trigger the installation of the AMA extension to those machines that still don’t have it installed yet.
NOTE: If you create different DCRs that collect the same event IDs from the same machines, or if you include the same events multiple times in one DCR, events will be duplicated. Event ID 4799 is already part of the Minimal Event IDs selection, whereas 4798 is part of Common events. If you are already collecting Minimal events, you only need to add event 4798. We advise you to either use only one DCR per workspace, or to supervise carefully what you are collecting. Please refer to Best practices for data collection rule creation and management in Azure Monitor - Azure Monitor | Microsoft Learn.
To learn more about the Azure Monitor Agent (AMA), please have a look at:
- Overview of the Azure monitoring agents - Azure Monitor | Microsoft Docs
- Data Collection Rules in Azure Monitor - Azure Monitor | Microsoft Docs
- Migrate to the Azure Monitor agent (AMA) from the Log Analytics agent (MMA/OMS) for Microsoft Sentinel | Microsoft Docs
Detecting potential Discovery Attacks
In this article, we will show a potential Discovery attack, particularly on two specific MITRE ATT&CK techniques: T1087 Account Discovery and T1069 Permission Groups Discovery. Both belong to the enumeration category, which adversaries use to get more information on potential victims and accounts to later take advantage for lateral movement access as well as escalation.
In this blog article series, we focus on detecting suspicious behaviors, using event ids only.
Although Microsoft Defender for Endpoint (MDE) can detect various discovery methods, it does not throw an alert for the execution of the script that we will discuss in this article. The reason is that by querying regular accounts and groups the same events are generated. Alerting whenever many account or group properties are accessed could generate many informational alerts.
Therefore, the detection we describe in this article is not 100% complete and needs to be adjusted for your environment – every environment is different, and users behave differently in their roles. However, it is a good starting point to define baselines and detections for you to better protect your infrastructure.
Once an attacker managed to get access to a corporate device – e.g., through a phishing attack – often the goal is to compromise other accounts and move laterally until they have control over the entire environment. Therefore, the logical first step is discovery: finding out which accounts and groups exist to plan the next steps of the attack.
We can detect account discovery (T1087) by evaluating event id 4798 (“A user's local group membership was enumerated”). Permission Group discovery (T1069) can be analyzed using event id 4799 (“A security-enabled local group membership was enumerated”). Both event ids can be found in the Windows Security event log.
There are different ways to view accounts and groups in an environment, and enumerating accounts is not necessarily malicious. Below you can find a script that enumerates Active Directory groups and their memberships using adsisearcher:
This script first enumerates Active group memberships and adds all enumerated user accounts and their group memberships into a PSCustomObject that is returned by the script.
This script is part of the book “PowerShell Automation and Scripting for Cybersecurity: Hacking and defense for red and blue teamers” written by Miriam C. Wiesner and can also be found here: https://raw.githubusercontent.com/P...ster/Chapter06/Get-UsersAndGroupsWithAdsi.ps1
If you are interested in learning more about PowerShell in a security context, you can get the book here: Amazon.com
This will return a list of users such as:
If accounts and group memberships are viewed using the Microsoft Management Console (MMC) console, event id 4798 and 4799 could be generated as well. When adversaries are enumerating accounts and groups, usually there are multiple accounts enumerated at the same time.
Therefore, we added a threshold for our query: if there are more than 5 events indicating enumeration during the same time frame you will get a result. When copying and reusing this query, please adjust the threshold to your environment to get useful results: while we suggested an example static value as a threshold, it is important to recognize that for enterprise or large organizations, a historical baseline needs to be calculated. This baseline can often represent a significantly larger number, reflecting the scale and complexity of such environments.
Code:
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 DCRs for advanced use cases. Please join us for Part 2 of our 3 part blog series in which we discover ways on how to detect possible Execution Policy bypasses. We welcome your feedback and questions on this or any of the other parts of this blog article series and look forward to hearing from you.
Miriam Wiesner (@miriamxyra) – Senior Security Research PM for Microsoft Defender XDR Incidents | Maria de Sousa-Valadas Castaño – Senior Product Manager USOP | Shirley Kochavi – Senior Product Manager USOP
Continue reading...