The new schema is designed to improve performance, accuracy, and ease of use. See how to apply it to existing queries.

Back in August, I put together a blog post where I described how to use Advanced Hunting to measure your deployment of Attack Surface Reduction Controls. I also talked about this subject on an episode of Defrag Tools on Channel 9.

One of the things you may have noticed from the process I outlined in my blog or in the Defrag Tools episode is that you really need to be good at memorizing (or looking up) GUIDs to be effective at managing the output. We provide all the rules with GUIDs buried within, but if you didn’t want to mentally translate GUIDs, you had to build your own lookup table to convert them into something human/readable. It was possible, but it wasn’t easy (enough).

We also noticed that most customers were using an Audit -> Measure -> Configure -> Enforce workflow for these rules, but doing so rule-by-rule (instead of all-or-nothing). That means you ended up measuring everything to go after the one rule you targeted. As filtering based on columns is much faster than parsing fields from JSON and filtering them afterwards, you also paid a performance hit.

We thought we could do better.

While we hate making changes that may affect existing queries, we wanted to equip every defender and every hunter with better performance, improved accuracy, and ease of use. (The work of defending is hard enough.) That is why we have introduced some schema improvements to Attack Surface Reduction in Windows Defender ATP.

In this post, I’m going to show you how to apply the new schema to the existing queries from my previous blog, to get a feel for how that would work on any queries you may have written or want to write. Also, because we really do hate breaking things, we have automatically modified the queries you have saved in the Windows Defender ATP portal to work correctly with these changes.

How many ASR events were triggered?

First, we’ll rewrite our query to output how many ASR events were triggered in the environment:

MiscEvents\n | where ActionType startswith \"Asr\" \n | summarize NumberOfEvents=count() by ActionType\n | sort by NumberOfEvents desc

Immediately, we can see better detail on exactly what was happening within the environment:

Which devices might be impacted, and how much?

Again, with the new schema changes, it becomes easier to investigate the potential device impact. In fact, let’s rewrite that query to discover what our impact will be across the device landscape.

MiscEvents\n | where ActionType startswith \"Asr\" \n | summarize AsrDetections=count() by ComputerName\n | order by AsrDetections desc

We quickly zero in on the potential impact of the rules we have applied:

Which apps are potentially the most impacted by my rule set?

Now let’s get down to understanding the potential compatibility impact of our rules by rewriting the fourth query from my previous post, pivoting on the impacted app:

MiscEvents\n | where ActionType startswith \"Asr\" \n | summarize DevicesImpacted=dcount(ComputerName) by InitiatingProcessFileName, ActionType\n | order by DevicesImpacted desc

Again, we’ve discovered that the query ends up shorter and faster, while still producing the same, and very actionable, results:

So far so good. We’ve updated our existing queries to make them shorter, easier to maintain, and faster. But let’s not stop there! We’ve got an updated schema that is supposed to make it easier for us to set up rules, so let’s dig a bit deeper and go further than I did in my last post.

Leveraging the new schema to configure exclusions for Office Child Processes

One of the primary motivations for updating the schema is to ensure that it’s easier for you to configure controls so, here, I’ll explore how you can specifically target the Office Child Processes ASR control.

Office ASR controls come in handy as you start to constrain what Office apps can do. Of course, the very best control would be to disable macros. Alas, most organizations I know have a dependency on macros, and that’s not an option. (Similarly, the safest configuration of Windows is to disallow the execution of .exe files, which is similarly problematic for productivity.) So, instead of breaking everything, you disallow the behaviors that tend to indicate malicious behavior, while still allowing legitimate behavior.

One such behavior that is uncommon for well-meaning documents, but quite common for malicious ones, is spawning a new process. So, let’s look at how we can identify the specific behaviors that we are seeing in the environment:

MiscEvents\n | where ActionType == \"AsrOfficeChildProcessBlocked\" \n | summarize DevicesImpacted=dcount(ComputerName) by InitiatingProcessFileName, FileName

Because of the new syntax, we can easily write a clearer (and more performant) query that tells us which Office app is impacted, along with the child process created (which is what we would add to the exclusion list if it turned out to be a legitimate behavior of the Office app). As you can see in the figure below, I can now see the device on which the behavior was detected in order to investigate the issue further.

But wait, there’s more! If I want to investigate to see if it might be legitimate behavior, I can further enhance the query by searching for nearby file creations, and then identify candidates for the document that might be the trigger:

let DocsOpenedOnDevice =\n    FileCreationEvents\n    | where FileName contains \".doc\" or FileName contains \".ppt\" or FileName contains \".xls\"\n    | project ComputerName, DocFileName=FileName, DocOpenedTime=EventTime;\nMiscEvents\n | where ActionType == \"AsrOfficeChildProcessBlocked\" \n | join kind = inner DocsOpenedOnDevice on ComputerName\n | where (EventTime-DocOpenedTime) between (0min..5min)\n | project ComputerName, ChildProcess=FileName, LaunchingProcess=InitiatingProcessFileName, DocFileName\n | distinct *

And the result of my query is as follows:

As you can see, we’re starting to really dig deep into what might be going on, either in an attack or in benign behavior. Additionally, we can start with a clear understanding of the current environment, and watch it change over time.

Conclusion

I hope this gives you a good feel for the change that we’ve made in the schema for Attack Surface Reduction in Windows Defender ATP and why we’ve made it—namely, to make it easier for you to set up protective ASR controls and increase the cost and complexity to any adversary who may be trying to target you! I also hope that you see how similar the queries are before and after this change, and that very little modification is necessary (and most of it is shortening).

For details on all of the Attack Surface Reduction controls, see Reduce attack surfaces with attack surface reduction rules.

Continue the conversation. Find best practices. Bookmark the Windows 10 Tech Community.

Looking for support? Visit the Windows 10 IT pro forums.

Back in August, I put together a blog post where I described how to use Advanced Hunting to measure your deployment of Attack Surface Reduction Controls. I also talked about this subject on an episode of Defrag Tools on Channel 9.

One of the things you may have noticed from the process I outlined in my blog or in the Defrag Tools episode is that you really need to be good at memorizing (or looking up) GUIDs to be effective at managing the output. We provide all the rules with GUIDs buried within, but if you didn’t want to mentally translate GUIDs, you had to build your own lookup table to convert them into something human/readable. It was possible, but it wasn’t easy (enough).

We also noticed that most customers were using an Audit -> Measure -> Configure -> Enforce workflow for these rules, but doing so rule-by-rule (instead of all-or-nothing). That means you ended up measuring everything to go after the one rule you targeted. As filtering based on columns is much faster than parsing fields from JSON and filtering them afterwards, you also paid a performance hit.

We thought we could do better.

While we hate making changes that may affect existing queries, we wanted to equip every defender and every hunter with better performance, improved accuracy, and ease of use. (The work of defending is hard enough.) That is why we have introduced some schema improvements to Attack Surface Reduction in Windows Defender ATP.

In this post, I’m going to show you how to apply the new schema to the existing queries from my previous blog, to get a feel for how that would work on any queries you may have written or want to write. Also, because we really do hate breaking things, we have automatically modified the queries you have saved in the Windows Defender ATP portal to work correctly with these changes.

How many ASR events were triggered?

First, we’ll rewrite our query to output how many ASR events were triggered in the environment:

MiscEvents\n | where ActionType startswith \"Asr\" \n | summarize NumberOfEvents=count() by ActionType\n | sort by NumberOfEvents desc

Immediately, we can see better detail on exactly what was happening within the environment:

Which devices might be impacted, and how much?

Again, with the new schema changes, it becomes easier to investigate the potential device impact. In fact, let’s rewrite that query to discover what our impact will be across the device landscape.

MiscEvents\n | where ActionType startswith \"Asr\" \n | summarize AsrDetections=count() by ComputerName\n | order by AsrDetections desc

We quickly zero in on the potential impact of the rules we have applied:

Which apps are potentially the most impacted by my rule set?

Now let’s get down to understanding the potential compatibility impact of our rules by rewriting the fourth query from my previous post, pivoting on the impacted app:

MiscEvents\n | where ActionType startswith \"Asr\" \n | summarize DevicesImpacted=dcount(ComputerName) by InitiatingProcessFileName, ActionType\n | order by DevicesImpacted desc

Again, we’ve discovered that the query ends up shorter and faster, while still producing the same, and very actionable, results:

So far so good. We’ve updated our existing queries to make them shorter, easier to maintain, and faster. But let’s not stop there! We’ve got an updated schema that is supposed to make it easier for us to set up rules, so let’s dig a bit deeper and go further than I did in my last post.

Leveraging the new schema to configure exclusions for Office Child Processes

One of the primary motivations for updating the schema is to ensure that it’s easier for you to configure controls so, here, I’ll explore how you can specifically target the Office Child Processes ASR control.

Office ASR controls come in handy as you start to constrain what Office apps can do. Of course, the very best control would be to disable macros. Alas, most organizations I know have a dependency on macros, and that’s not an option. (Similarly, the safest configuration of Windows is to disallow the execution of .exe files, which is similarly problematic for productivity.) So, instead of breaking everything, you disallow the behaviors that tend to indicate malicious behavior, while still allowing legitimate behavior.

One such behavior that is uncommon for well-meaning documents, but quite common for malicious ones, is spawning a new process. So, let’s look at how we can identify the specific behaviors that we are seeing in the environment:

MiscEvents\n | where ActionType == \"AsrOfficeChildProcessBlocked\" \n | summarize DevicesImpacted=dcount(ComputerName) by InitiatingProcessFileName, FileName

Because of the new syntax, we can easily write a clearer (and more performant) query that tells us which Office app is impacted, along with the child process created (which is what we would add to the exclusion list if it turned out to be a legitimate behavior of the Office app). As you can see in the figure below, I can now see the device on which the behavior was detected in order to investigate the issue further.

But wait, there’s more! If I want to investigate to see if it might be legitimate behavior, I can further enhance the query by searching for nearby file creations, and then identify candidates for the document that might be the trigger:

let DocsOpenedOnDevice =\n    FileCreationEvents\n    | where FileName contains \".doc\" or FileName contains \".ppt\" or FileName contains \".xls\"\n    | project ComputerName, DocFileName=FileName, DocOpenedTime=EventTime;\nMiscEvents\n | where ActionType == \"AsrOfficeChildProcessBlocked\" \n | join kind = inner DocsOpenedOnDevice on ComputerName\n | where (EventTime-DocOpenedTime) between (0min..5min)\n | project ComputerName, ChildProcess=FileName, LaunchingProcess=InitiatingProcessFileName, DocFileName\n | distinct *

And the result of my query is as follows:

As you can see, we’re starting to really dig deep into what might be going on, either in an attack or in benign behavior. Additionally, we can start with a clear understanding of the current environment, and watch it change over time.

Conclusion

I hope this gives you a good feel for the change that we’ve made in the schema for Attack Surface Reduction in Windows Defender ATP and why we’ve made it—namely, to make it easier for you to set up protective ASR controls and increase the cost and complexity to any adversary who may be trying to target you! I also hope that you see how similar the queries are before and after this change, and that very little modification is necessary (and most of it is shortening).

For details on all of the Attack Surface Reduction controls, see Reduce attack surfaces with attack surface reduction rules.

Continue the conversation. Find best practices. Bookmark the Windows 10 Tech Community.

Looking for support? Visit the Windows 10 IT pro forums.

The new schema is designed to improve performance, accuracy, and ease of use. See how to apply it to existing queries.