A collection of runtime process-level mitigation features, formerly known as Enhanced Mitigation Experience Toolkit (EMET). Configurable via an XML policy frontend for RtlSetImageMitigationPolicy. Pretty much the user-configurable subset of SetProcessMitigationPolicy.
Export
Forget what I wrote this for, might’ve been testing which mitigations worked system-wide
Get-ProcessMitigation -System | select -ExcludeProperty ProcessName, Source, Id | % {'<SystemConfig>'} {
$_.psobject.properties | % {" <$($_.name) $(
$_.value.psobject.properties | % { $_.name+'="'+$_.value+'"' }
) />"}
} {'</SystemConfig>'}Schema
I wanted an XML policy schema for some codegen but couldn’t find one, so I got to carving. Microsoft.ProcessMitigations.Commands.dll implements the PowerShell cmdlets so it seemed like a good place to start. ILSpy made quick work of them, they’re just calling the win32 MitigationConfiguration.dll (like ValidateXMLFromManaged(path)).
It’s pretty easy to call from PowerShell, but I don’t really want to rely on Windows.
Add-Type -TypeDefinition @"
using System;
using System.Runtime.InteropServices;
public class MitigationConfig
{
[DllImport("MitigationConfiguration.dll", CharSet = CharSet.Auto)]
public static extern int ValidateXMLFromManaged(string fileName, ref bool result);
}
"@
$result = $false
$hr = [MitigationConfig]::ValidateXMLFromManaged("ExploitGuard.xml", [ref]$result)
Write-Host "Return code: $hr, Result: $result"ValidateXMLFromManaged makes me think the DLL might have a schema somewhere. Strings didn’t find anything,Get-Content -Encoding unicode was better - the XML properties were present, but as UTF-16 space-separated strings? With no types or anything. Time to pull out Ghidra.
It’s COM… The decomp is gross, but it’s pretty much just calling IXMLDOMDocument2.loadXML with XML validation enabled. No schema validation in sight, despite the cmdlet arg mentioning an xsd, so I guess I’ll build a schema myself.
IXMLDOMDocument2 *xmlDoc = NULL;
hr = CoCreateInstance(&CLSID_DOMDocument60, NULL, CLSCTX_INPROC_SERVER, &IID_IXMLDOMDocument2, (void**)&xmlDoc);
hr = xmlDoc->put_async(VARIANT_TRUE);
hr = xmlDoc->put_validateOnParse(VARIANT_TRUE);
hr = xmlDoc->put_resolveExternals(VARIANT_TRUE);
...
hr = xmlDoc->load(xmlVariant.bstrVal, &parseResult);Those strings I was seeing were only used in ImportMitigation, not validation.
Florian’s great policy was really helpful for testing, but his system-wide mitigations included some that are per-app-only in the docs, so I left an issue. Turns out the docs are just wrong.
My tooling (and skill lol) isn’t good enough for a clean decomp of the C++ objects in ImportMitigation, but I suspect it’s just passing parsed data straight to RtlSetImageMitigationPolicy and letting it do validation for system vs app mitigations. Hard to tell for sure without making a Ghidra type for IXmlReader and I really can’t be bothered 🤷♂️
I did notice PowerShell cmdlet Set-ProcessMitigation has a hardcoded blocklist, for mitigations that aren’t supported system-wide. But thanks to winbindex I can see it hasn’t been updated since at least 1809.
private string[] BlockInSystemMode = new string[14]
{
"EnableExportAddressFilter", "AuditEnableExportAddressFilter", "EnableExportAddressFilterPlus", "AuditEnableExportAddressFilterPlus", "EnableImportAddressFilter", "AuditEnableImportAddressFilter", "EnableRopStackPivot", "AuditEnableRopStackPivot", "EnableRopCallerCheck", "AuditEnableRopCallerCheck",
"EnableRopSimExec", "AuditEnableRopSimExec", "DisallowChildProcessCreation", "AuditChildProcess"
};The cmdlet’s serializer has a lot more properties than MitigationConfiguration.dll, like SystemCalls.AuditFsctlSystemCalls, so I wonder whether it’s using deprecated properties that ImportMitigation(string xmlPath) ignores. AuditDisallowFsctlSystemCalls is a valid ProcessMitigation policy but I can’t find references to it for an ImageMitigation policy.