Update 23/05/2020
Added new info regarding ASR GUI! A community tool that will help you reporting and setting ASR rules locally! Ideal for lab scenarios!
Kudos to Hermann Maurer!
Hello again and welcome to the 3rd part of our blog series on demystifying attack surface reduction (ASR) rules.
The 3rd part is focused on how to report and troubleshoot Microsoft Defender ATP ASR Rules, both their configuration and the audit and block events.
Remember that you can follow the blog series here to read all the posts on this topic.
Continuing with the “How” - now on how to report and troubleshoot ASR rules
Keeping a bit of the tradition on the former blog post parts, if you asked us what is the best possible way to report and troubleshoot ASR rules events, our answer would logically be: It depends! :)
And that is very much the truth. Because it will depend eventually on the actual solution of choice that you are using to enable and configure ASR rules, your licensing, your role within your organization, etc. The point is, we have multiple ways of accomplishing very similar outcomes, some with more functionalities and/or granularity than others. Part 3 is all about going through each one of those and making sure you are aware of the options.
#1 How can I get a report on ASR rules?
Microsoft 365 security center
The Microsoft 365 security center is the new home for monitoring and managing security across your Microsoft identities, data, devices, apps, and infrastructure. Here you can easily view the security health of your organization, act to configure devices, users, and apps, and get alerts for suspicious activity. The Microsoft 365 security center is specifically intended for security admins and security operations teams to better manage and protect their organization. Visit the Microsoft 365 security center at https://security.microsoft.com.
In Microsoft 365 security center, we offer you a complete look at the current ASR rules configuration and events in your estate. Please note that your devices must be onboarded into the Microsoft Defender ATP service for these reports to be populated.
Here is a screenshot, directly taken from the Microsoft 365 security center (under Reports > Devices > Attack surface reduction ).
If you want to drill down to the device level, select Configuration from the Attack surface reduction rules pane. This will take you the following screen, where you can select a specific device and check its individual ASR rule configuration.
Microsoft Defender ATP – Advanced hunting
One of the most powerful and coolest features of Microsoft Defender ATP is advanced hunting. If you are unfamiliar with advanced hunting, please refer to our documentation - Proactively hunt for threats with advanced hunting.
Advanced hunting is a query-based (Kusto Query Language) threat-hunting tool that lets you explore up to 30 days of the captured (raw) data, that Microsoft Defender ATP Endpoint Detection and Response (EDR) collects from all your machines. Through advanced hunting you can proactively inspect events in order to locate interesting indicators and entities. The flexible access to data facilitates unconstrained hunting for both known and potential threats.
Through advanced hunting, it is possible to extract ASR rules information, create reports, and get in-depth information on the context of a given ASR rule audit or block event.
ASR rules events are available to be queried from the DeviceEvents table in the advanced hunting section of the Microsoft Defender Security Center. For example, a simple query such as the one below can report all the events that have ASR rules as data source, for the last 30 days, and will summarize them by the ActionType count, that in this case it will be the actual codename of the ASR rule.
DeviceEvents
| where Timestamp > ago(30d)
| where ActionType startswith “Asr”
| summarize EventCount=count() by ActionType
The above shows that 187 events were registered for AsrLsassCredentialTheft (102 for Blocked and 85 for Audited), 2 events for AsrOfficeChildProcess (1 for Audited and 1 for Block) and 8 events for AsrPsexecWmiChildProcessAudited.
Now, let us say that you want to focus on the AsrOfficeChildProcess rule, and get details on the actual files and processes involved. We just need to change the filter for ActionType and replace the summarize line with a projection of the wanted fields (in this case they are DeviceName, FileName, FolderPath, etc.).
DeviceEvents
| where (ActionType startswith “AsrOfficeChild”)
| extend RuleId=extractjson(“$Ruleid”, AdditionalFields, typeof(string))
| project DeviceName, FileName, FolderPath, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine
The cool thing about advanced hunting is that you can shape the queries to your liking, so that you can see the exact story of what was happening, regardless of whether you want to pinpoint something on an individual machine, or you want to extract insights from your entire environment.
Microsoft Defender ATP machine timeline
An alternative to advanced hunting, but with a narrower scope, is the Microsoft Defender ATP machine timeline. You can view all the collected events of a device, for the past 6 months, in the Microsoft Defender Security Center, by going to the Machines list, select a given machine, and then click on the Timeline tab.
Pictured below is a screenshot of the Timeline view of these events on a given endpoint. From this view, you can filter the events list based on any of the Event Groups along the right-side pane. You can also enable or disable Flagged and Verbose events while viewing alerts and scrolling through the historical timeline.
#2 How to troubleshoot ASR rules?
The first and most immediate way is to check locally, on a Windows device, which ASR rules are enabled (and their configuration) is by using the PowerShell cmdlets.
Nevertheless, we will show you other sources of information that Windows offers, to troubleshoot ASR rules’ impact and operation.
#2.1 Querying which rules are active
One of the easiest ways to determine if ASR rules are already enabled—and, if so, which ones—is through a PowerShell cmdlet, Get-MpPreference.
Here is an example:
As you can see, there are multiple ASR rules active, with different configured actions.
To expand the above information on ASR rules, you can use the properties AttackSurfaceReductionRules_Ids and/or AttackSurfaceReductionRules_Actions.
Example:
Get-MPPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids
The above shows all the IDs for ASR rules that have a setting different from 0 (Not Configured).
The next step is then to list the actual actions (Block or Audit) that each rule is configured with.
Get-MPPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Actions
As you can see from the above output, mapping rules to actions via PowerShell can be a bit of a pain. You can do it manually, by copying and pasting both above results into an Excel file, but that’s not the easiest way of achieving our end goal (knowing which rules are enabled and their specific actions).
Don’t forget to always map the above results with the available list of rules!
To simplify your ASR rules troubleshooting in PowerShell, we have made a quick and dirty sample script that helps you map rules and actions in an easy way. Just pull the script from this GitHub repo.
Here is a small example of what the above script might output.
Update 23/05/2020
Based on the above code, a MS colleague (Hermann Maurer), created a nice GUI both for reporting and setting ASR rules!
Here's how it looks:
Very slick! Files are available in his Github repo.
All-in-all, although PowerShell is an important auditing/reporting mechanism to have, there are alternative ways, more streamlined ones, of checking your machine’s and estate’s current ASR rule configurations, such as the ones showed at the beginning of the blog in part 2 of this blog series, in the “How can I get a report on ASR rules?” section.
#2.2 Querying blocking and auditing events
Windows Event Viewer
ASR rule events can be viewed within the Windows Defender log.
To access it, open Windows Event Viewer, and browse to Applications and Services Logs > Microsoft > Windows > Windows Defender > Operational.
Microsoft Defender Malware Protection Logs
You can also view rule events through the Microsoft Defender Antivirus dedicated command-line tool, called mpcmdrun.exe, that can be used to manage and configure, as well as automate tasks if needed.
You can find this utility in %ProgramFiles%\Windows Defender\MpCmdRun.exe. You must run it from an elevated command prompt (i.e. run as Admin).
To generate the support information, type MpCmdRun.exe -getfiles. After a while, several logs will be packaged into an archive (MpSupportFiles.cab) and made available in C:\ProgramData\Microsoft\Windows Defender\Support.
Extract that archive and you will have many files available for troubleshooting purposes.
The most relevant files are:
- MPOperationalEvents.txt - This file contains same level of information found in Event Viewer for Windows Defender’s Operational log.
- MPRegistry.txt – In this file you will be able to analyze all the current Windows Defender configurations, from the moment the support logs were captured.
- MPLog-***.txt – This log contains more verbose information about all the actions/operations of the Windows Defender.
Looking into MPOperationalEvents.txt, we find the same sort of information we found before when we blocked Word from launching a child process.
Within another file, called MPRegistry.txt, you will find a section called “Windows Defender Exploit Guard\ASR”, where you can doublecheck what rules are active and see their configurations.
In the above screenshot we can see rule “Block all Office applications from creating child processes” (D4F940AB-401B-4EFC-AADC-AD5F3C50688A) is enabled with a value of 2, which means Audit.
We hope you have found part 3 of our blog series about demystifying ASR rules helpful! Please let us know if you have any questions in the comments section.
As always, you can find all the blogs in the series here.
Our 4th and final post will be coming out shortly, stay tuned!
António and Rob
Program Managers @Pernille-Eskebo Defender ATP Product Group