Security Brief: WaterPlum Targets Developers With Fake Jobs and Malicious NPM Packages

What happened

A joint advisory published on 18 September 2026 by Japanese, US, Australian and German authorities details activity attributed to the North Korean WaterPlum cyber actor group, commonly referred to as Contagious Interview. According to the advisory, the group has targeted software developers, web freelancers and other IT professionals by posing as legitimate employers or recruiters and presenting attractive job opportunities.

The campaign is particularly relevant to web development teams because the infection chain can begin with a normal-looking technical interview or coding assignment. Victims may be instructed to download and run files from code repositories or collaboration platforms. The advisory says attackers have used malicious Node Package Manager packages containing malware families including BeaverTail, InvisibleFerret, OtterCookie, OtterCandy and StoatWaffle.

Why the campaign matters to web teams

Developer workstations often sit close to source code, repositories, browser sessions, cloud consoles, deployment tools and application credentials. The advisory warns that successful compromise can give the actors opportunities to move beyond an individual developer and into organizations that employ or contract them.

Authorities report that WaterPlum compromised at least 30,000 devices across more than 100 countries between approximately December 2025 and July 2026. The advisory also states that funds or account credentials were taken from more than 7,000 cryptocurrency wallets, with at least 1.7 billion Japanese yen, approximately 10.71 million US dollars, transferred in cryptocurrency assets on behalf of the DPRK.

The broader risk is not limited to cryptocurrency. The advisory says targeted data can include browser-stored authentication information, clipboard contents, keystrokes, screenshots and files accessible from the victim device. Stolen credentials may also create opportunities to target employers, clients and contracting organizations.

How the fake recruitment chain works

A typical scenario starts with a developer receiving a job approach through social media, a job platform, freelance marketplace or another recruiting channel. The applicant is then asked to complete a coding task or troubleshoot an issue during a technical interview.

Fake recruiter or employer
        ↓
Technical interview or coding assignment
        ↓
Victim clones a repository or installs a package
        ↓
Malicious NPM package or project configuration executes
        ↓
Backdoor, RAT or infostealer gains access
        ↓
Credentials, files or other sensitive data are stolen
        ↓
Employer or client systems may become follow-on targets

The advisory specifically warns about unfamiliar Visual Studio Code projects. StoatWaffle has been observed using malicious VS Code project configuration capable of triggering code execution when a project folder is opened and trusted. Authorities recommend opening unfamiliar projects in Restricted Mode and checking .vscode/tasks.json before trusting the project.

Hypothetical scenario: a developer coding test becomes an entry point

Imagine a freelance JavaScript developer is contacted about a well-paid Web3 project. The recruiter asks the developer to clone a repository and fix a small bug before the next interview. The repository looks plausible, but one of the packages or project configuration files contains malicious code.

The developer runs the project on the same laptop used for Git hosting, email, cloud administration and client work. If an infostealer captures browser credentials, authentication data or files, the original fake recruitment exercise can become a wider organizational incident.

The attacker may gain opportunities to access repositories, client accounts or infrastructure that were never part of the original coding assignment. Even when malware never directly targets a production website, compromised developer access can create a route toward unauthorized code changes, credential abuse and follow-on attacks.

Practical defensive steps for developers and web teams

• Do not run unfamiliar coding assignments on your normal development workstation. Use a disposable virtual machine or sandbox for untrusted projects.
• Open unknown VS Code projects in Restricted Mode. Do not automatically trust the author of an unfamiliar repository.
• Inspect project configuration. Review .vscode/tasks.json and other scripts capable of downloading or executing additional files.
• Review dependencies before installation. Unexpected packages, obfuscated code, unusual install scripts and unexplained dependency additions deserve scrutiny.
• Separate development and production credentials. Compromise of one developer device should not automatically provide unrestricted production access.
• Apply least privilege. Developers and contractors should have only the repositories, systems and credentials required for their work.
• Use endpoint detection and response. The joint advisory explicitly recommends EDR for organizations to monitor malicious behavior and help prevent exploitation.
• Revoke access quickly after suspected compromise. Rotate relevant credentials, terminate sessions and review repository, cloud and deployment activity.

The related North Korean IT worker risk

The advisory also discusses North Korean IT workers using remote employment, contractors, laptop farms and third-party facilitators to obtain work and generate revenue. It describes cases involving source-code exposure, extortion and website disruption.

In one case cited in the advisory, an IT worker hired for website maintenance defaced the hiring company's website and rendered it inaccessible. In another, an IT worker allegedly extorted a company over payment and published proprietary source code online.

For organizations that outsource development, the security lesson is broader than any particular country or workforce. Contractor access should be designed so identity verification, source-code access, production credentials, least privilege and rapid account revocation do not depend on trust alone.

What to do after suspected developer compromise

If a developer has executed suspicious code, removing the repository is not enough. The advisory recommends disconnecting an impacted device from the internet when infection is detected or suspected. Organizations should assume that sensitive information may already have been exfiltrated and investigate accordingly.

A practical response should include isolating the affected endpoint, preserving useful evidence, resetting or rebuilding the system as appropriate, rotating credentials, revoking active sessions and reviewing access to source-code repositories, cloud platforms and deployment systems.

Teams should also inspect recent commits, deployment events, newly created credentials and configuration changes. A developer compromise can become a software supply chain problem if stolen access is later used to modify code or deployment infrastructure.

Where Vulnify fits

Vulnify does not claim to detect WaterPlum malware, malicious NPM packages on developer workstations, compromised laptops or North Korean IT workers. Those areas require endpoint security, repository review, dependency analysis, identity controls and incident response.

Vulnify can support the public-facing validation stage after a development or credential compromise is suspected. The Website Security Scanner can help assess exposed website weaknesses, while Website Watch can help identify new or worsening public-surface conditions over time.

The JavaScript Library Vulnerability Checker can inspect supported publicly exposed JavaScript library information. It should not be treated as an NPM malware scanner, endpoint security product or replacement for software composition analysis inside a development environment.

What organizations should do now

Development teams should treat unexpected coding assignments, unfamiliar repositories and recruiter-supplied packages as untrusted code. Unknown code should be reviewed and executed only in isolated environments. Access to production systems, repositories and sensitive credentials should be limited to what each developer or contractor genuinely needs.

If compromise is suspected, investigate the endpoint first, then follow the incident into connected systems. Review repository activity, cloud access, deployment history and credentials. Finally, validate the public website for unexpected exposure or configuration changes. New exposed paths, altered security headers, unexpected technologies, certificate problems or other public-facing differences can provide useful evidence during recovery.

Source and attribution

This Security Brief is based on the 18 September 2026 joint advisory published through the FBI Internet Crime Complaint Center by authorities from Japan, the United States, Australia and Germany. Attribution, activity scale, malware-family information and specific incident examples in this article reflect the findings and assessments presented by those agencies.