SaassyCode’s VS Code extension campaign shows active malware persistence

At a glance

What this is: Knostic says the SaassyCode VS Code campaign kept expanding, with five more malicious extensions published after disclosure and one still live.

Why it matters: Developer tools can become an identity and supply-chain foothold, so IAM, endpoint, and secrets teams need to treat IDE extensions as a governed attack surface.

By the numbers:

• As of June 11, the campaign stands at 24 confirmed extensions and more than 32,000 installs across the full campaign.

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

Context

SaassyCode is a malicious VS Code extension campaign that abuses the trust developers place in marketplace extensions and update mechanisms. The issue is not just malware distribution. It is the use of a familiar developer tool as an access path into endpoints, secrets, and potentially downstream identity material.

For IAM and NHI teams, the governance gap is that workstation tooling often sits outside the same control plane used for service accounts, tokens, and privileged access. When an extension can execute code at every startup and drop payloads through normal update flows, traditional application allowlisting and manual review are too slow to matter.

Key questions

Q: What should security teams do when a VS Code extension starts spawning script hosts?

A: Treat code.exe spawning cscript.exe or mshta.exe as a high-confidence compromise signal, not as normal editor behavior. Investigate the extension version, publisher name, and any script files in %TEMP%. Remove the extension from all managed endpoints, then check for stolen tokens, cached credentials, and any other developer secrets that may have been exposed during execution.

Q: Why do malicious developer extensions increase identity risk?

A: Because they can inherit trust from a managed workstation and reach the same secrets, session artifacts, and local credentials that attackers value in other NHI compromise paths. Once the extension executes, the editor environment becomes part of the identity perimeter. That means extension governance, endpoint control, and secrets monitoring need to work together, not separately.

Q: How can organisations reduce risk from silent extension updates?

A: Use separate approval for first install and for subsequent version changes, especially where extensions can execute code or access local files. Monitor version history, publisher changes, and new child-process behavior after update. If an extension was approved months ago, do not assume the current version is still the same risk profile.

Q: What is the difference between extension allowlisting and workload identity governance?

A: Extension allowlisting controls what can run on the developer endpoint, while workload identity governance controls what tokens, keys, and service accounts that endpoint can reach. In practice, you need both. A trusted workstation can still become the launch point for secret theft, so identity controls must extend into the tools developers use every day.

Technical breakdown

Activation events and startup execution in VS Code extensions

VS Code extensions can register activationEvents that determine when code runs. In this campaign, the malicious extensions use activationEvents: ["*"] so the payload can trigger on every startup, not just on first use. That matters because it turns a marketplace install into repeated execution, which increases reliability and shortens the defender's response window. The extension can look functional while still loading hidden logic in the background, so user trust in the UI becomes part of the attack surface. Static review must therefore inspect package metadata and activation paths, not only visible features.

Practical implication: block or flag extensions with broad startup activation unless there is a documented business need and a controlled approval path.

How the dropper chain uses code.exe, cscript.exe, and temporary files

The Boardwalk cluster downloads a JavaScript file from attacker infrastructure, writes it to %TEMP%\lizzy.js, and executes it with cscript.exe from the VS Code process tree. This is a classic loader pattern: the extension itself is the initial installer, Windows Script Host performs the second-stage execution, and temporary file placement helps the payload blend into normal developer activity. The child process chain code.exe to cscript.exe is especially useful for detection because it is not typical VS Code behavior. The chain also creates a clear process-artifact relationship that can be hunted without payload detonation.

Practical implication: alert on code.exe spawning cscript.exe or mshta.exe, and hunt for suspicious script files in %TEMP% tied to extension activity.

Why sleeper updates make extension abuse harder to spot

EasyStudio shows the sleeper model. A benign version is published first, builds trust and installs, then a later update introduces malicious behavior through the normal update mechanism. That pattern defeats one-time review because the initial install can be clean while the operational risk appears only after automatic update. The governance lesson is that marketplace vetting at install time is not enough. You need version-aware monitoring, publisher reputation checks, and update controls that do not assume all extensions remain safe after approval.

Practical implication: compare installed version history against release notes and treat silent extension updates as a separate control point.

Threat narrative

Attacker objective: The attacker aims to use trusted developer tooling to gain repeated code execution on endpoints and create a foothold for secret theft or follow-on compromise.

1. Entry occurs when a developer installs a seemingly useful VS Code extension from the marketplace and the extension activates on startup.
2. Escalation occurs when the extension downloads a second-stage script, writes it to a temporary path, and launches cscript.exe or mshta.exe from code.exe.
3. Impact occurs when the payload gains repeated execution on every VS Code startup, creating a durable foothold for credential theft or further payload delivery.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.

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

NHI Mgmt Group analysis

Trusted developer tooling is now part of the identity attack surface. A malicious extension does not need to break authentication to matter. It can inherit trust from the developer workstation, then abuse that trust to reach secrets, session artifacts, and downstream services. The practitioner implication is that workstation software provenance now belongs in identity governance, not only endpoint hygiene.

Extension marketplaces have become a practical persistence layer. The SaassyCode pattern shows that a clean install can become a weaponised update without changing the user's behaviour. That undermines review models that focus on first install approval and ignore version drift. Practitioners should treat marketplace update channels as lifecycle events with security consequences, not as passive delivery plumbing.

Process lineage is the most useful early signal in this campaign. The repeated code.exe to cscript.exe and code.exe to mshta.exe chains are not normal developer workstation behavior. That makes process ancestry a stronger detection point than payload classification alone. The implication is that identity and endpoint teams should hunt for abnormal child processes as evidence of developer-tool abuse, not wait for malware signatures.

Extension approvals need a separate governance model from software allowlisting. A code editor extension is small enough to pass casual review but privileged enough to access tokens, files, and browser state. That creates a governance blind spot between desktop software control and identity control. The practitioner conclusion is that extensions should be governed as delegated execution, with explicit lifecycle review and revocation.

Identity blast radius is the right concept for developer ecosystems. A single extension install can expose local secrets, cached credentials, and paths into cloud accounts if the workstation is already a trusted source of tokens. The broader the workstation's identity footprint, the larger the blast radius from one malicious extension. Security programmes should measure extension exposure alongside secrets exposure and endpoint privilege.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, according to The State of Secrets in AppSec.
• The average of 6 distinct secrets manager instances creates fragmentation that undermines centralised control, according to The State of Secrets in AppSec.

What this signals

Developer workstation governance now needs the same seriousness as secrets governance. A trusted extension can become a delivery vehicle for payloads that reach browser-stored passwords, session tokens, and API keys. The practical shift is to treat IDE telemetry, extension inventory, and child-process monitoring as part of identity security operations, not as separate desktop concerns.

With 43% of security professionals already concerned about AI systems learning and reproducing sensitive information patterns from codebases, per The State of Secrets in AppSec, any compromise path that touches developer tools also touches the data that powers AI-assisted coding and search. That makes extension hygiene a data governance issue as much as an endpoint issue.

The immediate programme signal is that version-aware controls matter more than one-time approval. An extension that was safe at install time can become a different risk at update time, so security teams should plan for continuous review of publisher reputation, process lineage, and secret exposure on managed developer devices.

For practitioners

• Inventory all installed VS Code extensions Build an enterprise inventory of installed extensions, including version history and publisher name, so you can identify the live Boardwalk Plus package and any lookalike publisher variants.
• Hunt for suspicious process ancestry Alert on code.exe spawning cscript.exe or mshta.exe, then check whether the child process wrote script files into %TEMP% or executed from an extension directory.
• Review auto-update behavior for developer tools Separate initial approval from update approval for extensions, because a clean first release can later deliver malicious functionality through the normal marketplace channel.
• Treat developer endpoints as secret-bearing systems Assume browser-stored passwords, API keys, session tokens, and developer secrets may be reachable after extension abuse, and validate whether endpoint containment limits that exposure.
• Remove matching publisher variants immediately Search for close publisher-name variants associated with the same extension family and revoke them across managed workstations before further execution occurs.

Key takeaways

• SaassyCode shows that a developer extension can function as a durable compromise path even when the UI appears legitimate.
• The campaign's scale, with 24 confirmed extensions and more than 32,000 installs, shows how quickly extension abuse can propagate across developer environments.
• Process lineage, version control, and secret exposure monitoring are the controls most likely to shorten detection and limit blast radius.

Key terms

• Malicious Extension Update: A malicious extension update is a later version of a trusted tool that introduces harmful code after initial approval. The risk is lifecycle drift, where a clean first release becomes an execution vehicle through the normal update path and bypasses the trust decision made at install time.
• Process Lineage: Process lineage is the parent-child chain of processes created during execution on an endpoint. In identity investigations, it helps distinguish normal application behavior from abuse, especially when a trusted application like an editor spawns script hosts or shell-like tooling that it would not normally use.
• Developer Endpoint Blast Radius: Developer endpoint blast radius is the amount of identity and secret exposure that becomes reachable if a workstation is compromised. It includes local credentials, cached session tokens, API keys, and any paths into cloud services that the workstation can access through the developer's normal environment.

What's in the full article

Knostic's full research covers the operational detail this post intentionally leaves for the source:

• Full extension metadata for the Boardwalk cluster, including publisher names, install counts, and version identifiers.
• Static source-code findings from extension.js, including the exact activation logic and dropper chain.
• Additional indicators of compromise, including file paths, hashes, and network IOCs not reproduced here.
• Remediation notes and methodology details for analysts validating the campaign across managed endpoints.

👉 The full Knostic post covers extension metadata, dropper details, and additional IOCs.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.