Attack Surface Reduction (ASR) rules are a great way to harden an environment. They block well-known attack vectors that malware tends to use. Organizations with attack surface reduction rules enabled in a block mode are better protected against attacks such as ransomware.

Moving ASR rules from audit mode into a block can be overwhelming, as an audit can produce a lot of data. Making sense of this data is tricky and requires drilling through to find out what is important and how to use the data to create exclusions.

Within this article, I will walk through the different ways of verifying the audit results,  different types of exclusions, and providing an advanced KQL that surfaces detailed information.

Threat & Vulnerability Recommendations

If you open an ASR security recommendation in Microsoft’s Defender Vulnerability Management, it will surface a basic user impact analysis as seen in Figure 1. This analysis provides you with an idea of what the user impact could be when enabling this feature.

The above image means that on 97% of all affected devices, no audit hits occurred. However, this means that there were hits on 3% of devices – which isn’t a small number. Unfortunately, the details of the files causing these hits aren’t available here.

Built-in Reporting

If you want some more details, you can use the attack surface reduction reporting that is built into the security portal. To see the report, navigate to reports > attack surface reduction rules (Figure 2).

The top part of the page provides some ‘high-level’ statistics. The table below shows each individual hit and provides you with the affected device and software. This enables you to verify if this is a legitimate file that needs to be enabled or if this file can be blocked.

However, this method isn’t that scalable. Because the table has an entry for each audit, it can become quite lengthy. In the above example, there are 22.000 hits, which isn’t workable.

Setting the Scene

Before we dive into the query, I want to discuss two things: exclusions and phased rollouts. It is important to get these out of the way, as both are included in the query.

There is no single way to add an exclusion for attack surface reduction rules. There are several different methods:

• You can add an exclusion for all ASR rules at once or an exclusion scope to a specific rule.
• Wildcards are supported, meaning you can whitelist entire folder paths or specific files.
• By adding indicators, you can whitelist a specific certificate or file hash.

Settings such as ASR are often rolled out in a phased approach or in different ‘rings’. There are typically three different rings: test, canary, and production. These rings can be defined in Intune, but are not present by default in Microsoft Defender. In order to surface these, you can use Intune policies to create a Defender tag that represents the tag.

Using Advanced KQL

If you are just starting out with KQL, it is recommended to review the following article first. This provides an introduction to the language.

The KQL query consists of a few steps. I will walk through each step individually to ensure it’s understandable. This query should be a starting point from which you can start experimenting for yourself to see what works best.

The query can be found below.

1. DeviceEvents
2. | where Timestamp > ago(30d)
3. | where ActionType == "AsrUntrustedExecutableAudited"
4. | join (
a. DeviceInfo
b. | where Timestamp > ago(30d)
c. | where DeviceType == "Workstation" and RegistryDeviceTag =="TST"
d. | summarize arg_max(Timestamp, *) by DeviceId)
5. on DeviceId
6. | invoke FileProfile()
7. | summarize Hits=count(), UniqueDevices=dcount(DeviceId), AffectedDevices=make_set(DeviceName), Signed=make_set(SignatureState), NumberOfUniqueHashes=dcount(SHA256), AffectedUsers=make_set(InitiatingProcessAccountName), Rings=make_set(RegistryDeviceTag) by FileName, FolderPath
8. | project-reorder FolderPath, FileName, Hits, UniqueDevices, Rings, AffectedDevices, AffectedUsers, NumberOfUniqueHashes, Signed

1. All audit data for Attack Surface Reduction rules is stored in the DeviceEvents table.
2. By default, Microsoft Defender advanced hunting has a retention period of 30 days. That is why I query the past 30 days by default. If a bigger retention period is desired, ingesting the data into Microsoft Sentinel is recommended.
3. The next line filters on a specific rule. While it is possible to get all results at once, filtering the results by the rule is recommended, as each rule has another attack vector and use case. All action types are documented in the ASR reference.
4. In the next step, we ‘join’ this data to the DeviceInfo table, a single in KQL is much the same as in SQL. Joining ensures only machines matching certain conditions are included in the ASR results. This step is essential to keep focused on your scope. You don’t want to treat servers and endpoints the same; this way, you can separate the data easily.

a. The DeviceInfo table is refreshed multiple times a day and contains basic device information.

b. By using the maximum query period, we use as much data as possible.

c. I filter only workstations (excluding servers) and only devices with a ‘TST’ tag. This is the tag I have previously set using Intune, so I know I am only looking at the results of my ‘test’ group.

d. Because the DeviceInfo table is refreshed multiple times, there can be duplicate entries for devices. By using the summarize operator together with the arg_max function, we only get the latest entry for each device.

5. We match this information to our bigger query using the ‘DeviceId’ column, as this is a unique value.

6. The FileProfile function enriches files based on the file hash. This allows us to know if the file is signed or not. By having this information, you can decide whether it is possible to exclude this file using the certificate method.

7. The summarize operator allows us to combine audit events originating from the same file and location. This allows us to create more focused results and identify what events have the biggest impact (occurrence). This line also uses the following operators.

a. Count(): counts the number of hits per path and file name.

b. Dcount(DeviceId): Provides the number of unique devices hitting this rule.

c. Make_set(): Creates a list of all unique values.

8. In the final step, the project-reorder operator cleans up the result. This updates the order of columns in the results, ensuring we can put the most important data first.

The query returns a combined list of all the results with the following useful columns:

• FolderPath: The location where the file resides.
• FileName: The name of the file that is hitting the rule.
• Hits: The total number of events for the specific path and file name.
• UniqueDevices: The number of devices with a hit.
• Rings: Shows if the hit is in a specific roll-out wave (if the tags are deployed).
• AffectedDevices: A list of devices that have an audit hit.
• AffectedUsers: All users who have a file that hits this ASR rule.
• NumberOfUniqueHashes: This column gives you an idea if the hash of the file updates often. If it does, whitelisting using file hash is not a good idea.
• Signed: Determines whether the file is signed or not. This is useful for a potential exclusion using a certificate.

Building Further

It is recommended that you take this query and update it according to your needs. Before you can do this, you need to know what data is in a table and what values exist. To do so, there are two queries I use.

The first one is simple. The take operator allows you to take a number of random lines from a table. Getting 10 entries makes it easy to identify what columns exist and what data they contain.

DeviceEvents
| take 10

To dig a little bit deeper, use the distinct operator. This provides all unique values for a specific column. With the query below, you can learn what kind of values exist for ‘DeviceType’.

DeviceInfo
| distinct DeviceType

KQL is your Weapon.

When working with large volumes of data, KQL should be the primary weapon of choice. It allows you to easily and quickly get through to what’s important and go from millions of audit events to a couple of lines.