This post has been republished via RSS; it originally appeared at: Core Infrastructure and Security Blog articles.
This is John Barbare and I am a Sr Customer Engineer at Microsoft focusing on all things in the Cybersecurity space. In a previous blog back in July, 2020, I walked through a demo of setting up an Attack Surface Reduction (ASR) rule policy in Microsoft Endpoint Manager (MEM) for your Windows Operating Systems and how to view the detections once applied.
Since then, Microsoft has introduced a new “Warn Mode” in addition to the Audit and Block modes previously. With that said, I will give a brief overview of ASR Rules, demo what the differences are in the different modes, show custom security notifications for your organization, and the hunt for ASR rule alerts in the new Microsoft 365 Defender unified portal.
What are Attack Surface Reduction Rules?
Attack surface reduction rules help prevent software behaviors that are often abused to compromise your device or network. For example, an attacker might try to run an unsigned script off a USB drive, or have a macro in an Office document make calls directly to the Win32 API. ASR rules can constrain these kinds of risky behaviors and improve your organization's defensive posture to decrease your risk considerably from being attacked with Ransomware, various other types of malware, and other attack vectors.
If you are evaluating or executing a proof of concept from a 3rd party HIPS (Host Intrusion Prevention System) over to ASR rules, this article will assist you in the planning, development, and proper configuration in MEM. With the complete end to end protection Microsoft offers, this article will focus on the Attack Surface Reduction component of Windows Defender Exploit Guard. Prevent actions and apps that are commonly used by malware, such as launching executables from email (.exe, .dll, .scr, .ps, .vbs, and .js).
- Scripts or applications that launch child processes
- Most rules can be set to Audit to monitor activity prior to being set to enforce
- All rules support exclusions based on file or folder names
- ASR rules support environmental variables and wildcards
ASR rules may block legitimate applications from making changes, so these features come with both an Audit mode and a Block mode and a newly released Warn mode. I always recommend to my customers when configuring ASR rules for the first time to conduct the changes in Audit mode first so it will allow for testing of the policy before moving any of the rules into Block mode. But now we can audit, then warn, before placing into block mode so our users know that a risky behavior is being detected. This is exactly like using SmartScreen where the user goes to website that is malicious, and is warned but given the choice to bypass or not continue at all. This is great before rolling out a new feature and will provide some great context around the warn mode feature.
With the new warn mode, whenever content is blocked by an ASR rule, users see a dialog box that indicates the content is blocked. The dialog box also offers the user an option to unblock the content. The user can then retry their action, and the operation completes. When a user unblocks content, the content remains unblocked for 24 hours, and then blocking resumes. Warn mode helps your organization have ASR rules in place without preventing users from accessing the content they need to perform their tasks.
Supported OS for Warn Mode and Requirements
Warn mode is supported on devices running the following versions of Windows OS:
Microsoft Defender Antivirus must be running with real-time protection in Active mode.
In addition, make sure Microsoft Defender Antivirus and antimalware updates are installed.
- Minimum platform release requirement: 4.18.2008.9
- Minimum engine release requirement: 1.1.17400.5
Exceptions to Warn Mode
The following three ASR rules are not supported in Warn Mode:
- Block persistence through WMI event subscription (GUID e6db77e5-3df2-4cf1-b95a-636979351e5b)
- Use advanced protection against ransomware (GUID c1db55ab-c21a-4637-bb3f-a12568109d35)
In addition, warn mode is not supported on devices running older versions of Windows. In those cases, ASR rules that are configured to run in warn mode will run in block mode.
Setting up Warn Mode Using Microsoft Endpoint Manager
The first item we want to do is make sure that all the devices we want to push the new ASR rule policy are showing up inside MEM admin center. This paper assumes you have enrolled all the devices for your preferred method, and we are checking to make sure the devices are shown before creating or pushing out a new policy. Navigate to the Microsoft Endpoint Manager admin center and login with your credentials. Once logged in you will arrive at the home page.
Select “Devices” and then “All devices” to make sure the device you will be applying the new ASR rule Policy has been synchronized.
Next, we will select the “Endpoint Security” tab which is under the “Device” tab.
This will bring you into the main policy dashboard to create the new ASR Warn rule policy. First you will select “Attack Surface Reduction” under the “Manage” tab. Select “create policy” at the top, and then a window will open to pick the operating system “Platform” and “Profile”. For “Platform”, select Windows 10 and later and for “Profile”, select Attack Surface Reduction Rules and click “Create” at the bottom.
This will bring you to the creation of the profile for ASR. Name the profile in the “basics” tab and then provide a brief description and click next.
The next tab, “Configuration settings” is where you will configure the ASR rules. Here we have placed all the ASR rules in warn except the ones that are not allowed. From selecting the third ASR rule, one can see all the settings for the rule including the new Warn mode. You can also search for a setting in the top box underneath the settings and before the ASR rules. After placing them in the correct mode, select next.
Next, we will have the option to assign the policy to select groups, all users, all devices, or all users and devices. Here we are targeting just a select group and will pick the IT Group for this new policy. Selecting the groups to include and IT Group will target the devices inside the group and then click select and then click next. This is the equivalent to applying a policy to an organizational unit in Group Policy Objects.
Many users ask when to use user groups and when to use device groups. The answer depends on your goal. Use device groups when you do not care who is signed in on the device, or if anyone is signed in. You want your settings to always be on the device. Use user groups when you want your settings and rules to always go with the user, whatever device they use.
Review and Create
Now let’s head over to finalizing up the newly created profile on the review and create profile page. You will see all the settings for our new Warn ASR policy, and you can confirm before selecting create. Go ahead and click on create to save the new ASR policy.
The next page will bring you to the summary page where you can view the new ASR rule policy you just created. When you select the policy name that you have created, you will be redirected to the overview page which will display more detailed information.
When you select a tile from this view, MEM displays additional details for that profile if they are available. In this case, it applied my new ASR Rule Warn Mode policy to my lab test machine that I targeted successfully.
Testing Out the New Warn Mode
In my lab, I will test out one of the rules to show you what Warn mode looks like when triggering an ASR Rule with my newly applied ASR Warn mode policy. In the first instance I have a malicious Microsoft Word Document that will create multiple child processes. As seen below, I open the document and then bypass the security warning and click on Enable Content.
After bypassing the alert, a Windows Security notification is presented with a dialog box that indicates the content is blocked. The dialog box also offers me the new option to unblock the content. The dialog box below has been increased in size to show you the full warning.
If the ASR Policy would have been in Block mode, the below dialog box would have been presented to the user.
As one can see during testing or implementation of ASR Rules, you can see the real value of using Warn mode versus going strait to Audit and then full Block mode. This way you can let your users know you will be implementing a new security policy and they will be warned before full implementation.
Customizing the Dialog Box
If your organization wants to display a customized notification from Windows Security to display options to call, email, or redirect the user to a help portal, the instructions can be found here. I will not walk through the steps, but the screenshot below depicts what a customized notification would look like when an ASR Rule or any other Windows Security notification is displayed.
Advanced Hunting with ASR Rules in Microsoft 365 Defender
Microsoft Defender 365 provides detailed reporting for events as part of its alert investigation scenarios. You can query Microsoft Defender 365 data by using advanced hunting using KQL (Kusto Query Language). Login into Microsoft 365 Defender and select Hunting and then Advanced Hunting blade at the top. The query we will run is the following:
| where ActionType startswith 'Asr'
Monitoring the ASR Rules in Microsoft 365 Defender
In the same window, select Configuration Management blade under Endpoints and then select Go to Attack Surface Management. Select the detections tab to see a more fine-grained ASR rule detection graph in Audit and Block mode over a period time and what has been detected.
Thanks for taking the time to read this article and I hope you understand the new Warn mode for ASR rules and how you can use it in your organization during testing and pre-implementation. Using the new unified portal - Microsoft Defender 365 – to hunt for ASR detections and see a graph of what is getting triggered will further show the value for any IT Manager the value of the Microsoft 365 security stack. Hope to see you in the next blog and always protect your endpoints!
Thanks for reading and have a great Cybersecurity day!