Closed rafalfitt closed 1 year ago
Hi, I tried modifying the default Exploit Protection settings of Windows a couple of months ago but I remember not getting the right results and was having lots of compatibility issues.
These are really sensitive things that need extensive trial and error and testing to make sure they don't crash programs or even the OS itself as a result, so it's gonna take some time to verify how the built-in Windows programs and executables behave.
I'm not sure whether it's possible to automatically verify an executable is compatible with a specific Exploit Protection feature or not, it'd speed up the verification process a lot.
I can also think about the possibility that a program might be compatible with an Exploit Protection feature right now but the next version of it might crash.
Added this to the project.
EMET/Exploit Protection has unlimited scope and compat verification can be painful for certain mitigations. Some require binary support though, which could be checked automatically (CFG, CET Shadow Stack, etc). Audit mode is helpful too if centralised logging is available.
Most implementations I've seen have focused on apps that process untrusted input eg browsers, Office/Acrobat, 7zip/NanaZip. Would that be a suitable approach here?
It's not robust, but this works:
dumpbin /headers /loadconfig .\msedge.exe | sls "Control Flow Guard", "CF Instrumented", "FID table present"
Could do .Matches.Length -eq 3
, but individual checks with sls -Quiet
would be better imo
@pl4nty Thank you!
Yes, I think only configuring individual apps that are not system components is safer option, but since this script is general purpose I'm not sure how we can know which programs users have installed when running the script. Will have to prompt user for confirmation before running each of the categories i think.
Edge for example has some exploit protection features by default
Hardware-enforced Stack Protection and Arbitrary Code Guard (ACG)
Edge also has code integrity guard but available through a policy that requires AD/AAD.
I'll try dumpbin method on Edge to see what result i get ^^
This is the result for Edge executable
00010500 Guard Flags
CF instrumented
FID table present
Long jump target table present
CF instrumented means that the binary file has been compiled with the /guard:cf option, which enables Control Flow Guard (CFG) for the code. CFG is a security feature that prevents exploits from hijacking the control flow of the program by checking the validity of indirect call targets at runtime.
FID table present means that the binary file has a GuardCFFunctionTable attached to the load configuration directory, which is a sorted list of relative virtual addresses (RVA) that contain information about valid CFG call targets. These are, generally speaking, address taken function symbols. An image that wants CFG enforcement must enumerate all address taken function symbols in its GFIDS table.
Long jump target table present means that the binary file has a GuardCFLongJumpTargetTable attached to the load configuration directory, which is a sorted list of RVAs that are valid long jump targets. If a long jump target module sets IMAGE_GUARD_CF_LONGJUMP_TABLE_PRESENT in its GuardFlags field, then all long jump targets must be enumerated in the LongJumpTargetTable.
Also system informer can show the exploit protections applied to each running process
This is the setting that works with Edge and loads websites fine, haven't done extended testing yet to see if it crashes after running with many tabs and for many hours
<AppConfig Executable="C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe">
<DEP Enable="true" EmulateAtlThunks="true"/>
<ASLR ForceRelocateImages="true" RequireInfo="true" BottomUp="true" HighEntropy="true"/>
<StrictHandle Enable="true"/>
<ExtensionPoints DisableExtensionPoints="true"/>
<ControlFlowGuard Enable="true" SuppressExports="false" StrictControlFlowGuard="true"/>
<SignedBinaries MicrosoftSignedOnly="true" AllowStoreSignedBinaries="true" Audit="false" AuditStoreSigned="false" EnforceModuleDependencySigning="true"/>
<Fonts DisableNonSystemFonts="true" AuditOnly="false" Audit="false"/>
<ImageLoad BlockRemoteImageLoads="true" AuditRemoteImageLoads="false" BlockLowLabelImageLoads="true" AuditLowLabelImageLoads="false"/>
<SEHOP Enable="true" TelemetryOnly="false"/>
<Heap TerminateOnError="true"/>
</AppConfig>
Anything else either prevents Edge from loading or loads but gets stuck with 100% CPU usage.
With System Informer, I can see child processes of msedge.exe having different process mitigations. some of them have a lot more and some of them have only few. Probably because of the Edge policies I applied for sandboxing different components of it.
Gonna need some more info understanding the whole thing and how the Edge policies work with MDAV exploit protection features, which one takes priority etc.
If anyone wants to help testing this configuration for extended periods, here is the PowerShell code
Set-ProcessMitigation -Name 'msedge.exe' -Enable DEP,
EmulateAtlThunks,
BottomUp,
ForceRelocateImages,
RequireInfo,
HighEntropy,
StrictHandle,
DisableExtensionPoints,
CFG,
StrictCFG,
MicrosoftSignedOnly,
AllowStoreSignedBinaries,
EnforceModuleDependencySigning,
DisableNonSystemFonts,
BlockRemoteImageLoads,
BlockLowLabelImageLoads,
SEHOP,
TerminateOnError,
UserShadowStack
Using PowerShell is better than xml file importing imo because this way the hardening script will only touch specific executables and won't overwrite any other possible existing user/system settings.
The final exploit protection/process mitigations that I'm going to add to the script if I continue seeing no issues. If anyone has suggestions for including other processes please let me know.
Edge opens PDFs using Adobe Acrobat engine.
Working on Nanazip
@pl4nty which process mitigations do you think are suitable for M365/Office apps ?
# Enable Mandatory ASLR Exploit Protection system-wide
set-processmitigation -System -Enable ForceRelocateImages
# Enable Exploit Protection/process mitigations for Microsoft Edge - applies to all Edge channels
Set-ProcessMitigation -Name 'msedge.exe' -Enable DEP,
EmulateAtlThunks,
BottomUp,
ForceRelocateImages,
RequireInfo,
HighEntropy,
StrictHandle,
DisableExtensionPoints,
CFG,
StrictCFG,
MicrosoftSignedOnly,
AllowStoreSignedBinaries,
EnforceModuleDependencySigning,
DisableNonSystemFonts,
BlockRemoteImageLoads,
BlockLowLabelImageLoads,
SEHOP,
TerminateOnError,
UserShadowStack
# Enable Exploit Protection/process mitigations for other system components
Set-ProcessMitigation -Name "mscorsvw.exe" -Enable DisableExtensionPoints
Set-ProcessMitigation -Name "ngen.exe" -Enable DisableExtensionPoints
Set-ProcessMitigation -Name "ngentask.exe" -Enable DisableExtensionPoints
Set-ProcessMitigation -Name "PrintDialog.exe" -Enable DisableExtensionPoints
Set-ProcessMitigation -Name "SystemSettings.exe" -Enable DisableExtensionPoints
Set-ProcessMitigation -Name "runtimebroker.exe" -Enable DisableExtensionPoints
Set-ProcessMitigation -Name "C:\Windows\System32\vmcompute.exe" -Enable CFG, SuppressExports, StrictCFG
Set-ProcessMitigation -Name "C:\windows\system32\vmwp.exe" -Enable CFG, SuppressExports, StrictCFG
# Enable Exploit Protection/process mitigations for Quick Assist
Set-ProcessMitigation -Name "QuickAssist.exe" -Enable DisableExtensionPoints,
StrictHandle,
BlockDynamicCode,
MicrosoftSignedOnly,
AllowStoreSignedBinaries,
EnforceModuleDependencySigning,
DisableNonSystemFonts,
BlockRemoteImageLoads,
BlockLowLabelImageLoads,
EnableExportAddressFilter,
EnableExportAddressFilterPlus,
EnableImportAddressFilter,
EnableRopStackPivot,
EnableRopCallerCheck,
EnableRopSimExec,
UserShadowStack,
UserShadowStackStrictMode -Disable AllowThreadsToOptOut
Why are you not using a XML file with the Set-ProcessMitigation cmdlet ?
Such as Set-ProcessMitigation -PolicyFilePath settings.xml
Why are you not using a XML file with the Set-ProcessMitigation cmdlet ?
Such as
Set-ProcessMitigation -PolicyFilePath settings.xml
Hi, good question, I noticed there is a mitigation that can only be configured using PowerShell
Other than that, I tested it a bunch of times and I saw using import xml can override Exploit Protection settings already set by user.
You should take all the documentation about Exploit Protection with a big pinch of salt, because ACG (BlockDynamicCode) can be enabled just fine within a XML file:
A lot could be said about the table describing the mitigations (cf. https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/customize-exploit-protection?view=o365-worldwide#exploit-protection-mitigations), where most of the settings described as "App-level only" can indeed be enabled at system-level. In fact, any setting that is listed under Get-ProcessMitigation -System
can be configured at system-level, whatever the documentation is saying about it.
@Harvester57 In that case we should open issues for that doc page
I don't think that paragraph is referring to ACG though, but only this part
Can optionally allow thread opt-out and allow remote downgrade (configurable only with PowerShell).
The bigger issue i had with it was overriding previously set user process mitigations, but with the current method the script only touches individual program names and individual mitigations for them, it's the most specific method imho
I put them in CSV for easier verification too
I also made sure the script won't call Set-ProcessMitigation
cmdlet too much by collecting all enable/disable flags and only use the cmdlet once for each program.
M365 apps including OneDrive added: https://github.com/HotCakeX/Harden-Windows-Security/releases/tag/v2023.08.28
https://github.com/Harvester57/Exploit-Protection-policy https://github.com/milgradesec/windows-settings/blob/main/ExploitGuard/ExploitSettings.xml