SaassyCode shows VS Code extensions can hide persistent loaders

At a glance

What this is: This is Knostic’s analysis of SaassyCode, a campaign in which malicious VS Code extensions acted as runtime loaders and delivered staged payloads through shared malware infrastructure.

Why it matters: It matters because developer tools can become hidden execution paths that bypass normal software trust assumptions, which affects NHI governance, endpoint controls, and supply chain monitoring.

👉 Read Knostic's analysis of the SaassyCode VS Code extension campaign

Context

Malicious VS Code extensions can behave like trusted software while actually acting as loaders for staged payloads. In this campaign, the extension code executed automatically on startup, which means the identity and execution problem is not the marketplace listing itself but the runtime trust granted to extension code.

For IAM and NHI teams, the key issue is that software delivery is now tightly coupled to identity-bearing execution on the endpoint. When a trusted developer tool can spawn hidden loaders, persist in system directories, and invoke scripting engines, the security boundary shifts from install-time review to ongoing runtime governance.

This is a supply chain and execution control problem that sits adjacent to identity security rather than outside it. The campaign is atypical in scale but typical in structure, because it uses familiar Windows living-off-the-land behavior to blend code execution, persistence, and staging into ordinary developer workflows.

Key questions

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. Approve them only if you can monitor outbound domains, child processes, and post-install payload changes. If an extension can download new code after review, its trust profile changes continuously and requires runtime detection, not just marketplace vetting.

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. The real signal is the process lineage from the editor, the remote payload fetch, and unusual write locations such as %TEMP% or hidden program data paths.

Q: What do security teams get wrong about extension trust?

A: Teams often assume publish-time review is enough. In reality, a remote loader can keep changing after approval, so the actual execution must be governed by content integrity, network destinations, and child-process behaviour. A trusted listing is not the same as trusted runtime behaviour.

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.

Technical breakdown

How malicious VS Code extensions become runtime loaders

A VS Code extension can declare broad activation events, including activation on every editor start, and then execute code before a user opens the extension UI. In this campaign, the extension downloaded a second-stage JavaScript payload and launched it through Windows Script Host, which turns the extension into a runtime loader rather than a static plugin. That separation between marketplace package and remote payload is the key control break. The code that was reviewed in the marketplace is not necessarily the code that runs later, because the payload can be swapped server-side without republishing the extension.

Practical implication: treat extension approval as runtime-risk approval, not just marketplace hygiene.

Staged payload delivery and living-off-the-land execution

The observed chains used multi-stage delivery through JScript, VBS, batch, and PowerShell, with each stage unpacking the next. The batch layer carved decoy and real payload blobs out of lines marked with special delimiters, decoded the loader with base64 plus XOR, and then invoked an in-memory PowerShell injector. This design reduces static signature value and keeps the malicious logic fragmented across formats that defenders often inspect separately. The use of cscript.exe, cmd.exe, and powershell.exe also blends into common admin tooling, which makes detection depend on process lineage and content analysis rather than simple file hashes.

Practical implication: alert on multi-script process chains, not just suspicious binaries.

Persistence under C:\ProgramData\IntelDriver and masqueraded binaries

The payloads established persistence by hiding files under C:\ProgramData\IntelDriver\ and by copying PowerShell into a user Downloads path under the name svchost.exe. That pattern combines filesystem masquerade with system-like naming to evade casual inspection and some basic allowlist logic. The final stage also used scheduled task creation, memory injection, and ETW patching, which shows the operator was aiming for durable execution and reduced telemetry visibility. The persistence choice is especially important because it moves the problem from a one-off dropper to a repeatable endpoint foothold.

Practical implication: hunt for non-standard PowerShell copies and hidden system-like directories in user and program data paths.

Threat narrative

Attacker objective: The attacker objective is to establish persistent Windows endpoint execution from a trusted developer extension and use that foothold to deliver and run hidden follow-on payloads.

1. Entry began when users installed malicious VS Code extensions that activated automatically on editor startup and fetched remote JavaScript payloads from attacker-controlled domains.
2. Escalation occurred as the staged loaders used Windows Script Host, batch crypters, and in-memory PowerShell injection to unfold deeper payloads while hiding behind normal Windows execution paths.
3. Impact followed through persistence in C:\ProgramData\IntelDriver, scheduled task creation, process injection, and telemetry tampering that gave the operator durable endpoint control.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Developer tooling now carries identity-like execution authority: A VS Code extension that can spawn script hosts, write to program data, and create scheduled tasks behaves like an identity-bearing workload on the endpoint. That makes it part of the NHI problem space even when the object is packaged as software, because it can act, persist, and stage independently of user intent. Teams should treat extension execution as a governed non-human actor, not a harmless plugin.

Hidden persistence paths are the symptom of insufficient endpoint control alignment: C:\ProgramData\IntelDriver and renamed svchost.exe copies show that the operator expected defenders to key on common filenames rather than lineage and location. This is a classic mismatch between control design and attacker tradecraft. Practitioners need controls that bind execution legitimacy to origin, path, and child process behavior, not to file names alone.

Supply chain review must include payload mutability, not just publisher reputation: The rogiant chain showed that the attacker could change what runs without changing the extension version because the payload lived outside the VSIX. That breaks the assumption that a signed or reviewed package remains stable after approval. The practitioner conclusion is that mutable payload hosting is itself a governance signal.

Extension abuse is now a blended endpoint and identity issue: The campaign is not only malware delivery, and not only software supply chain risk. It is a trust problem where a developer tool, remote payload host, and local Windows script hosts collectively form the execution path. Security programmes that split endpoint, software supply chain, and identity ownership will miss the combined risk.

From our research:

• 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.
• For a broader breach pattern view, 52 NHI Breaches Analysis shows how exposed credentials and runtime abuse turn fast into persistent access.

What this signals

Hidden execution inside developer tooling is becoming an identity governance problem, not just an endpoint problem: when software can fetch and execute new payloads after approval, the governance model has to follow runtime identity behaviour rather than marketplace reputation. That same shift shows up in NHI programmes, where static review fails once the actor can change what it does after onboarding.

Ephemeral trust debt: this campaign shows how a trusted extension can accumulate runtime permission debt the moment it starts fetching code and creating persistence. The practical signal is that teams need to track which tools can introduce new executable state after installation, because that is where the control boundary actually moves.

The operational lesson is simple. If your programme only watches installed software and not spawned processes, writable persistence paths, and mutable payload hosting, you are measuring the wrong layer of trust. That gap is especially visible in AI-enabled developer environments, where one extension can become the first hop in a broader compromise chain.

For practitioners

• 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. Prioritise extensions that can execute before a user opens the extension UI.
• 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.
• Require runtime inspection for mutable extension payloads Do not rely on marketplace review alone when the extension downloads executable content after install. Correlate extension metadata with outbound domains, content hashes, and child process behavior during execution.
• Cross-link developer endpoint alerts with NHI governance workflows Treat extension-driven loaders as non-human execution paths that need ownership, lifecycle review, and removal handling. Use the NHI Lifecycle Management Guide to align ownership and offboarding of persistent tooling artifacts.

Key takeaways

• SaassyCode shows that malicious VS Code extensions can function as runtime loaders, not just unwanted add-ons.
• The campaign reused common Windows scripting and persistence techniques, which means detection has to focus on process lineage, payload mutability, and hidden filesystem paths.
• Teams should treat developer extensions as governed execution surfaces and align endpoint telemetry with identity and supply chain controls.

Key terms

• Runtime Loader: A runtime loader is code that fetches or unpacks additional payloads after initial installation or launch. In practice, it means the reviewed package is only a first stage, and the real behavior can change later without a new release.
• Living-off-the-land Execution: Living-off-the-land execution uses legitimate operating system tools to run malicious actions. The technique reduces obvious malware signals because the attacker relies on trusted binaries such as script hosts, batch interpreters, or PowerShell instead of dropping a custom executable.
• Payload Mutability: Payload mutability is the ability for an attacker to change what code runs after a benign-looking package has been approved. It matters because trust based on a single version or hash no longer describes the actual runtime risk once remote content can be swapped in.
• Process Lineage: Process lineage is the parent-child chain of running processes that shows how execution began. In this campaign, lineage from the editor into script hosts and loaders is more informative than file names alone, because legitimate tools were used as launch points.

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.

👉 Knostic's full post covers the staged loaders, persistence artifacts, and campaign linkage details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.