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

Source: Bleeping Computer

A coordinated campaign targeting software developers with job‑themed lures is using malicious repositories that masquerade 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 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 Bitbucket. They later discovered multiple repositories that shared code structure, loader logic, and naming patterns. When a target clones the repository and follows a standard workflow, malicious JavaScript executes automatically when the app is launched. The script downloads additional malicious code (a JavaScript backdoor) from the attacker’s server and runs it directly in memory with the Node.js process, enabling remote code execution on the machine.

Overview of the attack chain – Source: Microsoft

To increase the infection rate, the attackers embedded several execution triggers within the malicious repositories, as explained by Microsoft:

• VS Code trigger – A .vscode/tasks.json file with runOn: "folderOpen" executes a Node script as soon as the project folder is opened (and trusted).
• 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.
• 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. It 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.

Stage 2’s server‑polling function – Source: Microsoft

Microsoft found that the campaign involved multiple repositories sharing 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 details about the attacker or the overall scope of the operation.

Recommended mitigations

• Enforce VS Code Workspace Trust or Restricted Mode to prevent automatic script execution when opening untrusted folders.
• Deploy Attack Surface Reduction (ASR) rules that block suspicious PowerShell/Node.js behaviors.
• Monitor risky sign‑ins with Entra ID Protection.
• Minimize secrets stored on developer endpoints; use short‑lived tokens with the least required privileges wherever possible.