Iranian Hackers Turn Fake Coding Tests Into Cross-Platform RAT Delivery System

• The Mess: The Iran-linked Nimbus Manticore group is using fake recruitment offers and programming tests to deliver two remote-access trojans, NodeRabbit and PollCat, targeting developers across Windows, Linux and macOS.
• The Damage: A developer who runs a malicious coding assignment can hand attackers persistent access to a workstation containing source code, credentials, SSH keys and cloud access.
• The Fix: Treat unsolicited coding tests as untrusted software, verify recruiters independently and never execute recruitment assignments on a machine containing production credentials or sensitive repositories.

The job interview is now an attack surface.

Researchers have linked the Iran-aligned Nimbus Manticore group to a campaign targeting developers with fake recruitment offers.

The bait arrives through professional networking and recruitment channels.

The victim is offered a job.

Then comes the technical test.

Download this archive.

Run the project.

Build the application.

Check the results.

Except the test isn’t a test.

It’s malware.

The Payload Has Two Names

Security researchers identified two remote-access trojans associated with the campaign:

NodeRabbit

and

PollCat.

Both are built around JavaScript/Node.js components.

That is significant because Node.js is completely normal in development environments.

A developer executing:

npm install

or

npm run

doesn’t automatically look like someone launching malware.

The attacker is hiding inside a workflow developers already perform every day.

The Recruiter Is the First Stage

The campaign begins with social engineering.

The attackers pose as recruiters or representatives of companies looking for developers.

The victim may receive:

• a job offer
• a request for an interview
• a programming assignment
• a GitHub repository
• a ZIP archive
• a link to a coding platform

Nothing about that sequence is inherently suspicious.

That’s why it works.

The attacker isn’t asking the victim to install a random executable.

They’re asking them to do their job.

The Coding Test Is the Weapon

Eventually the victim receives a development project.

The project looks ordinary.

It may contain:

• JavaScript
• Node.js
• configuration files
• package manifests
• build scripts
• documentation

The malicious code is embedded inside that environment.

Once the victim executes the project, the malware can establish communication with the attacker’s infrastructure.

The interview is over.

The compromise has begun.

Why Developers Are Such Valuable Targets

A developer workstation can contain an absurd amount of useful material.

Think about what is sitting behind the keyboard:

GitHub sessions.

SSH keys.

Cloud credentials.

npm tokens.

Docker credentials.

VPN access.

Internal documentation.

Source code.

CI/CD credentials.

An attacker doesn’t necessarily need to compromise the company’s production server.

They can compromise the person who already has access.

Node.js Makes the Malware Look Normal

This is a clever choice.

Node.js is installed on millions of developer systems.

Developers routinely execute code from third-party repositories.

They also install dependencies from package registries.

That creates a huge amount of legitimate activity for malware to hide inside.

A suspicious executable immediately raises questions.

A suspicious package.json is easier to overlook.

That’s the advantage.

Cross-Platform Is the Bigger Problem

The campaign isn’t limited to Windows.

Researchers observed targeting across:

• Windows
• Linux
• macOS

That matters because developers aren’t concentrated on one operating system.

A company may have:

Windows laptops

for general employees,

macOS

for designers and engineers,

and

Linux

for servers and development environments.

A malware family capable of operating across multiple platforms can follow the developer rather than the operating system.

Remote Access Changes Everything

A traditional information stealer wants data.

A RAT wants a foothold.

NodeRabbit and PollCat provide attackers with remote access capabilities.

That means the victim’s machine can become a long-term operational base.

The attacker can potentially:

• execute commands
• inspect files
• collect system information
• access credentials
• download additional payloads
• maintain persistence

The exact capabilities depend on the deployed variant and environment.

But the objective is clear.

Get inside.

Stay inside.

Harvest access.

This Is Initial Access Broker Material

A compromised developer workstation has another value.

The attacker doesn’t necessarily need to use the access themselves.

They can sell it.

That’s where the Initial Access Broker economy becomes relevant.

One developer account can provide access to:

Company A → GitHub → AWS → production

That access can become a commodity.

Someone else may pay for it.

The original malware operator doesn’t need to conduct the final attack.

They just sell the door.

LinkedIn Makes the Attack More Convincing

Professional networking platforms are ideal for this kind of social engineering.

The attacker can create a believable identity.

They can reference:

• a real company
• a real job position
• a real technology stack
• a realistic salary
• a realistic interview process

Then the victim receives a technical assignment that appears completely normal.

The more accurate the recruitment process looks, the less suspicious the payload becomes.

Developers Should Stop Running Tests on Their Main Machines

This is the easiest defensive lesson.

A coding assignment from a stranger is untrusted code.

Treat it like malware.

Run it inside:

• a disposable VM
• an isolated container
• a dedicated test machine
• a sandboxed environment

And keep sensitive credentials away from it.

Especially:

SSH keys.

Cloud credentials.

GitHub tokens.

npm tokens.

Production environment variables.

If the assignment is malicious, the attacker gets the sandbox.

Not your infrastructure.

npm install Is Not Harmless

Developers sometimes treat package installation as equivalent to downloading documentation.

It isn’t.

Installing a package executes code in many development workflows.

A malicious dependency can run during:

• installation
• build
• testing
• application startup

That means the coding test itself can be clean while one dependency performs the compromise.

The developer may never notice.

Look at the Repository Before Running It

Before executing a recruitment assignment, inspect:

• package.json
• package-lock.json
• install scripts
• lifecycle hooks
• postinstall scripts
• dependency names
• external URLs
• shell commands
• encoded JavaScript
• unexpected binaries

A coding test shouldn’t need unexplained access to your filesystem.

If it does, stop.

The Recruiter Can Be Verified

There is an easy way to make this attack significantly harder.

Don’t verify the recruiter using information supplied by the recruiter.

Find the company’s official website.

Find the company’s public careers page.

Contact the company through an independently obtained address.

Ask whether the recruiter and assignment are legitimate.

It takes minutes.

It can prevent weeks of incident response.

If You Already Ran the Assignment

If a suspicious coding test was executed on a real workstation, don’t just delete the project.

Assume the machine may be compromised.

From a clean device:

• rotate passwords
• revoke GitHub sessions
• revoke API tokens
• rotate SSH keys
• rotate cloud credentials
• invalidate npm tokens
• review recent repository activity
• inspect cloud login history
• check for unexpected accounts
• inspect newly created SSH keys
• review outbound network connections

For corporate systems, isolate the endpoint and perform forensic analysis.

AI Doesn’t Make the Attack Necessary

There is a lot of attention around AI-powered malware.

This campaign doesn’t need it.

The attackers already have something more effective:

a believable human story.

A recruiter.

A job.

A coding assignment.

A deadline.

That’s enough to convince developers to execute untrusted code.

The malware can remain relatively ordinary.

The delivery mechanism does the heavy lifting.

The Developer Is the New Perimeter

For years, organizations tried to protect the perimeter.

Then cloud infrastructure dissolved much of it.

Now the developer workstation can be the perimeter.

It may have access to more critical infrastructure than a traditional office computer ever did.

Compromise the developer.

Harvest the credentials.

Move into the cloud.

Access the repositories.

Then attack production.

The initial malware doesn’t have to be spectacular.

The credentials are the payload.

Bugstoday Opinion

Fake job offers have always been used for scams.

Using them to compromise developers is considerably nastier.

A developer isn’t being asked to click a suspicious attachment.

They’re being asked to prove their skills.

That’s exactly why the attack works.

The victim executes the attacker’s code voluntarily because the code is disguised as employment.

Bugstoday verdict: never run a recruitment coding assignment on a workstation that has access to your real infrastructure. Put it in a disposable environment, verify the recruiter independently and assume every repository you receive from a stranger is hostile until proven otherwise. The easiest developer workstation to compromise is the one where npm install is considered harmless.

Today’s Bugs. Tomorrow’s Breaches.

Sources

• Kaspersky — Nimbus Manticore Research
• Kaspersky Threat Intelligence Portal
• MITRE ATT&CK — Software Deployment Tools
• Node.js Security Documentation
• GitHub — Secret Scanning and Token Security