E
Eddie Morra
I've been re-testing Attack Surface Reduction today but it seems the internals have changed since last time I tested it.
The rule for "Block Win32 API calls from Office macro" (92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B) is working differently for me now than as it did in the past.
The past behaviour I spectated was the Win32 API call being blocked dynamically, but this is no longer the case on my testing environment.
The new behaviour I am spectating is the Microsoft Office document having its access blocked by Windows Defender with a toast notification informing me of this block. It would appear that this rule now works by scanning any macro scripts under the document to determine if they are trying to introduce access to any Win32 API routines and are just rejecting the access to the document to winword.exe/other Microsoft Office processes if a Win32 API routine import is detected.
It's only been a few months since I last tested, I do not know why the behaviour is different compared to last time. I actually enabled the rule before making the PoC document, and then ran the PoC document on the testing environment, but the Win32 API calls were successful - to be precise, I was testing an OpenProcess (KernelBase.dll) call to open a handle to notepad.exe. However, when trying to close the document, Windows Defender then kicked in and blocked access to save the document, indicating that the ASR rule was kicking in and working, and that they simply block access to the document with a macro script scanner instead of bothering to intercept and block the Win32 API calls for this ASR rule.
My testing environment is Windows 10 Professional (1803) with no other security software in the way except from Windows Defender.
The rule for "Block Win32 API calls from Office macro" (92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B) is working differently for me now than as it did in the past.
The past behaviour I spectated was the Win32 API call being blocked dynamically, but this is no longer the case on my testing environment.
The new behaviour I am spectating is the Microsoft Office document having its access blocked by Windows Defender with a toast notification informing me of this block. It would appear that this rule now works by scanning any macro scripts under the document to determine if they are trying to introduce access to any Win32 API routines and are just rejecting the access to the document to winword.exe/other Microsoft Office processes if a Win32 API routine import is detected.
It's only been a few months since I last tested, I do not know why the behaviour is different compared to last time. I actually enabled the rule before making the PoC document, and then ran the PoC document on the testing environment, but the Win32 API calls were successful - to be precise, I was testing an OpenProcess (KernelBase.dll) call to open a handle to notepad.exe. However, when trying to close the document, Windows Defender then kicked in and blocked access to save the document, indicating that the ASR rule was kicking in and working, and that they simply block access to the document with a macro script scanner instead of bothering to intercept and block the Win32 API calls for this ASR rule.
My testing environment is Windows 10 Professional (1803) with no other security software in the way except from Windows Defender.