Update and Infect: How the SaassyCode Campaign Grew from Two Extensions to Nineteen

This post updates our original SaassyCode disclosure from June 1, 2026. It documents the full nineteen-extension campaign family, new technical findings, and active indicators for defenders. Read the original post →

Executive Summary

• Knostic's June 1 disclosure identified two malicious VS Code extensions. Continued investigation has confirmed they are part of a coordinated family of nineteen extensions, published over a 19-day window from May 20 to June 7, 2026 and still growing.
• Combined installs across confirmed malicious extensions now exceed 17,544 -  ManageRBLX (8,184), TrelloBlox (8,077), StudioBoard (1,281), and BloxyTask (2). These figures represent Marketplace download counts; actual infection rates are lower, as the payload executes on Windows only and requires VS Code to restart after installation.
• In at least one confirmed case, the actor used a sleeper strategy: publishing a clean version of an extension first, then delivering a malicious update through the normal VS Code update mechanism.
• Five extensions were published within a three-minute window on June 4, consistent with an automated publishing pipeline.
• The campaign continued after Knostic's June 1 disclosure. Three additional extensions (StudioBoard, RoTracker, and RblxTasker) were published on June 6–7 and confirmed malicious by AgentMesh. StudioBoard had accumulated 1,281 installs by the time of detection and pushed four versions in a single day.
• BloxyTask, the most technically advanced variant, introduces a five-stage infection chain ending in shellcode injection into a Windows system process. The final payload's capabilities and command-and-control infrastructure remain unconfirmed pending dynamic analysis.
• The payload execution chain in this family affects Windows only. Developers on macOS or Linux who installed these extensions were not subject to the same infection chain.
• At the time of publication, at least one sleeper extension — ManageR2BLX2 — remained live on the VS Code Marketplace. Static analysis confirms it carries no active payload but is a confirmed family member pre-positioned for weaponisation.

How the Investigation Started

On June 1, we published findings on two malicious VS Code extensions: ManageRBLX and TrelloBlox. Both posed as Trello-style Kanban board tools for Roblox and game developers, both activated silently on VS Code startup, and both downloaded and executed a multi-stage payload chain without any user interaction. Together they had accumulated over 16,000 installs before removal.

That disclosure closed the immediate threat, but the investigation did not stop there.

In the days following publication, AgentMesh (Knostic's continuous monitoring system for the VS Code Marketplace) flagged new extensions with familiar characteristics: the same lure description word for word, the same activation pattern, the same extension structure. Publisher names changed. Extension names changed. The core toolkit did not.

What had appeared to be a two-extension incident turned out to be a coordinated, still-active campaign of nineteen.

From Two Extensions to Nineteen

The nineteen extensions fall into two clear categories: thirteen malicious extensions built to deliver a payload, and six sleepers with clean code pre-positioned for future weaponisation. Within the malicious group, clusters reflect different delivery infrastructure and technique — with the most recent cluster representing a post-disclosure escalation that introduced heavy obfuscation as a new evasion layer.

Most extensions in the family were published under a publisher account sharing the extension's own name — a pattern consistent with automated account generation at scale. Several exceptions exist, including the two original extensions and BloxyTask.

On Cluster D: BloxTasker and ManageBlox contain the same malicious activate() skeleton as all other weaponised family members. The distinction from Cluster E sleepers is clear: sleepers have no payload delivery code at all.
On Cluster F: StudioBoard, RoTracker, and RblxTasker were published after Knostic's June 1 disclosure, representing the actor's response to detection pressure — shifting to heavy JavaScript obfuscation to evade static analysis. All three share identical evidence line numbers in AgentMesh scans, confirming they were built from the same obfuscated template.

Full Family Reference — All 19 Extensions

Campaign Evolution: Infrastructure Under Pressure

The infrastructure this campaign used did not stay static. It changed, and the timing of each change suggests the actor was actively monitoring for disruption.

The first two extensions pointed to custom-registered domains for payload delivery. After Knostic's June 1 disclosure, no new extensions pointed to those domains. The next wave used a GitHub repository (hxxps://github[.]com/jjengu/heyheyhey) as the payload source. GitHub is a deliberate infrastructure choice: the domain is widely trusted and rarely blocked by corporate network controls.

Later extensions diversified further. One used Netlify for payload hosting. BloxyTask delivered its first stage through a Cloudflare Worker. Then, in the wave published after the June 1 disclosure, the actor introduced a new technique: heavy JavaScript obfuscation. Rather than changing hosting infrastructure, Cluster F extensions hide their C2 URLs inside obfuscated code, making static analysis significantly harder and rendering simple URL-based detection ineffective.

The progression — custom domain → GitHub → CDN → serverless → code obfuscation — demonstrates consistent adaptation. Each detection event produced a measurable technical response within days.

The pace of publishing reinforces that this was not casual activity. On June 4, five of six new extensions appeared within a three-minute window. StudioBoard alone pushed four version updates on June 6–7 — suggesting active iteration in direct response to detection signals.

The Sleeper Strategy

The most strategically significant finding in this investigation is not a technical one. It is a question of timing.

VS Code extension security monitoring typically focuses on newly published extensions. The assumption underlying most detection approaches is that a malicious extension carries its payload from the moment it appears on the Marketplace. The SaassyCode actor, in at least one confirmed case, used a different approach.

TrelloBlox was first published as version 4.9.6. That version was clean, with no malicious code, no payload download, no outbound connections. It existed on the Marketplace, accumulating installs, with nothing to flag. Then version 5.7.0 was published. That version contained the downloader. The two versions are confirmed as distinct by their SHA-256 hashes. Users who had installed the clean version and had VS Code's default automatic extension updates enabled would have received the malicious version without reinstalling with no prompt, no new installation event, and no indication that the extension they had already trusted had changed.

How a Sleeper Becomes Malicious

Conceptual illustration based on confirmed family behaviour. The structural pattern below reflects what was observed across weaponised family members. Source code for TrelloBlox v4.9.6 (clean) was not recovered; the clean activation pattern shown is consistent with what static analysis confirmed in other family sleepers.

Clean version (e.g. TrelloBlox v4.9.6 - confirmed clean by SHA-256)

activate()

├─ Register extension command

├─ Open Kanban board on command trigger

└─ Display UI

No network activity. No process execution. No payload delivery.

Weaponised update (e.g. TrelloBlox v5.7.0 — confirmed malicious by SHA-256)

activate()

├─ [ADDED] Fetch remote file from external host (runs on every VS Code startup)

├─ [ADDED] Write fetched content to temp directory

├─ [ADDED] Execute via Windows Script Host (hidden window)

├─ Register extension command

├─ Open Kanban board on command trigger

└─ Display UI

The user does not reinstall the extension. VS Code updates it silently in the background through the normal extension update mechanism. On the next VS Code startup, the updated activate() function runs automatically — and so does the payload delivery logic that was just added to it.

This is the core risk: the version users and scanners originally reviewed may not be the version running on the endpoint. Publication-time scanning is not sufficient. Security teams need extension inventory, version tracking, update monitoring, and EDR detection for IDE-spawned processes.

This is what we refer to as the sleeper strategy: establish the publisher namespace, build a legitimate install base, then weaponise via routine update. To be precise about the evidence: this pattern is directly confirmed for TrelloBlox. Whether it was used for other extensions in the family cannot be determined from available data.

The earliest extension in the family, Romanager, was published on May 20 — six days before the first high-install weaponised extension. Romanager had no malicious payload at any observed point. We assess it as likely a publishing pipeline test: the actor confirming they could publish, establish a namespace, and maintain a Marketplace presence before deploying the campaign proper. This is an analyst assessment, not a confirmed finding.

As of June 6, six extensions — Romanager, ManageR2BLX2, RoOrganizer, TaskGrid, RoDesk, and Taskify — remained on the Marketplace with no active payloads but with the same structural fingerprints as the confirmed malicious members. These were assessed as pre-positioned for future weaponisation via the same update mechanism.

At the time of publication, ManageR2BLX2 remained available for install on the VS Code Marketplace. We recommend removing it immediately if installed and reporting it via the VS Code Marketplace report functionality.

ManageR2BLX2 - Static Analysis

ManageR2BLX2 (publisher: broblx8x, v1.0.0) was confirmed live on the VS Code Marketplace at the time this post was published and subjected to full static analysis.

The extension currently functions as a working Kanban board. However, static analysis identified the actor's own ManageRBLX v4.9.6 builder template embedded inside the package as managerblx.zip. The actor left their own toolkit inside the VSIX, providing direct confirmation that ManageR2BLX2 was built from the same assembly line as the rest of the family.

Cluster F: The Post-Disclosure Wave

The three extensions in Cluster F (StudioBoard, RoTracker, and RblxTasker) were published on June 6–7, after Knostic's original disclosure. They represent the actor's clearest documented response to detection pressure: replacing straightforward payload URLs with heavily obfuscated JavaScript that dynamically constructs module names and C2 addresses at runtime.

AgentMesh flagged all three as DANGEROUS, identifying heavy obfuscation, dynamic construction of child_process module references, and suspicious URLs assembled from encoded string fragments. The payload delivery mechanism cannot be fully resolved statically as the obfuscation is specifically designed to prevent it.

StudioBoard is the most significant of the three. It accumulated 1,281 installs, more than any other Cluster F extension, and pushed four versions (v4.7.0 through v4.7.3) within a single day, suggesting active iteration in response to scanning signals. All three share identical evidence line numbers in their AgentMesh scans, confirming they were built from the same obfuscated builder template.

BloxyTask: The Most Advanced Variant Observed

BloxyTask was published on June 6 and had two installs at the time of discovery. It is the most technically evolved extension in the family observed to date in terms of infection chain complexity.

The earlier family members all used the same execution path: download a JavaScript file to the Windows temp directory, execute it using the Windows Script Host (cscript.exe). BloxyTask changed this. It downloads an HTA — an HTML Application file — and executes it using mshta.exe, the Windows HTML Application Host. This is a different Windows subsystem, producing a different process chain, with a different detection signature from the family's earlier variants.

The five-stage infection chain:

Stage 0: VS Code Extension. The extension activates automatically on every VS Code startup. Its malicious code downloads an HTA file from a Cloudflare Worker and executes it in a hidden window. The advertised Kanban board UI crashes on first load because a required variable is never defined in the extension's code. The malicious activation runs regardless of whether the user ever opens the tool.

Stage 1: HTA Downloader. The HTA file downloads a batch script from a second hosting provider and executes it.

Stage 2: Obfuscated Batch Script. A heavily obfuscated batch file, over 700 KB in size, extracts two components from its own contents and writes them to disk: a shellcode blob stored with an image file extension, and an encrypted PowerShell script. It also copies powershell.exe to the user's Downloads folder under a different name to evade process-name detection.

Stage 3/4: In-Memory PowerShell Injector. The PowerShell script, decoded and executed entirely in memory, performs two functions: it installs persistence by creating a scheduled task that will relaunch the loader on every user login, and it injects the shellcode blob into explorer.exe. If the primary injection target is unavailable, the injector tries five alternative Windows processes in sequence. This stage was fully decoded during analysis.

Important: While Stage 4 runs in memory, the infection chain writes several files to disk that persist after execution — including the shellcode blob, the loader script, and scheduled task configuration files. These disk artifacts are documented in the detection section below and are the primary targets for forensic investigation and remediation.

Stage 5: Reflective Shellcode Loader. The shellcode's architecture — a position-independent loader designed to decrypt and execute an encrypted payload blob in memory — is consistent with professional offensive tooling, based on static analysis. The loader contains a 390 KB encrypted payload that it decrypts and executes in the context of the injected process.

The final payload's capabilities, credential targets, and command-and-control infrastructure cannot be determined from static analysis. Dynamic analysis is required to recover these details. We are publishing without that answer and are stating that clearly. Defenders who encounter this infection should submit the shellcode file to a sandbox service as part of their incident response process.

Two findings from the BloxyTask analysis are worth highlighting for the broader campaign story. First: the extension's source code contains the command identifier managerblx.open and a reference image tagged "ManageRBLX" — artifacts from the original ManageRBLX extension carried over unchanged. This is the strongest available evidence linking the two extensions, whether through shared authorship, a shared codebase, or a shared builder toolkit. Second: the Kanban board UI — the entire stated purpose of the extension — was never functional. The malicious activation code was the only working part of the extension from the beginning.

Detection and Defensive Guidance

If you have any extension from the SaassyCode family installed, remove it immediately and treat the host as potentially compromised.

Windows only: The infection chain depends on Windows-specific execution (mshta.exe, batch scripting, Windows API process injection). Developers on macOS or Linux who installed these extensions were not subject to the same infection chain. The extensions should still be removed.

The earliest detection opportunity is the process relationship: VS Code (Code.exe) spawning mshta.exe (BloxyTask variant) or cscript.exe (earlier family members). Neither is a normal child process of a development IDE. An EDR alert on either relationship is a strong and relatively low-noise signal in standard developer environments.

Detection Quick Reference

Confirming Active Infection

If the bytes DE AD BE CA FE BA EF are present in explorer.exe process memory, shellcode has been injected and is active.

Do not reboot before removing persistence artifacts. The scheduled task (applicationbackup) will relaunch the loader on the next user login, re-injecting the shellcode even after a reboot. Remove the scheduled task and delete the C:\ProgramData\IntelDriver\ directory before or immediately alongside rebooting.

Remediation (Plain Language)

1. Remove the extension from VS Code immediately.
2. Delete the scheduled task named applicationbackup.
3. Delete the persistence directory: C:\ProgramData\IntelDriver\ and all contents.
4. Delete svc.exe from the user's Downloads folder.
5. Delete applicationbackup.xml from %AppData% and applicationbackup.vbs from %LocalAppData%.
6. Reboot to clear any injected shellcode from process memory.
7. Rotate credentials: browser-stored passwords, API keys, session tokens, and developer credentials. The specific credentials targeted by BloxyTask's final payload are unknown pending dynamic analysis — credential rotation is the appropriate precautionary response.
8. Submit icon.png from the IntelDriver directory to ANY.RUN, Triage, or a comparable sandbox service to identify the final payload and recover C2 infrastructure.

Network Indicators (Defanged)

All network indicators were active at time of analysis. Cluster F C2 URLs remain embedded in obfuscated code and could not be statically resolved. Current availability of all indicators should be treated as unknown.

Sample Hashes (VSIX: SHA-256)

YARA detection rules for the full family and Sysmon detection configurations are available from the Knostic Labs team on request.

Why This Campaign Matters

The SaassyCode campaign is most significant not for any individual technical finding, but for what it demonstrates about how the VS Code extension ecosystem can be systematically exploited by a patient, operationally disciplined actor.

Within 19 days, this campaign grew from two extensions to nineteen — adapting infrastructure, evasion technique, and delivery mechanism at each point where it encountered resistance. After Knostic's June 1 disclosure, the actor did not stop. They published three more extensions, introduced code obfuscation to defeat static analysis, and one of those extensions (StudioBoard) accumulated over 1,200 installs before detection.

The update-based weaponisation vector is the hardest piece to address with existing controls. Marketplace scanning that runs at publication time cannot catch an extension that publishes clean and weaponises later. ManageR2BLX2 illustrates this precisely: a confirmed family member that any automated scanner would classify as safe at publication time, because the threat is in the update that hasn't been pushed yet.

This is not a problem unique to the VS Code Marketplace. Any extension ecosystem that permits silent updates, or any package registry that allows authors to publish new versions without re-review, shares the same structural vulnerability. The SaassyCode investigation is a concrete demonstration of that risk in a widely used developer tool.

Developers are high-value targets. Their machines hold source code, cloud credentials, CI/CD pipeline access, and repository keys. An implant that establishes persistence on a developer workstation — regardless of what that implant ultimately does — has access to infrastructure that extends well beyond the individual machine.

Conclusion

The SaassyCode campaign is active. As of the publication of this post, new extensions continue to appear, the actor continues to iterate on evasion, and at least one pre-positioned sleeper extension remains on the Marketplace.

All nineteen confirmed family members are documented in this post. We encourage developers, security teams, and the security community to report these extensions through the VS Code Marketplace report functionality and to notify Microsoft's security team directly. AgentMesh continues to monitor the VS Code Marketplace for new extensions matching SaassyCode family patterns.

If you are a developer who installed any extension listed in this post, remove it immediately and follow the remediation steps above. If you suspect an active infection, submit the shellcode artifact to a sandbox service and share the results with your security team.

Investigate your VS Code extension exposure with AgentMesh →

All network indicators in this post are defanged. All hashes are SHA-256. Analysis was performed using static methods only — no malicious code was executed in a production environment. The final payload capabilities and C2 infrastructure for BloxyTask Stage 5 and Cluster F extensions remain unconfirmed pending dynamic analysis. Statements regarding threat actor intent and future campaign activity are analyst assessments.

Related: New VS Code extensions attack campaign: SaassyCode — ManageRBLX & TrelloBlox · New Malicious VS Code Extension Backdoor: Remote Text Fetcher