How do you detect an AMSI bypass?

Detect an AMSI bypass at three layers. In PowerShell script block logs (Event 4104), hunt for AmsiUtils, amsiInitFailed and AmsiScanBuffer tokens and for reflection patterns that fetch them. In the registry, alert on AmsiEnable set to zero and on deletion of AMSI provider keys. In memory, use EDR or Threat-Intelligence ETW telemetry to catch a protection change and small write on the amsi.dll code page, and alert on PowerShell version 2 downgrades. Because authors obfuscate strings, correlate these signals rather than relying on one keyword.

Detecting AMSI Bypass: Patching, Reflection and Provider Tampering

The Antimalware Scan Interface lets Defender and other engines inspect PowerShell, VBScript, JScript, .NET assemblies and Office macros after deobfuscation. That makes it a prime target: a one-line bypass blinds script-based detection for the rest of the session. The bypass itself is short, noisy and often copy-pasted, which gives defenders several reliable places to look.

Signals at a Glance

Signal	Where	ATT&CK
Script block text containing AmsiUtils, amsiInitFailed or AmsiScanBuffer	PowerShell 4104, MDE PowerShellCommand	T1562.001
Write or VirtualProtect against the amsi.dll code section in the same process	EDR memory telemetry, ETW Threat-Intelligence	T1562.001
amsi.dll loaded into a process that never loads it, or not loaded where it should be	Sysmon 7	T1562.001
AmsiEnable set to 0 or AMSI provider key deleted	Sysmon 12/13, registry telemetry	T1112
powershell.exe -version 2 downgrade to an engine without AMSI	Sysmon 1, 4688	T1059.001

Script-Level Bypasses

The best-known bypasses use .NET reflection to flip the private amsiInitFailed field, or patch AmsiScanBuffer in memory so it returns a clean result. Both need a handful of recognisable tokens at some point, even when the author splits strings. Script block logging records the code after PowerShell has de-obfuscated it, so hunt there first:

// Microsoft Defender XDR (KQL) - AMSI bypass strings in PowerShell script blocks
DeviceEvents
| where ActionType == "PowerShellCommand"
| extend cmd = tostring(parse_json(AdditionalFields).Command)
| where cmd has_any ("AmsiUtils", "amsiInitFailed", "AmsiScanBuffer", "amsiContext", "AmsiOpenSession")
     or cmd matches regex @"(?i)\[Ref\]\.Assembly\.GetType\(.{0,40}Am.{0,6}si"
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, cmd
// tune/validate: security tooling and some admin scripts reference these names legitimately.

Do not rely on string matching alone. Authors concatenate or encode the names, so add a behavioural pair: a PowerShell process that also changes AmsiEnable or starts as version 2. The registry route is quieter and easy to catch:

title: AMSI Disabled via Registry
logsource:
  product: windows
  category: registry_set
detection:
  amsi_enable:
    TargetObject|endswith: '\Software\Microsoft\Windows Script\Settings\AmsiEnable'
    Details: 'DWORD (0x00000000)'
  provider_removed:
    EventType: DeleteKey
    TargetObject|contains: '\Microsoft\AMSI\Providers\'
  condition: amsi_enable or provider_removed
level: high
# tune/validate: confirm your EDR does not itself write these keys during upgrades.

Memory Patching and Process Context

An in-process patch is the hardest variant to log with default Windows telemetry, because the write is a few bytes inside a loaded module. Endpoint products that subscribe to the Microsoft-Windows-Threat-Intelligence ETW provider can see the protection change on the amsi.dll code page. If you run such a product, make sure that alert is routed to the SOC rather than left as informational.

Treat VirtualProtect on the amsi.dll .text section, followed by a small write, as a high-confidence event when it comes from the process that loaded the DLL.
Use Sysmon Event ID 7 to baseline which processes load amsi.dll; a rare host process suddenly loading it, or a script host that no longer does, is worth a look.
Alert on powershell.exe -version 2 and on the .NET 2.0 feature being enabled; version 2 has no AMSI integration.
Check for a missing AMSI provider: Defender registers under the AMSI Providers key, and a deleted entry means scripts are no longer scanned.

Vetted sources

Start from the SigmaHQ AMSI bypass and script block rules, Elastic’s defense-evasion AMSI detections, Splunk ESCU PowerShell content and the MITRE ATT&CK T1562.001 procedure examples. Atomic Red Team ships safe bypass tests so you can prove each detection fires. Baseline your own environment first — red team tooling and security products reference the same strings.

Build Detections That Fire

Mjolnir Security helps blue teams turn threat intelligence into high-fidelity detections across endpoint, network, identity and cloud telemetry.

Detection EngineeringManaged Detection & ResponseThreat HuntingIncident ResponsePurple Teaming

Detection Engineering We build and tune detections mapped to ATT&CK from your own telemetry.
Threat Hunting as a Service Hypothesis-driven hunts for the behaviours on this page.
24/7 Incident Response Containment when a detection fires. Call +1 833 403 5875.

Written by: Mjolnir Threat Research (MTAC)  |  Published: October 12, 2026  |  Last reviewed: October 12, 2026

Signals at a Glance

Script-Level Bypasses

Memory Patching and Process Context

Build Detections That Fire

Defense Evasion Detection

Detection Hub

ETW Tampering Detection