The Microsoft Sentinel Data Connector that utilizes the modern agent (AMA) for collecting Windows Security Events is for a couple of months general available.

The Log Analytics/MMA agent will be retired in 2024, which seems like a long way off. Preparing to use the new Azure Monitor Agent (AMA) is an important step and will take some years including the adoption and configuration of Azure Arc for on-premises resources.

In this blog post, we will show the capabilities of the new Windows Security Events collecting via the Azure Monitoring Agent (AMA), comparison between the MMA and AMA agent, and connector / DCR configuration with the use of Microsoft Sentinel. Last part is some reporting with the use of workbooks.

Introduction AMA vs MMA

Let’s start with the main comparison between the previous legacy Microsoft Monitoring Agent (MMA) and the new Azure Monitoring Agent (AMA).

AMA is supported for multiple environments, Azure Arc is a requirement for environments outside Azure. On-premises resources requires onboarding with Azure Arc.

The biggest difference is based on the Data Collection Rules. The new AMA agent makes it possible to enable data collection based on DCR rules. The MMA agent was not flexible enough to choose what specific events to collect and was separated into 4 selections (All Events, Common, Minimal, none). Selective collection for specific events is only possible with the AMA agent.

FeatureAMA agentMMA/OMS agent
EnvironmentsAzure
Other cloud ( Azure Arc)
On-premises (Azure Arc)		Azure
Other cloud
On-premises
EPS per server on Windows5K1K
EventsAll security events
Common
Minimal
Custom		All security events
Common
Minimal
None
Support for file-based logsNoYes
Support for IIS, DNSS logsNoYes
Support for DCR
Data Collection Rules		YesNo
Supports scopingYesNo

Microsoft Monitoring Agent (MMA)

The Microsoft Monitoring Agent supports 4 options for specific data collections.

  • All events – All Windows security and AppLocker events.
  • Common – A standard set of events for auditing purposes. The Common event set may contain some types of events that aren’t so common. This is because the main point of the Common set is to reduce the volume of events to a more manageable level, while still maintaining full audit trail capability.
  • Minimal – A small set of events that might indicate potential threats. This set does not contain a full audit trail. It covers only events that might indicate a successful breach, and other important events that have very low rates of occurrence.
  • None – No security or AppLocker events. (This setting is used to disable the connector.)

According to Microsoft docs, these are the pre-defined security event 

Event setCollected event IDs
Minimal1102, 4624, 4625, 4657, 4663, 4688, 4700, 4702, 4719, 4720, 4722, 4723, 4724, 4727, 4728, 4732, 4735, 4737, 4739, 4740, 4754, 4755, 4756, 4767, 4799, 4825, 4946, 4948, 4956, 5024, 5033, 8001, 8002, 8003, 8004, 8005, 8006, 8007, 8222
Common1, 299, 300, 324, 340, 403, 404, 410, 411, 412, 413, 431, 500, 501, 1100, 1102, 1107, 1108, 4608, 4610, 4611, 4614, 4622, 4624, 4625, 4634, 4647, 4648, 4649, 4657, 4661, 4662, 4663, 4665, 4666, 4667, 4688, 4670, 4672, 4673, 4674, 4675, 4689, 4697, 4700, 4702, 4704, 4705, 4716, 4717, 4718, 4719, 4720, 4722, 4723, 4724, 4725, 4726, 4727, 4728, 4729, 4733, 4732, 4735, 4737, 4738, 4739, 4740, 4742, 4744, 4745, 4746, 4750, 4751, 4752, 4754, 4755, 4756, 4757, 4760, 4761, 4762, 4764, 4767, 4768, 4771, 4774, 4778, 4779, 4781, 4793, 4797, 4798, 4799, 4800, 4801, 4802, 4803, 4825, 4826, 4870, 4886, 4887, 4888, 4893, 4898, 4902, 4904, 4905, 4907, 4931, 4932, 4933, 4946, 4948, 4956, 4985, 5024, 5033, 5059, 5136, 5137, 5140, 5145, 5632, 6144, 6145, 6272, 6273, 6278, 6416, 6423, 6424, 8001, 8002, 8003, 8004, 8005, 8006, 8007, 8222, 26401, 30004

Azure Monitoring Agent (AMA)

The Azure Monitoring Agent (AMA) is re-written from the ground and the replacement for the Microsoft Monitoring Agent used by Log Analytics.

The Azure Monitor agent uses data collection rules (DCR) to configure data to collect from each agent. Data collection rules enable the manageability of collection settings at scale for different groups of environments or machines, which results in less cost and fewer events.

Have a single special Event Log on a specific server you want to collect? We can do that now without collecting it from any other servers.

The list of supported OS’s can be found here, basically, Windows Server 2008R2 SP1 and above are supported. Outside Windows, Linux is supported. You can of course use Azure Policy for the deployment.

Xpath?

Before explaining the usage, let’s start with explaining Xpath. XPath stands for XML (Extensible Markup Language) Path language and is used to explore specific XML details. XPath entries are written in the form LogName!XPathQuery

Below mapping based on Security EventID 4624 Security!*[System[(EventID=4624)]] 

The following blog post written by Roberto Rodriquez/Microsoft gives well-explained in-depth insights for Xpath/ DCR.  Later in this blog more examples during the DCR creation.

Micosoft Sentinel dataconnectors

Currently, there are many data connectors in Microsoft Sentinel. The following data connectors are mapped against the MMA or AMA agent. For using the new DCR collection use the Windows Security Events via AMA connector.

  • Security events via legacy agent: Legacy version based on the MMA agent / Log Analytics (1)
  • Windows Security via AMA: New version based on Azure Monitoring agent (2)

Enable the Microsoft Sentinel connector

Multiple options are available for installing the Azure Monitoring Agent, in this blog post the installation based on Microsoft Sentinel is explained. For more detailed standalone install instructions check the following source: Manage the Azure Monitor agent | Microsoft Docs

For Azure cloud machines no extra Azure Arc configuration is required. For enabling the new connector, take the following Microsoft Sentinel steps:

  1. Open Microsoft Sentinel
  2. In the menu select Data connectors (1)
  3. Select the Windows Security event via AMA connector (2) Tip: Search for Security events
  4. Open the connector page (3)

Now from the connector page configure the new data sources. Make sure you have read and write permissions. For collecting security events from Windows agents and installing the AMA agent. Start with creating a new data collection rule (DCR). For creating the new rule click the button Create data collection rule

The Data Collection Rule is the location where the data should be sent. In this blog we use the Microsoft Sentinel Log Analytics workspace.

Fill in the following values:

  • Rule name: Name for specific Data Collection Rule
  • Subscription: Select the subscription
  • Resource Group: Select resource group ( Data Collection rule is Azure Resource.

Now select the devices or Resource groups/ subscriptions and press Apply. After enabling the installation of the Azure Monitoring agent will be automatically installed on these machines. Selection for single virtual machines is possible or complete resource groups/ subscriptions:

Single machine: targeting one single machine

Resource group: targeted all selected subscriptions

Review the selected resources and go to the tab; collect.

For collecting events select one of the event groups:

  • All Security Events
  • Common
  • Minimal
  • Custom – defining custom queries using Xpath (explained later in blog)

After completing Azure Policy will force the Azure Monitoring extension installation directly to the selected resources. Name of the extension type: Microsoft.Azure.Monitor.AzureMonitorWindowsAgent.

Rule associations

Multiple rules can be associated based on multiple Data Collection Rules.

For example, consider an environment with a set of virtual machines running a line of business applications and others running SQL Server. You might have one default data collection rule that applies to all virtual machines and separate data collection rules that collect data specifically for the line of business application and for SQL Server. The associations for the virtual machines to the data collection rules would look similar to the following diagram.

Diagram shows virtual machines hosting line of business application and SQL Server associated with data collection rules named central-i t-default and lob-app for line of business application and central-i t-default and s q l for SQL Server.
Rule associations: Source: Microsoft.com

Enable the connector – Azure Arc

For Azure Arc machines the configuration is almost the same. For the on-premises resources make sure it is onboarded correctly with Azure Arc en visible in the infrastructure – server blade. 

The scope part of the Sentinel connector shows the Azure Arc devices.

After completing Azure Policy will force the Azure Monitoring extension installation directly to the selected resources. Name of the extension type: Microsoft.Azure.Monitor.AzureMonitorWindowsAgent.

Create Custom Collection

After finalizing the setup you can change the rule with more events of different types. The selection custom enables the custom event configuration.

Collect only event 4625 (failed sign-in)

Security!*[System[(EventID=4625)]] 

Collect event 4625( failed sign-in and 4624 (Successfully logged on)

Security!*[System[(EventID=4624) or (EventID=4625)]]

Collect event 1, 299, 4624, 2625, 4661, 4662, 4663, 4664, 4665

Security!*[System[(EventID=1) or (EventID=299) or (EventID=4624) or (EventID=4625) or (EventID=4661) or (EventID=4662) or (EventID=4663) or (EventID=4665)]]

Collect all critical, Error, Warning, and Information events from the system log except Event ID 6.

System!*[System[(Level=1 or Level=2 or Level=3) and (EventID != 6)]]

For validating rules before adding in Sentinel, PowerShell can be used for validating XPath queries. use the Get-WinEvent cmdlet to validate the XPath query.

$XPathQuery = "*[System[(EventID=4625)]]" 
Get-WinEvent -LogName Security -FilterXPath $XPathQuery

Result PowerShell:

However, there’s a shortcut for creating XPath queries using the Event Viewer. Open the Event Viewer and select the log file. Choose Filter Current log and enter the Event IDs you want to collect. Click on XML for opening the Xpath structure.

Events Microsoft Sentinel

After some time we should start seeing some events collected by the connector and DCR rules. Go to Logs and run the following KQL query for summarizing the EventID

SecurityEvent
| summarize count () by EventID

View the connector page for the data received view part of the Windows Security Events connector:

Monitoring workbook – AMA migration tracker workbook

Enable in Microsoft Sentinel the AMA migration tracker workbook for some extra visibility into migrations from MMA to the new AMA agent. The AMA migration tracker workbook gives visibility in the installed Azure and Azure Arc servers with the MMA or AMA agent and visibility in the attached Data Collection Rules for each associated VM, or DCR’s associated with DCR rules.

  1. Open Microsoft Sentinel
  2. In the menu select Workbooks
  3. Select the Templates tab and search for AMA migration tracker
  4. Save the AMA Migration tracker workbook

The following tabs are available:

Servers and extensions installed: Overview of current VM,s and which machines are connected with AMA, MMA, or installed with both agents. Useful for migrations and visibly during MMA migrations.

Data Collection Rules under Subscriptions: Shows all configured Data Collection Rules under the subscriptions. The view contains the OS, Streams, xPath, name, and connected resourceGroup. When selecting a specific DCR all associated VMs are visible in the view

VMs with AMA: Shows all servers with AMA installed. Select each server individually for viewing the connected Data Collection Rules which are associated with the machine.

Sources

W3schools.com: XPath Tutorial

Microsoft: Azure Monitor agent overview – Azure Monitor | Microsoft Docs 

Microsoft Tech Community: Testing the New Version of the Windows Security Events Connector