Process Mitigations are a Windows feature that enables exploit mitigations on either a per-process or system-wide basis. This post explores our research into potential defensive applications of Process Mitigations to prevent commodity attack techniques as well the limitations of the control.

How do they work?⌗

Process Mitigations provide the following protections (click to expand):

Source: Microsoft

Likely one of the most well-known applications of Process Mitigations is Cobalt Strike’s blockdll feature. This configures the C2 implant to spawn child processes with a Process Mitigation that prevents loading non-Microsoft DLLs, which notably prevents loading EDR-related DLLs that are not cross-signed by Microsoft (see here and here for more details).

Under the hood, Process Mitigations are deployed either during/after process creation or persistently via a system configuration change. When creating a new process, the caller can specify a Mitigation policy in the process startup information like:

#include "pch.h"
#include <iostream>
#include <Windows.h>

int main()
{
	PROCESS_INFORMATION pi = {};
	STARTUPINFOEXA si = {};
	SIZE_T attributeSize = 0;
	
	InitializeProcThreadAttributeList(NULL, 1, 0, &attributeSize);
	PPROC_THREAD_ATTRIBUTE_LIST attributes = (PPROC_THREAD_ATTRIBUTE_LIST)HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, attributeSize);
	InitializeProcThreadAttributeList(attributes, 1, 0, &attributeSize);

	DWORD64 policy = PROCESS_CREATION_MITIGATION_POLICY_BLOCK_NON_MICROSOFT_BINARIES_ALWAYS_ON;
	UpdateProcThreadAttribute(attributes, 0, PROC_THREAD_ATTRIBUTE_MITIGATION_POLICY, &policy, sizeof(DWORD64), NULL, NULL);
	si.lpAttributeList = attributes;

	CreateProcessA(NULL, (LPSTR)"notepad", NULL, NULL, TRUE, EXTENDED_STARTUPINFO_PRESENT, NULL, NULL, &si.StartupInfo, &pi);
	HeapFree(GetProcessHeap(), HEAP_ZERO_MEMORY, attributes);

	return 0;
}

Source: ired.team

Other related APIs include: SetProcessMitigationPolicy and GetProcessMitigationPolicy.

To persistently configure a Mitigation Policy, you can use the PowerShell Set-ProcessMitigation cmdlet to configure both system-wide and per-process settings. Alternatively, you can directly write changes to the Registry. For per-process options, Process Mitigations use Image File Execution Options (IFEO) under the hood via the MitigationOptions subkey.

Prior defensive applications⌗

While not widely used, there are some notable applications of Process Mitigations for defensive purposes:

• Gabriel Landau of Elastic Security lists the NoRemoteImages option, set via a driver, as a mitigation for his PPLFault exploit chain (see slide #44 or the talk recording)
• Elliot Killick discussed using the MicrosoftSignedOnly option to mitigate DLL sideloading for specific applications here
• Nathan Blondel discussed the implications of Arbitrary Code Guard on injection into PPL processes here
• As part of the Chrome browser sandbox here

Example: AppInit DLLs⌗

As example, we will demonstrate how Process Mitigations can be used to prevent AppInit DLL persistence. AppInit DLLs allow an attacker with administrative rights to inject their own DLL into any process that loads user32.dll by configuring a Registry key.

The malicious DLL c:\inject.dll spawns a message box on load.

The extensions point mitigation is a per-process mitigation that disables AppInit DLLs, IMEs, and Event Hooks.

Any process configured with this mitigation will ignore the DLL specificed in the AppInit DLL Registry settings.

Limitiations for commodity attacks⌗

System-wide mitigations are primarily focused on exploit protections whereas per-process mitigations can be applied for additional uses, like the above example. Because per-process mitigations are controlled by IFEO, they are ultimately limited by the same limitation of other IFEO controls. Notably, that IFEO must be set based on a process’ file name (or a subset of matches via the FilterFullPath option). You cannot set global IFEO mitigations options. This also means that per-process mitigations can be easily bypassed by simply renaming/moving the target process.

Due to this, Process Mitigations are largely unsuitable as a general control for commodity attacks. Though they may be suitable in more limited capacities, such as mitigating specific attacks against a specific process that requires a static path (e.g., things in System32). Ultimately, we decided to not pursue this approach further.

If you have any questions or concerns, feel free to reach out to @2xxeformyshirt.

Additional resources⌗

Additional useful public research around Process Mitigations include:

• Yarden Shafir’s post Understanding a New Mitigation: Module Tampering Protection, 2022 Paranoia talk Security Features You’ve Never Heard of (but should), and tool MitigationFlagsCliTool
• James Forshaw’s 2016 TROOPERS talk The Joy of Sandbox Mitigations
• Emeric Nasi’s Code Injection series part 4