Should Windows Defender Exploit Guard policies be configured for Windows system files and for files used by other security software(like firewall/av)? I am talking abut per-file policies. Also, is there any list of which mitigations to use for common known processes, like office, browsers, media applications and such?
As the description for Exploit protection explains, "Out of the box, your device is already set up wit the protection settings that work best for most people". This means you don't need to do anything.
The answer is no unless you are systems expect. The same procedures stated for prior EMET setting revisions apply to WDEG. That is each individual app setting must be thoroughly tested prior to being applied in production mode.
That is one of reasons I am asking is there any safelist of what to use/not use for common known applications. I know there were some lists before, in EMET times but they seem to be gone/outdated.
Pretty sure it already knows many of the safe one - especially those Microsoft developed. I personally would not trust or go by any list developed by any 3rd party. If one of your programs is blocked, and if you are 200% sure it is a legitimate program, then you can add/exclude as necessary, when necessary.
The problem with WDEG versus EMET is that in EMET, you would get notification on the desktop when a mitigation feature was triggered; at least in most cases. Such is not the case in WDEG, you have to manually search the Windows event security - mitigations log for such activity.
Could anybody at least give me some example of settings for latest chrome.exe? Seems that most online lists are not compatible with my system and stuff like StackPivot, CallerCheck or SimExec is letting chrome start but blocks all content.
Chrome's own powerful Win32kLockdown filter is what causes all of those mitigations to fail. For those newer mitigations to function, it involves injecting PayloadRestrictions.dll into the process and PayloadRestrictions.dll calls back via Win32k to function, thus causing chrome.exe to crash or at least not load any content or plugins. This is OK with me since I know that Chrome's Win32kLockdown filter is far more powerful and secure in comparison to those payload mitigations. Here is my current working chrome.exe mitigation settings: Code: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\chrome.exe] "MitigationOptions"=hex:11,13,11,01,01,01,10,11,10,00,00,00,00,10,00,00 "MitigationAuditOptions"=hex:00,00,00,00,00,00,20,00,00,00,00,00,00,00,00,00
Thanks Are there any particular concerns that you want to resolve with these rules, or is this simply the list of the mitigations that you found to play well with Chrome?
Could it be possible that those Mitigation Options are computer specific? For me the look different and when I am trying to set similar chain chrome.exe doesn't work. Here are some outdated examples: https://support.microsoft.com/en-us/help/2909257/emet-mitigations-guidelines https://www.chromium.org/Home/chromium-security/chromium-and-emet
What causes process mitigations to trigger can vary from system to system. It can depend on what other security software is installed, whether those are injecting into the chrome.exe processes (or others) and so on. For example, if an antivirus module (dll) is injecting into chrome.exe and is not signed by Microsoft, that would trigger the non-MS signed mitigation to trigger. But there are many other examples as well. Similar to EMET, you need to go one mitigation at a time until you determine which mitigation caused the crash or other symptom. The first and most easy step on latest Windows 10 is to make good use of the Event Log. Open Event Viewer and go to: Applications and Services Logs > Microsoft > Windows > Security-Mitigations: From there, you have Kernel Mode mitgations and User Mode mitigations. Personally, I like to create a Custom View for both of those sub-sections and therefore they will be in the Custom Views section at the top of Event Viewer for quick and easy viewing/sorting. Now, try to reproduce the crash that was caused by a process mitigation and hopefully you should get some good details in the event log to narrow down the problematic mitigation so that you can uncheck that mitigation for the chrome.exe process in WDEG. Most cases show up in those event logs. Give that a try and report back here with your findings and we'll see what caused the problem for you.
You're welcome. Well, luckily Chrome developers already tap into the majority of the best mitigations and opt-in already in their code base. But generally I try to enable the most mitigations as possible without causing any negative effects. For other programs, such as Thunderbird for example, I do the same and enable as much as possible, however, I avoid EAF/EAF+ because of the performance impact. It's not worth it to me. And security/privacy related, such as KeePass, I enable all mitigations as possible but also keep any performance degrading mitigations like EAF as well because it does not affect KeePass so much.
Hey Bill_Bright, question about your last comment "...you can add/exclude as necessary, when necessary." One of our enterprise applications that has a dll hook into any application that needs to be ran as an admin kicks off a mitigation log when ran. "Process '\Device\HarddiskVolume2\Windows\System32\dllhost.exe' (PID 7580) was blocked from loading the non-Microsoft-signed binary '\Program Files\...hook.dll'. For the life of me, I cannot find any documentation that allows me to whitelist the hook.dll file so that Exploit Guard ignores it. Could you elaborate on your process to add/exclude the file from Exploit Guard analysis?
I don't think you can for the Code Integrity Guard mitigation. It is all .dlls must be Microsoft code signed or you disable the mitigation. Believe only select WDEG app mitigations have .dll selection capability: https://www.ghacks.net/2017/10/25/configure-windows-defender-exploit-guard-in-windows-10/
Hmmm, not really as I have never had the WD block anything legit. Did itman's suggestion help? What happens if you go to Virus & threat protection > Virus & threat protection settings > Add or remove exclusions and add your file there.
I don't see how that is possible. Let's refer back to your previous posting: The WDEG mitigation that controls this is Code Integrity Guard: Dllhost.exe running your app as a shell is trying to load your unsigned Microsoft hook.dll into one or more WDEG defined app/s for which the Code Integrity Guard mitigation is enabled. The only way I know of preventing this is to disable the Code Integrity Guard mitigation for every WDEG app that has it enabled which is being injected with the hook.dll. Doing this opens up these apps for .dll injection by malware so be aware of that. Another possibility is your enterprise app has loaded the hook.dll into the AppInit_DLLs registry key. Any .dll loaded there is injected into every running process at boot time. Or is just using the Win API, SetWindowsHook, - most likely - to do so. The WDEG app mitigation that prevents against all these is Disable Extension Points. Again I can't see how .dll specification via PowerShell for Code Integrity Guard would be applicable. Unless there is a command line option like EnableCodeIntegrityGuardMinus -CIGModules dllName1.dll,dllName2.dll? Below is an example of the old EMET EAF+ mitigation where .dlls could be specified as shown below. Also note that .dlls are being specified for the ASR mitigation for IE. Again, this just enables EAF+ and ASR protection at the .dll level for Internet Explorer: BTW - here's the Microsoft ref. on WDEG customization.: https://docs.microsoft.com/en-us/wi...exploit-guard/customize-exploit-protection#t1
