Using the Azure Sentinel Windows Security Events Connector for getting custom events
Microsoft announced on 14th June 2021 a new version of the Windows Security Events data connector. The new feature reached currently the public preview release. In comparison with the current public Security Events connector some new improvements are added for the new Security Events data connector.
One of the biggest improvements is the support for the Azure Monitoring Agent (AMA) and the Data Collection Rules (DCR).
In this blog the usage of the new connector and collecting custom events based on the events with Xpath.
Note: The Windows Security Events data connector based on the Azure Monitor Agent (AMA) is currently in PREVIEW.
Recommended read for more detailed information: Microsoft blog
Security events vs Windows Security events?
Two different names two different connectors. What is the difference?
- Security events: Get data insights based on the Log Analytics Agent
- Windows Security Events: based on the Azure Monitoring Agent
The security events connector uses 4 levels of event collection.
- All events
Minimal is still collecting a lot of events. For the minimal source the following events are collected:
1102, 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
Common is containing the following events:
1, 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
Based on the minimal set of logs, a lot of events are captured – and there is no way to include only specific events. With the new Windows Security Events collector this is possible. With the end result; reduce the cost for getting Security events into Azure Sentinel for further usage.
Enable the connector
The Windows Security Event connector uses the new Azure Monitor Agent (AMA). To collect security events from any system that is not an Azure virtual machine, the system must have Azure Arc installed and enabled. (blog about Azure Arc coming soon)
For enabling the new connector, take the following Azure Sentinel steps:
- Open Azure Sentinel
- In the menu select Data connectors
- Select the Security Events (Preview) connector and open the connector page Note: Select the preview connector
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. Start with creating a new data collection rule. For creating the new rule click the button Add data collection rule
The Data Collection Rule is the location where the data should be sent. In this blog we use the Azure 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 for sending the data
In the next screen; Resources it is required to configure the set of machines to collect data from. When selecting the Azure Monitoring Agent extension will be automatically installed on these machines. For installing the agent click on Add Resources
Note: This will also enable System Assigned Managed Identity on these machines, in addition to existing User Assigned Identities (if any).
Now selecting the devices and press Apply. After enabling the installation of the Azure Monitoring agent will be automatically installed on these machines.
Now the Azure Monitoring extension is installed on the machine. The extension type:
During the add resource setup, you have the option to select which events to stream. The followings option are available: All Events, Common, Minimal, custom. More about the custom part in the next section.
After some hours the first data is available from the new connector. For the verification track, the received data from the connector page or with the KQL events based on the SecurityEvent table.
Custom Detection is available for the new Security Events connector. The new connector allows custom input based on the XPath queries layout. For example:
Collecting only event 4625 ( failed sign-in
Collecting event 4625( failed sign-in and 4624 (Successfully logged on)
Security!*[System[(EventID=4624 or EventID=4625)]]
Note: Important following the Microsoft docs:
Make sure to query only Windows Security and AppLocker logs. Events from other Windows logs, or from security logs from other environments, may not adhere to the Windows Security Events schema and won’t be parsed properly, in which case they won’t be ingested into your workspace. Source
Testing with PowerShell
For testing the Xpath query. It is easy to test the output with PowerShell.
For the above examples run the following PowerShell command:
Get-WinEvent -LogName Security -FilterXPath ‘*[System[EventID=4624]]’
Add custom sources in Sentinel
From the Sentinel connector page. Open the current data collection rule configuration or add a new one for specifying the rules.
- Click edit or Add data collection rule
- Go to Collect and change the event streaming to Custom
- Now it’s time to filling in the Xpath event sources. Fill in the Xpath rule and press Add.
- Added logs are visible in the Event logs view:
With the above example, the Event connector is only streaming EventID=4624, 4625, and 4661. The biggest advantage no extra cost for unused events in the Minimal or Common data collection table.