Notifications
Clear all
Topic starter
09/07/2026 9:34 am
TL;DR: Two malicious VS Code extensions used the marketplace as a delivery layer for staged Windows loaders that ran on every startup, hid persistence under C:\ProgramData\IntelDriver, and reused the same builder toolkit across two campaign instances, according to Knostic. The pattern shows that developer tooling can become an identity and execution control gap when extension trust is treated as a packaging problem instead of a runtime governance problem.
NHIMG editorial — based on content published by Knostic: SaassyCode and malicious VS Code extensions targeting users of Trello and Roblox
Questions worth separating out
Q: How should teams handle VS Code extensions that fetch code at runtime?
A: Treat runtime-fetching extensions as executable supply chain components, not static productivity tools.
Q: Why are malicious developer extensions hard to detect in practice?
A: They often use normal tools such as cscript.exe, cmd.exe, and powershell.exe, which blend into legitimate administration.
Q: What do security teams get wrong about extension trust?
A: Teams often assume publish-time review is enough.
Practitioner guidance
- Inventory extension activation events and remote fetch behavior Flag any VS Code extension that activates on startup, spawns script hosts, or retrieves code from a remote domain after installation.
- Hunt for script-host process chains from code.exe Alert on code.exe spawning cscript.exe, wscript.exe, cmd.exe, or powershell.exe, especially when the child process writes to %TEMP%, %ProgramData%, or a user Downloads directory.
- Block masqueraded PowerShell and suspicious program-data persistence Search for svchost.exe outside system paths, hidden system-like folders under C:\ProgramData\IntelDriver, and scheduled tasks created by script interpreters rather than approved management tools.
What's in the full article
Knostic's full analysis covers the operational detail this post intentionally leaves for the source:
- Complete IoC set for both campaign instances, including domains, hashes, staged filenames, and persistence artifacts.
- Automated reverse-engineering notes for the stage-4 payloads, including the shared builder/operator toolkit.
- Campaign linkage evidence showing how the two extension families share tooling while differing in delivery infrastructure.
- Endpoint-level detection context for the process trees, renamed binaries, and scheduled task behavior.
👉 Read Knostic's analysis of the SaassyCode VS Code extension campaign →
VS Code extensions as loaders: what SaassyCode means for teams?
Explore further
09/07/2026 9:35 am
Runtime trust for developer extensions is the real control plane: The marketplace package is only a delivery container if it can fetch and execute remote payloads at runtime. That means review processes focused on code at publish time miss the actual execution boundary. The practitioner conclusion is that extension governance has to move from install approval to continuous runtime inspection.
A few things that frame the scale:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
A question worth separating out:
Q: What should organisations do when an extension starts spawning script hosts?
A: Contain the endpoint, remove the extension, and inspect for persistence artifacts such as scheduled tasks, renamed binaries, and hidden directories under program data. Then review whether similar runtime loaders exist elsewhere, because one compromised extension often indicates a broader allowance problem.
👉 Read our full editorial: SaassyCode shows VS Code extensions can hide persistent loaders
