← ./resources / blog
Windows Defense · Memory Tampering//2026-09-07

AMSI Write Raid: Detecting Low-Volume Memory Tampering

“Write Raid” research highlights a defensive blind spot: a security-relevant change may consist of a very small write rather than a large injected region. Detection must retain protection history and writer context, then connect subtle memory mutations to inspection health and subsequent behavior.

LGBy Lisa Garcia · Security Researcher
Defensive scope

This article does not document target locations, write values, discovery logic, or working bypasses. “Write Raid” is treated as a defensive research category, not as attribution from one indicator.

Why small writes matter

Many memory detections emphasize new executable allocations or bulk cross-process copies. In-process tampering can instead modify a few bytes or a pointer in an already loaded security component. The resulting process may retain normal module names, signatures on disk, and ordinary ancestry. Page-level integrity, write provenance, and scan-health baselines become the decisive evidence.

Small mutation, larger telemetry consequenceNormal script hostand AMSI imageTiny write orpointer changeScan volume orresults divergeBehaviorcontinuesHigh-value fields: original bytes · new bytes · page state · writing thread · module · timestampCorroborate with script logs, child processes, identity events, file activity, and network telemetry
Mutation size is a poor proxy for security impact; the target and resulting loss of visibility matter more.

Detection model

  • Track writes and protection changes affecting AMSI-related pages or process control data.
  • Compare changed pages to the exact signed image after loader adjustments.
  • Identify the writing thread, its start module, stack, and preceding content source.
  • Measure scans per active script-host process and flag unexplained discontinuities.
  • Join integrity changes to PowerShell, WSH, Office, browser, and child-process telemetry.

Do not treat any one-byte difference as malicious. Relocations, hotpatching, EDR instrumentation, profilers, and application compatibility can alter memory legitimately. The exact range, supported vendor behavior, signature chain, and event ordering determine severity.

Forensic workflow

Preserve volatile memory and the raw endpoint timeline. Extract the affected region with surrounding bytes, the corresponding clean image, page protections, threads, modules, script content, and provider state. Determine whether the mutation occurred before the scan gap and whether execution flowed through the changed data or code. Search the enterprise for the same writer and mutation pattern while keeping behavior-based detections active.

Safe lab and tools

Use a harmless test program with an explicitly mutable buffer to validate low-volume write telemetry. Generate synthetic health records representing scan interruption instead of changing AMSI. PE-sieve, Moneta, Volatility 3, capa, and Sigma support triage and detection engineering.

ATT&CK, CVEs, and controls

The behavior aligns with T1562.001 Impair Defenses and may coexist with T1055 or T1059 depending on the complete chain. AMSI Write Raid describes a tampering approach, not a vulnerability, so it has no intrinsic CVE. Enforce application control, tamper protection, least privilege, script restrictions, ASR policy, current security-engine versions, and alerting on security-module integrity plus telemetry-health changes.

AMSIMemory WritesTelemetry Health
← Previous: AMSI PatchingNext: ETW Theory →