Loading story…
Researchers reported that Microsoft WinGet can be abused as a living-off-the-land binary to execute arbitrary PowerShell logic through its winget configure feature and Desired State Configuration (DSC) resources. The technique uses YAML configuration files supplied from local storage or remote URLs, which are processed by ConfigurationRemotingServer.exe; WinGet can also download DSC modules into %LOCALAPPDATA%\Microsoft\WinGet\Configuration\Modules. Because the activity does not require directly launching powershell.exe, it may reduce defender visibility even though execution still flows through System.Management.Automation and AMSI.
Follow-on research showed the same execution path can be triggered more stealthily through the WinGet COM API, avoiding a visible WinGet.exe process while still enabling offensive actions such as reverse shells and persistence through local administrator creation. The reports said some EDR tools may not classify the behavior as malicious and urged defenders to monitor WinGet-related process creation, child process activity from ConfigurationRemotingServer.exe, network connections, DLL loads, registry changes, AMSI telemetry, and forensic artifacts including WinGet’s config.db history database.
Get the actors, campaigns, and ATT&CK mapping behind it.
3 events from the most recent confirmed update back to the earliest known activity.
An ipurple.team article published offensive examples of WinGet abuse, including a reverse shell and local administrator creation for persistence, and provided detection guidance focused on process creation, network connections, DLL loads, and forensic review of WinGet's config.db history database.
Dylan Davis and Matthew Schramm demonstrated invoking the WinGet configuration engine through an API instead of WinGet.exe, producing a process tree where WindowsPackageManagerServer.exe parents ConfigurationRemotingServer.exe. The ipurple article identifies DSCourier as a proof-of-concept for this technique.
A researcher using the handle TwoSevenOneThree showed that Microsoft WinGet can execute PowerShell code embedded in YAML configuration files through Desired State Configuration resources, including fetching configurations from remote HTTPS locations and disguising them with non-.yaml extensions.
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
Researchers highlighted how Windows Management Instrumentation (**WMI**) can be abused to establish stealthy, fileless persistence on Windows systems and to support remote execution across an enterprise. Black Hat research detailed the use of permanent WMI event subscriptions, asynchronous event consumers, and WMI-based backdoors that can survive reboots while leaving limited traditional malware artifacts on disk. Follow-on research showed WMI remains relevant for lateral movement because it provides native access to remote process creation, system management, and execution through trusted Windows components. The combined findings reinforce that defenders should treat unusual WMI activity, remote WMI execution, and unauthorized event subscription creation as high-priority indicators of compromise in environments where attackers seek persistence and post-compromise mobility.
Aug 9, 2026
SpecterOps research highlighted that **Windows Subsystem for Linux 2 (WSL2)** can be abused as a stealthy execution and persistence layer on Windows endpoints because each WSL2 distribution runs as its own **Hyper-V VM** with a separate Linux filesystem and processes. Attackers can inject a beacon object file into an installed WSL2 distro to execute arbitrary commands, read files, and pivot into a Linux environment while many endpoint tools primarily observe only a short-lived `wsl.exe` process on the Windows side. The research also noted that the `$WSL` share and in-guest activity may not be scanned or instrumented by multiple security products, degrading common alerting rules and enabling longer dwell time and harder incident investigations. Operationally, this tradecraft allows intruders to run Linux utilities “out of sight” of traditional Windows-focused telemetry, potentially supporting internal reconnaissance, lateral movement, credential access, and data staging from within the WSL2 guest while maintaining access to corporate resources. The reporting recommends expanding defensive coverage to include **WSL2 activity monitoring and logging** (beyond `wsl.exe` process starts) to reduce blind spots created by the Windows/Linux boundary and to improve detection of malicious tooling and persistence inside WSL2 distributions.
Jun 29, 2026