ipurple.team via Reddit

WinGet YAML Configs Execute PowerShell, Evade Detection

microsoft cybersecurity windows-security evasion

Key insights

  • WinGet's configure parameter runs PowerShell via YAML DSC files without spawning a standard PowerShell process, bypassing PowerShell-specific monitoring controls.
  • Researchers Dylan Davis and Matthew Schramm demonstrated a COM API variant via the DSCourier tool that skips the WinGet binary, leaving only WindowsPackageManagerServer.exe as evidence.
  • Malicious YAML configs can masquerade as .jpg or .txt files and be fetched from remote HTTPS servers, defeating file-type-based inspection at the perimeter.

Why this matters

Windows Package Manager is part of the Windows-native toolchain, meaning this execution vector requires no additional attacker tooling and exists on a broad population of enterprise endpoints. The COM API variant via DSCourier bypasses the WinGet binary entirely, leaving defenders reliant on monitoring process names like WindowsPackageManagerServer.exe that fall outside most existing detection rule sets. The ability to fetch malicious configurations disguised as .jpg or .txt files from remote HTTPS servers means file-type inspection and perimeter filtering provide no meaningful barrier against this technique.

Summary

WinGet, Microsoft's Windows Package Manager, can execute arbitrary PowerShell via YAML Desired State Configuration files without ever spawning a standard PowerShell process, and researchers Dylan Davis and Matthew Schramm have built proof-of-concept tools to demonstrate exactly how it works. The attack uses WinGet's configure parameter to load YAML files containing PowerShell through the PSDscResources module. Those files can carry any extension (.jpg, .txt) and be fetched from remote HTTPS servers. A stealthier COM API variant called DSCourier skips the WinGet binary entirely, leaving only WindowsPackageManagerServer.exe as a process trace. Essentially: (iPurple Team, Dylan Davis, Matthew Schramm) have documented a living-off-the-land technique that hides arbitrary code execution inside Windows-native package management tooling. - Local Administrator privileges are required, but no additional attacker tooling beyond WinGet itself is needed. - Execution history is saved to a config.db SQLite database at a known path under AppData, available for post-incident forensics. - ConfigurationRemotingServer.exe and WindowsPackageManagerServer.exe process spawning are the primary detection signals defenders can act on. With detection hinging on monitoring unfamiliar process names and a database artifact that only captures history after execution completes, the window for catching this attack in real time is narrow.

Potential risks and opportunities

Risks

  • Enterprise endpoints without process-monitoring rules for ConfigurationRemotingServer.exe are exposed to persistence and reverse shell deployment via WinGet YAML abuse requiring only local Administrator access.
  • Attackers can fetch malicious configs from HTTPS endpoints using files disguised as .jpg or .txt, defeating file-type inspection and rendering perimeter filtering ineffective against this vector.
  • The config.db SQLite database forensic artifact captures execution history only after the fact, meaning detection gaps exist during the live execution window before incident responders review AppData logs.

Opportunities

  • EDR and endpoint security vendors (CrowdStrike, Microsoft Defender, SentinelOne) can differentiate by shipping detection logic specifically targeting ConfigurationRemotingServer.exe and WindowsPackageManagerServer.exe spawning anomalies.
  • Application control and allowlisting vendors (Carbon Black App Control, Airlock Digital) can expand coverage to block WinGet DSC-based execution paths before DSCourier-like tools appear in commodity malware kits.
  • Threat intelligence platforms cataloging living-off-the-land binaries can add WinGet DSC abuse to their detection databases, giving security teams actionable coverage for Windows-native tooling misuse.

What we don't know yet

  • Whether Microsoft has acknowledged this WinGet DSC abuse vector and plans any configuration control or patch to restrict remote YAML execution.
  • Whether DSCourier or similar COM API-based tools have appeared in real-world attacks beyond the iPurple Team proof-of-concept stage.
  • Whether major EDR vendors such as CrowdStrike, SentinelOne, or Microsoft Defender have shipped detection rules targeting ConfigurationRemotingServer.exe and WindowsPackageManagerServer.exe spawning by anomalous parent processes.

Originally reported by ipurple.team

Read the original article →

Original headline: WinGet Abused for Stealthy Code Execution and Security Tool Evasion via YAML PowerShell DSC Files — No CVE, No Patch