Defender for Endpoint - Implementing ASR Rules

Defender for Endpoint - Implementing ASR Rules
Photo by Roberta Anitori / Unsplash

Phase 1: Discover and create exceptions

To get started, we will create a policy to set all Attack Surface Reduction rules to Audit mode to ensure applications are not impacted. This allows us to gather telemetry data for any applications that might be affected by these rules. Data should be collected for 30 days first, and then exclusions can be made for any legitimate applications that we want to allow. Creating exclusions too early reduces visibility for the scope of impact across all devices. For this article, I will use Intune's Endpoint security profile, but the doc below details all available options.

Enable attack surface reduction rules
Enable attack surface reduction (ASR) rules to protect your devices from attacks that use macros, scripts, and common injection techniques.

Some audit events, such as Block credential stealing from the Windows local security authority subsystem, are not always indicative of true application impact because they use less precise detection logic to generate auditing data. This means that some applications will require testing on devices where the rules have been set to Block to evaluate whether the application is truly affected or not.

Microsoft made significant investments to an internal allow list for Block credential stealing from the Windows local security authority subsystem in early 2022, and the default mode will be changing to Block. It is recommended to start with Block, and all KQL queries in this article will exclude hits for this rule.

Because it could take a long time to research all applications to determine how the rules affect them, it is better to simply create exclusions for all rule detections that make sense, move rules to Enabled (Block mode) as quickly as possible, and then work on removing exclusions. This provides improved protection sooner and frees up time to focus on other priorities if needed. For many rules, the scope for exclusions could be limited to a smaller subset of devices as well.

Creating the exclusions list

To discover potential exclusions, we could use the Attack surface reduction rules report in the M365 Defender portal to create exclusions as detailed in the following guide from Microsoft: Optimize ASR rule deployment and detections

Alternatively, I like to have the raw data, so we can also query the data for Attack Surface Reduction rule detections using Advanced Hunting in the Microsoft 365 Defender portal: Advanced Hunting - Microsoft 365 security

The following query provides a list of fully qualified file paths for applications that would have been blocked by all configured Attack Surface Reduction rules (except the Credential Theft rule):

DeviceEvents
| where Timestamp > ago(30d)
| where ActionType startswith 'Asr'
| where ActionType !startswith 'AsrLsassCredentialTheft'
| extend FullPath = strcat(FolderPath, "\\", FileName)
| distinct FullPath

Use the Export button to download the list as a CSV, then review and remove any items that should not be excluded such as unapproved applications running from the user’s profile. Exclusions for applications in user writable areas should be avoided whenever possible, but they may be needed during this phase as a temporary solution to avoid potential impact to important applications.

Before we add exclusions to the Intune policy, run the following query to gather more details about rule detections, which devices they apply to, and which applications on those devices may be impacted:

DeviceEvents
| where Timestamp > ago(30d)
| where ActionType startswith 'Asr'
| where ActionType !startswith 'AsrLsassCredentialTheft'
| extend FullPath = strcat(FolderPath, "\\", FileName)
| summarize count() by ActionType, DeviceName, FullPath

Use the Export button again to download the data as a CSV and save this file for later analysis. This will be helpful with identifying which devices have which potentially affected applications, and we can reference this when we go back to remove exclusions.

Finally, run the following query to identify Attack Surface Reduction rules that have not been detected in the past 30 days:

let asrRules = datatable(ActionType:string) ['AsrExecutableEmailContentAudited','AsrExecutableOfficeContentAudited','AsrLsassCredentialTheftAudited','AsrObfuscatedScriptAudited','AsrOfficeChildProcessAudited','AsrOfficeCommAppChildProcessAudited','AsrOfficeMacroWin32ApiCallsAudited','AsrOfficeProcessInjectionAudited','AsrPersistenceThroughWmiAudited','AsrPsexecWmiChildProcessAudited','AsrRansomwareAudited','AsrScriptExecutableDownloadAudited','AsrUntrustedExecutableAudited','AsrUntrustedUsbProcessAudited','AsrVulnerableSignedDriverAudited'];
DeviceEvents
| where Timestamp > ago(30d)
| where ActionType startswith 'Asr'
| distinct ActionType
| join kind=rightanti asrRules on ActionType

The rules returned by this query can be configured as Enabled for all devices, and we will create an alert for any new detections. If concerned about support workload, the following are usually the safest to enable first, then do the rest after waiting a few weeks:

Block untrusted and unsigned processes that run from USB
Block Adobe Reader from creating child processes
Block executable content download from email and webmail clients
Block JavaScript or VBScript from launching downloaded executable content
Block persistence through WMI event subscription
Block Office applications from creating executable content

Adding exclusions

Next, modify the ASR rule profile and populate the exclusions list in the policy. To do this, log into the Intune portal and go to Endpoint security, Attack surface reduction or follow this link: Endpoint security - Attack surface reduction

Click on the Attack Surface Reduction rules policy, then click Properties and click Edit next to Configuration settings.

Scroll to the bottom of the policy, click on the Import button, then select the first CSV we downloaded and updated that had only the full paths in them. If using the CSV that was downloaded using the Export button, be sure to leave the My data has headers box checked. Click select, then click Review + save.

Once clients have updated to include the exclusions, the telemetry data should no longer include ASR rule detections unless it is something that hasn’t been seen in the past 30 days. Now we only need to monitor for new detections and simply update the exclusions as necessary.

To automate this monitoring process, we can use custom detections in the Microsoft 365 Defender portal under Advanced Hunting: Advanced Hunting - Microsoft 365 security

Set the time period to Last 24 hours, run the following query:

DeviceEvents
| where ActionType startswith 'Asr'
| where ActionType !startswith 'AsrLsassCredentialTheft'
| extend FullPath = strcat(FolderPath, "\\", FileName)

The results should be empty or close to empty (if all devices have received the updated policy). Now click Create detection rule and fill out the information for the alert details as desired and click Next:

Check the box for Device and select DeviceId or DeviceName depending on your needs. If you want user details in the alert, check the box for User and select InitiatingProcessAccountUpn, then click Next.

Skip the Actions page by clicking Next, then specify the scope for All devices or the device group if being used, then click Next. Review the Summary page

Note that the query will run against the previous 30 days of data and generate alerts. These alerts can be closed in bulk by going to Alerts, creating a Filter, selecting all, clicking Manage alerts, and then setting the status to Resolved.

Phase 2: Enforce for pilot group

The next step is to identify devices that we feel comfortable enabling the ASR rules in blocking mode on. The goal is to balance potential impact of blocking application functionality that hasn’t been detected yet with the workload of the support team who will need to add exclusions as they are discovered.

Once devices have been identified, add them to a device group in Azure AD and exclude them from the existing Attack Surface Reduction rules policy to prevent conflicting policies. Now, Duplicate the existing policy as seen below, edit the policy to set all rules to Block/Enable, and then target the pilot device group for testing.

During this time, monitor new detections and respond to user feedback by adding exclusions as necessary. If an issue needs to be resolved more quickly, remove the affected device from the device group, then force a policy sync on the device to revert it back to Audit mode. Consider adding these reverted devices to an “Exclude” group to simplify excluding them from future phases.

Phase 3: Enforce for larger group

With 6-8 weeks of auditing data used to create exclusions, there should be very limited to no impact, and by now, the processes for addressing issues should be well understood. A safe way to create a larger group is to query for devices that have not had detections over the past 30 days using this query:

DeviceInfo
| project DeviceName, AadDeviceId
| join kind=leftanti ( 
    DeviceEvents 
    | where Timestamp > ago(30d)
    | project DeviceName, ActionType
    | where ActionType startswith 'Asr' 
    | where ActionType !startswith 'AsrLsassCredentialTheft' )
on DeviceName
| distinct AadDeviceId

Again, click the Export button to download the results. Unfortunately, we can only query the Azure AD Device ID and not the Object ID that we need to add the devices to groups, so we will need to use PowerShell modules or the Graph API to look up the Object ID for a given Device ID. This example uses the Microsoft Graph PowerShell SDK, but the same logic will work for native Graph API calls.

First, install the Microsoft Graph PowerShell SDK:

Install-Module Microsoft.Graph -Scope CurrentUser

Connect to the Graph API with permissions to create and modify a group and read device properties:

Connect-MgGraph -Scopes "Device.Read.All","Group.ReadWrite.All"

Create a group for our devices:

$groupId = (New-MgGroup -DisplayName 'ASR Rules Phase 3' -MailEnabled:$false -MailNickname 'ASRPhase3' -SecurityEnabled).Id

Get Device IDs from the CSV, look up the Object ID, and add it to the group:

(Import-Csv -Path '.\Downloads\New query.csv').AadDeviceId | ForEach-Object { 
    if (Get-MgDevice -Filter "DeviceId eq '$_'" ) { 
        New-MgGroupMember -GroupId $groupId -DirectoryObjectId (Get-MgDevice -Filter "DeviceId eq '$_'").Id 
    }
}

Now we can add this group as an included group in the assignments for the new ASR rule that we used for the pilot. Continue to add exclusions as needed to the policy, and if necessary, remove devices from the group to put a device back into the audit mode group.

Phase 4: Enforce for all devices

Finally, assign the new policy to All Devices excluding devices reverted for further investigation.

To do this, remove the All Devices assignment on the Audit policy and add an assignment for the “Exclude” device group if you created one. Next, edit the new policy used for Phase 2 and 3, and change the assignment to target All Devices and add the “Exclude” device group as an excluded group.

Allow a week or two to ensure everything is stable, then work on remediating devices that had to be added to the Exclude group until all devices are receiving the new policy. To deploy the new policy to these devices, simply remove them from the “Exclude group.” At this point, all devices should have all rules except the Credential Theft rule enabled.

Phase 5: Remove exceptions

Excluding the credential theft rule, detections are generally low and limited to a smaller set of devices (unless detection are related to base applications). It may be helpful to start with the rule with the lowest number of detections and work up to the ones with the highest number of detections. You can use the data exported from page 2 to reference which rules had detections with which applications on which devices.

To reduce end user impact and validate no issues when removing exclusions, duplicate the new ASR rules policy in Intune and remove the exclusion you are working on. Now create a device group for a few test devices, exclude the group from the existing ASR rules policy, and assign the testing group to the newly modified policy. If testing shows no application impact, consider adding a subset of affected devices to the testing group until comfortable with removing that exclusion from the primary ASR policy.

Block Credential Theft Rule

This has traditionally been a difficult rule to enable because the audit data makes it seem that many applications use this functionality, so there is concern that enabling it may break applications. This is due to poor detection logic for auditing, so any application that enumerates LSASS will trigger a detection.

Microsoft has been refining the internal allow list and working with vendors to ensure this rule will not cause issues with legitimate applications. Starting March 2022, Microsoft will begin enabling this rule by default as they are confident their telemetry data shows there will be no issues.

It would not be recommended to create exclusions for this rule. Instead, consider enabling this rule slowly across small batches of devices at a time and monitor Block events very closely.

Known bypasses and techniques

Emeric Nasi from SEVAGAS

experiments/windows-defender/ASR at master · commial/experiments (github.com)

Mastodon