Windows Defender Exploit Guard ASR Rules for Office
On this blog post I continue looking at the ASR rules, this time I'm looking at the ASR rules for Office. The ASR rules for office are:
- Block Office applications from creating child processes
- Block Office applications from creating executable content
- Block Office applications from injecting code into other processes
- Block Win32 API calls from Office macro
These rules only work on the following versions of Microsoft Office on Windows 10, version 1709 (and later) with Windows Defender configured with Real-Time protection enabled:
- Microsoft Office 365
- Microsoft Office 2016
- Microsoft Office 2013
- Microsoft Office 2010
Another thing to take in to account is that these controls only work with the following Office applications:
- Microsoft Word
- Microsoft Excel
- Microsoft PowerPoint
- Microsoft OneNote
for testing we will use Word 2016 and Excel for my tests of the feature.
Office Child Process Creation
Lets look at the most common one with some of the most common technique. We will start by enabling the rule via PowerShell for blocking child process creation from the Office products covered by the control by specifying the rule GUID D4F940AB-401B-4EFC-AADC-AD5F3C50688A and enable blocking.
We will try first VBA Shell, this is the simplest of all methods, no fear of loading wshom.ocx and having that flagged by an EDR software.
This technique was blocked as expected.
Next method we will try is using Wscript.Shell COM, this has the unique signature of Office loading the wshom.ocx component.
Wscript.Shell was blocked also.
Since the documentation mentions that it also blocks malicious office Add-Ins here is a very simple one that launches notepad.exe. If the attacker is skilled enough he would not run the risk of launching a process but perform all his actions from .Net until he has measured the maturity level of the target to determine what he can and can not do. This technique is great for persistence when used under the user HKCU registry key since tools like AutoRuns from Sysinternals miss it.
Again ASR blocked the process creation.
Since the rule only monitors for Word, Excel, PowerPoint and OneNote lets try to use the COM technique to have another none covered Office application be the one to launch the process for us. In this case we will have Outlook execute the process.
This technique worked, notepad.exe was launched. Now this technique is not as stealthy as one would think initially. It has the unique aspect that the Outlook process was started with the Embedding switch that we see when an app is automated, not a common occurence in most environments.
Now lets try using WMI to crate the process.
Using WMI worked, it launches the process from wmiprvse.exe so it has a very unique process tree.
Next I tried DDE to get command excution.
{DDEAUTO c:\\windows\\system32\\cmd.exe "/k calc.exe" }
Execution was blocked.
Results of all child process test are in the table bellow:
Process Injection and Win32 API
I will now test Process Injection and Win32 API use by leveraging the macro bellow I generated from Metasploit and modified slightly to bypass the Windows Defender rule for it. The macro leverages several Win32 API calls and injects the payload in to memory
I started by enabling the Process Injection Rule.
This macro injects in to it self I expect given that the wording of the rule is that it will allow execution since the macro is not injecting in to another process. My hunch was proven correct the code worked and calc was launched. The description in the rule is clear but when the default of Cobalt Strike and Metasploit, plus many block post basing themselfs off the research of Diddier Stevens and ScriptJunike inject in such manner I was surprised the scenario was not covered. Sadly I do not have samples in my playbook for injecting in to other processes to test.
Now this should be mitigated by the next rule that prevents the abuse of Win32 API calls in macros.
To enabled the rule we just need to run Add-MpPreference cmlet and specify the appropriate GUID.
When I execute the same file as I did before it is blocked and reported in to the event log. This is a great mitigation to the injection techniques since most rely on Win32 API to achieve their task.
Block Executable Content Creation
The Block Office applications from creating executable content rule will block the creation of Windows Scripting Hosts files, CMD, BAT, EXE, DLL and other file types.
To enabled the rule we just need to run Add-MpPreference cmlet and specify the appropriate GUID.
Once enabled we can test the rule by using the following macro.
Once the macro executes the creation of the VBS script is blocked and the action is logged.
This rule blocks based on file extension. By changing the extension we are able to bypass the rule. When the rule is used with the child process creation rule it can mitigate the creation of a file with a none blocked extension than then is launched by an interpreter.
Conclusion
The ASR rules for Office when combined with each other and with the existing policies for blocking macros limiting access and use to a selected group that need the function mitigates very well the exposure. The rules are not perfect since they can be bypassed but no control in it of it self is infallible. Like any control to mitigate attacks having knowledge of how they can be bypass allows for the building of a layered approached that can alert on malicious behavior. This is why I preferred to look at all this specific rules together.
As always I hope you find the information in the blog post useful.