Loading story…
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.
Get the actors, campaigns, and ATT&CK mapping behind it.
5 events from the most recent confirmed update back to the earliest known activity.
The same testing showed that PowerShell Module Logging event 4103 still captured meaningful evidence of the executed code, while AMSI and Windows Defender detected the smuggling code as malicious and blocked execution in the lab.
In lab testing, dfir.ch found that PowerShell Script Block Logging event 4104 recorded the spoofed benign command rather than the executed malicious command, and the executed AST did not appear as a separate Script Block Logging entry.
BC-Security presented "ScriptBlock Smuggling," a PowerShell technique described as spoofing arbitrary messages into Script Block logs while bypassing AMSI without reflection or memory patching.
According to X user @thomasmechen, attackers quickly adapted ScriptBlock Smuggling and used it to spread Vidar Stealer. The dfir.ch analysis also cites a more elaborate example posted by Nasreddine.
AtomicsonaFri announced a new Atomic Red Team test for ScriptBlock Smuggling. The test builds separate spoofed and executed ASTs, combines them into a new ScriptBlockAst, and invokes the resulting script block.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
Get the adversaries, campaigns, and ATT&CK mapping behind this technique, with detections ready to deploy.
2 references tracked. Mallory keeps watching after this page renders.
Map 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.
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.
Aug 15, 2026
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 linked new **LazyScripter** activity to the **Octopus** backdoor after analyzing malicious document lures that targeted Windows users with a fake patch PDF and a Microsoft Word file containing embedded fake PDF objects. In both cases, user interaction triggered heavily obfuscated batch scripts that downloaded additional payloads from `hpsj.firewall-gateway.net`, a domain tied to the campaign. Reporting indicates the group has targeted the airline sector since at least 2018, and the latest samples reused infrastructure and tradecraft previously associated with Octopus. The scripts focused on rapid host takeover by elevating privileges, disabling **Microsoft Defender** and other Windows security controls, tampering with services and scheduled tasks, modifying the registry for persistence, and using PowerShell download cradles to fetch next-stage malware over ports 80 and 443. The final payload collected host, user, and process information, encrypted the stolen data with **AES-CBC**, and sent it to command-and-control endpoints on the same domain. MITRE ATT&CK tracking for **LazyScripter** also aligns the group with phishing-led initial access, PowerShell and VBScript execution, registry-based persistence, defense evasion, tunneling, and RAT-style post-compromise activity.
Aug 15, 2026