Advice Request Windows Defender's Attack Surface Reduction (ASR) Rule Tests

[Eddie Morra]

Hiya

I've decided to come back to testing Windows Defender's Attack Surface Reduction (ASR) feature - which is part of the Exploit Guard component - and I've created this thread to share my testing results for various rules as and when I have time to prepare and run a test for them. I'll test as many of them as I can because the documentation is extremely bland in terms of explaining how they actually work, and reverse-engineering how the internals of the different rule implementations work to conduct a proper and reliable test can be very time-consuming and tricky when they aren't all grouped together under the same components.

Please do note that this is not based on insider knowledge. I do not have any insider knowledge from Microsoft (e.g. Windows Defender Team) to help me conduct these tests. The testing is based on personal and manual research/trial and error. Due to this, you should take everything with a grain of salt, because it is very easy for a mistake to be made. Do not assume that any information presented to you under this thread by me is 100% accurate because there's no guarantee that this is the case. It is vital that you remember that the implementations of ASR rules internally are subject to change at any time through Windows/Office updates (as has been the case numerous times in the past - I've seen rules completely change over time with my own eyes), so always bear that in mind.

Before jumping into the tests, I will mention the specifications of my testing environment and how I am enabling these ASR rules, because this information may be important to other people (or help them replicate if they are capable of doing so).

Prerequisite information
​

Testing environment: Windows 10 Professional (version 1803) with no third-party security software installed. Windows Defender is enabled for real-time protection and has not had any configuration changes except for the ASR rules. I will re-test on Windows 10 Professional (version 1809) in a few weeks time and notify if any changes to the tests I am conducting now are present.

I'm using Office 365 (based on the 2016 version) as a subscribed Business customer.

I am enabling the rules through the Group Policy Editor (type in "gpedit.msc" without "" in the Windows Run box (Windows Key + R) to open it). You will not have access to the Group Policy Editor by default if you're a Windows 10 Home user, however there is a way to install it... This won't be covered here for obvious reasons though.

Group Policy Editor -> Computer Configuration -> Administrative Templates -> Windows Components -> Windows Defender Antivirus -> Windows Defender Exploit Guard -> Attack Surface Reduction -> Configure Attack Surface Reduction rules. All rules which are configured have the value of "1" to block.

Test 1
"Block Win32 API calls from Office macro"
​

The GUID for this ASR rule is 92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B.

This test is undoubtedly going to be one of the simplest but at the same time, it is one of the most important. 9 times out of 10, an Office VBA macro which is genuine and is not up to no good, is not going to need to be dependent on the Win32 API - this figure isn't from statistics, it is completely opinionated, so bear this in mind. The fact of the matter is, it isn't uncommon for malicious macro's to be dependent on the Win32 API... it is prevalent for malicious macro's. The reason for this is simple: the Win32 API provides the ability for a malicious macro to do a number of things from general process, file-system, registry and even networking management, among more. It's a no-brainer for malware authors who are relying on an Office VBA macro.

If we take a look at a recent blog post from the Windows Defender Team, we can actually see that a malicious macro they are using for analysis is using the Win32 API (as a demonstration of what I'm talking about).

Source:
Office VBA + AMSI: Parting the veil on malicious macros - Microsoft Secure %

The NtAllocateVirtualMemory routine which is being imported is from NTDLL and is part of the "Native API" (NTAPI). However, the WriteProcessMemory and EnumSystemCodePagesW routines are part of the "Win32 API".

In the past when I've tested this ASR rule, it was dynamic-based as opposed to static-based. This means that it was blocking the Win32 API calls as they were attempted whilst the Office VBA Macro script was being executed by the interpreter... but this is not the result of the test I've just conducted. It would appear that in the recent months, this ASR rule has been modified internally. I cannot get this ASR rule to block Win32 API calls dynamically at all anymore, I can only get it to block access to the Microsoft Office document containing the macro script which imports Win32 API routines.

The test for this ASR rule is incredibly simple and I will outline the testing process in bullet-point form to make it easy for readers to follow.

1. Create a new Microsoft Office document (I am using Microsoft Word for this test).
2. After the new document has been created, press the Alt key + F11 at the same time to open Microsoft Visual Basic for Microsoft Office.
3. At the top of the window -> Insert -> User Form.
4. Double-click on the form to move into the code-view and you'll automatically have a private subroutine named "<FormName>_Click" generated for you. You can ignore this because it isn't required for the test.
5. Outside of the private subroutine, import a Win32 API routine from a module like kernel32.dll or kernelbase.dll.
6. Save and close down the Visual Basic window.
7. Save the Microsoft Office document with the extension of *.docm.
8. Close down the Microsoft Office application you're using for the test.

All you need to do after following the above steps is to enable the ASR rule. Once the ASR rule has been enabled, re-open the document you saved earlier and Windows Defender should intervene by blocking access to the document and alerting you with a Windows 10 toast notification to inform you that the activity has been blocked. Note, Windows Defender isn't going to automatically rid the test document... or at-least it shouldn't do this. It's happened to me in the past but not during this test.

If you want an example of code you can put into a macro script to test this, you can copy-paste the below.

Private Declare PtrSafe Function OpenProcess Lib "kernel32" (ByVal DesiredAccess As Long, ByVal InheritHandle As Long, ByVal ProcessId As Long) As Long

You do not need to actually call the imported routine, the import just has to be present.

Screenshots:

Spoiler: Kernel32/KernelBase note.

Bear in mind, kernelbase.dll was introduced starting Windows 8, and was a replacement for holding some of the kernel32 API routines (among newer ones). For compatibility reasons, kernel32.dll routines which are now implemented under kernelbase.dll are just wrappers for calling the kernelbase.dll versions.

I think it is safe to conclude after this test that this ASR rule relies on a static macro script scanner as opposed to functioning dynamically now - in the past I recall it blocking the Win32 API calls instead of just throwing no access to the document. Beforehand, I was testing dynamically by injecting code into winword.exe which would do various things with the Win32 API, and I also tried enabling ASR and then creating a new document which would use the Win32 API from within a macro script, but it won't block the activity dynamically anymore. As of right now, I can only get it to block the entire document on open/saving when a macro is included which supports the Win32 API usage.

Thread post ending​

Test 2: Discuss - Windows Defender's Attack Surface Reduction (ASR) Rule Tests

I'm sure other members will have things to add in the comment discussion here about their own testing because I'm not the only person here who has tested/is testing ASR rules - please feel free to share and discuss ASR in the comments whether it be about testing or in general. For when I add new tests, I'll just post it as a new post on the thread.

Cya

 

[Local Host]

You will not have access to the Group Policy Editor by default if you're a Windows 10 Home user, however there is a way to install it... This won't be covered here for obvious reasons though.

I strongly advise against this as it causes more issues than not, users on Windows 10 Core should use regedit and/or powershell.

 

[oldschool]

It's great that you're doing this testing to shed a bit of light on the murky world of MS and WD. Your work is also a great addition for MT!

 

[Eddie Morra]

Hiya

Test 2
"Block Office applications from injecting code into other processes "​

The GUID for this ASR rule is 75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84.

The purpose of this ASR rule is to prevent Office applications from being able to perform Remote Code Execution (RCE) operations.

I hope to conduct several different tests for this ASR rule to understand more about where it draws the line between what it can or cannot prevent, however for the first test on this ASR rule, I'll be relying on a file-less injection attack towards another process running on the environment.

I will outline the stages of the file-less injection attack below, but will not be providing source code to replicate for obvious reasons.

1. Initialize dynamic imports for NtClose (NTDLL), NtOpenProcess (NTDLL), NtQuerySystemInformation (NTDLL), NtProtectVirtualMemory (NTDLL), NtReadVirtualMemory (NTDLL) and NtWriteVirtualMemory (NTDLL). For locating the base address of NTDLL under the virtual memory of the current process (which would have been winword.exe), access to the _PEB structure and then enumerating through the linked list of loaded modules was performed manually. For locating the addresses of the exported routines which were needed, a custom EAT scanner was used over using the Win32 API.
2. NtQuerySystemInformation was used with the SystemProcessInformation class to enumerate a list of the running processes on the environment. This was done to find the Process Identifier (PID) of the process which will be targeted for the RCE attack (I targeted notepad.exe for testing purposes).
3. The address for NtRemoveIoCompletionPort (NTDLL) under the virtual address space of the current process was retrieved using the same module handle to NTDLL which was manually acquired earlier and the custom EAT scanner. This is going to be used during the RCE attack against notepad.exe. The testing environment was Windows 64-bit and the Office 365 installation is also 64-bit which means winword.exe and notepad.exe were both 64-bit, and thus the base address of NTDLL under their own virtual address space will be the same, because Windows modules only have Address Space Layout Randomization (ASLR) on a per-session basis (meaning all 32-bit processes have the same base address in their own VM for the Windows modules and the same applies for 64-bit processes and the Windows modules). Due to this, the address to NtTerminateProcess (NTDLL) for winword.exe will be valid for notepad.exe as well.
4. A process handle to notepad.exe was acquired through the use of NtOpenProcess whilst specifying the PROCESS_ALL_ACCESS flag for the DesiredAccess (ACCESS_MASK) argument.
5. The memory access protection at the address of NtRemoveIoCompletionPort under the virtual address space of notepad.exe was changed to PAGE_EXECUTE_READWRITE through the use of NtProtectVirtualMemory.
6. The first four bytes at the address of NtRemoveIoCompletionPort under the virtual address space of notepad.exe was changed to 0xC3, 0x90, 0x90, 0x90 which means at the disassembly you'll find RET NOP NOP NOP. The memory manipulation was performed via NtWriteVirtualMemory.
7. Even if the NTSTATUS error code was STATUS_SUCCESS from NtWriteVirtualMemory, the NtReadVirtualMemory routine was used to retrieve the first byte at the address of NtRemoveIoCompletionPort under the virtual address space of notepad.exe to check that it really is now 0xC3.
8. The memory access protection at the address of NtRemoveIoCompletionPort under the virtual address space of notepad.exe was changed back to its original value (which was stored earlier for future reference).
9. The process handle to notepad.exe was now no longer needed and was closed with NtClose.

If everything was successful (including the NtReadVirtualMemory check) then a message will be displayed to confirm this. If anything failed, an error message will be displayed to confirm this. Originally, during testing, I was checking through debugging, but after confirming that everything does work when the ASR rule is disabled and fails to work when the ASR rule is enabled, I decided there was no need to keep repeating this and to just display a message for testing quickly in the future.

Just to be clear, the injected shell-code is pointless. The only point to the patch was to confirm that the memory manipulation can be made remotely and that is all there is to the test.

When the ASR rule is disabled:

I will now enable the ASR rule and do a re-test to confirm if the RCE attack still works or not.

After enabling the ASR rule, the call to NtProtectVirtualMemory fails with the NTSTATUS error code of 0xC0000022 which is for STATUS_ACCESS_DENIED. To put this in English, the operation is being blocked by Windows Defender's Exploit Guard (Attack Surface Reduction) component.

We never actually reach the stage of calling NtWriteVirtualMemory, because we cannot even unprotect the memory at the target so the call would not be successful (since the original memory access protection at the address we are targeting does not permit write access yet, only Read and Execute access). However, if you do choose an address which has the correct memory access protection for you already, the call to NtWriteVirtualMemory will still fail. NtAllocateVirtualMemory will also fail.

We could still obtain a handle to notepad.exe with sufficient access rights to use the handle with virtual memory operation NTAPI routines, we just couldn't have those virtual memory operations carried out by the Windows kernel. The operations were blocked and the ability to perform the RCE attack successfully was taken away from us.

We can confirm that the NtProtectVirtualMemory (NTDLL) routine was not patched by Windows Defender by checking the disassembly of the routine, and we can even set a break-point to ensure we reach the system call stub.

We only had to check for a patch at the address of the routine in-memory because we know that Import Address Table (IAT) and Export Address Table (EAT) had not been modified to intercept the routine we are checking. Even if the IAT had been modified, it wouldn't have affected us because we were relying on dynamic imports, and we know the EAT hadn't been touched because the address being used in the dynamic import was authentic (resided under NTDLL) and had the real system call stub at the address in-memory.

Windows Defender's Exploit Guard component is blocking the RCE attack from a kernel-level - they've implemented the security feature under the kernel routines from ntoskrnl.exe. System calls will not bypass the rule because Windows Defender isn't relying on user-mode patching techniques to prevent the RCE attack, it's returning STATUS_ACCESS_DENIED during the execution flow of the virtual memory operation at a kernel-level.

I think it is safe to conclude that Windows Defender's Exploit Guard for Attack Surface Reduction is not just static-based like some of the rules (e.g. the Win32 API blocking rule which I tested yesterday - the results are in the original post - was based on static scanning methods unlike in the past) and is neither only user-mode based as we can see from the research of this test.

さようなら!

 

[LDogg]

Great test! And very informative.

~LDogg

 

[Andy Ful]

If you were not a lady, I might think that you are a grown-up incarnation of @kram7750 / @Wave
Sadly, he is absent on MT for some time.
I wish, he will be back soon to discuss some topics with you.

 

[Eddie Morra]

If you were not a lady, I might think that you are a grown-up incarnation of @kram7750 / @Wave
Sadly, he is absent on MT for some time.
I wish, he will be back soon to discuss some topics with you.

The profile is wrong, I'm a Male hahahaha.

I'll just admit it once and for all... this is a grown-up incarnation of 7750 / @Wave / @Opcode (NtOpcode)

I don't know how long I'll be back for though before I disappear - since I am trying to go into something non-computing related for career - but I am back for the time being.

 

[shmu26]

Wave, you are better than ever. Please stay around. I don't remember you doing testing like this before. All I remember is the long explanations that are over my head

 

[Andy Ful]

The profile is wrong, I'm a Male hahahaha.

I'll just admit it once and for all... this is a grown-up incarnation of 7750 / @Wave / @Opcode (NtOpcode)

I don't know how long I'll be back for though before I disappear - since I am trying to go into something non-computing related for career - but I am back for the time being.

Hi my friend, you are better than ever.

Edit.
I did not even notice that I replicated a part of @shmu26 post.:notworthy:

 

[Andy Ful]

Here is Vendula Kubova and @Wave.

It looks like a Baltic beach. Welcome back ... and stay for a while.:emoji_ok_hand:

 

[shmu26]

I have the Baltic beach for my desktop background. No kidding. But without humans...

 

[Eddie Morra]

Hiya

Test 3
"Block untrusted and unsigned processes that run from USB"​

The GUID for this ASR rule is b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4.

This rule works by preventing Office VBA Macro's from using non-trusted or unsigned content which is being stored on removable media (such as a USB or an external HDD/SSD and other types of removable media). The official documentation has a few words about this rule and I'll be relying on the information for the test I am conducting for this rule.

Rule: Block untrusted and unsigned processes that run from USB
With this rule, admins can prevent unsigned or untrusted executable files from running from USB removable drives, including SD cards. Blocked file types include:

• Executable files (such as .exe, .dll, or .scr)
• Script files (such as a PowerShell .ps, VisualBasic .vbs, or JavaScript .js file)

The documentation does not explain what constitutes as "trusted" or "untrusted", but it does provide insight into the applicable file extensions that are covered by this rule (e.g. Portable Executable's and scripts).

I will be doing a different test with this rule in the near future but to kick-start testing of this rule, I'll be using an unsigned Win32 PE which I created myself (it does nothing but print text on the console window with printf).

I will not be using an Office VBA Macro for this first test because I have a little trick which simplifies things for me (since I am not a fan of programming with VBA). I am embedding the test under a native DLL which is written in C and then I am injecting this DLL into winword.exe (Microsoft Word main process) and having the test initiated by the DllMain entry-point routine. The Office VBA Macro's are processed under winword.exe as well, and I have confirmed that this works perfectly fine for testing this ASR rule (I have already tested it before writing this up) so this test is not bogus because of this.

The steps for the test are as follows.

1. I have inserted removable media and copied over a Win32 PE to it named "TotallySignedWin32.exe".
2. I am forcing winword.exe to call the CreateProcessW (Kernel32 -> KernelBase) Win32 API routine to spawn a new process where the process's image is TotallySignedWin32.exe from the removable media.
3. I am showing an alert under winword.exe through the MessageBoxW (Kernel32) Win32 API routine to notify the success status of the process creation operation.

Spoiler: Source code

The source code for the compiled code I am having ran on a new thread under winword.exe is below; it's a really small and simple snippet.

BOOL
UsbTrustTestsUnsigned()
/*++

Routine Description:

    Creates a new process using an unsigned Win32 PE (located on removable media)
    as the target.

Arguments:

    None.

Return Value:

    BOOL

        TRUE - the process was successfully created.

        FALSE - the process could not be created, call GetLastError
                      for more information on why the operation failed.

Remarks:

    The Win32 PE target is hard-coded.

References:

    https://docs.microsoft.com/en-us/windows/desktop/api/processthreadsapi/nf-processthreadsapi-createprocessa

--*/
{
    BOOL BlStatus = FALSE;
    WCHAR FileName[26] = L"D:\\TotallySignedWin32.exe";
    STARTUPINFO StartupInformation = { 0 };
    PROCESS_INFORMATION ProcessInformation = { 0 };

    memset(&StartupInformation,
        0,
        sizeof(STARTUPINFO));

    memset(&ProcessInformation,
        0,
        sizeof(PROCESS_INFORMATION));

    //
    //    Create a new process for the unsigned Win32 PE.
    //
    BlStatus = CreateProcess(FileName,
        NULL,
        NULL,
        NULL,
        FALSE,
        0,
        NULL,
        NULL,
        &StartupInformation,
        &ProcessInformation);

    return BlStatus;
}

Simple, quick and effective. Straight to the point. No beating around the bush.

I will inject the DLL into winword.exe to have my test routine called to confirm that winword.exe successfully spawns the process with the unsigned Win32 PE image.

I will now enable the ASR rule through Group Policy Editor which will make the registry change for me automatically. Afterwards, I will restart winword.exe and repeat the test.

Windows Defender successfully intervened with the process creation attempt and prevented it from happening. We can see that this rule at-least works for Win32 PE images and process creation... but there's still something unclear about how this rule works. Is it being enforced from user-mode or kernel-mode? I'm very much interested in finding out and I am going to do exactly that. It doesn't have to stay a secret for me to burden, we can all find out!

There's a very easy way to find out if this operation is being blocked from a user-mode or kernel-mode level. When we call the CreateProcessW (Kernel32 -> KernelBase) Win32 API routine, it eventually leads to an undocumented routine named CreateProcessInternalW (KernelBase). This routine will call a routine exported by NTDLL named NtCreateUserProcess, which performs a system call to get the Windows kernel to call the real NtCreateUserProcess (NTOSKRNL). All we need to do is check if the NtCreateUserProcess system call stage is being reached... because if it isn't, then it means someone (Windows Defender) is intervening before this point, which would confirm that this rule works from a user-mode level.

All we need to do is use WinDbg to accomplish this. We can attach to winword.exe and set a break-point at NtCreateUserProcess (NTDLL). If the break-point hits when we continue and have our own code ran under a thread in winword.exe, as long as the disassembly at the address of NtCreateUserProcess all matches as it should, then it means the operation is being blocked by Windows Defender from a kernel-level.

1. I've started up the 64-bit version of WinDbg.
2. View -> Disassembly to open the Disassembly window.
3. Located the Disassembly for ntdll!NtCreateUserProcess.
4. Used the "bu" command to set a break-point at ntdll!NtCreateUserProcess.
5. Injected the code into winword.exe to trigger the process creation operation to see whether the break-point was hit before Windows Defender managed to intervene.

To add to the suspense, I will let you all know... I do not know the outcome of this yet. I decided to add this as a bonus and so I hadn't prepared for it, I was just curious and decided to do it at the same time as writing this test up.

Would you look at that! The break-point is successfully hit. The instructions at the address of ntdll!NtCreateUserProcess have not been modified by Windows Defender at all, they are exactly as they are supposed to be.

I decided to "Step Into" with F11 (you can also use F8) past the SYSCALL instruction and as soon as the system call fired off for the process creation operation, Windows Defender intervened.

This confirms that Windows Defender is blocking the operation from a kernel-mode level and not a user-mode level. It is important to remember that this may not always be the case (e.g. depending on how the rule is being tested), although I suspect it will be for the remainder of the tests I decide to do with this rule (and believe me, there will be more).

My suspicion is that Windows Defender is blocking this operation through the PsSetCreateProcessNotifyRoutineEx kernel-mode callback. I do know that Windows Defender uses this callback for real-time process scanning (e.g. on-execution scanning) and it would be more than applicable for the implementation of this ASR rule for the process creation scope. For the module loading scope (since this rule also includes prevention of Office VBA Macro's from loading and using non-trusted/unsigned modules), I suspect they'd be using PsSetLoadImageNotifyRoutine/Ex if that is also integrated from a kernel-mode level... but we can talk more about that when we conduct that test in the future.

Bear in mind, my suspicion on how this rule is being integrated is speculation.

Before I sign off on this post, I do happen to have some juicy intelligence which may be interesting to some. While writing this review and re-testing several times to make the screenshots, I actually found out one of the factors which determines whether a Win32 PE is "trusted" or not. It's possible it was a bug with the ASR rule because the Win32 PE was still not digitally signed, however, I noticed that if I ran the application X (X is an unknown number of times because I wasn't counting and it was randomly found but let's go with the number 10+), that Windows Defender would not block it even though it should have when the ASR rule was enabled. Therefore, it is possible that this rule will ignore the digital signature status (e.g. unsigned or not) if it believes the PE image is "trusted" (e.g. has been ran on the environment many times before). I'll need to look into this more to confirm these findings, so take all of it with a grain of salt for now, just in case it was a fault on my part and not Windows Defender's.

That's all for this test... Next time I test this ASR rule, I'll be looking into how it behaves with script and unsigned module testing.

Cya

 

[shmu26]

Pretty interesting about the run 10+ times! Makes sense, though.

 

[Andy Ful]

...
Therefore, it is possible that this rule will ignore the digital signature status (e.g. unsigned or not) if it believes the PE image is "trusted" (e.g. has been ran on the environment many times before).
...

When I tested another ASR rule "Block executable files from running unless they meet a prevalence, age, or trusted list criteria", I noticed that if the file was executed once (WD real-time protection had to be turned ON), then the rule has always allowed the execution. If the real-time protection was off when executing the file, then after activating the real-time protection the ASR rule could still block the execution. So, ASR can also check the execution history for other rules, as well.

 

[Eddie Morra]

When I tested another ASR rule "Block executable files from running unless they meet a prevalence, age, or trusted list criteria"

There's hardly any documentation on this one. I've been trying to locate where it is (e.g. under which component) but no luck so far. I saw some people asking about it on the MSDN documentation comments/feedback area, but the replies were cryptic and didn't actually explain what the askers were after (which was more information on how the prevalence/age/trusted list criteria is determined).

Apparently, administrators can also specify rules for determining those factors, but... no documentation on how to do it if it is actually possible.

 

[Andy Ful]

If I will have some time, I will try to use Sysinternals Process Monitor, to find out which registry keys are queried when this rule is active. But, this will be probably hard work and time-consuming.

 

[Eddie Morra]

If I will have some time, I will try to use Sysinternals Process Monitor, to find out which registry keys are queried when this rule is active. But, this will be probably hard work and time-consuming.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender\Windows Defender Exploit Guard\ASR\Rules -> 01443614-cd74-433a-b99e-2ecdc07bfc25

I'm going to check some Windows Defender components and see if it references the key for that rule at all via registry operations... if I can find evidence of this via reverse-engineering then I can get more insight into where it is used and how it is used.

EDIT:
Good news, made some progress. Baby steps...

 

[Andy Ful]

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender\Windows Defender Exploit Guard\ASR\Rules -> 01443614-cd74-433a-b99e-2ecdc07bfc25

I'm going to check some Windows Defender components and see if it references the key for that rule at all via registry operations... if I can find evidence of this via reverse-engineering then I can get more insight into where it is used and how it is used.

EDIT:
Good news, made some progress. Baby steps...

There can be also some new keys available under the:
HKLM\SOFTWARE\Microsoft\Windows Defender\Windows Defender Exploit Guard\ASR
HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Windows Defender Exploit Guard\ASR
for configuring this rule or other rules.