Potential Antimalware Scan Interface Bypass via PowerShell

IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Potential Antimalware Scan Interface Bypass via PowerShell

Detects PowerShell scripts that reference Antimalware Scan Interface (AMSI) bypass classes, methods, or known bypass strings. Attackers attempt AMSI bypass to disable scanning and run malicious PowerShell content undetected.

Rule type: query

Rule indices:

logs-windows.powershell*
winlogbeat-*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

https://github.com/S3cur3Th1sSh1t/Amsi-Bypass-Powershell

Tags:

Domain: Endpoint
OS: Windows
Use Case: Threat Detection
Tactic: Defense Evasion
Data Source: PowerShell Logs
Resources: Investigation Guide

Version: 118

Rule authors:

Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Potential Antimalware Scan Interface Bypass via PowerShell

Possible investigation steps

Does the preserved script block show active AMSI bypass behavior or reference-only content?
Focus: powershell.file.script_block_text, source in file.path or file.name, and whether bypass helpers execute or are only mentioned.
Hint: treat AmsiUtils, amsiInitFailed, AmsiScanBuffer/AmsiOpenSession patching, ScriptBlockAst smuggling, VirtualProtect/Marshal.Copy, and logging suppression as active-behavior anchors.
Implication: escalate when content flips AMSI state, patches scan routines, smuggles script blocks, or invokes decoded content; lower suspicion only for inert research text or bounded training with no execution path.
Does reconstruction add payload execution, download logic, or extra evasion?
Why: Script Block Logging can split helper functions, decoded strings, and later stages across multiple fragments.
Focus: reconstruct fragments scoped by host.id and powershell.file.script_block_id; order with powershell.sequence, confirm powershell.total, then read powershell.file.script_block_text. !{investigate{"description":"","label":"Script block fragments for the same script","providers":[[{"excluded":false,"field":"powershell.file.script_block_id","queryType":"phrase","value":"{{powershell.file.script_block_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
Hint: review surrounding 4104 blocks for the same host.id and process.pid with different powershell.file.script_block_id; keep timestamp comparison tight to avoid PID reuse. !{investigate{"description":"","label":"PowerShell script blocks for the same process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4104","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
Hint: if fragments are missing, score visible bypass logic and record the missing sequence range as unresolved, not benign.
Implication: escalate when reconstruction adds download, decode, in-memory execution, credential access, persistence, Disable Script Logging, or unloadobfuscated/unloadsilent evasion; lower suspicion only when complete fragments remain bounded to authorized lab or training content.
Can endpoint process telemetry recover how PowerShell was launched?
Focus: if available, recover the process via host.id and process.pid before interpreting process.* or process.parent.*; read process.command_line, process.parent.command_line, and process.Ext.session_info.logon_type, expanding the window if PowerShell started earlier. !{investigate{"description":"","label":"Process events for the PowerShell instance","providers":[[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
Implication: escalate for encoded commands, PowerShell v2 downgrade, Office/browser parents, remote-administration launchers, or service/network logon that does not fit the user; missing endpoint telemetry leaves launch context unresolved, not benign.
Do the user, host, and source context fit an authorized test workflow?
Focus: user.id, host.id, host.name, preserved file.path or file.name, and recovered launch context.
Hint: if no source path is preserved, treat the block as interactive, pasted, in-memory, or remotely delivered and require stronger corroboration before benign closure.
Implication: escalate when standard-user, shared-workstation, production-server, user-writable-source, or fileless-delivery context cannot be tied to one authorized lab, red-team, detection-engineering, or training case; lower suspicion only when all context supports that exact workflow.
If local evidence remains suspicious or unresolved, does the pattern recur for the same user or host?
Focus: last-48h related alerts for the same user.id, looking for repeated AMSI bypass, delivery, credential access, persistence, or defense evasion. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
Hint: check the same host.id before expanding beyond the affected host or user. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
Implication: broaden scope when related alerts show repeated evasion or follow-on abuse; quiet pivots lower scope only and never close active bypass without local evidence proving one exact authorized workflow.
Escalate on active bypass logic, suspicious provenance, launch abuse, operational follow-on evidence, or partial/mixed visibility; close only when script content, reconstruction, launch, source, and related-alert evidence bind activity to one exact authorized lab, training, or red-team workflow; preserve artifacts and escalate when outside confirmation is needed.

False positive analysis

Authorized detection-engineering, red-team, malware-analysis, training, or reference-only course/research use can trigger this rule. Confirm that powershell.file.script_block_text, reconstruction, user.id, host.id, source/session context, and recovered launch context all stay inside the same test case and add no second stage. If records are unavailable, recurrence supports assessment only when the same telemetry pattern proves the exact exercise; do not close on recurrence alone.
Before creating an exception, validate that the same user.id, host.id, stable source path, launch context, and reconstructed fragment pattern recur across prior alerts from this rule. Build the exception from that confirmed workflow pattern. Avoid exceptions on AMSI strings alone, on user.name alone, or on a host alone.

Response and remediation

If confirmed benign, reverse temporary containment and document which evidence proved the authorized workflow: script content, reconstruction, user.id, host.id, preserved source path, and recovered launch context. Create an exception only if the same workflow pattern recurs and the telemetry still proves the exact exercise.
If suspicious but unconfirmed, preserve the script block content, fragment IDs and sequence numbers, process.pid, recovered launch details, script-named URLs or paths, source files, and related-alert exports before containment. Apply reversible containment first, such as tighter monitoring on the affected host.id or user.id, temporary restrictions for script-named URLs, or suspend-process actions when the host role can tolerate them. Escalate to isolation only if reconstructed content or recovered launch evidence confirms operational follow-on activity.
If confirmed malicious, contain the host or account based on the script content, recovered launch chain, source path, script-named indicators, or related-alert evidence that established unauthorized operational use. Record the recovered PowerShell process details, parent chain, script content, downstream commands, and affected user.id / host.id before terminating processes, deleting files, or purging sessions.
Block confirmed malicious script-named URLs or hashes, collect referenced source files, and eradicate only the unauthorized scripts, payloads, startup artifacts, scheduled tasks, and security-control changes expressed in reconstruction or recovered launch context.
Before destructive cleanup, review related hosts and users for the same script fragments, launch chain, downgrade pattern, script-named indicators, or already-running PowerShell reuse so scope is understood before evidence is removed.
After the incident, retain Script Block Logging plus required endpoint process telemetry, and document PowerShell version 2 downgrade, logging-suppression, or script-block smuggling variants in the case record.

Setup

edit

Setup

PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). Setup instructions: https://ela.st/powershell-logging-setup

Rule query

edit

event.category:"process" and host.os.type:windows and
  (
    powershell.file.script_block_text : (
      "System.Management.Automation.AmsiUtils" or
      amsiInitFailed or
      "Invoke-AmsiBypass" or
      "Bypass.AMSI" or
      "amsi.dll" or
      AntimalwareProvider or
      amsiSession or
      amsiContext or
      AmsiInitialize or
      unloadobfuscated or
      unloadsilent or
      AmsiX64 or
      AmsiX32 or
      FindAmsiFun or
      "AllocHGlobal((9076" or
      "[cHAr](65)+[cHaR]([byTe]0x6d)+[ChaR]([ByTe]0x73)+[CHaR]([BYte]0x69"
    ) or
    powershell.file.script_block_text:("[Ref].Assembly.GetType(('System.Management.Automation" and ".SetValue(") or
    powershell.file.script_block_text:("::AllocHGlobal((" and ".SetValue(" and "-replace" and ".NoRMALiZe(")
  ) and
  not powershell.file.script_block_text : (
    "sentinelbreakpoints" and "Set-PSBreakpoint"
  )

Framework: MITRE ATT&CK^TM

Tactic:
- Name: Defense Evasion
- ID: TA0005
- Reference URL: https://attack.mitre.org/tactics/TA0005/
Technique:
- Name: Obfuscated Files or Information
- ID: T1027
- Reference URL: https://attack.mitre.org/techniques/T1027/
Sub-technique:
- Name: Command Obfuscation
- ID: T1027.010
- Reference URL: https://attack.mitre.org/techniques/T1027/010/
Technique:
- Name: Impair Defenses
- ID: T1562
- Reference URL: https://attack.mitre.org/techniques/T1562/
Sub-technique:
- Name: Disable or Modify Tools
- ID: T1562.001
- Reference URL: https://attack.mitre.org/techniques/T1562/001/
Tactic:
- Name: Execution
- ID: TA0002
- Reference URL: https://attack.mitre.org/tactics/TA0002/
Technique:
- Name: Command and Scripting Interpreter
- ID: T1059
- Reference URL: https://attack.mitre.org/techniques/T1059/
Sub-technique:
- Name: PowerShell
- ID: T1059.001
- Reference URL: https://attack.mitre.org/techniques/T1059/001/

« Suspicious Antimalware Scan Interface DLL Modification of AmsiEnable Registry Key »