A coordinated attack campaign is actively targeting software developers through malicious repositories disguised as legitimate Next.js projects and technical assessment materials.
The attackers rely on job-themed lures, presenting fake recruitment challenges that convince developers to clone and run poisoned code on their own machines.
Once a developer executes the project, it silently connects to attacker-controlled command-and-control (C2) infrastructure, granting hackers remote access to the developer’s system along with any sensitive data stored on it.
The campaign was first spotted through suspicious outbound network connections originating from Node.js processes on affected developer machines.
These processes were repeatedly reaching out to known C2 IP addresses, which prompted a deeper review of the execution chains behind those connections.
By correlating network activity with process telemetry, analysts traced the Node.js execution back to malicious repositories, including one hosted on Bitbucket presented as a recruiting-themed technical assessment and another using the naming convention “Cryptan-Platform-MVP1.”
Microsoft Defender Experts and the Microsoft Defender Security Research Team identified a broader cluster of related repositories by pivoting on shared code structure, loader logic, and naming patterns.
Repository families such as “Cryptan,” “JP-soccer,” “RoyalJapan,” and “SettleMint” carried near-duplicate variants labeled v1, master, demo, platform, and server.
This consistent structure helped analysts uncover additional repositories not referenced in observed telemetry but exhibiting the same execution logic and staging infrastructure.
The scale of this campaign makes it particularly dangerous for development teams operating in corporate environments.
Developer machines routinely hold access to high-value assets including source code, environment secrets, cloud API keys, database credentials, and build pipelines.
When untrusted code runs on a corporate device, a single compromise can quickly extend beyond one endpoint and potentially expose an organization’s entire infrastructure.
This campaign reflects a calculated shift in how attackers approach software supply chain threats.
By embedding malicious behavior inside what appears to be a normal project, hackers can achieve reliable code execution while blending into routine developer workflows, making this a significant threat to development teams worldwide.
Three Entry Points, One Shared Backdoor
All three execution paths in this campaign lead to the same result: runtime retrieval and in-memory execution of attacker-controlled JavaScript.
The first path abuses Visual Studio Code workspace automation. When a developer opens and trusts a project folder, the .vscode/tasks.json file is pre-configured with runOn: "folderOpen," immediately triggering a Node.js script that fetches a JavaScript loader from a Vercel-hosted staging endpoint.
After execution, the script begins beaconing to attacker-controlled infrastructure.
.webp)
The second path fires when a developer starts the development server using npm run dev. Trojanized assets, such as a modified jquery.min.js, decode a base64-encoded URL and retrieve the same JavaScript loader from Vercel.
.webp)
The third path triggers on server startup, where malicious backend routes decode a hidden base64 endpoint from a .env file, transmit the full process environment — including cloud API keys and access tokens — to the attacker, and execute attacker-supplied JavaScript via dynamic compilation.
.webp)
Once any of these paths fires, a lightweight Stage 1 payload profiles the host and begins polling the C2 server at fixed intervals.
.webp)
Stage 2 then takes over, providing persistent operator-driven tasking, directory browsing, sensitive file collection, and staged uploads of stolen data to attacker infrastructure.
.webp)
Developers should enable Visual Studio Code Workspace Trust and Restricted Mode to block automatic code execution in unknown folders.
Organizations should apply attack surface reduction rules to prevent obfuscated script execution, enforce strong authentication and conditional access for developer accounts, and avoid storing production credentials on development machines.
Security teams should monitor for unusual Node.js outbound connections using DeviceNetworkEvents and DeviceProcessEvents hunting queries, and perform identity risk triage whenever a developer endpoint compromise is suspected.
Follow us on Google News, LinkedIn, and X to Get More Instant Updates, Set CSN as a Preferred Source in Google.
