When the Next Job Offer Compromises Your System

A New Scam Targeting Freelancers and Developers

As a freelancer, you get used to being active on multiple platforms at the same time. Whether through classic freelancer marketplaces, personal contacts, or networks like Malt, Upwork, or similar platforms – new project inquiries regularly land in your inbox. This is exactly how a recent request reached me as well.

At first glance, everything looked completely legitimate. The contact either appeared under a company profile belonging to an established business or as a real, identifiable person with an online presence, work history, and a profile that clearly did not look like a low-effort fake. Nothing felt like a typical scam. On the contrary, the professionalism was likely intentional – it builds trust.

In the past, such inquiries were usually handled in a traditional way: an initial conversation, a rough project outline, maybe a call where someone explains the technical scope. Today, everything is supposed to move faster. “Just take a quick look at the project,” they say. Sometimes you receive a ZIP file – which many developers are fortunately already suspicious of – but more often now, you are simply given access to a GitHub repository.

A completely normal repository. Clean structure. Modern tech stack. Nothing obviously suspicious. And that is exactly where the problem begins.

How the Attack Works – and Why You Don’t Notice It Immediately

The approach is deceptively simple and exploits what developers do every day: trusting familiar tools and established workflows. The repository itself does not contain any obviously malicious code. It looks like a standard frontend or full-stack project.

The malicious behavior does not start when you clone the repository, but only when you run it locally – for example with npm run dev. While many developers have become cautious about classic postinstall scripts (and often disable them entirely), attackers have adapted and now use a different approach: parallel npm scripts.

When the project is started, an additional Node.js script runs quietly in the background. It has nothing to do with the actual application. This script downloads external code, executes it dynamically, and installs itself persistently inside the user’s home directory. From there, it continues running in the background – completely independent of whether the project is still open or has already been closed.

There is no crash, no warning, no suspicious console output. The project starts normally. And that is precisely what makes this attack so dangerous.

What Actually Happens in the Background

The downloaded payload acts as both an infostealer and a backdoor. It scans the system for browser profiles, extracts stored credentials, decrypts saved passwords, collects cookies, wallet data, .env files, and other sensitive configuration files.

At the same time, it establishes a persistent connection to an external command-and-control server. Through this connection, the attacker can execute remote commands, upload files and directories, or download additional payloads – all controlled remotely.

What makes this especially problematic is that no classic exploit is involved. Nothing is “hacked” in the traditional sense. Only legitimate developer tools like Node.js, npm, and socket-based communication are abused. Because of this, many security mechanisms never trigger.

Why This Scam Is So Effective

These attacks are not aimed at servers or production environments – they are aimed directly at developers. They rely on the fact that running third-party code locally is a normal and necessary part of our job.

Simply cloning a repository is usually harmless. The actual compromise happens only when the code is executed. And in the context of evaluating a project or job offer, that step feels entirely natural.

The professional appearance of the request, the credible identity of the contact, and a technically clean repository ensure that the usual warning signs often appear far too late.

Conclusion: Zero Trust – Even in Your Local Dev Environment

This experience made one thing very clear to me: security does not start in production. Local development environments are a valuable target as well. Freelancers in particular, who constantly review new projects, are especially attractive to attackers.

The most important takeaway is simple, even if it is uncomfortable: zero trust. Even if the repository looks professional. Even if the contact appears legitimate. Even if it feels like “just taking a quick look”.

Unknown projects do not belong on your primary machine. Not on systems with access to production credentials. Not in environments that contain sensitive data. Trust is useful – but when it comes to running code, isolation should be the default.

This was not an isolated incident. And it certainly won’t be the last.