Loading story…
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.
Get the actors, campaigns, and ATT&CK mapping behind it.
5 events from the most recent confirmed update back to the earliest known activity.
On July 13, 2026, Purple Team published material describing persistence via a malicious AMSI provider DLL that registers as a COM server and AMSI provider, and can launch calc.exe when scanned content matches a trigger string.
A GitHub repository named Amsi-Bypass-Powershell was published, collecting numerous PowerShell-focused AMSI bypass and evasion methods from prior research and offensive tradecraft. The repository includes techniques such as AmsiScanBuffer patching, AmsiUtils manipulation, provider interception, DLL hijacking, PowerShell v2 fallback, and logging tampering guidance.
On June 17, 2022, Mariusz Banach (mgeeky) published the Stracciatella project, a C# tool for launching PowerShell runspaces while attempting to disable AMSI, ETW, and Script Block Logging before execution.
On June 18, 2018, MDSec published research detailing multiple PowerShell defense-evasion techniques, including AMSI bypasses via reflection and amsi.dll patching, plus script block logging bypasses through cached policy and signature manipulation.
Adam Chester's MDSec article states that Matt Graeber made an early public reference in 2016 to the AMSI bypass that uses reflection to set System.Management.Automation.AmsiUtils.amsiInitFailed to true.
Vulnerabilities, threat actors, malware, products, organizations, breaches, and observables Mallory has linked to this story. Indicator values are masked here and available in full in the app.
Indicator values are masked on this page. See the values in Mallory Domains, IPs, hashes, and URLs are exportable to your SIEM.
Get the adversaries, campaigns, and ATT&CK mapping behind this technique, with detections ready to deploy.
4 references tracked. Mallory keeps watching after this page renders.
ipurple.team
Open sourcegithub.com
Open sourcegithub.com
Open sourcemdsec.co.uk
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Threat researchers report that attackers and malware operators continue to bypass Microsoft’s **Antimalware Scan Interface (AMSI)** on Windows, weakening a key inspection layer for PowerShell and other script-based activity. Recent telemetry highlighted two dominant techniques: tampering with PowerShell’s `AmsiUtils` state, including the `amsiInitFailed` flag, and patching AMSI-related code in memory—especially `AmsiScanBuffer` or `amsi.dll`—to force scan failures. Sophos said memory-patching now accounts for most observed AMSI bypass attempts and has appeared in activity involving **Cobalt Strike**, **Agent Tesla** downloaders, **WannaMine**, and intrusions linked to **ProxyLogon** exploitation. Separate research showed that an older AMSI bypass using **DLL hijacking** can still work by planting a fake `amsi.dll` with the expected exports in specific directories, in some cases even without elevated privileges. SensePost said Microsoft did not assign a CVE because AMSI is not treated as a security boundary, but **Windows Defender** added detections that reduce the technique’s reliability for low-privileged users, and the PowerShell team was reported to be working on a fix. Researchers also noted that attackers may sidestep AMSI through PowerShell version downgrades, alternate scripting engines such as `jscript` or `cscript`, or other evasive tradecraft, reinforcing that AMSI should be backed by **defense in depth** and timely patching rather than relied on as a standalone control.
Aug 15, 2026
Researchers documented **ScriptBlock Smuggling**, a PowerShell technique that can spoof benign content in Script Block Logging and help bypass AMSI inspection without using reflection or patching. The method abuses how PowerShell handles script blocks so that security tooling may record an innocuous command while a different payload executes, creating a misleading audit trail for defenders reviewing event `4104` logs. Follow-up forensic testing found the technique does not fully erase evidence of malicious activity. In lab experiments, Script Block Logging captured the spoofed command, but the surrounding smuggling logic and PowerShell Module Logging event `4103` still revealed execution details, including a proof of concept that used `Invoke-WebRequest` to download a file. Researchers also noted reports that the approach had been adapted for **Vidar Stealer** delivery, while Microsoft Defender and AMSI still detected the tested samples as malicious, indicating the technique can hinder visibility but not eliminate forensic traces.
Aug 1, 2026
Attackers can abuse **PowerShell profile scripts** to gain persistence on Windows by placing malicious commands in `profile.ps1`, causing a payload to run automatically whenever a user starts a PowerShell session. A proof-of-concept example showed a helper program creating the `WindowsPowerShell` profile directory and writing a command that launched a payload, which then executed with `powershell.exe` as its parent process. The technique has also been linked to real-world activity, with reports noting **Turla** has used PowerShell profile persistence in the wild. Microsoft’s documentation shows why the method is effective: PowerShell supports multiple profile locations and scopes, including per-user and all-users profiles and host-specific variants, all of which can execute at startup depending on configuration and privileges. The same documentation also outlines key defensive controls, including enforcing signed scripts through execution policy, using `pwsh -NoProfile` to prevent profile loading, and understanding that profile behavior differs across platforms and remote sessions, which can affect both attacker tradecraft and defender response.
Aug 15, 2026