The Job Offer That Owns Your Laptop: Why Fake Coding Challenges Are a Real Threat to Your Developers
Most of the security controls you've paid for assume the attack arrives by email. This one doesn't.
Kaspersky has published research on an Iranian state-backed espionage group that recruits its victims, literally. The operators build convincing recruiter profiles on LinkedIn and job boards, approach software engineers about a role, and send over a "technical challenge" as part of the interview process. The candidate downloads the project, runs it on their own machine, and hands an intelligence service a foothold on a developer workstation.
It's a clean piece of tradecraft, and it's worth understanding even if you don't think you're the target.
What actually happened
The group is tracked by Kaspersky as Mirage Kitten, and elsewhere as UNC1549, Smoke Sandstorm, and Nimbus Manticore. It's been active since 2022 and is tied to Iranian state interests. In this campaign, documented by Kaspersky researcher Omar Amin, the group targeted aviation, aerospace, and fintech organizations, with confirmed victims in Afghanistan, Egypt, and Ethiopia, and related samples surfacing from India, Türkiye, Israel, Iraq, Germany, and Ireland.
The chain works like this:
A recruiter reaches out. This isn't a mass phish. It's a tailored approach to a specific engineer, on a platform where being contacted by a recruiter is completely normal.
The candidate gets a coding challenge. In the samples Kaspersky recovered, that meant archives like Front-Technical-Challenge.zip, containing a working project-management application, hosted on Amazon cloud storage and sometimes gated behind an access code to look more official. One version instructed the candidate to review the application and fix its flaws within three hours, and explicitly banned the use of AI tools. Read that twice. The deadline manufactures urgency, and the AI ban conveniently discourages the one thing that might have flagged the malicious code.
The project is real. The dependencies aren't. Two packages bundled into the project, colorized_terminal and pretty-log (both versioned 2.1.0), carried the payload. Critically, these were never published to the npm registry. They shipped inside the archive, in the project's own node_modules folder, which means nothing was there for a registry-scanning tool to catch. The payload launched as a detached background process out of a hidden cache directory.
Two remote-access trojans, three operating systems. The campaign delivered NodeRabbit, a Node.js RAT with eleven-plus commands, and PollCat, a heavily obfuscated JavaScript RAT with twenty-two. Both run on Windows, Linux, and macOS from a single codebase. As Kaspersky put it, the shift to cross-platform scripting means the payloads "blend naturally into developer workstations." On a developer's machine, a Node process doing unusual things is just Tuesday.
Persistence hides in developer tooling. On Windows, registry Run keys and scheduled tasks disguised as Microsoft Edge Update or Intel driver components. On Linux, @reboot cron entries. On macOS, launch agents, plus a fake VS Code extension called "GitHub Copilot Helper" and malicious Git post-merge and post-checkout hooks. That last one deserves its own moment: the malware re-establishes itself every time the developer pulls code.
The traffic looks legitimate. Command-and-control ran through Azure-hosted web endpoints behind Cloudflare, with AES-256-GCM-encrypted JSON. Outbound HTTPS to a Microsoft cloud domain is not going to light up anyone's firewall.
One more detail tells you who these operators are hunting: PollCat checks the victim's machine for twenty-four hard-coded vendor folders, including Google, Microsoft, Cisco, Palo Alto, VMware, CrowdStrike, and Kaspersky. They aren't just looking for a laptop. They're looking for a laptop that touches a supply chain.
Why this matters if you're not an aerospace firm in Cairo
The named victims are a long way from Colorado, and it would be easy to file this under "interesting, not mine." A few reasons not to.
The recruiter lure is shared tradecraft, not one group's trick. Multiple state-sponsored actors, Iranian and North Korean among them, have converged on fake job offers aimed at developers, because it works. The specific infrastructure in this report will be dead within weeks. The playbook won't be.
It routes around the controls you actually bought. Your email gateway never sees a LinkedIn message. Your web filter sees a download from Amazon cloud storage. Your EDR sees Node.js running a project the user deliberately installed. Every one of those is a normal event; the attack lives in the space between them.
The compromised asset is the worst one to lose. A developer workstation typically holds source code, SSH keys, cloud credentials, CI/CD tokens, package-registry access, and an authenticated browser session to your source-control provider. Compromise a finance laptop and you have a fraud problem. Compromise a developer laptop and you may have handed someone your intellectual property, along with the ability to modify what you ship to your own customers.
"Run this untrusted code" is the job. You can train a payroll clerk not to open attachments. You cannot train a software engineer not to run unfamiliar code, because that's what you hired them to do. The control has to be structural, not behavioral.
What to check in your own environment
You don't need a threat-intelligence program to work through this list. You need an afternoon.
Where does unvetted code get executed? Find out whether your engineers are running take-home projects, client sample code, open-source repos, and proof-of-concept downloads directly on the same machine that holds production credentials. In most small and mid-sized shops the answer is yes, and nobody has ever asked.
Is there a disposable place to run it? A throwaway VM or container with no credentials, no persistent tokens, and no access to internal networks turns this entire attack chain into a shrug. If one doesn't exist and isn't easy to spin up, engineers will keep using their laptops, and they'll be right to, because you gave them no alternative.
Do you know what's actually in your dependency tree? This campaign never touched the public registry, which means registry-reputation checks would have missed it entirely. Ask whether anyone inspects vendored dependencies and lockfile changes before npm install runs, and whether install scripts are allowed to execute by default.
Are you looking at Git hooks and editor extensions at all? These are two of the least-monitored persistence locations on a developer's machine, and this campaign used both. A quick sweep of .git/hooks across your repos and installed VS Code extensions across your engineering fleet is a cheap exercise with a real chance of finding something.
What can one developer laptop reach? Map it: which cloud accounts, which repositories, which production systems, which secrets in plaintext on disk. This is the question that determines whether a compromised workstation is an incident or a catastrophe.
Would you see the beacon? Outbound HTTPS to *.azurewebsites.net is unremarkable in most environments. If a workstation started talking to a Microsoft-hosted endpoint on a regular interval at 3 a.m., is there anyone or anything in your organization that would notice?
Does anyone verify recruiters? Give your team an explicit, blame-free path to say "I got approached about a job, does this look real?" without it becoming an awkward conversation about loyalty. A five-minute check beats a six-figure incident.
How Mile High Cyber can help
We're a Colorado Springs-based security firm, and this is the kind of problem we're built for: small enough to be practical, senior enough to know where to look.
Penetration testing that follows the real path. A test that stops at the perimeter tells you nothing about this scenario. We look at what an attacker actually reaches once they're on an endpoint inside your environment: which credentials are recoverable, which systems that unlocks, and how far lateral movement goes before something stops it. Every engagement is human-led and manual. We use tooling, but a certified tester launches it, validates it, and interprets it. No AI does our testing for us.
Application security and build-pipeline review. Dependency handling, install-script policy, secrets management, CI/CD token scope, and code-signing practices: the controls that decide whether one compromised laptop becomes a customer-facing supply-chain event.
Vulnerability management. Ongoing visibility into what's exposed across your fleet, so the developer workstation running an unpatched stack isn't something you learn about from an incident report.
vCISO advisory. If the answer to "where do we run untrusted code?" is "wherever," you need a policy, a workflow, and someone to own them. That's a vCISO engagement, not a product purchase.
Our engagements are fixed-price with no hourly overruns, staffed by named US-based testers with no offshoring or subcontracting, and every penetration test includes one free re-test within 60 days of the final report. Finding the problem isn't the point. Fixing it is.
What to do next
Pick the cheapest control first: a disposable environment for running untrusted code, and a standing rule that take-home assignments and unfamiliar repos go there. That single change breaks this attack chain at the point of execution, and it costs you almost nothing.
Then work outward: dependency hygiene, developer-endpoint monitoring, and an honest look at what a single engineering laptop can reach on its worst day.
If you'd like a second opinion on where your developer workstations sit in your risk picture, or you want that path tested rather than assumed, talk to a founder directly. No sales process, no obligation.
Terry Bradley, CISSP, is the President and Founder of Mile High Cyber, with nearly 30 years of experience in cybersecurity. A CISSP since 2008, he specializes in penetration testing, vulnerability management, and virtual CISO services, helping small and mid-sized organizations identify, remediate, and verify their most critical security risks.