PowerShell Evasion and AMSI Provider Abuse Enable Stealthy Windows Execution

Public offensive tooling and research continue to show how attackers can weaken PowerShell defenses by bypassing AMSI, suppressing Script Block Logging, and evading Constrained Language Mode. MDSec documented several methods, including flipping the private .NET flag System.Management.Automation.AmsiUtils.amsiInitFailed, patching amsi.dll in memory, forcing AmsiOpenSession failures, altering cached Group Policy settings to disable logging, and clearing PowerShell's suspicious signature list to reduce forced logging. The techniques were later operationalized in tools such as Stracciatella, a C# runspace launcher that executes PowerShell while attempting to disable AMSI, ETW, and logging at startup, supports encoded input and named-pipe command delivery, and was promoted for use with frameworks including Cobalt Strike and BOF.NET.

Separate research also showed that AMSI itself can be abused for persistence by registering a malicious AMSI provider DLL as a COM server under HKLM, allowing code to run whenever AMSI-inspected content matches a trigger while still returning AMSI_RESULT_NOT_DETECTED. In the demonstrated sample, the provider watched for a specific string and launched calc.exe, highlighting how AMSI can be turned from a scanning interface into an execution mechanism. Defenders were advised to monitor unsigned DLL loads by PowerShell and registry changes affecting AMSI provider and InprocServer32 entries, as these tradecraft patterns can support stealthy post-exploitation and long-term Windows persistence.