Fake Job Interview Malware: How North Korean Operators Weaponize Coding Tests Against Developers (2026 Defense Guide)

If you are a developer or run a small engineering team, the most dangerous email in your inbox right now is not a phishing lure pretending to be your bank. It is a friendly recruiter offering a remote role with a generous salary, followed by a "short technical assessment" hosted on GitHub or Bitbucket. Clone the repo, run the project, share your screen on the call. That is the entire trap.

This is the Contagious Interview campaign (tracked by various vendors as DeceptiveDevelopment and attributed to the North Korean cluster commonly called Famous Chollima). It has been running and mutating since 2023, and through 2025 and into 2026 it has gotten noticeably better at targeting people who should know better: senior engineers, blockchain developers, and DevOps staff with admin rights. In my experience securing developer workstations, this is the threat I now brief every new engineering hire about on day one, because it bypasses almost every control built for office workers and aims straight at the one thing developers do dozens of times a week without thinking — running untrusted code.

Why developers are the perfect target

Most malware has to convince a victim to do something abnormal: enable macros, disable antivirus, paste a PowerShell command. Developers do the equivalent of all three as part of their normal job. Cloning a stranger's repository, installing its dependencies, and running it is routine. The attacker does not need an exploit or a zero-day. They just need you to do your job inside a project they control.

The payoff is also higher. A developer's machine frequently holds:

• Browser-stored credentials and session cookies for cloud consoles (AWS, GCP, Azure), GitHub, and internal tools.
• Cryptocurrency wallet extensions like MetaMask, Phantom, and the local keystores behind them.
• SSH keys, cloud CLI tokens, and .env files with production secrets.
• Password manager data, including browser-extension vaults that may be unlocked during a session.

One compromised laptop can become an entry point into an entire company's infrastructure. That is why this campaign overlaps with major supply-chain and exchange intrusions.

The attack chain, step by step

1. The approach

Contact usually starts on LinkedIn, but I have also seen it on Upwork, Telegram developer groups, Discord servers, and direct email. The recruiter persona is polished: a real-looking profile, a plausible company (sometimes a real company being impersonated, sometimes a fake crypto/Web3 startup), and a role that matches your actual skill set because they read your profile first. Compensation is attractive but not absurd. The conversation moves to a "quick assessment" fast.

2. The malicious project

You get a link to a repo on GitHub, Bitbucket, or GitLab, or a zipped project, with a task like "find and fix the bug" or "add a feature to this demo app." The code looks like a normal Node.js, React, or Python project. The malicious part is buried where reviewers rarely look:

• Inside a heavily minified or obfuscated line in a config file, a server file, or a deep dependency.
• In a postinstall or other lifecycle script in package.json that fires automatically when you run npm install.
• Hidden behind a benign-looking import that pulls a malicious npm package the attacker published.

The first-stage payload most often seen is BeaverTail — a JavaScript infostealer and loader. It harvests browser data and crypto-wallet extensions, then downloads the second stage.

3. The backdoor

BeaverTail typically pulls down InvisibleFerret, a Python backdoor that provides persistence, remote command execution, file exfiltration, keylogging, and the ability to deploy remote-access tooling (AnyDesk-style control has been observed). Newer variants in this family, including one researchers named OtterCookie, expand the data theft and add clipboard monitoring to catch wallet addresses and seed phrases. The point is that the toolkit keeps changing, so signature-only detection is unreliable.

4. The "camera not working" pivot

A second flavor of this campaign skips the repo and uses the video interview itself. During the call your "camera" or "microphone" fails, and the recruiter helpfully tells you to download a fix or a specific meeting client (fake builds of apps with names mimicking real conferencing tools have been used). The download is the malware. If anyone on a job call ever tells you to run a terminal command or install an unfamiliar app to fix your A/V, end the call. That is the attack, not tech support.

How to recognize it before you run anything

You will not always spot the malicious code by reading it — obfuscation is the point. So treat the situation as the signal, not the code. Red flags I tell teams to treat as automatic stop signs:

• A recruiter who pushes you to clone and run a project locally rather than complete a task on a standard platform like HackerRank, CoderPad, or a shared online IDE.
• Pressure to install a specific app, SDK, or "meeting client" outside official app stores.
• Instructions to run npm install, npm start, pip install, or a setup script before reading the code.
• A company with a thin or very new web presence, a Web3/crypto focus, and salaries paid in stablecoins.
• Communication that drifts to Telegram or Discord quickly and avoids verifiable corporate email or a formal applicant-tracking system.
• A coding task delivered as a zip file or a private repo with unusual dependencies and lifecycle scripts.

The defensive playbook

The core principle is simple: never run interview code, or any untrusted code, on a machine that holds anything you care about. Everything below is built around that rule.

1. Run untrusted code in a disposable, isolated environment

This is the single control that defeats the whole campaign. Build a throwaway sandbox and treat anything that touches it as burned.

• Disposable VM: Keep a clean virtual machine snapshot (VirtualBox, VMware, UTM on Apple Silicon, or a cloud VM you can destroy). Disable shared folders, shared clipboard, and drag-and-drop. Do the task, then revert to the snapshot. No host credentials, no wallets, no SSH keys ever live here.
• Container for code execution: For quick checks, run the project in Docker with no network until you have read it. Example: docker run --rm -it --network none -v $(pwd):/app -w /app node:20 bash, then inspect before you ever add network access. Add --read-only and drop capabilities for more isolation.
• Linux sandboxing: On Linux, firejail --net=none --private node app.js confines a process to a throwaway home directory with no network.
• GitHub Codespaces / cloud dev environments: Running the project in an ephemeral cloud workspace keeps the blast radius off your laptop entirely.

2. Inspect before you execute

Before running anything, even in a sandbox, do a fast triage:

• Open package.json and look at the scripts block. Be deeply suspicious of preinstall, postinstall, and any script that pipes to node -e, fetches a URL with curl/fetch, or references base64 blobs.
• Install dependencies without running their scripts: npm install --ignore-scripts. This blocks the most common auto-execution path.
• Search for obfuscation. Long single-line strings, eval(), Buffer.from(...,'base64'), require('child_process'), and dynamic import() of remote content are warning signs. Grep the tree: grep -rniE "eval\(|child_process|base64|atob\(|fromCharCode" .
• Check unfamiliar dependencies against the public registry and their download counts. A package with near-zero downloads pulled into a "coding test" deserves scrutiny. Run npm audit, but do not trust a clean audit as proof of safety — these are often brand-new malicious packages, not known-vulnerable ones.

3. Separate identities and money from your dev box

• Move crypto to a hardware wallet. Ledger or Trezor keys never touch the host where you run code. Browser-extension wallets on a developer machine are exactly what BeaverTail is built to loot.
• Do not store work and personal credentials in the same browser profile. Use separate profiles, and lock your password manager when you are not actively using it so an infostealer cannot scrape an unlocked vault.
• Use short-lived cloud credentials. Prefer SSO and temporary tokens (AWS IAM Identity Center, aws sso login) over long-lived access keys sitting in ~/.aws/credentials.
• Keep secrets out of .env files on the same machine where you run untrusted projects. Use a secrets manager and inject at runtime.

4. Harden the endpoint

• Run a real EDR/antivirus, not just the default. For small teams, Microsoft Defender for Business, CrowdStrike Falcon Go, SentinelOne, or even properly configured Defender plus a tool like Malwarebytes raises the cost of the second stage considerably.
• Enable DNS and network filtering. InvisibleFerret needs to reach its command-and-control server. Filtering DNS (NextDNS, Cloudflare Gateway, Pi-hole with threat lists) and watching for connections to unfamiliar hosts can catch the callback.
• Block lifecycle scripts globally during triage. You can set npm config set ignore-scripts true for your evaluation account so packages cannot auto-run install hooks.
• Keep Node, Python, and your OS patched, and remove old global packages you no longer use.

5. Verify the human

• Confirm the company independently. Find the company's real domain yourself, then check whether the recruiter's email matches it. Look up the recruiter on the company's actual site, not just LinkedIn.
• Insist on standard assessment platforms. A legitimate employer is fine with HackerRank, CoderPad, or a live shared editor. Refusal to use anything but "clone my repo and run it" is itself a finding.
• Reverse-image-search profile photos. Many of these personas reuse stock or stolen images.

What to do if you already ran the code

Assume full compromise and move fast. Speed matters more than tidiness here.

• Disconnect the machine from the network immediately to cut off the backdoor's command channel and exfiltration.
• From a separate, clean device, rotate everything that machine could reach: GitHub tokens and SSH keys, cloud access keys, password-manager master password, and the credentials of any site whose cookies could have been stolen. Revoke active sessions and OAuth grants where possible.
• Move any crypto to a new wallet generated on a clean device or hardware wallet. If a seed phrase was ever typed or stored on the infected host, treat that wallet as permanently lost and abandon it.
• Re-enroll MFA on critical accounts, because session-cookie theft can sail past MFA prompts entirely.
• Wipe and reinstall the OS. Do not try to clean this in place. Persistence and additional payloads make a clean rebuild the only reliable option.
• If this is a work device, notify your security team or MSP. One developer's laptop is often the start of a wider incident, and an early heads-up changes the outcome.

For team leads and small businesses

This is not only an individual problem. If you hire developers or contractors, build a simple, written rule: technical assessments are completed on approved platforms or inside a company-provided sandbox, never by running candidate-supplied code on a personal or production-connected machine. Give every engineer a disposable VM image and make sandboxing the default, not an emergency measure. Pair that with an EDR rollout, DNS filtering, and least-privilege cloud access so a single mistake cannot cascade into your production environment.

The strength of this campaign is that it turns a developer's competence against them — the more comfortable you are running other people's code, the easier you are to hit. The fix is not to become paranoid about every repository. It is to make "running untrusted code" a boring, contained, reversible act. Snapshot, isolate, inspect, revert. Do that consistently and the slickest fake recruiter on LinkedIn ends up with nothing but a wiped sandbox.