Post by 
October 21, 2025 | 
In today’s job market, it is common for recruiters to send candidates a technical task before the interview. However, not all tasks are safe. Recently, we came across a case of a Node.js “test project” that had nothing to do with coding skills. Instead, it was a malware package designed to steal cryptocurrency, browser passwords, and system data.
This article explains how the attack worked, highlights the red flags, and shows how you can protect yourself.
Early Red Flags
Before even looking at the code, several red flags suggested something was off. The recruiter offered an unusually high salary but never mentioned the company’s name. They skipped the usual interview steps and immediately pushed a technical task, without a call or background check.
On top of that, the role was supposed to be for a .NET engineer, yet the assignment was in Node.js. Taken together, these inconsistencies strongly indicated a potential scam long before any code review began.
The Malicious Code
At first look, the repository seemed like a typical Node.js backend project. It had a standard folder structure with middleware/, config/, and routes/. But hidden inside was a backdoor that enabled Remote Code Execution (RCE).
The suspicious file was:
backend/src/middleware/errorHandler.js
Usually, an error handler middleware in Node.js is simple: it catches errors, logs them, and sends a response. But here it looked very different.
const handler = new (Function.constructor)(‘require’, errCode); handlerFunc(require);
Why This Was Dangerous
The malicious “test project” hid its true purpose behind clever tricks. Instead of clear, readable JavaScript, it relied on obfuscated code using Function.constructor, essentially a disguised eval, which allowed attackers to execute any string as code.
A variable named errCode wasn’t just an error reference; it actually carried malicious instructions that would run whenever the error handler was triggered.
To make things worse, the attackers buried this inside an error handler file, a place most developers consider generic code and rarely review in detail.
In practice, this meant the project was designed to run extra, hidden code that had nothing to do with the application. Every time the server started or encountered an error, the injected script could:
- Download additional malicious software
- Execute arbitrary commands on the system
- Connect to external servers for attacker instructions
In other words, this wasn’t a coding test at all. It was a carefully disguised malware package, delivered under the pretense of a job opportunity.
The malicious project didn’t rely only on the error handler. It also used supporting files to hide its tracks and make the attack look like normal development behavior.
- runtimeConfig.js
Inside backend/src/config/runtimeConfig.js, there was a function called initRuntimeConfig(). Its job was to take a value from the .env file and decode it from base64. At first glance, this looked like a standard configuration step that developers often use .env files to store sensitive keys or settings.
However, when the base64 string was decoded, it revealed a URL pointing to an attacker-controlled server. This wasn’t a configuration at all, it was a clever way to smuggle a hidden command-and-control (C2) endpoint into the project.
- .env file
Normally, .env files contain sensitive environment variables, such as database passwords, API keys, or feature flags. This makes them a trusted part of many projects. The attackers abused this trust by placing an encoded URL in the .env file. To anyone glancing at the code, it looked like just another harmless “API key.” In reality, it was the trigger for the malware, the first stage of downloading and running payloads from the attacker’s infrastructure.
Why This Matters
Because most developers trust config files, this tactic could slip through even experienced reviewers and lead to compromised systems. This approach is dangerous because most developers wouldn’t think twice about a .env file or a config loader. These files are usually ignored in code reviews, treated as boring “plumbing.” By hiding the malicious URL here, the attackers increased their chances that no one would notice until it was too late.
The End Goal
The final payload was never about testing coding skills; it was built to steal sensitive data. Once executed, it:
- Collected system details such as hostname, platform, and user directories.
- Extracted browser data, specifically targeting cryptocurrency wallet extensions.
- Copied wallet keys from popular apps like Exodus and Solana.
- Pulled credentials from the macOS Keychain and browser password managers.
- Exfiltrated everything to an attacker-controlled server.
The initial API calls in the codebase were nothing more than a smokescreen. It objective was remote code execution (RCE) and large-scale data theft.
How to Stay Safe
To protect yourself from similar attacks, follow these practices:
- Run suspicious tasks in a virtual machine (VM), never execute unknown code directly on your main laptop.
- Use a trusted password manager and avoid storing credentials in browsers or local apps that can be easily compromised.
- Trust your instincts; vague job offers are often a sign of a scam.
Conclusion
Fake technical tasks are a growing attack vector, directly targeting developers and engineers. These scams exploit trust and curiosity, tricking candidates into running malware presented as a job assessment.
Spot the red flags, isolate untrusted code, and protect your credentials; otherwise, your next ‘job test’ could end in a breach instead of an offer.
