If you’re a developer, you’ve probably done a “quick take-home” or hopped on a video call where something “doesn’t work.” That’s the hook. A joint advisory tied North Korea’s WaterPlum group to the “Contagious Interview” campaign: fake recruiting conversations and coding tests that pushed people to run booby-trapped projects—infecting at least 30,000 devices across 100+ countries and stealing crypto from thousands of wallets. The goal isn’t just messing with you. It’s getting your credentials, your keys, your employer access, and anything else they can quietly pull off your machine.
How the “Contagious Interview” trap actually plays out (and why smart people fall for it)
After you hear “North Korea” and “malware,” it’s easy to assume the setup is sloppy. It’s not. The “Contagious Interview” campaign tied to WaterPlum works because it looks like regular recruiting chaos: mixed signals, rushed timelines, and “can you just run this real quick?” moments. Law enforcement says the group used fake interviews and coding tests to get victims to download projects, “troubleshoot” issues, or execute code .
The typical flow (what it looks like from your side)
1) The recruiter outreach feels normal
You get contacted through places devs actually use: recruiting networks and freelance platforms. The persona is often tied to AI, crypto, or NFT companies—the kind that “moves fast” and hires remote .
They’ll have just enough polish to pass a skim:
- A plausible company story
- A role that matches your GitHub/LinkedIn
- A quick “we loved your background” note that hits your ego in a very specific way
2) The interview cadence creates pressure
The pace is the trick. Fast scheduling. Lightweight screening. A “technical round” that’s really a delivery mechanism. The campaign explicitly used fake recruiting conversations to move targets into a moment where running something feels like the only way to keep the process going .
3) The ‘friction moment’ shows up
This is where it flips from social engineering to infection. You’ll be asked to do one of these:
- Download a take-home project (often a repo or zip) and run it locally
- Install a dependency (“it’s just npm install”)—sometimes via malicious npm packages
- Fix a video call issue (“your mic plugin is blocking,” “our meeting tool needs an update,” “run this script”)
The request is framed as helpful, not dangerous. That’s the whole point.
Why engineers fall for it (even careful ones)
This campaign doesn’t rely on you being careless. It relies on you being competent.
Here are the psychology levers that hit devs hardest:
- “You’re blocking the interview.” The ask is positioned as a small step to keep the process moving: run the project, open the folder, install the package. You feel like the bottleneck if you push back.
- “It’s normal dev work.” Running untrusted code is the job… in the right environment. In an interview, the line blurs fast.
- Urgency + politeness. The tone is “quick fix.” No drama. No obvious scam language. Just a tight timeline and a gentle nudge.
- Authority by association. The persona borrows credibility by impersonating real companies or sounding like a real internal recruiter .
And once the trap works, the stakes aren’t limited to your laptop. The advisory notes WaterPlum infections were used to steal credentials and crypto at scale —and compromised machines can become a bridge into employers and clients .
The malware stack: what BeaverTail, InvisibleFerret, OtterCookie/OtterCandy, and StoatWaffle are looking for
Once you run the “test” or open the “sample project,” you’re not dealing with one piece of malware. You’re dealing with a stack—components that land in different ways, then team up to steal data and keep access. A joint advisory links WaterPlum’s Contagious Interview activity to multiple families: BeaverTail, InvisibleFerret, OtterCookie, OtterCandy, and StoatWaffle .
What each malware family does (plain English)
- BeaverTail (JavaScript malware in npm packages)
What it is: JavaScript malware hidden inside npm packages .
How it lands: You install dependencies as part of an “assignment,” and the malicious package comes along for the ride.
What it does: Acts as an early-stage foothold—getting code execution inside a workflow that developers already trust (Node/npm).
- InvisibleFerret (Python-based backdoor)
What it is: A Python backdoor .
How it lands: Often dropped after the first infection step (think: “stage two”).
What it does: Gives the attacker a way back into your machine after the interview “task” is over.
- OtterCookie (JavaScript RAT + info stealer)
What it is: A JavaScript remote-access trojan (RAT) and information stealer .
How it lands: Delivered as part of the chain once the attacker has a path to run code.
What it does: Collects data and can support remote control behaviors.
- OtterCandy (OtterCookie plus extra RAT capability)
What it is: Malware that combines OtterCookie and RAT capabilities .
How it lands: Typically as a follow-on component.
What it does: Expands control and stealing options—more “operator-friendly,” less noisy than smash-and-grab tactics.
- StoatWaffle (malicious VS Code project execution)
What it is: Modular Node.js malware delivered via malicious Visual Studio Code projects .
How it lands: The key detail: it uses configuration files that execute code after a folder is opened and trusted .
What it does: Turns a normal dev habit—opening a repo in VS Code—into execution. That’s a nasty trick because it feels “read-only,” right up until it isn’t.
What they’re trying to steal (and why it matters)
The advisory is blunt about the targets after compromise :
- Browser credentials → saved logins, SSO sessions, password managers in the browser
- Clipboard contents → copied passwords, API tokens, seed phrases (people copy these more than they admit)
- Keystrokes → whatever you type: credentials, recovery codes, internal URLs
- Crypto private keys + seed phrases → direct wallet drain risk
- Documents + screenshots → contracts, internal diagrams, customer data, “stuff on your desktop”
And the part developers often underestimate: access on your laptop can be used to pivot into your employer’s or clients’ networks, turning a “job interview” problem into an enterprise breach .
Red flags during recruiting: what to treat as a hard stop
When an interview process is being used as delivery, the “technical” parts start looking weird in very specific ways. WaterPlum’s Contagious Interview activity is tied to fake recruiting that pushes candidates into downloading projects, troubleshooting “issues,” or executing code —and it also overlaps with the broader DPRK playbook of fraudulent IT-worker operations .
Treat the patterns below as hard stops, not “maybe I’m being paranoid.”
A tight hard-stop checklist (recruitment phishing + malicious take-homes)
Repo and project behavior
- Random repo links sent over chat with “just run it locally” vibes, especially if they dodge a normal hiring portal or official email trail.
- Any instruction to “trust this workspace” in VS Code without a clear, verifiable reason. StoatWaffle is called out as using VS Code projects where config can execute after a folder is opened and trusted .
- A take-home that’s “simple,” but immediately requires:
- extra setup scripts,
- new package managers,
- copied terminal commands you didn’t ask for,
- or “quick fixes” that look like busywork.
Dependency and install asks
- Installing dependencies from unusual sources (custom registries, direct URLs, “use this fork/package”), or anything that feels like bypassing the standard ecosystem.
- “It’s just an npm install” paired with urgency. The advisory notes this campaign used malicious npm packages to infect devices .
Video-call “fixes” that don’t add up
- Any push to install a “codec,” “plugin,” “meeting patch,” or run a script to fix audio/video.
- Repeated “camera problems” used as a narrative device. Investigators found WaterPlum actors used AI face-swapping during online interviews, then turned off cameras and blamed network problems .
The bigger DPRK pattern behind the weirdness
These aren’t isolated tricks. Agencies directly connect WaterPlum activity with fraudulent IT-worker operations —the same ecosystem that:
- steals data during infections, then reuses stolen identity documents to impersonate victims and obtain jobs
- runs operational setups like “laptop farms” (Japan’s NPA reported dismantling one)
If a “recruiter” can’t handle basic verification, but is perfectly organized about getting you to run code or install something, that’s not a fast-moving startup. That’s a playbook.
Defend yourself (developers): a practical workflow for handling take-homes and “sample projects” safely
If you take one thing from the advisory, take this: don’t run unknown code outside a sandbox, and inspect files for commands that fetch additional payloads . That single habit breaks a big chunk of recruitment phishing.
Here’s a workflow you can actually stick to.
Step-by-step: a safer way to handle take-homes
- Verify the org and the human (fast, not obsessive)
- Ask for an email from the company’s real domain, not just chat.
- Confirm the recruiter/interviewer exists on the company site or a consistent presence.
- If the “company” can’t handle basic verification, treat the take-home like hostile input.
- Move the assignment off your daily machine
Use an isolated environment every time:
- A dedicated VM (or separate laptop) with no personal accounts signed in
- No password manager browser profile
- No crypto wallets, no SSH keys you care about
- Snapshots enabled so you can roll back
This lines up with the advisory’s direct guidance to avoid running unknown code outside a sandbox .
- Assume outbound network activity is part of the trap
If you can, block or restrict outbound connections from the VM while you inspect the project. Why? The advisory warns to look for commands that fetch additional payloads .
Practical options:
- Pause network while reviewing files
- Allow-list only what you need (docs, known package registries)
- Watch for surprise calls to paste sites, file hosts, “update servers,” or raw IPs
What to inspect before you run anything (quick checklist)
package.json (Node/npm)
Look at:
scripts(especiallypreinstall,postinstall,prepare)- weird one-liners that use
curl,wget,powershell,python,node -e - scripts that decode blobs (base64) or spawn shells
VS Code workspace files (high-signal for this campaign)
StoatWaffle is described as being delivered via malicious Visual Studio Code projects, using configuration files that execute code after a folder is opened and trusted .
Check these before clicking Trust:
.vscode/settings.json.vscode/tasks.json.vscode/launch.json- recommended extensions (
.vscode/extensions.json) - any workspace file (
*.code-workspace)
If the instructions tell you to “just trust the workspace,” slow down. Read the configs first.
“Second-stage fetch” indicators (common across stacks)
Hunt for anything that:
- downloads binaries/scripts during setup
- pulls from new domains on first run
- “updates” itself
- runs on open/build/test without you explicitly triggering it
A small habit that pays off
Keep a separate “interview identity”:
- a clean email alias
- a clean browser profile in the VM
- minimal tokens on disk
If you use a privacy tool like Cloaked, this is one of the few times it’s directly helpful: you can share an alias email/number with recruiters without tying the whole process to the same identifiers you use everywhere else.
The goal isn’t to be scared of every take-home. It’s to treat unknown code like unknown code—because that’s exactly what it is.
Defend your org (employers): stop the fake-candidate-to-internal-access pipeline
The candidate is just the entry point. WaterPlum’s activity isn’t limited to draining wallets or stealing personal creds—agencies warn attackers can use compromised computers to pivot into employers’ or clients’ networks, pushing this into IP theft and espionage territory . Add the overlap with DPRK fraudulent IT-worker operations, and hiring becomes an access-control problem, not an HR problem .
Hiring controls that actually help (without turning interviews into theater)
Identity + location checks (consistent, not random)
The advisory’s guidance to employers is direct: verify applicants’ identities, locations, and qualifications .
Make it routine:
- Verified identity: government ID checks through an approved vendor, plus a consistent policy on what you accept.
- Location validation: compare claimed location vs. network signals during interviews and onboarding (VPN use isn’t always malicious, but unexplained patterns are a smell).
- Live verification: short “turn your camera on, show a room pan, read a code” checks when something feels off.
Why it matters: investigators found WaterPlum-linked actors used AI face-swapping in online interviews, then turned cameras off and blamed network issues .
Watch for the broader DPRK IT-worker pattern
Agencies connect WaterPlum to North Korea’s IT-worker operations, noting shared infrastructure, and warn that stolen identity documents can be reused to impersonate victims and obtain jobs . Japan’s NPA also reported dismantling an IT-worker “laptop farm” .
Operational tells worth training recruiters and interviewers to report:
- Camera-on resistance that’s framed as “network problems” over and over
- A candidate who avoids any spontaneous interaction (typing on demand, quick screen share pivots, showing local system settings)
- Overly controlled setups that don’t match the story (always perfect framing, no ambient cues, rigid scripts)
Technical guardrails: assume a bad hire happens anyway
- Least-privilege onboarding (day 1 should be boring)
The advisory explicitly warns to restrict access to only the systems and data required for the job .
Do it in layers:
- New devs start with read-only where possible (docs, repos) and earn write access.
- Separate credentials for:
- code repo
- cloud console
- CI/CD
- secrets manager
- Short-lived access grants and time-boxed elevation.
- Segmented dev environments (keep “new person” work contained)
- Put new hires in a segmented dev sandbox: separate cloud accounts/projects, separate VPCs, separate secrets.
- Make “prod-adjacent” access something you grant later, with peer review and audit trails.
- Monitor dev-tool behavior (because the toolchain is the target)
This campaign uses developer workflows as execution paths. Build detections around:
- unexpected child processes spawned by editors/IDEs
- unusual outbound connections right after opening a repo or running build scripts
- suspicious dependency install behavior (new registries, postinstall execution patterns)
- A clear policy on running external code
Agencies also call out what individual developers should do: avoid running unknown code outside a sandbox and inspect files for commands that fetch additional payloads .
Make that enforceable at org level:
- Mandate that take-homes, OSS evaluation, and “random GitHub project” testing happens in company-approved sandboxes/VMs
- Provide those sandboxes so people don’t improvise on their daily workstation
- Document what to inspect (scripts, installers, workspace configs) and who to call when something’s off
If you treat hiring as part of your security boundary, you don’t have to guess whether a candidate is real. You just have to make it hard for a fake one to turn “hello” into internal access.
