I’ve recently been asked about why Log Analytics was not able to capture Security logs from a Windows server as it is not an option under the Log name list:
The short answer is because this is not a feature included natively within a Log Analytics Workspace as described in the following Microsoft documentation:
Configuring Windows Event logs
https://docs.microsoft.com/en-us/azure/azure-monitor/agents/data-sources-windows-events#configuring-windows-event-logs
You can't configure collection of security events from the workspace. You must use Microsoft Defender for Cloud or Microsoft Sentinel to collect security events.
In this post, I will demonstrate how to set up Azure Sentinel to capture a Windows Active Directory Domain Controller event logs and query them.
I will also write a separate post to demonstrate how to use Microsoft Defender for Cloud in the future.
Create Log Analytics Workspace
Begin by creating a Log Analytics Workspace that will store the Azure Sentinel streamed Active Directory Domain Controller logs:
Enable monitoring for Active Directory Domain Controller and attached it to the Log Analytics Workspace
Navigate to Azure Monitor > Virtual Machines > Not monitored and enable the domain controllers:
Enable Insights and select the Log Analytics Workspace that was created earlier to capture the logs when the following window is displayed:
The following agents will be installed:
Repeat the process for any additional domain controllers.
Add Microsoft Sentinel to the new Log Analytics Workspace
With the Domain Controllers added to the Log Analytics Workspace, proceed to create and add a new Microsoft Sentinel with the Log Analytics Workspace:
Configure Azure Sentinel Data Connector to collect Windows Security events
Navigate to Data Connectors, type in Security Events in the filter text field, select Windows Security Events via AMA then click on Open connector page:
In the opened connector page, navigate to the Configuration section and click on the button Create data collection rule button:
Fill in the field for the rule name, subscription and the resource group for the data collection rule:
Click on the +Add resource(s) button and note that This will also enable System Assigned Managed Identity on these machines, in addition to existing User Assigned Identities (if any).
Select the domain controller(s) to that this data collection rule will apply to then click Apply button:
The selected list of VMs will be listed as resources. Proceed to click on the Collect tab:
The following options are presented:
- All Security Events
- Common
- Minimum
- Custom
Hovering over the information button displays the following:
- All events - All Windows Security and App Locker events.
- Common - A standard set of events for auditing purposes.
- Minimal - A small set of events that might indicate potential threats. By enabling this option, you won't be able to have a full audit trail.
- Custom - Allows you to filter and select the security events to stream by using Xpath queries.
A more detailed breakdown of what is included in Common and Minimal can be found here:
https://docs.microsoft.com/en-us/azure/sentinel/windows-security-event-id-reference?WT.mc_id=AZ-MVP-5003408
- All events - All Windows security and AppLocker events.
- Common - A standard set of events for auditing purposes. A full user audit trail is included in this set. For example, it contains both user sign-in and user sign-out events (event IDs 4624, 4634). There are also auditing actions such as security group changes, key domain controller Kerberos operations, and other types of events in line with accepted best practices.
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. For example, it contains successful and failed user logons (event IDs 4624, 4625), but it doesn't contain sign-out information (4634) which, while important for auditing, is not meaningful for breach detection and has relatively high volume. Most of the data volume of this set is comprised of sign-in events and process creation events (event ID 4688).
- Custom - A set of events determined by you, the user, and defined in a data collection rule using XPath queries. Learn more about data collection rules.
Minimal
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
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
If the Custom option is desired, use the following documentation to fine tune the events collected:
Limit data collection with custom XPath queries
https://docs.microsoft.com/en-us/azure/azure-monitor/agents/data-collection-rule-azure-monitor-agent#limit-data-collection-with-custom-xpath-queries
An example of only collecting event ID 4625, which is an event logged for failed attempts is to use:
Security!*[System[(EventID=4625)]]
You can also configure to only capture successful login Event ID
Security!*[System[(EventID=4624)]]
Or perhaps both:
Security!*[System[(EventID=4624 or EventID=4625)]]
For the purpose of this demonstration, we’ll select Common and then create the rule:
The ingestion and availability of the data should be present within minutes.
To query for security events, navigate to the Logs blade:
We can start with a query as simple as the following, which would retrieve all events with the user name tluk:
SecurityEvent
| where TargetUserName == 'tluk'
Another more in depth query can be to use Event ID 4625, which is an event that is logged for any logon failure. With this in mind, we can reference the following Microsoft documentation:
https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4625
… to create the following query which will query for event ID 4625, then map the SubStatus code with the reason so it is displayed in the results. Note that kusto queries are case sensitive and the hexadecimal code is in all lower case:
SecurityEvent
| where EventID == 4625
| extend Reason = case(
SubStatus == '0xc000005e', 'There are currently no logon servers available to service the logon request.',
SubStatus == '0xc0000064', 'User logon with misspelled or bad user account',
SubStatus == '0xc000006a', 'User logon with misspelled or bad password',
SubStatus == '0xc000006d', 'The cause is either a bad username or authentication information',
SubStatus == '0xc000006e', 'Indicates a referenced user name and authentication information are valid, but some user account restriction has prevented successful authentication (such as time-of-day restrictions).',
SubStatus == '0xc000006f', 'User logon outside authorized hours',
SubStatus == '0xc0000070', 'User logon from unauthorized workstation',
SubStatus == '0xc0000071', 'User logon with expired password',
SubStatus == '0xc0000072', 'User logon to account disabled by administrator',
SubStatus == '0xc00000dc', 'Indicates the Sam Server was in the wrong state to perform the desired operation.',
SubStatus == '0xc0000133', 'Clocks between DC and other computer too far out of sync',
SubStatus == '0xc000015b', 'The user has not been granted the requested logon type (also called the logon right) at this machine',
SubStatus == '0xc000018c', 'The logon request failed because the trust relationship between the primary domain and the trusted domain failed.',
SubStatus == '0xc0000192', 'An attempt was made to logon, but the Netlogon service was not started.',
SubStatus == '0xc0000193', 'User logon with expired account',
SubStatus == '0xc0000224', 'User is required to change password at next logon',
SubStatus == '0xc0000225', 'Evidently a bug in Windows and not a risk',
SubStatus == '0xc0000234', 'User logon with account locked',
SubStatus == '0xc00002ee', 'Failure Reason: An Error occurred during Logon',
SubStatus == '0xc0000413', 'Logon Failure: The machine you are logging on to is protected by an authentication firewall. The specified account is not allowed to authenticate to the machine.',
SubStatus == '0x0', 'Status OK',
strcat('Unknown reason substatus: ', SubStatus))
The following is an event I intentionally generated by typing in an incorrect password:
It is important to note that the amount of data collected can vary depending on the size of the environment so to avoid unexpected charges due to the amount of data ingested by Sentinel and into Log Analytics, start with minimum to get an idea of the amount of data per day and fine tune the configuration. Hope this helps anyone looking for a demonstration on how to set up security events collection in Azure. Kusto query is extremely powerful and will be able to provide all sorts of useful data for troubleshooting, auditing, and reporting.
