[Low Priority] Simplewall seems to be generating executable code pages when it doesn't need to.

[gettysburg]

Hi Henry,

all my production systems are using the Windows 10 / Server 2019 Defender "Exploit Protection" features, read more here (MS Docs):

https://docs.microsoft.com/en-us/microsoft-365/security/defender-endpoint/exploit-protection-reference?view=o365-worldwide

I've turned on Arbitrary code guard in combination with Code integrity guard for simplewall.exe, which prevents harmful software from being able to load shell-code or unsigned libraries into simplewall in order to disable it's protections.

However, it seems like simplewall is triggering one of the mitigations on it's own.

The log can be found in Event Viewer, under Applications and Services Logs -> Microsoft -> Windows -> Security-Mitigations -> Kernel Mode.

Example of such an entry:

Process '\Device\HarddiskVolume3\Program Files\simplewall\simplewall.exe' (PID XXXX) was blocked from generating dynamic code.

There are 1162 entries, all created at the same time:

The only way to recreate these entries is to close SimpleWall completely, then restart it.

Maybe check if you have some VirtualAlloc(Ex) call with any of the PAGE_EXECUTE page rights which would trigger this?

It does not block SimpleWall from working but you shouldn't need to create dynamic code anyway, as it's insecure, and, in my case, just end's up getting blocked by my kernel anyway.

Here's my entire exploit protection configuration for SimpleWall.exe, just for reference - reading the docs linked above is highly recommended.

<AppConfig Executable="simplewall.exe">
  <ASLR ForceRelocateImages="true" RequireInfo="true" />
  <StrictHandle Enable="true" />
  <ExtensionPoints DisableExtensionPoints="true" />
  <DynamicCode BlockDynamicCode="true" AllowThreadsToOptOut="false" Audit="false" />
  <ControlFlowGuard Enable="true" SuppressExports="false" StrictControlFlowGuard="true" />
  <SignedBinaries MicrosoftSignedOnly="true" AllowStoreSignedBinaries="false" Audit="false" AuditStoreSigned="false" EnforceModuleDependencySigning="true" />
  <Fonts DisableNonSystemFonts="true" AuditOnly="false" Audit="false" />
  <ImageLoad BlockRemoteImageLoads="true" AuditRemoteImageLoads="false" BlockLowLabelImageLoads="true" AuditLowLabelImageLoads="false" />
  <Payload EnableExportAddressFilter="true" AuditEnableExportAddressFilter="false" EnableExportAddressFilterPlus="true" AuditEnableExportAddressFilterPlus="false" EnableImportAddressFilter="true" AuditEnableImportAddressFilter="false" />
  <ChildProcess DisallowChildProcessCreation="true" Audit="false" />
</AppConfig>

Thank you for looking into this, I would look through your code to find the culprit but I'm busy with other things :-)

Best Regards.

[bb33bb]

i also use processhacker to make simple wall sandboxed

[gettysburg]

i also use processhacker to make simple wall sandboxed

By making it a protected process or stripping handle access? :-)

Yeah, that would also work but I need a solution that I can quickly import across new instances.

For example:

Set-ProcessMitigation -PolicyFilePath filename.xml

[pwn0r]

interesting question. How does code integrity help here? @gettysburg

It only allows MS signed binaries, right? simplewall.exe is actually unsigned in the first place, right?

[gettysburg]

interesting question. How does code integrity help here? @gettysburg

It only allows MS signed binaries, right? simplewall.exe is actually unsigned in the first place, right?

Hi, yes, as of 3.4.3, no code signing certificate is compiled into simplewall - mitigations can still be enabled, and only apply for dynamically linked libraries.

Also, you're right, Microsoft signed binaries only, with the option to also allow Microsoft Store signed binaries (this is mainly for apps, which do not exist on Server 2019 LTSC but only on desktop Windows 8.1 / 10 systems).

The mitigation getting triggered here is the one preventing privileged processes from opening a handle to SimpleWall through OpenProcess, then allocating a page and changing it's page flags to executable through the use of VirtualProtect(Ex) (PAGE_EXECUTE_READWRITE for example) and writing some shell-code by using API's such as WriteProcessMemory.

The same mitigation applies for calls to VirtualProtect(Ex) and VirtualAlloc(Ex) from within the process, too.

A great post reverse-engineering these mitigations and providing further information:

https://www.countercraftsec.com/blog/post/arbitrary-vs-kernel/

[gettysburg]

Small update from my side (still busy with my job):

I tried locating instances of VirtualAlloc use along with the PAGE_EXECUTE_READWRITE constant in this repository, but couldn't find any - I noticed however that you do have your own application framework which I didn't have the time to completely audit, but from what I have seen so far, you seemingly use your own heap with only the default page protection flags, meaning RW, not RWX.

Any idea why Windows Exploit Protection still complains about simplewall generating executable code?