Process Mitigation Management Tool

I assume that this would be for all SKUs with regard to the process mitigations. This GUI implementation within Windows Defender Security Center is still incomplete but so far appears to be added to the App & Browser control tab below the SmartScreen settings. The VBS (virtualization based security) such at Windows Defender Application Guard seems to be Enterprise only though, as far as I know. I think that would be a big mistake for Microsoft to withhold some of these modern security protections from home users as well.

 

Here is what is in the latest insider update I installed yesterday. But when you click on customize you can look at second screen shot.

 

Here are some process mitigations for 64-bit Firefox users on 64-bit Windows 10.

Spoiler: settings.xml

Code:

<?xml version="1.0" encoding="UTF-8"?>
<MitigationPolicy>
  <AppConfig Executable="firefox.exe">
    <DEP Enable="true" DisableATL="false" />
    <ASLR BottomUp="true" ForceRelocate="true" HighEntropy="true" DisallowStripped="true" />
    <StrictHandle RaiseExceptionOnInvalid="true" HandleExceptionsPermanently="true" />
    <SystemCall DisallowWin32kSysCalls="false" />
    <ExtensionPoint DisableExtensionPoints="true" />
    <DynamicCode ProhibitDynamicCode="false" AllowThreadOpt="false" AllowRemoteDowngrade="false" />
    <CFG EnableCFG="false" EnableExportSuppression="false" StrictMode="false" />
    <BinarySignature MicrosoftSignedOnly="false" StoreSignedOnly="false" MitigationOptIn="false" />
    <FontDisable DisableNonSystemFonts="true" AuditNonSystemFontLoading="false" />
    <ImageLoad NoRemoteImages="true" NoLowMandatoryLabelImages="true" PreferSystem32Images="true" />
  </AppConfig>
  </MitigationPolicy>

Or IFEO MitigationOptions registry hex value: 1111000101110101

 

And now for some real "meat and potatoes"...


Fortifying Google Chrome / Chromium Based Browsers
* Tested on Windows 10 Creators Update (64-bit) with 64-bit Chromium

Spoiler: settings.xml

Code:

<?xml version="1.0" encoding="UTF-8"?>
<MitigationPolicy>
<AppConfig Executable="chrome.exe">
<DEP Enable="true" DisableATL="false" />
<ASLR BottomUp="true" ForceRelocate="true" HighEntropy="true" DisallowStripped="true" />
<StrictHandle RaiseExceptionOnInvalid="true" HandleExceptionsPermanently="true" />
<SystemCall DisallowWin32kSysCalls="false" />
<ExtensionPoint DisableExtensionPoints="true" />
<DynamicCode ProhibitDynamicCode="false" AllowThreadOpt="false" AllowRemoteDowngrade="false" />
<CFG EnableCFG="true" EnableExportSuppression="true" StrictMode="true" />
<BinarySignature MicrosoftSignedOnly="false" StoreSignedOnly="false" MitigationOptIn="false" />
<FontDisable DisableNonSystemFonts="true" AuditNonSystemFontLoading="false" />
<ImageLoad NoRemoteImages="true" NoLowMandatoryLabelImages="true" PreferSystem32Images="true" />
</AppConfig>
</MitigationPolicy>

Process Mitigations would be applied via the Set-ProcessMitigation -PolicyFilePath settings.xml command and verified via Get-ProcessMitigation -Name chrome.exe command to verify settings via Registry settings or via Get-Process chrome | Get-ProcessMitigation to pull process mitigation settings from running chrome.exe processes including child processes, etc. I am starting to appreciate PowerShell more these days. The good thing is that I am still able to verify and modify any of my process mitigation settings even while PowerShell is within Constrained Language Mode.

Or IFEO MitigationOptions registry hex value: 1111010101110101


Now there are a few crucial things that I wanted to test and confirm. Chromium does DisallowWin32kSysCalls on some of that child processes, particularly the AppContainer processes. Doing DisallowWin32kSysCalls on the main chrome.exe process would cause it to fail. So I kept that setting on defer and wanted to ensure that any child processes that rely on DisallowWin32kSysCalls are still able to automatically set that mitigation themselves. Confirmed, that remained consistent which is good news. I also wanted to ensure that AppContainer processes were working as per normal as well and that remained consistent as well. So these process mitigation settings allowed using some of the more stringent process mitigations which are already applied to many of the chrome.exe child processes, but allowed to apply these also to the main chrome.exe process and broker process as well.

Therefore I've still got a fully functional and highly efficient Chromium running with many more high level Windows 10 process mitigations to make exploitation more difficult. And of course, as always, I've got chrome.exe processes locked down with the memory sandbox provided by MemProtect to ensure that there are no process memory-process memory communications should the system contain any malicious code at any point. MemProtect protects even already exploited program memory space.

These rules are for 64-bit Chromium (or Google Chrome or other chrome.exe based browsers) specifically on 64-bit Windows 10. Using 32-bit Windows or 32-bit Chrome on 64-bit Windows would be absolutely silly these days.

 

Testing here with GFlagsX in Chromium 60 LKGR:



Everything seems to be working fine.

 

even if windows 10 became fort knox, its not bye bye given windows 10 only has a minority of the desktop market

does this tool work on windows 8.1?

 

Good Question but with M$ stressing for users to migrate over to Win 10, it's just my uneducated guess that this might just be part of that persuasion factor?

 

I apologize for forgetting to follow up on this question.

The GFlagsX tool (and the Microsoft Process Mitigations PowerShell tool) may still function on Windows 8.1, particularly GFlagsX should work. Both tools utilize the built-in IFEO registry MitigationOptions which are still functional in Windows 8.1, however, you would just be missing a few mitigations which are only on Windows 10. If I was using Windows 8.1, I would absolutely still make use of whichever MitigationOptions are available.

See: https://theryuu.github.io/ifeo-mitigationoptions.txt

Go down to Windows 10+ section (Dynamic code policy and below) to know which mitigations are not available on Windows 8.1, and all mitigations above that point are still available on 8.1.

 

For what it's worth, guys/gals, I have stopped using the ProcessMitigations PowerShell tools (topic of this thread) until it is fully integrated into Windows Defender Security Center. I just can't be bothered to mess around too much with PowerShell these days and would prefer to neuter PowerShell more than anything with Constrained Language Mode and other various blocking mechanisms.

So for the time being, I am pretty much entirely using the open-source GFlagsX (https://github.com/zodiacon/GflagsX) tool which is portable and quite a simple UI to enable/disable various process mitigations. I absolutely recommend this tool.

The good thing is that if users have rather large IFEO registry MitigationOptions settings that they want to share or transfer to other computers, you can still use the ProcessMitigations PowerShell tool to backup the entire IFEO MitigationOptions settings from registry and save that into an .XML file, or various .XML files if preferred. Then the ProcessMitigations PowerShell tool can be used on other systems to load all of those IFEO MitigationOptions into registry.

The developer of this GFlagsX tool (who also has many other great open-source tools, by the way) is the main author behind the Windows Internals books. I have to admit, I felt very awkward when I had to report a minor bug in the GFlagsX program to him. But he was fantastic and fixed the bug within 12 hours or less. He was also open to some of my other suggestions for the tool for future releases.

 

I'm using GFlagsX and it is really great, I don't see why would I use PowerShell to use these mitigations.

Thank you very much for this discovery.

 

thanks bud

 

@EASTER and others,

I wanted to bring this over here from the other thread regarding GFlagsX tool since it covers process mitigations. There was some discussion about the fact that GFlagsX did not work well on smaller screens such as 1366x768 due to the fact that GFlagsX does not have resize ability for the UI. So I mentioned that to the developer and he added scrollbar functionality to make it easier on small screens. However, at the time, he had not yet provided a compiled binary. So I decided to compile with VS2017 lastnight and did some testing. The scrollbar function works as expected. I decided to take it a bit further at the time and removed the two other tabs, keeping literally only the Process Mitigations settings and the scrollbar. I still want to figure out how to remove the actual tab itself since it takes up some pixels and at that point we wont need the scrollbar anymore. But for now, here is it:

Link: https://sendit.cloud/je18s1fa2557
(GFlagsX 0.21 with some additional tabs removed)

VirusTotal: ~ Removed VirusTotal Results as per Policy ~

Screenshot:



EDIT: Therefore I would still like to figure out how to remove the Image tab itself to save some more pixels and then it should no longer need the scrollbar. Also the "MORE SETTINGS" box around the "Mitigation Options" box can also likely be removed to save some pixels. But I've got to study the code a bit more. I'll post here if I can improve it some more.

EDIT2: GFlagsX developer also confirmed to me that he will absolutely add the MitigationOptions settings for the remaining EMET mitigations such as EAF, EAF+, several ROP, etc. as Win10 RS3 moves further along.

EDIT3: OK so I have finally resolved the sizing issue.
(I just have to re-upload the binary and rescan at VT)

 

Guys/Gals, quick question... should I start a separate thread here to discuss GFlagsX specifically? If yes, should it be here in anti-malware or in software and services? Thank you.


Anyway, I've fixed up GFlagsX up quite nicely without the need to resize or anything. Just the "meat and potatoes".

GFlagsX with Mitigation Options

• Based on version 0.21
• Removed additional tabs
• Kept just the Process Mitigations

Download: https://sendit.cloud/4is892s1tnn0
VirusTotal: ~ Removed VirusTotal Results as per Policy ~




EDIT: I would definitely like to share any and all changes back to the developer, whether manually or forking on GitHub. I'm not sure if the developer would want to maintain a second build of this (likely not) or simply keep a public fork going for other to contribute to.

 

Thanks @WildByDesign . You read my mind, I was thinking the same thing. I agree GFlagsX deserves its own dedicated thread.

 

@Mister X Glad to hear that. You're welcome. But where should the thread be? In this sub-forum or over in Software & Services?

I figured that since this thread initially was supposed to be for the PowerShell Process Mitigations module and I believe that GFlagsX definitely deserves it's own discussion thread where we can all share different settings and so on.

Also, would you be interested in starting up the new thread? I've got to head out the door at the moment. But if you want, you can go ahead and start it and feel free to copy the download link, details, and screenshot image as well if you'd like. Thank you. By the way, I absolutely love this simple, portable yet powerful tool, if anyone could not notice already.

 

GFlagsX
And so nobody else had Windows Defender flag this as it was unzipped? It did for me then said it could solve the problem.
I downloaded the GFlags-master.zip file.

 

In this one. Ultimately, it's a security software to fight malware in essence.

 

Thanks. For the sake of my own sanity and my brain not explodes when re-wording phrases etc, I will copy-paste your entire post. LOL

Edit: Done. Hope you like it. If any infos are missing or anything to add just tell me please.

 

This is nice thank you. So looks like it needs to be done per app?

 

PowerShell

Just beginning to put my own nose in this one. The possibilities are many!

 

Nice work WildByDesign. Very cool. Thanks for sharing, really appreciate it.

 

@JimboW You're welcome.