Hackers Target Developers With Malicious Next.js Repositories, Microsoft Warns

Microsoft Defender experts recently identified a targeted campaign targeting developers that uses malicious repositories disguised as legitimate Next.js projects and technical assessment materials.

These repositories, once executed, provided attackers with full control of developers’ systems, enabling them to exfiltrate critical data and execute arbitrary commands.

The threat actors employed common developer workflows as their attack surface, making the malicious repositories appear normal at first glance. The campaign is highly coordinated, using job-related lures to trick developers into interacting with the repositories.

The attack was first identified through suspicious outbound connections to attacker-controlled command-and-control (C2) infrastructure.

Telemetry data revealed that Node.js processes were making repeated communications with known C2 IP addresses, which prompted further investigation.

Initial analysis revealed repositories hosted on Bitbucket, presented as technical assessments for recruitment purposes.

Upon further review of the repository names, file structures, and code patterns, Microsoft’s defenders identified multiple additional related repositories.

These repositories followed consistent naming conventions and shared loader logic, enabling security analysts to expand their search and discover additional repositories involved in the attack.

Repositories such as “Cryptan-Platform-MVP1” and others with similar naming conventions were part of a coordinated attack aimed at silently compromising developer environments.

Malicious Execution Paths

The identified malicious repositories use multiple paths to achieve the same goal runtime retrieval and execution of attacker-controlled JavaScript, which later stages into command-and-control activity.

Stage 1 registrar payload retrieved at runtime and executed by Node.js. (Source: microsoft)
Stage 1 registrar payload retrieved at runtime and executed by Node.js. (Source: microsoft)

These paths primarily involve triggering payloads through regular developer activities, such as opening a project in Visual Studio Code or running a development server.

Path 1: Visual Studio Code Workspace Execution

Some variants of the repositories exploit Visual Studio Code’s workspace automation. The .vscode/tasks.json file, configured with runOn: “folderOpen”, automatically runs malicious tasks when the developer opens the project.

The task fetches a JavaScript loader from a staging server and executes it using Node.js, granting the attackers access.

Stage 2 telemetry showing command polling and operational reporting to the C2 via /api/handleErrors and /api/reportErrors (Source: microsoft)
Stage 2 telemetry showing command polling and operational reporting to the C2 via /api/handleErrors and /api/reportErrors (Source: microsoft)

Path 2: Build-Time Execution During Application Development

Another execution path is triggered when the developer manually runs the application. Malicious logic is embedded into seemingly legitimate application files, such as modified JavaScript libraries.

When the development server starts, this code fetches a JavaScript loader from a C2 server and executes it in memory.

Path 3: Server Startup Execution

The third path activates when the developer starts the backend server. Malicious loader logic in backend modules or routes executes during server initialization.

This path involves exfiltrating environment data, such as API keys and database credentials, and executing remote code in memory using dynamic compilation.

Staged Command-and-Control Execution

Once any of these paths is triggered, the attackers establish an initial foothold with a lightweight registration payload that repeatedly polls a C2 server.

This server responds with a unique instance identifier, allowing the attacker to maintain persistence. Following this, the attackers can remotely control the compromised systems, exfiltrate valuable data, and execute additional payloads as needed.

To protect against this type of attack, Microsoft recommends several actions for both developers and security teams.

Stage 2 executes tasks by piping server-supplied JavaScript into Node via STDIN. (Source: microsoft)
Stage 2 executes tasks by piping server-supplied JavaScript into Node via STDIN. (Source: microsoft)

Developers should enable Visual Studio Code workspace trust settings to limit the automatic execution of tasks in untrusted environments.

Additionally, securing developer workflows and regularly reviewing repository contents before granting trust can help prevent this type of malicious activity.

For organizations, Microsoft Defender for Endpoint’s advanced hunting tools can help track malicious Node.js processes and abnormal outbound connections.

Indicator TypeExamples
Domainsapi-web3-auth.vercel.app, price-oracle-v2.vercel.app, ip-check-notification-03.vercel.app
IP Addresses87.236.177.9, 147.124.202.208, 163.245.194.216
URLshxxp://87.236.177.9:3000/api/errorMessage, /hsocketNext, /uploadsecond
Filenamesnext.config.js, tasks.json, jquery.min.js
Filepaths.vscode/tasks.json, server/routes/api/auth.js, .env
SHA-256 Hashesddd43e493cb333c1cc5d7cd50a6a5a61ecd89cfa5f4076f62c2adf96748b87f8, 449e2bf57ab4790427a3a7de3d98b6c540e76190a3d844de2f0e7b66be842b19

Follow us on Google News , LinkedIn and X to Get More Instant UpdatesSet Cyberpress as a Preferred Source in Google.

Varshini
Varshini
Varshini is a Cyber Security expert in Threat Analysis, Vulnerability Assessment, and Research. Passionate about staying ahead of emerging Threats and Technologies..

Trending News

Related Stories