A recruiter shows up with a good-looking AI engineer role.

The company looks plausible enough. The position sounds real. The process moves like a normal interview process. Nothing too strange at the beginning.

Then comes the technical test.

"Clone this private repository and run it locally."

That was the moment the whole thing started to smell wrong.

The candidate refused to run it on the main machine, which was the correct decision. Later, the repository was inspected safely inside a virtual machine. And the result was not "bad code", or "a sloppy take-home assignment", or "some weird dependency problem".

It was malware.

Hidden inside the repository was a .vscode/tasks.json file that tried to auto-execute a curl | bash command when the project was opened. That command downloaded a dropper from a disguised domain. The dropper installed another script under ~/.vscode/, used nohup for persistence, and fetched a second stage payload.

That second stage was not subtle about its intentions. It went after crypto wallets, SSH keys, AWS credentials, browser sessions, environment variables, and opened a command-and-control channel.

And if the candidate had simply run npm start, the project would have sent the entire process.env to an external server and executed arbitrary JavaScript received in the response.

That is full remote code execution.

Not "oops, I installed a bad package".

Not "this repo looks suspicious".

Full compromise of a developer workstation.

this has a name

This is not an isolated scam.

It is part of a documented campaign known as Contagious Interview, attributed to North Korean state-backed operators connected to the Lazarus ecosystem. Different vendors track pieces of this activity under names like NICKEL ALLEY, Void Dokkaebi, and related DPRK clusters.

The pattern is brutally effective because it abuses something developers already consider normal: technical interviews.

A fake recruiter contacts a developer. The job is usually in crypto, Web3, AI, trading, or some adjacent high-salary niche. The conversation looks professional enough. The candidate gets a coding assignment. The assignment is hosted on GitHub, GitLab, or Bitbucket. The repository looks like a normal app.

Then the trap closes.

Sometimes the malware is hidden in an npm dependency. Sometimes it is in a package script. Sometimes it is in obfuscated JavaScript. Sometimes it is fetched from a cloud host like Vercel. And increasingly, it is wired into developer tooling itself.

That last part matters.

Microsoft has documented cases where the attack uses Visual Studio Code workflows. The victim opens the downloaded project in VS Code, gets the normal Workspace Trust prompt, and if they trust the folder, VS Code can execute the repository task configuration. Sophos documented the same abuse pattern through .vscode/tasks.json, with tasks configured to fetch malware using curl or wget depending on the victim's operating system.

That means the dangerous action is not always "run the app".

In some cases, the dangerous action is "open the repo in the editor and trust it".

That is a very different risk model from the one most developers carry in their heads.

why developers are the target

Attackers are not targeting developers because we are special.

They are targeting developers because our machines are ugly treasure chests.

A normal developer laptop may contain:

• SSH private keys
• GitHub and GitLab sessions
• AWS credentials
• GCP or Azure credentials
• Kubernetes configs
• .env files
• production-like database URLs
• CI/CD tokens
• package registry tokens
• browser cookies
• password manager sessions
• crypto wallet extensions
• source code for private systems

That is not "one endpoint". That is a jumping point into companies, cloud accounts, deployment systems, source repositories, and sometimes customer data.

This is why the campaign is so focused on engineers, especially people working around crypto, trading, AI, infrastructure, and startup ecosystems. A recruiter can pressure a job seeker in a way a random phishing email cannot. The victim wants the job. The victim wants to look responsive. The victim does not want to be the annoying person who refuses to run the take-home project.

That social pressure is the exploit.

The malware is just the implementation detail.

the campaign is industrial now

The scale is the part that should make engineering leaders pay attention.

This is not one clever operator manually sending sketchy repositories on LinkedIn.

Socket has been tracking the Contagious Interview supply-chain activity across package ecosystems and reports hundreds of malicious npm packages tied to the campaign. In one 2025 wave alone, Socket counted 338 malicious npm packages with more than 50,000 downloads. By the later 2025 waves, public reporting had counted well over 535 malicious npm packages and more than 80,000 total downloads. The campaign tracker later showed activity continuing into 2026 across npm, PyPI, Cargo, Go, and Composer artifacts.

Dark Reading, citing Trend Micro research, reported that the campaign evolved into a worm-like supply-chain threat: compromised developer projects can carry malicious VS Code task configuration, which then spreads when other developers clone and trust the repository. Trend Micro also reported more than 750 infected repositories and more than 500 malicious VS Code task configurations in March 2026.

Sophos' NICKEL ALLEY research shows the same operator pattern from another angle: fake companies, fake LinkedIn credibility, GitHub accounts posing as legitimate software organizations, Vercel-hosted payloads, and repositories dressed up as Web3 or full-stack projects. In many observed cases, the repository is only the loader. The real payload lives off-platform on Vercel or attacker-controlled infrastructure, which makes takedowns and static repository review less reliable.

Microsoft's write-up names payload families such as OtterCookie, BeaverTail, Invisible Ferret, and FlexibleFerret. The important point is not the malware branding. The important point is what they do: exfiltrate secrets, profile the machine, monitor clipboard contents, take screenshots, fetch more modules, and execute attacker-supplied commands.

This is an interview pipeline turned into malware delivery infrastructure.

And it has been active for years. Microsoft traces related Contagious Interview activity back to at least late 2022. Other reporting describes heavy abuse from 2023 onward. It is still active in 2026.

what gets stolen

If this lands on your real machine, assume the attacker is not just stealing the toy project.

Assume they are going after:

• crypto wallets and wallet browser extensions
• seed phrases and private keys
• SSH private keys
• AWS credentials
• cloud provider configs
• GitHub, GitLab, and Bitbucket sessions
• npm and package registry tokens
• browser session cookies
• .env files
• clipboard contents
• screenshots
• keystrokes
• source code
• CI/CD access

Also assume they may keep access.

Some payloads are remote access trojans. Some open command-and-control channels. Some install persistence. Some fetch new code after the first stage has already passed the easiest checks.

That is why "I opened it but did not run anything" is no longer a good enough safety line. If an editor task fired, if a dependency installed, if a package script ran, or if some obfuscated loader fetched a second stage, the damage may already be done.

the red flags

Here is the checklist I would keep close if I were interviewing right now.

🚩 They ask you to clone a private or unfamiliar repository and run it locally.

🚩 The company exists only on LinkedIn, with no convincing web presence, customer footprint, team page, funding history, or normal public trail.

🚩 The recruiter found you, but has no mutual connections, a thin profile, or a recently created account.

🚩 The technical test is a whole project to download instead of a sandboxed exercise.

🚩 They are in a hurry: "just run it, it is quick", "we need this today", "screen share while you install it".

🚩 The repo contains .vscode/tasks.json, suspicious workspace settings, postinstall or preinstall scripts, obfuscated dependencies, minified blobs, encoded URLs, or network calls during startup.

🚩 They insist you use your own machine instead of a sandbox, VM, browser IDE, or company-provided environment.

🚩 The role is crypto, Web3, trading, AI, or developer tooling, especially if the compensation is strangely generous for the amount of process involved.

And the counter-check:

✅ Legitimate technical interviews usually use CoderPad, HackerRank, LeetCode, Replit shared sessions, GitHub Codespaces, or a constrained environment.

✅ Legitimate companies can verify the recruiter, company domain, interview process, and hiring manager.

✅ Legitimate recruiters do not need you to run proprietary mystery code on your personal machine.

✅ Legitimate engineering teams should not get offended when a developer asks for a safer way to inspect a take-home assignment.

If they do get offended, that is useful signal.

what to do instead

First defence: scan the repository before opening it.

Use scanrepo.dev. It checks repositories for hidden scripts, suspicious dependency behavior, malicious patterns, and known attack signatures. This is exactly the kind of lightweight defensive step that should become normal for recruiter-provided code.

Then slow down.

Do not open an untrusted repository directly in your main VS Code profile. Do not grant Workspace Trust to a folder just because the prompt appears during an interview. That prompt is not decoration. It changes what the project is allowed to do.

If you must inspect the code locally, use a disposable VM or a container with no access to your home directory, SSH keys, cloud credentials, browser profiles, password manager, or clipboard history.

Before running anything:

• inspect .vscode/tasks.json
• inspect .vscode/settings.json
• inspect package.json
• search for postinstall, preinstall, prepare, and install scripts
• search for curl, wget, bash, sh, powershell, eval, Function, child_process, exec, spawn, axios, fetch, and suspicious encoded strings
• check for hidden files and unusual directories
• check commit history
• check contributor profiles
• check whether dependencies are new, typosquatted, or oddly unpopular
• check whether the app calls external servers on startup

For VS Code specifically, review Workspace Trust settings under:

Settings -> Security -> Workspace Trust

If you regularly inspect unknown code, create a separate editor profile for hostile repositories. Better yet, inspect them in a VM and throw the VM away afterwards.

For npm projects, never start with npm install on your real machine. Package lifecycle scripts are code execution. A malicious postinstall is not less dangerous because it is in package.json.

For AI and crypto roles, be even more suspicious. That is where the attacker return is highest.

what companies should change

This is not only an individual developer problem.

Companies should stop normalizing "clone this repo and run it locally" as an interview pattern.

If your hiring process requires candidates to run code, provide a sandbox. Use a browser IDE, a Codespaces-style environment, a prepared VM, or a constrained runner. Make it boring. Make it auditable. Make it safe.

And if you are hiring engineers, say explicitly that candidates are not expected to run unknown code on their personal machines. That one sentence would remove a lot of social pressure from the candidate.

Security teams should also treat recruitment as an attack surface. Developers interviewing elsewhere may still be using corporate machines. Even if that violates policy, it happens. If your protection strategy assumes engineers never mix personal hiring activity with work devices, your strategy is based on a fantasy.

Monitor for editor-launched shells. Watch for VS Code or Cursor spawning bash, curl, wget, PowerShell, Python, or Node processes that immediately talk to low-reputation domains. Look for package installs that launch network activity unrelated to normal registries. Hunt for broad filesystem enumeration around .env, wallet, key, password, seed, and credential patterns.

This campaign is successful because it lives in the gap between "security training" and "how developers actually work".

Close the gap.

trust your instinct

The candidate in the story did the most important thing right: they paused.

That is the real lesson.

Not every weird recruiter is Lazarus. Not every bad take-home assignment is malware. Not every small company with a thin LinkedIn page is fake.

But a stranger asking you to clone a private repo and run it locally is not a harmless request anymore.

It is an executable trust decision.

Treat it like one.

If it feels off, stop. Scan it. Open it in a disposable environment. Ask for a sandbox. Ask them to verify the company and process. Ask why the test cannot run in a browser environment.

A real company will survive those questions.

A fake recruiter will get impatient.

That impatience may be the warning that saves your machine.

references

• Microsoft Security Blog: Contagious Interview: Malware delivered through fake developer job interviews
• Sophos: NICKEL ALLEY strategy: Fake it 'til you make it
• Dark Reading: DPRK Fake Job Scams Self-Propagate in 'Contagious Interview'
• Socket: North Korea's Contagious Interview Campaign
• Socket: North Korea's Contagious Interview Campaign Escalates: 338 Malicious npm Packages, 50,000 Downloads
• Socket: Contagious Interview Campaign Escalates With 67 Malicious npm Packages and New Malware Loader
• Security Buzz: North Korea's Contagious Interview Malware Floods npm With 200 New Packages
• CyberPress: North Korean Hackers Use VS Code Workspace Trust to Deploy Malware
• GBHackers: Fake IT Worker Schemes and Contagious Interview Threats