A job interview is supposed to test what a developer can build. In the WaterPlum campaign, authorities say the interview itself can become part of the attack.
On September 18, 2026, Japanese, U.S., Australian and German authorities published a joint advisory identifying WaterPlum, commonly referred to as “Contagious Interview,” as a North Korean cyber actor group targeting software developers and other IT professionals. The advisory says WaterPlum exploited at least 30,000 PCs in more than 100 countries from around December 2025 through July 2026. It also says the actors transferred cryptocurrency worth at least 1.7 billion Japanese yen, or $10.71 million, to North Korea and took funds or account credentials from more than 7,000 cryptocurrency wallets.
There is an important terminology correction here: WaterPlum is the name of the cyber actor group, not the name of one particular piece of malware. The campaign has used several malware families, including BeaverTail, InvisibleFerret, OtterCookie, OtterCandy and StoatWaffle.
That distinction matters because the real story is broader than a malware sample. WaterPlum is using a familiar professional interaction — a job opportunity — to persuade developers to run software they should otherwise treat as untrusted.
What WaterPlum Actually Is
WaterPlum is the name authorities are using for a North Korean cyber actor group that targets IT professionals through recruitment-themed social engineering.
The group reportedly approaches job seekers through social media, online job platforms, gig-work services and freelance marketplaces. According to the joint advisory, attackers may pose as prospective employers and impersonate legitimate AI, cryptocurrency or NFT companies.
The crucial part happens during the recruitment process.
A candidate may be asked to join an online technical interview or complete a coding assignment. The attacker can then instruct the candidate to download and execute files hosted on developer platforms, collaboration services or code repositories. The stated reason may be to complete the coding task or troubleshoot a supposed problem with an online video-conferencing platform.
So let's separate two ideas:
The recruiter is one trust decision. The code is another.
A person can appear convincing while the repository or package they provide is malicious.
Why a Coding Test Is Such an Effective Lure
For developers, downloading and running unfamiliar code is not automatically suspicious. It is part of the job.
You may clone a repository, install NPM packages, configure environment variables, run a development server and execute build scripts before you can even evaluate a project.
That normal workflow gives a fake recruiter a believable reason to ask for risky actions.
Imagine you receive a message saying:
“We like your portfolio. Please download this Next.js project, fix the checkout bug, and send us your solution.”
Nothing about that instruction necessarily looks bizarre to a developer.
The danger starts when the project contains an additional payload that has nothing to do with the assignment.
Independent research from Elastic Security Labs illustrates how convincing these projects can be. In a July 2026 investigation, Elastic found trojanized coding assignments built from otherwise functional software projects. One sample was based on a real Next.js e-commerce template, with malicious code inserted into the project while parts of the payload were hidden inside SVG files.
That is a much more sophisticated social-engineering problem than a traditional phishing email.
The victim is not necessarily persuaded to open an obviously malicious attachment. The victim is persuaded to perform a normal development task on malicious code.
What Happens After the Code Runs
According to the joint advisory, WaterPlum uses malicious loaders to establish backdoor access and can then use remote-access trojans to maintain connectivity, persistence and pathways to move across victim systems. Infostealing components are used to collect sensitive information and cryptocurrency and send it to command-and-control infrastructure.
The malware families involved are not identical.
The advisory describes BeaverTail as JavaScript-based malware hidden in NPM packages and InvisibleFerret as a Python-based backdoor. OtterCookie is described as a JavaScript remote-access trojan and information stealer, while OtterCandy combines capabilities associated with OtterCookie and RATatouille. StoatWaffle is a modular Node.js malware family that can use malicious Visual Studio Code projects as decoys.
That variety is one reason it is misleading to think of WaterPlum as “one virus.”
The campaign is better understood as an attack operation using several related pieces of malware and several delivery techniques.
Elastic's research adds another technical detail: one Contagious Interview sample hid Base64-encoded payload fragments inside HTML comments in SVG images and reconstructed them during execution. Elastic said the malicious project remained functional enough to look like a legitimate development exercise.
For a developer, that creates an uncomfortable but useful lesson: working software can still contain malicious behavior.
A project does not have to crash, display a warning or obviously break your machine to be dangerous.
What Information Is at Risk?
The potential damage extends well beyond cryptocurrency.
The joint advisory says WaterPlum targets browser authentication data, clipboard information, keystrokes, screenshots, cryptocurrency-wallet data and files stored on PCs or shared folders. Stolen identity documents may also be useful for impersonation.
Now consider a typical developer workstation.
You might have browser sessions for GitHub, cloud dashboards and email. You might have SSH keys, API credentials, project files, .env files, saved passwords or access to private repositories. A compromise therefore does not necessarily stop at the personal computer.
Authorities warn that stolen credentials may be used to obtain data, trade secrets and cryptocurrency from victims' employers, clients or contracting parties. They also identify espionage, intellectual-property theft, lateral movement and extortion as possible follow-on damage.
That is the more serious part of the campaign.
The developer can be the initial target, while the developer's employer or client becomes the secondary target.
WaterPlum Has Already Reached a Large Scale
The September 18 advisory says WaterPlum exploited at least 30,000 PCs in more than 100 countries between roughly December 2025 and July 2026. The primary targets included web designers, engineers and specialists working with cryptocurrency, blockchain and Web3 technologies.
The same advisory says funds or account credentials were taken from more than 7,000 cryptocurrency wallets, with at least 1.7 billion JPY ($10.71 million) in cryptocurrency transferred to North Korea.
Those figures need to be read carefully.
The 30,000 figure is the number of PCs the Japanese National Police Agency reported as exploited in the stated period; it is not a count of 30,000 individual developers. Likewise, the wallet figure does not mean every one of those wallets necessarily lost funds. The advisory describes funds or account credentials being transferred from more than 7,000 wallets.
The distinction matters because security statistics can sound more precise than they really are when converted into headlines.
The “Laptop Farm” Connection
The advisory also describes a related North Korean IT-worker ecosystem involving so-called laptop farms.
In this arrangement, employment-related computers can be physically located at an intermediary's site while being remotely controlled by North Korean IT workers. The workers can use those machines to obtain and perform contracts through crowdsourcing platforms or for companies.
Authorities say they found links between WaterPlum actors and North Korean IT workers through shared IP addresses associated with laptop farms, cloud-sourcing services and applications to a Japanese cryptocurrency exchange.
This does not mean every unusual recruiter, remote developer or freelance applicant is connected to WaterPlum.
What it does show is that the broader threat environment can involve both fraudulent employment activity and direct cyber theft.
For businesses, that means identity verification, access control and endpoint security cannot be treated as separate problems.
What the Story Says About Developer Security
One of the most useful lessons here is that a trusted development environment can become a dangerous one very quickly.
Visual Studio Code, for example, includes Workspace Trust and Restricted Mode specifically because unfamiliar projects can contain code or configuration that should not be trusted automatically. Microsoft says Restricted Mode limits or disables features such as tasks, debugging, workspace settings, extensions and terminal access that could allow code to execute.
That is directly relevant to the WaterPlum advisory, which tells users to avoid opening unknown VS Code projects or to open them in Restricted Mode. The advisory also recommends examining .vscode/tasks.json for commands that attempt to download or execute additional files.
A useful way to think about this is simple:
Opening code is not the same as trusting code.
You may need to inspect a repository before you decide whether it deserves to run on your machine.
Common mistake: trusting a repository because it is hosted on a reputable platform
Why it happens: GitHub, Bitbucket and other developer platforms are normally associated with legitimate software, so the platform itself can create a false sense of trust.
Better approach: Trust the source, repository and code separately. Inspect the project before execution, especially when it came from an unexpected recruiter or a person you met only online.
Elastic's July research demonstrated why this matters: its researchers found trojanized repositories that looked like functional software projects and were designed specifically around coding-test scenarios.
The platform can be legitimate while the project is malicious.
What Developers Should Do Before Running a Job Assignment
The answer is not to reject every coding test.
Instead, let's change where we run untrusted code.
The joint advisory recommends avoiding execution of unknown third-party code on systems containing cryptocurrency assets or sensitive personal data. It recommends using a sandbox or virtual machine for unknown code and checking for obfuscated or unreadable sections before execution.
Microsoft's current VS Code documentation also recommends keeping unfamiliar workspaces in Restricted Mode until you have reviewed them.
For a developer, a sensible workflow is:
- Verify the recruiter and company separately from the code.
- Download the assignment without immediately trusting the project.
- Inspect configuration files, scripts and dependencies.
- Use an isolated environment for unfamiliar code.
- Do not put production credentials, valuable crypto wallets or sensitive client data inside the test environment.
- Only grant additional trust after you understand what the project is doing.
One small distinction is especially important: a virtual machine or sandbox reduces the blast radius; it does not magically make malicious code safe. Isolation still has to be configured correctly.
What If You Already Ran a Suspicious Coding Project?
This is where speed matters.
Problem: You already executed the interview project, package or script and now suspect it was malicious.
Why it happens: Some malware is designed to remain quiet and perform normal-looking tasks before stealing credentials or contacting its command-and-control infrastructure.
What to check: Think about what was available to the machine while the code was running: browser sessions, credentials, private keys, cryptocurrency wallets, files and development accounts.
What to do: The joint advisory says to disconnect the affected device from the internet if infection is suspected. It also says that even after malware is removed, users should assume sensitive information may already have been exfiltrated. For cryptocurrency, the advisory recommends creating a new wallet on a separate device, moving assets to it and storing the new seed phrase offline. It also recommends backing up essential data and performing a full operating-system reset because undetected malware may remain.
The important point is that removing the visible malware is not necessarily the same thing as reversing the compromise.
If a password, session token, private key or seed phrase was exposed, the relevant credential or asset may need to be replaced rather than merely “scanned clean.”
What Employers Should Change
Companies hiring developers face a parallel problem.
A technical assessment should not require a candidate to access production systems, use valuable credentials or work directly inside a sensitive corporate environment simply to prove that they can solve a coding problem.
Least-privilege access becomes especially important here.
The joint advisory recommends limiting access to source code, credentials and other information to the minimum necessary and using endpoint detection and response tools to monitor for malicious activity.
That principle also makes the hiring process safer.
A company can provide a deliberately isolated evaluation environment rather than asking candidates to connect unfamiliar code to systems containing real customer or production data.
There is another lesson for recruiters: the authenticity of the candidate and the safety of the code they submit are separate questions. Even a legitimate applicant can accidentally submit a compromised dependency or project. Security checks therefore need to cover the software workflow as well as the identity workflow.
AI Is Also Part of the Recruitment Deception
The advisory says WaterPlum members have conducted online interviews using AI face-swapping software. Authorities observed cases in which the actors later disabled their video and attributed the change to network problems.
That does not mean every video problem during an interview is suspicious.
It does mean that a video call should not be treated as definitive proof of identity.
The broader lesson is becoming increasingly relevant across online work: faces, voices, resumes and professional profiles can all be manipulated. Developers and employers therefore need multiple signals of trust rather than relying on one convincing video call.
For employers, that could mean verifying employment history, independently checking contact details and testing claimed technical knowledge in a controlled environment. The joint advisory also recommends probing claimed skills in detail and verifying certifications when appropriate.
What Is New About the September 2026 Disclosure?
The WaterPlum campaign was not born on September 18.
Independent security research had already documented related Contagious Interview activity. Elastic, for example, published research on July 18 describing a campaign in which a fake job offer was used to deliver a trojanized coding project containing an information stealer and remote-access capabilities.
The new development is the multinational government disclosure and the scale of the activity described in it.
The September advisory brings together attribution, victim targeting, malware families, cryptocurrency theft, follow-on risks and defensive guidance from multiple agencies. It also connects the WaterPlum campaign with related North Korean IT-worker activity and laptop-farm infrastructure.
That makes the latest announcement more consequential than a routine new malware report.
At the same time, not every technical detail of every WaterPlum operation is public. The agencies explicitly warn that the techniques listed in the advisory are examples and that the actors continue to refine their methods.
So the right takeaway is not that there is one fixed WaterPlum playbook.
The better takeaway is that the recruitment-and-coding-test technique is already established and can evolve.
The Bigger Problem Is Trust, Not Just Malware
WaterPlum's most interesting security feature is not a particular malware family.
It is the context in which the malware arrives.
Developers are expected to install packages. They are expected to clone repositories. They are expected to troubleshoot broken builds. They may even be expected to run scripts supplied by a potential employer.
That makes a fake coding assignment unusually powerful as a social-engineering tool.
A phishing message often asks you to do something suspicious.
A malicious interview assignment can ask you to do something completely normal — but with untrusted code.
That distinction changes how the problem should be approached.
The first question should not be, “Does this recruiter look real?”
It should be, “Does this code deserve access to my machine?”
And then a second question follows:
“Even if the code is legitimate, does it need access to everything else on this computer?”
Those two questions capture the security lesson WaterPlum is exposing.
What Developers Should Watch Next
WaterPlum is likely to remain a moving target because the campaign is built around social engineering rather than one static file.
Security researchers may identify new malware families. Recruiters may move to different platforms. Coding assignments may use different frameworks. And attackers can change the technical details of the payload while keeping the same basic psychological trick.
That means defenders should pay attention to the behavioral pattern, not just the WaterPlum label.
An unexpected recruiter message followed by pressure to execute unfamiliar code should get more scrutiny.
A supposedly urgent technical assignment that requires disabling a security feature deserves more scrutiny.
A project that behaves differently from what the assignment requires deserves more scrutiny.
And a development machine containing high-value credentials should never be treated as a safe place to experiment with unknown software simply because the request arrived through a professional-looking interview.
The most durable lesson from WaterPlum is therefore broader than one North Korean campaign: professional trust and software trust are not the same thing.
A recruiter can be convincing. A company can look legitimate. A coding task can appear completely normal. None of those facts make the code safe.
For developers, that extra layer of skepticism may be the difference between completing a job interview and accidentally giving an attacker access to the machine that powers their career.
0 Comments
Have a question, feedback, or something to add? Share your thoughts below.