Microsoft has warned that threat actors are weaponizing malicious Next.js repositories to compromise developers through what appear to be legitimate projects and recruiting‑style technical assessments.
The campaign abuses normal workflows in Visual Studio Code and Node.js to reach a staged command‑and‑control (C2) backdoor without relying on traditional malware installers.
Attackers publish repositories that appear to be real Next.js projects or technical assessment exercises, then rely on developers to open, build, or run them locally.
The investigation started from suspicious outbound connections made by Node.js processes to attacker infrastructure over HTTP port 3000, which repeatedly beaconed in short intervals.
According to Microsoft Defender Experts, the activity is part of a coordinated developer‑targeting campaign using job‑themed lures to blend into routine coding tasks.
By correlating process and network telemetry, analysts traced this traffic back to Bitbucket‑hosted repositories, including one framed as a recruiting assessment and another labeled with the Cryptan‑Platform‑MVP1 naming pattern.
Further pivoting on shared naming conventions such as “Cryptan”, “JP‑soccer”, “RoyalJapan”, and “SettleMint”, plus repeated use of variant labels like “v1”, “master”, “demo”, “platform”, and “server”, allowed Microsoft to uncover additional related projects that shared identical loader logic and staging infrastructure.
Structural reuse of files such as next.config.js, .vscode/tasks.json, jquery.min.js, and backend route modules confirmed these repositories belonged to the same malicious family rather than being coincidentally similar.
Three execution paths
Analysis of the malicious repositories shows three recurring execution paths that all converge on runtime retrieval and in‑memory execution of attacker‑controlled JavaScript.
First, some variants abuse Visual Studio Code workspace automation by configuring .vscode/tasks.json with runOn set to “folderOpen”, causing a Node.js task to run as soon as the project is opened and trusted.
In certain cases, this behavior is backed up by an obfuscated JavaScript dictionary processed during workspace initialization, ensuring execution even if tasks are restricted, and ultimately fetching a loader script from a Vercel‑hosted endpoint such as price‑oracle‑v2.vercel.app.
Second, build‑time execution is triggered when developers run npm run dev or start the Next.js server, where apparently benign assets like jquery.min.js are trojanized to act as loaders.
When the dev server launches, these assets decode a base64‑encoded URL, then pull a JavaScript payload from Vercel and execute it in memory via Node.js, again pivoting into the same C2 chain.
Third, server startup execution is implemented through backend routes and environment variables, with .env entries such as AUTH_API storing a base64‑encoded endpoint.
On startup, loader modules decode the endpoint, exfiltrate process.env to the attacker, and dynamically execute server‑supplied JavaScript using constructs like new Function(“require”, response.data)(require), achieving remote code execution inside the Node.js server process and exposing cloud keys, database credentials, and API tokens endpoint.
Regardless of how execution is triggered, all paths lead to a common Stage 1 script that acts as a lightweight registrar and bootstrap channel.
This payload profiles the host, repeatedly polls a registration endpoint, and maintains a durable instanceId across requests while optionally running additional server‑supplied JavaScript in memory.
Stage 2 then upgrades this foothold into a long‑lived controller that communicates with separate C2 IPs and APIs, frequently executed via node -e and designed to persist as a command loop.
Identity‑centric controls using Microsoft Entra ID Protection and Defender for Cloud Apps Conditional Access app control can help contain the impact of stolen tokens by monitoring risky sign‑ins and restricting high‑risk actions during investigations.
The controller polls for messages[] tasks, executes them through detached Node interpreters, and implements error reporting, retry logic, process tracking, and kill‑switch handling to keep sessions stable.
Telemetry shows attacker‑driven directory browsing via endpoints such as /api/hsocketNext and /api/hsocketResult, along with a staged upload workflow using /upload, /uploadsecond, and /uploadend to exfiltrate selected files.
Mitigations
Microsoft urges organizations to treat developer workflows as a primary attack surface and to harden trust boundaries around untrusted repositories.
Developer‑targeting campaign shows how a recruiting‑themed “interview project” can quickly become a reliable path to remote code execution by blending into routine developer workflows.
Visual Studio Code Workspace Trust and Restricted Mode should remain enabled by default for unknown projects, with policies requiring review of automation files like .vscode/tasks.json and next.config.js before granting trust.code.
On Windows endpoints, Microsoft recommends enabling attack surface reduction rules in Defender for Endpoint to constrain obfuscated or dynamically constructed scripts, as well as keeping cloud‑delivered protection and SmartScreen reputation checks active to block malicious downloads and infrastructure.
For detection and hunting, Microsoft advises leveraging Advanced Hunting tables like DeviceNetworkEvents and DeviceProcessEvents to look for Node.js initiating repeated outbound connections to vercel.app delivery domains and C2 paths such as /api/errorMessage and /api/handleErrors, as well as next.config.js or workspace loaders using eval or new Function.
Organizations using Microsoft Sentinel can operationalize these behaviors into hunting queries and analytics rules to detect future attempts to weaponize Next.js repositories and developer tooling.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
