ASR rules and Exploit protection best practices according to Microsoft.

[pingu-the-penguin]

Microsoft mentions using ASR rules in favour of Exploit protection settings for office apps:

Microsoft also has deprecated these 5 exploit protection rules:

EAF
IAF
SimExec
CallerCheck
StackPivot

First two were deprecated due to application compatibility issues but since the Harden app applies these mitigations to compatible apps, they should be kept imo. Just wanted to let you know they were deprecated.

Last 3 were replaced with Arbitrary Code Guard which I see is not enabled as an exploit mitigation in favour of the depreceated ones.

Thought it was interesting info and might have implications for this repo.

[HotCakeX]

Thank you very much, i'll definitely read it and make changes wherever needed

[pingu-the-penguin]

That sounds great! I also wanted to add that from my initial testing it seems like the Office apps are incompatible with Arbitrary Code Guard so that's probably another reason Microsoft wanted to push away from Exploit Protection usage on office apps. Let me know if you see the same behavior.

[pingu-the-penguin]

I also found this https://learn.microsoft.com/en-us/defender-endpoint/exploit-protection-reference which talks about potential compatibility considerations with other apps and with other exploit protection settings.

[pingu-the-penguin]

I had a couple suggestions regarding this topic:

I think if an office application works with the ASR rules, there is no harm in keeping the exploit protections (as long as they are not duplicating functionality). Additionally, if an app simply doesn't work with ACG, then using the exploit protections that were replaced by ACG could still be a good idea.

I also realised that many more exploit protections can be applied system-wide other than the 6(?) that are default-enabled. I was wondering if it could be worth a shot to audit how the other exploit protections when applied to the system would act and whether they would cause application/system instability or not.

To apply an exploit protection system-wide you can use Poweshell:

Set-ProcessMitigation -System -Enable (whatever the exploit protection reference is like DEP, PreferSystem32, DisableWin32kSystemCalls)

This can be set as a hardening option for the more extreme presets like the privileged access workstation or similar.

[HotCakeX]

I had a couple suggestions regarding this topic:

I think if an office application works with the ASR rules, there is no harm in keeping the exploit protections (as long as they are not duplicating functionality). Additionally, if an app simply doesn't work with ACG, then using the exploit protections that were replaced by ACG could still be a good idea.

I also realised that many more exploit protections can be applied system-wide other than the 6(?) that are default-enabled. I was wondering if it could be worth a shot to audit how the other exploit protections when applied to the system would act and whether they would cause application/system instability or not.

To apply an exploit protection system-wide you can use Poweshell:

Set-ProcessMitigation -System -Enable (whatever the exploit protection reference is like DEP, PreferSystem32, DisableWin32kSystemCalls)

This can be set as a hardening option for the more extreme presets like the privileged access workstation or similar.

It is now possible to do this in the Exploit Mitigations page, System View: https://github.com/HotCakeX/Harden-Windows-Security/wiki/Exploit-Mitigations#system-view

[pingu-the-penguin]

Thanks for this! I was wondering what your thoughts were on the deprecated policies and how they'd be implemented with the Office apps?