AMSI Patching: Detecting In-Process Security Tampering
AMSI patching attempts to alter code or control data inside an AMSI-integrated process so scanning fails, returns a benign result, or is skipped. Defenders should detect the mutation and its consequences without depending on one public patch sequence.
No patch bytes, target offsets, memory-writing code, or bypass commands are included. The examples are integrity-monitoring concepts for authorized environments.
What patching changes
AMSI client logic is loaded into the address space of an integrated application. Its executable pages should normally correspond to the correct signed Windows image after expected relocations. Tampering can affect instructions, branch behavior, function pointers, or data used by the scan path. The details vary, but every successful mutation needs a writer, a changed region, and an observable impact on inspection.
Integrity analysis without brittle signatures
Compare in-memory executable pages with the exact on-disk image for the endpoint’s architecture and patch level. Account for relocations, supported hotpatches, security instrumentation, and copy-on-write state. Record page protections before and after modification, identify the writing thread and module where telemetry permits, and verify whether the changed range belongs to executable code or mutable data.
- Hash page-sized regions after normal loader fixups rather than entire modules blindly.
- Resolve differences to functions and signed build metadata.
- Prioritize changes followed by a drop in AMSI events or abnormal scan results.
- Correlate with script-block logs, child processes, downloads, credentials, and networking.
- Baseline legitimate profilers, EDR hooks, application compatibility, and hotpatch activity.
Response workflow
Capture the affected process before termination when policy allows. Preserve its executable pages, module list, threads, call stacks, handles, script content, process ancestry, security-product state, and endpoint timeline. Compare the recovered image to a trusted file from the same system build. Scope the writer’s hash, signer, parent, command context, and changed bytes across the fleet.
Safe lab and GitHub tools
Validate detection with a benign application whose own test code page is changed by an approved instrumentation harness; do not alter AMSI. Confirm that memory-protection and integrity sensors identify the generic behavior, then inject synthetic AMSI-health events into a test SIEM. PE-sieve, Moneta, Volatility 3, and pefile support memory and image comparison.
ATT&CK, CVEs, and hardening
AMSI patching maps to T1562.001 Impair Defenses and may accompany T1059 scripting. It is a tampering technique, not a CVE. A provider-specific flaw should be cited only after exact product and version validation. Enable Defender tamper protection or equivalent controls, keep security components current, use WDAC/AppLocker and ASR, remove unnecessary scripting engines, restrict local administration, and alert on unexplained changes to security-related image pages.