Fake Next.js job interview tests backdoor developer’s devices

A coordinated campaign targeting software developers with job-themed lures is using malicious repositories posing as legitimate Next.js projects and technical assessment materials, including recruiting coding tests.

The attacker’s goal is to achieve remote code execution (RCE) on developer machines, exfiltrate sensitive data, and introduce additional payloads on compromised systems.

Multiple execution triggers

Next.js is a popular JavaScript framework used for building web applications. It runs on top of React and uses Node.js for the backend.

The Microsoft Defender team says that the attacker created fake web app projects built with Next.js and disguised them as coding projects to share with developers during job interviews or technical assessments.

The researchers initially identified a repository hosted on the Bitbucket cloud-based Git-based code hosting and collaboration service. However, they discovered multiple repositories that shared code structure, loader logic, and naming patterns.

When the target clones the repository and opens it locally, following a standard workflow, they trigger malicious JavaScript that executes automatically when launching the app.

The script downloads additional malicious code (a JavaScript backdoor) from the attacker’s server and executes it directly in memory with the running Node.js process, allowing remote code execution on the machine.

To increase the infection rate, the attackers embedded multiple execution triggers within the malicious repositories, Microsoft explained. These are summarized as follows:

1. VS Code trigger – A .vscode/tasks.json file set with runOn: “folderOpen” executes a Node script as soon as the project folder is opened (and trusted).
2. Dev server trigger – When the developer runs npm run dev, a trojanized asset (e.g., a modified JS library) decodes a hidden URL, fetches a loader from a remote server, and executes it in memory.
3. Backend startup trigger – On server start, a backend module decodes a base64 endpoint from .env, sends process.env to the attacker, receives JavaScript in response, and executes it using new Function().

The infection process drops a JavaScript payload (Stage 1) that profiles the host and registers with a command-and-control (C2) endpoint, polling the server at fixed intervals.

The infection then upgrades to a tasking controller (Stage 2) that connects to a separate C2 server, checks for tasks, executes supplied JavaScript in memory, and tracks spawned processes. The payload also supports file enumeration, directory browsing, and staged file exfiltration.

Microsoft found that the campaign involved multiple repositories that shared naming conventions, loader structure, and staging infrastructure, indicating a coordinated effort rather than a one-off attack.

Aside from the technical analysis, the researchers did not provide any details about the attacker or the extent of the operation. 

The tech giant advises that developers should treat standard workflows as the high-risk attack surfaces they really are and take appropriate precautions.

The recommended mitigations include enforcing VS Code Workspace Trust/Restricted Mode, using Attack Surface Reduction (ASR) rules, and monitoring risky sign-ins with Entra ID Protection.

Secrets stored on developer endpoints should be minimized, and short-lived tokens with the least required privileges should be used where possible.