Fake Next.js Job Tests Deploy In-Memory Malware via VS Code

Microsoft Defender Experts have uncovered a coordinated campaign that weaponizes fake job interviews to compromise developer machines. Attackers distribute malicious Next.js repositories disguised as technical assessments, exploiting Visual Studio Code's workspace automation to achieve in-memory JavaScript execution without touching disk.

The campaign represents an evolution of social engineering tactics targeting developers, turning routine development actions—opening a project folder, starting a dev server, or booting a backend—into reliable infection vectors.

How the Attack Works

The infection chain is elegant in its simplicity. Attackers pose as recruiters offering attractive positions at technology companies, then send candidates GitHub repositories containing "coding challenges" or "take-home assessments." The repositories appear legitimate, built with Next.js and following standard project conventions.

The malicious payload isn't in the application code itself. Instead, attackers abuse three distinct execution triggers that fire during normal development workflows:

VS Code folder-open trigger: Several repositories include a .vscode/tasks.json configured with runOn: "folderOpen". The moment a developer opens the project in VS Code and trusts the workspace, the task executes automatically.

Dev server trigger: Running npm run dev—the standard command to start a Next.js development server—activates embedded malicious scripts.

Backend startup trigger: A third variant decodes a base64-encoded endpoint from the project's .env file during server initialization.

All three paths lead to the same outcome: runtime retrieval and in-memory execution of attacker-controlled JavaScript. The malware never writes to disk, making detection significantly harder.

Vercel-Hosted Payloads

The execution chain follows a fetch-and-execute pattern. According to Microsoft's research, the initial payload retrieves a JavaScript loader from Vercel—a legitimate hosting platform commonly used for Next.js deployments. This abuse of trusted infrastructure helps the malicious traffic blend with normal development activity.

The attack uses a two-stage command-and-control architecture. An initial lightweight registration stage establishes host identity and can deliver bootstrap code. The malware then pivots to a separate controller that provides persistent tasking and continued in-memory execution capabilities.

Developer systems make attractive targets precisely because they typically contain sensitive data: source code, API keys, database credentials, and access tokens that can enable deeper network penetration.

Attribution and Connections

Microsoft did not formally attribute the campaign. However, the techniques—particularly the use of VS Code tasks and Vercel domains—align closely with tactics observed in North Korea-linked operations tracked as "Contagious Interview."

This campaign appears related to the Lazarus Group's graphalgo operation we covered two weeks ago, which planted malicious packages in npm and PyPI repositories using similar recruitment-themed lures. Where graphalgo poisoned package dependencies, this campaign embeds the malicious code directly in the development workflow itself.

The Contagious Interview operation has intensified throughout 2026. Socket researchers reported that operators pushed nearly 200 new malicious packages into npm in a single month, accumulating more than 31,000 downloads. The campaign has been active since at least May 2025, with GitLab's threat intelligence team predicting continued activity through 2026 due to its effectiveness.

The Developer Trust Problem

The attack exploits a fundamental tension in modern development. VS Code's workspace automation features boost productivity—but they also create execution opportunities for malicious projects. Developers routinely clone repositories from unknown sources for assessments, open-source contributions, or simply to learn from others' code.

This trust model worked when repositories contained only passive code. The addition of IDE automation, build scripts, and package manager hooks has transformed code repositories into executable environments.

The pattern mirrors other supply chain attacks targeting developer infrastructure. TeamPCP's cloud worm campaign similarly exploited automated development workflows, though it targeted CI/CD pipelines rather than local development environments. Both demonstrate how attackers increasingly focus on compromising the software supply chain at its source.

Defensive Measures

Microsoft recommends several mitigations. VS Code Workspace Trust and Restricted Mode should be the default posture for any repository acquired from unknown sources. These controls disable automatic code execution—including tasks, debugging, and extension features—until the workspace is explicitly trusted.

Organizations should establish policies requiring review of workspace automation files before trust is granted. Specifically, developers should inspect:

• .vscode/tasks.json for suspicious runOn configurations
• Package scripts in package.json for unexpected commands
• Any scripts that execute during standard development commands

For teams handling frequent technical assessments, consider dedicated virtual machines or containers for evaluating external code. This isolation prevents a compromised assessment from accessing production credentials or source code.

The campaign also reinforces the value of endpoint detection and response tools capable of monitoring Node.js process behavior, particularly network connections and child process spawning during development activities.

Why This Matters

Developer-focused attacks have grown increasingly sophisticated because developer machines sit at the intersection of multiple high-value assets. A compromised developer workstation can yield source code, deployment credentials, code signing keys, and access to internal systems—all from a single infection.

The fake interview vector is particularly insidious. Job seekers are motivated to run assessment code quickly and thoroughly, often on their primary work machines. The social pressure of an interview process works against the caution that might otherwise prevent infection.

For security teams, this campaign highlights the need to include developer workstations in threat modeling and to provide clear guidance on safely handling external code. The technical barriers to these attacks are low; the social engineering does most of the heavy lifting.