The LinkedIn job offer that came with a Python backdoor

What happened

A developer publishing under roman.pt walked through a LinkedIn recruiter interaction that ended with a malicious repository on his disk. The writeup — currently at 885 points on Hacker News — is a careful teardown: how the recruiter's profile looked legitimate enough to clear the usual sniff tests, how the 'take-home assignment' was a real-looking codebase with a believable README, and where exactly in the source tree the obfuscated payload was buried.

The interesting part isn't that the malware existed. It's that every step before it was indistinguishable from a real recruiting funnel. The recruiter persona had mutual connections, prior employment at named companies, and a history of public posts. The repo compiled. The tests mostly passed. The malicious string was hidden inside a config-shaped helper, base64-encoded behind what read like an env-lookup utility — the kind of code you skim and forget.

The attack pattern is not novel. Mandiant, CrowdStrike, Microsoft Threat Intelligence, and Unit 42 have all published on it under names like Operation Dream Job and Contagious Interview, attributing it to DPRK-aligned operators (Lazarus, BlueNoroff, and clusters thereof). What Roman's post adds is a current, end-to-end specimen, dissected by the target himself.

Why it matters

The threat model every senior engineer has been trained on assumes the adversarial code comes from a sketchy npm package or a phishing email. It doesn't assume the adversary is on your calendar. Remote-work hiring has normalized the take-home repo. A real coding challenge with a working build script is now the default first-round signal. Three years of that conditioning is exactly what the operators are exploiting.

The second structural factor is target selection. The roles being advertised in these lures cluster in crypto, fintech, and infrastructure — exactly where the highest-paying remote jobs live in 2026, and exactly where DPRK has the strongest revenue incentive to penetrate. The Bybit incident in February 2025, where $1.5B was drained after Safe{Wallet} developer infrastructure was compromised, has been publicly attributed to nearly identical malicious 'developer assessment' code delivered through a recruiter pipeline. That hack alone funded a non-trivial fraction of the regime's missile program.

The defensive gap is not for lack of trying. macOS XProtect/Gatekeeper, Linux AppArmor profiles, and Windows Defender consistently miss these payloads. The reasons are structural: the payloads are staged (stage 1 is small and benign-looking, stage 2 is fetched only after fingerprinting), they execute inside legitimate runtimes (node, python, deno), and they avoid persistence mechanisms that EDR tools watch. Endpoint defense was built around 'don't run untrusted binaries.' Modern attackers don't ship binaries — they ship scripts that the developer runs himself, on purpose, in the runtime he already has open.

The HN thread on Roman's post is unusually high-signal. The top-voted replies cluster around three observations: (1) the asymmetry — the attackers need exactly one of N targets to slip, and they have unlimited tries; (2) the blast radius — a typical dev machine in 2026 has SSH keys, AWS profiles, npm publish tokens, Vercel/Cloudflare API keys, a browser session for GitHub with org-admin rights, and a 1Password unlocked in the background; and (3) the LinkedIn problem — the platform has known about this attack pattern for years and the controls remain perimeter-only. Fresh accounts get rate-limited. Seasoned accounts (including hijacked legitimate ones) sail through. There is no marketplace-level signal warning a candidate that they're about to receive a tampered repo.

What this means for your stack

The practical rules are unglamorous and worth writing down once:

- Disposable VM, not a container. Containers share the host kernel. A malicious Node native module or a Python C extension with a kernel-side exploit gets you a host compromise. A real VM (UTM, Multipass, Lima, Firecracker, a throwaway EC2) costs you sixty seconds of boot time and gives you a real boundary. - Separate browser profile with zero logged-in accounts when reading the repo or running the dev server. The dev server itself can call `fetch('http://localhost/...')` against your auth cookies if you let it. - `npm install --ignore-scripts`, then audit the `postinstall` and `prepare` hooks before running anything. This is a one-line habit and catches the majority of the npm-side variants. - No secrets on the VM. Don't `aws configure`. Don't `gh auth login`. Don't paste your `.npmrc`. The repo doesn't need them to compile. - Treat job-offer-shaped artifacts like USB drives in a parking lot. The right trust posture for unsolicited recruiter code is the same one you'd apply to a stranger's binary, because that's exactly what it is.

For platform builders: if you're shipping a developer-facing tool that runs untrusted code on behalf of users — coding agents, AI IDEs, CI runners for forked PRs — assume your users are the target. The exploit doesn't have to defeat your sandbox; it just has to defeat the user's confidence that your sandbox is sufficient. Document your isolation model in plain English and ship safe defaults.

Looking ahead

The next escalation is obvious and already underway: agentic coding workflows. If your editor runs a coding agent that 'tries the repo to see if the tests pass' without your direct supervision, the human-in-the-loop pause that saved Roman disappears. The attacker no longer needs the developer to type `npm install` — the agent will do it, in the background, on a machine still logged into everything.

The Lazarus operators have run this same template across LinkedIn, Telegram, and Upwork for three years, and they're still landing engineers because the economics are unbeatable from their side: low cost per attempt, eight- to ten-figure payoff per hit. The defense that scales isn't better malware detection — it's the boring habit of running someone else's code somewhere it can't hurt you. Roman's writeup is worth reading not because the technique is new, but because it's a reminder, in 2026, that the recruiter is the threat actor now.