Hardening office with Windows Defender Exploit Guard

Windows_Security

Level 24
Thread author
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Mar 13, 2016
1,298
Exploit Guard Attck Surface Reduction Windows Defender Exploit Guard: Reduce the attack surface against next-generation malware

Exploit Guard per application mitigation Enable or disable specific mitigations used by Exploit protection

Not a discussion on how un-user friendly Microsoft has implemented these mitigations, but a question on what attack vectors remain after applying foolowing tweaks for poisoned OFFICE documents.

Exploit Guard per application mitigation (for Winword, Powerpnt, Excel)
a) Block remote images (Prevents loading of images from remote devices)
b) Code integrity guard (Restricts loading of images signed by Microsoft, WQL, and higher. Can optionally allow Microsoft Store signed images.)
c) Disable extension points (Disables various extensibility mechanisms that allow DLL injection into all processes, such as AppInit DLLs, window hooks, and Winsock service providers.)
d) Do not allow child processes - prefer this one through GUI instead of clunky ps1 script (Prevents an app from creating child processes.)

ASR rules through PS-1 script (run powershell as admin and copy these lines)

# Block Office applications from injecting code into other processes
Add-MpPreference -AttackSurfaceReductionRules_Ids 75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84 -AttackSurfaceReductionRules_Actions Enabled

# Block Office applications from creating executable content
Add-MpPreference -AttackSurfaceReductionRules_Ids 3B576869-A4EC-4529-8536-B80A7769E899 -AttackSurfaceReductionRules_Actions Enabled

# Block JavaScript or VBScript from launching downloaded executable content
Add-MpPreference -AttackSurfaceReductionRules_Ids D3E037E1-3EB8-44C8-A917-57927947596D -AttackSurfaceReductionRules_Actions Enabled

# Block execution of potentially obfuscated scripts
Add-MpPreference -AttackSurfaceReductionRules_Ids 5BEB7EFE-FD9A-4556-801D-275E5FFC04CC -AttackSurfaceReductionRules_Actions Enabled

# Block executable content from email client and webmail
Add-MpPreference -AttackSurfaceReductionRules_Ids BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550 -AttackSurfaceReductionRules_Actions Enabled

# Block Win32 API calls from Office macro
Add-MpPreference -AttackSurfaceReductionRules_Ids 92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B -AttackSurfaceReductionRules_Actions Enabled

Anyone is of-course free to give his opinion, but I hope the techies (like (@cruelsister , @Opcode @Lockdown , @Andy Ful etc) find some time to post their comments also.

Thanks
 
D

Deleted member 65228

I think the new Microsoft features are good and they can definitely help keep an end-point secure, there's no doubt about that. As long as they are used correctly and all work properly. I've not tested them all of course, I've experimented with a few Anti-Exploit features in Windows 10 though.

Used a spoiler so I didn't bloat/hijack the thread, but here's some info/thoughts which might provide insight to those interested. Take with a grain of salt as always.

The Windows modules follow a specific order of which ones are loaded first (always NTDLL.DLL first) and the addresses for NTAPI/Win32 addresses for modules like ntdll.dll, kernel32.dll, user32.dll, etc. only change per session (per boot). Therefore, whether ASLR is forced or not, the address to NtAdjustPrivilegesToken will be the same across all user-mode processes (of the same architecture for compilation) until the next reboot.

E.g.

32bit.exe -> 32-bit compilation -> NtAdjustPrivilegesToken (NTDLL) address will be the same for all other 32-bit compiled images which are ran for that session
64bit.exe -> 64-bit compilation -> same as for 32bit.exe except the address is 64-bit so it isn't valid for the 32-bit processes, but all other 64-bit processes will have the same address to that function (for example) as 64bit.exe

So if an attacker does gain code execution, and he needs to exploit another running process which has ASLR enabled, but the target routines (functions) used for exploitation are part of the Native API/Win32 API, then they can get the address normally, and that address will be valid for the target process as well, as long as the architecture types match.

b) Code integrity guard (Restricts loading of images signed by Microsoft, WQL, and higher. Can optionally allow Microsoft Store signed images.)
If the feature is supposed to block modules from being loaded into the address space of a process unless it follows a specific criteria (e.g. signed by Microsoft), 'manual mapping' the DLL will bypass it. This is why you cannot inject into MicrosoftEdgeCP.exe with common techniques but can still do it with 'reflective' DLL injection.

The reason for this is because the feature won't prevent remote thread creation. It'll try to tackle usage of LoadLibraryA/W or LdrLoadDll/LdrpLoadDll. Which means you can still perform shell-code injection, you just can't "load" a module using normal methods from within the injected code. Manual mapping (aka. reflective loading) doesn't use normal methods for the module loading, it replicates the Windows Loader (Ldr* routines) to do it manually.

# Block Win32 API calls from Office macro
If you can use P/Invoke for the Win32 API then you should be able to do it for NTAPI too. NTDLL is loaded in every user-mode process, it's impossible for a program to function without it (or at-least a manual custom implementation of it - e.g. an emulation of it). So if you can locate the addresses of NT* routines you can re-write Win32 API functions using them and bypass the feature. Although this is 100% unrealistic for Macro's hahahaha.

So unless Microsoft also block NTAPI when they refer to "Win32 API", well thats a flaw right there. But I've not tested with this so I cannot say for certain, so this is speculation.

The only other things I can think of would be Data Execution Prevention and Address Space Layout Randomisation:
1. If malicious code is already active but it needs to attack another process with DEP enabled, it can bypass it without exploitation of ROP chain calls if it can access the target process remotely via APIs like NtAllocateVirtualMemory or NtProtectVirtualMemory.

2. If malicious code is already active but an address which is different for each instance needs to be found (e.g. for a function which has code which exposes a vulnerability -> for exploitation) then pattern scanning will work. But ASLR toughens things up a lot for attackers, as does DEP.
 

Windows_Security

Level 24
Thread author
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Mar 13, 2016
1,298
@Opcode

Thanks for taking the time to explain: is it fair to conclude in layman's term the door is still not fully not closed but opening has become less. In regard to the flood of ransomware send as simple executables or documents with macro's and scripts, exploit guard will stop most of them with these settings.
 

Andy Ful

From Hard_Configurator Tools
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,040
I would also add the 'Network Protection' to Exploit Guard rules (run PowerShell as admin and copy the below line):
Set-MpPreference -EnableNetworkProtection Enabled
It can be disabled via:
Set-MpPreference -EnableNetworkProtection Disabled
.
Network protection works as SmartScreen for Edge, but now the capabilities are extended to any application.
So, if the malicious script is going to download something from the malicious website, it can be blocked by SmartScreen. This works in a similar way as the WebShield module in other AVs.
ASR is the first step on the long way to fight macros/scripts/scriptlets. In the present form, it can be bypassed:
Windows Defender Exploit Guard ASR Rules for Office
Windows Defender Exploit Guard ASR Obfuscated Script Rule
Windows Defender Exploit Guard ASR VBScript/JS Rule
 
Last edited:

Windows_Security

Level 24
Thread author
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Mar 13, 2016
1,298
@Andy Ful Thx for the tip (adding Network protection)

Incredible performance (typing from my Asus Transformer with only Intel Z3750 CPU with 2 GB RAM)

Windows 8.1 naked (SRP Basic User, UAC blocking unsigned elevation, ACL deny execute except TEMP)
C:\Program Files\Chromium\chrome.exe - 5 executions
3.2885
1.3846
1.3553
1.3487
1.3608

Windows 10 with Windows Defender Exploit Guard, Controlled folder access (SRP Basic user + UAC block unsigned elevation + Smartscreen) no noticeable and measured delay (as AppTimer results below show)
C:\Program Files\Chromium\chrome.exe - 5 executions Windows 10 With Windows Defender
3.1048
1.2868
1.3406
1.3211
1.3671
 
Last edited:

Andy Ful

From Hard_Configurator Tools
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,040
I think that Exploit Guard settings for the concrete application can be applied and transferred to other computers by using the REG file. For example, the below Reg file will block wscript.exe from creating the child processes:
Code:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\wscript.exe]
"MitigationOptions"=hex:00,00,00,00,00,00,00,00,00,00,00,00,10,00,00,00
"MitigationAuditOptions"=hex:00,00,00,00,00,00,00,00,00,00,00,00,20,00,00,00
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\wscript.exe]
"MitigationOptions"=hex:00,00,00,00,00,00,00,00,00,00,00,00,10,00,00,00
"MitigationAuditOptions"=hex:00,00,00,00,00,00,00,00,00,00,00,00,20,00,00,00
.
The above mitigation alone blocked all my VBS test trojan-downloaders, which easily bypassed ASR and OSArmor.:)
The same mitigation could be applied for cscript.exe, powershell.exe, mshta.exe, etc.
 
Last edited:
5

509322

Anyone is of-course free to give his opinion, but I hope the techies like @Lockdown respond

Not using Microsoft Office is the most effective anti-exploit for Microsoft Office exploits. Reducing attack surface is the most effective anti-exploit method.

So the best security is not to use Microsoft Office. It is very heavily targeted. If you have to use it, it's common sense - don't use macros - and use all the new security features. Unfortunately, Microsoft does not document all of the security features nor does it make every one of them easy to enable - which is typical M$ - which takes me back to my initial statement - don't use Microsoft Office !

Exploit Guard should curl the toes of anyone who is into spending days, weeks and months researching how to configure it; much the same as EMET.

Average Joe is better served and protected by using Chromebook. Chromebook with Chrome OS and Apple's OSes are the only ones what were developed with the perspective of the average Joe truly in mind.

PS - I mess with Microsoft Office in so far as I have to test it for compatibility with our product. Other than that, it represents a needless and completely avoidable high security risk. I do not use it on my personal systems. There are equally capable options that provide better value on the market.

I have spent 0 minutes messing with Exploit Guard because I immediately knew when I looked at it that its implementation was a mess - and I don't have time to sort out another one of Microsoft's messes. So perhaps someday I will come back to a thread like this where users have spent hours to spell it out for others and study how to enable Exploit Guard protections, but it will probably be years, and hopefully by then Microsoft will have fixed its mess - although I doubt it because we all know how MS does it. I say perhaps, because I do not worry about exploits, because I have half of Windows disabled anyway...
 
Last edited by a moderator:
5

509322

Anyone who is willing to learn and do manual configuration of Windows, you can greatly increase Windows security. Windows security can be hardened to a very high level. You have to make Windows security using this model a priority. You don't need 3rd-party security softs to do it. You need knowledge - and therein lies the really BIG rub.

The problem is that perhaps 1 out of 10,000 people are willing to put in the time and effort to learn Windows and Microsoft programs using their own built-in security features. In other words, security soft geeks are rare beasts seen occasionally on security soft forums.

One of my chief complaints with Microsoft has always been their practice of not documenting anything - which makes knowledge gathering and transfer quite difficult. Plus, there is absolutely nothing intuitive about Windows security.

Like I always say, there is no substitute for user learning and knowledge.
 

Handsome Recluse

Level 23
Verified
Top Poster
Well-known
Nov 17, 2016
1,242
I would also add the 'Network Protection' to Exploit Guard rules (run PowerShell as admin and copy the below line):
Set-MpPreference -EnableNetworkProtection Enabled
Where'd you get that?
I just configured one app, exported, copy paste configuration for other programs using Notepad and imported with
Set-ProcessMitigation -PolicyFilePath *\Settings.xml
No problems so far.
 
  • Like
Reactions: Sunshine-boy

Handsome Recluse

Level 23
Verified
Top Poster
Well-known
Nov 17, 2016
1,242
<AppConfig Executable="firefox.exe">
<StrictHandle Enable="true" OverrideStrictHandle="false"></StrictHandle>
<ExtensionPoints DisableExtensionPoints="true" OverrideExtensionPoint="false"></ExtensionPoints>
<SignedBinaries EnforceModuleDependencySigning="true" OverrideEnforceModuleDependencySigning="false"></SignedBinaries>
<Fonts DisableNonSystemFonts="true" AuditOnly="false" OverrideFontDisable="false" Audit="false"></Fonts>
<ImageLoad BlockRemoteImageLoads="true" OverrideBlockRemoteImageLoads="false" BlockLowLabelImageLoads="true" OverrideBlockLowLabel="false" AuditRemoteImageLoads="false" AuditLowLabelImageLoads="false"></ImageLoad>
<Payload EnableExportAddressFilter="true" OverrideExportAddressFilter="false" AuditEnableExportAddressFilter="false" EnableExportAddressFilterPlus="true" OverrideExportAddressFilterPlus="false" AuditEnableExportAddressFilterPlus="false" EnableImportAddressFilter="true" OverrideImportAddressFilter="false" AuditEnableImportAddressFilter="false" EnableRopStackPivot="true" OverrideEnableRopStackPivot="false" AuditEnableRopStackPivot="false" EnableRopCallerCheck="true" OverrideEnableRopCallerCheck="false" AuditEnableRopCallerCheck="false" EnableRopSimExec="true" OverrideEnableRopSimExec="false" AuditEnableRopSimExec="false"></Payload>
</AppConfig>

Here's a snippet of my exported config. This can be copy-pasted for other programs by replacing the executable name -- then import through Powershell.
 

About us

  • MalwareTips is a community-driven platform providing the latest information and resources on malware and cyber threats. Our team of experienced professionals and passionate volunteers work to keep the internet safe and secure. We provide accurate, up-to-date information and strive to build a strong and supportive community dedicated to cybersecurity.

User Menu

Follow us

Follow us on Facebook or Twitter to know first about the latest cybersecurity incidents and malware threats.

Top