Microsoft Uncovers New Malicious Campaign Targeting Developers

Microsoft researchers have uncovered a sophisticated campaign that utilizes malicious repositories disguised as legitimate development materials—specifically Next.js projects and technical assessment tasks to target developers. This ccampaign is particularly alarming because it is engineered to blend seamlessly into routine developer workflows, significantly increasing the likelihood of code execution. 

The main goal is to gain remote code execution on developer systems, which often house high-value assets such as proprietary source code, critical environment secrets (cloud keys, API tokens), and access to build and cloud resources. This campaign is an offshoot of the more familiar and pervasive fake job interview and phony tech worker scams that have been coming from North Korea for several years.

The investigation was triggered by suspicious outbound connections to attacker-controlled C2 infrastructure seen through Microsoft Defender telemetry. Analysts traced repeated Node.js process communication back to malicious Bitbucket-hosted repositories, including one masquerading as a recruiting-themed technical assessment.

To grasp the full scale of the attack, investigators broadened the scope by pivoting on shared artifacts:

• Repository Contents and Naming Conventions: Projects often followed repeatable naming conventions and "project family" patterns.
• Shared Coding Patterns: Analysts focused on common execution mechanisms, loader logic, and staging infrastructure across different repositories.

The researchers uncovered additional related repositories not directly referenced in initial logs, confirming a widespread threat cluster designed to exploit trust within the developer ecosystem.

Across all identified malicious repositories, the campaign employs multiple distinct entry points that all deliver the same outcome: the runtime retrieval and local execution of attacker-controlled JavaScript, which transitions into a staged command-and-control operation.

Here are the three primary execution paths identified:

Path 1: Visual Studio Code Workspace Execution

This path exploits built-in Visual Studio Code (VS Code) workspace automation to trigger execution the moment a developer opens and trusts the malicious project folder.

• Mechanism: The presence of a trojanized .vscode/tasks.json file is key. It is configured with runOn: "folderOpen", which causes a malicious task to run immediately.
• Redundancy: Some variants include obfuscated JavaScript within a dictionary-based fallback to ensure execution even if task execution is restricted.
• Outcome: The execution chain follows a fetch-and-execute pattern, retrieving a JavaScript loader from a staging endpoint (often hosted on Vercel) and executing it directly with Node.js.

Path 2: Build-Time Execution During Application Development

This path targets the typical action of starting a development server, such as running npm run dev or a direct server start command.

• Mechanism: Malicious logic is embedded within application assets that appear legitimate but are trojanized to act as loaders. A common example is a modified jquery.min.js file containing obfuscated code instead of the standard library.
• Execution Flow: When the development server starts, the trojanized asset decodes a base64-encoded URL, retrieves a Vercel-hosted JavaScript loader, and executes the payload in memory using Node.js.
• Outcome: This mechanism provides redundancy, guaranteeing the same backdoor behavior even if editor-based automation fails to trigger.

Path 3: Server Startup via Environment Exfiltration and Dynamic RCE

The third and arguably most dangerous path activates during the application backend's startup sequence.

• Mechanism: Malicious loader logic is embedded in backend modules or routes that execute at initialization or module import time.
• Data Theft: The repositories often include a .env file with a base64-encoded C2 endpoint (e.g., AUTH_API=<base64>). The loader decodes this endpoint, then immediately transmits the host's entire process environment (process.env) to the attacker's server.
• Remote Code Execution (RCE): The server's response delivers new JavaScript source code, which the loader executes in memory using dynamic compilation (new Function(...)(require)).
• Outcome: This path immediately exposes sensitive configuration (cloud keys, database credentials, API tokens) and enables persistent, in-memory RCE within the Node.js server process.

Regardless of which of the three paths is taken, they all lead to the same first stage payload. This initial script functions as a lightweight registrar and bootstrap channel.

After retrieval from the staging infrastructure, the script profiles the host system and repeatedly polls a registration endpoint. The C2 server can provide a durable instanceId to correlate activity and, most critically, can supply and execute additional JavaScript in memory using new Function(), enabling on-demand bootstrap and follow-on tasking without writing any additional payloads to disk.

This developer-targeting campaign highlights a growing trend where malicious actors leverage job-themed lures to circumvent traditional defenses and gain a foothold on highly privileged developer systems. The attackers' ability to blend into routine developer actions—opening a repo, running the dev server, or starting the backend—makes this threat particularly difficult to detect through standard security practices.