Sonatype Security Research is tracking a Lazarus Group npm campaign using dozens of malicious packages to abuse developer trust and deliver follow-on payloads.
The campaign goes beyond typosquatting, relying on brandjacking tactics like suffix addition, embedding, and version mimicry to make packages look ecosystem-adjacent.
Analysis of buffer-utilities shows a malicious dropper that fetches and executes remote payloads, setting the stage for ongoing attacker-controlled intrusions.
Organizations that installed affected packages should remove them, investigate for second-stage activity, and treat impacted systems as potentially compromised.
Sonatype is tracking a Lazarus Group campaign on npm, consisting of dozens of packages, some with up to 500 weekly downloads, aiming to abuse trust in open source to deploy malware. Leveraging tactics like suffix-addition, embedding, version mimicry, and more, brandjacking packages like this are designed to look like something that would belong in a developer environment.
These aren't mere typosquats. In this campaign, attackers seek to dupe developers looking for Buffer, Chai, React, and more, to deploy secondary, more nefarious payloads. We took a closer look at the malicious buffer-utilities package to understand attacker intentions.
Affected systems should be treated as potentially compromised if the package was downloaded. Removing the package is strongly recommended, but removal alone may not be sufficient if the second-stage payload has already executed. Organizations that installed this package should investigate the host for follow-on malicious behavior and remediate as appropriate.
Typosquatting remains a real threat, but it is no longer enough to think only in terms of misspelled package names. In fact, Sonatype recently found that only 9% of brandjacking packages rely on misspellings alone.
Brandjacking is the use of package names and contents that appear connected to legitimate projects or ecosystems to disguise malicious packages on open source. Typosquatting is one type, but attackers use a variety of naming-variant strategies.
This campaign relies on a variety of brandjacking techniques, such as suffix-addition, version mimicry, and embedding, in addition to typosquatting. That distinction matters. A malicious package does not need to look identical to a trusted package. It may only need to look like it belongs nearby.
For developers, that means dependency review cannot stop at "does this name look misspelled?" For security teams, it means controls need to evaluate package context, publisher behavior, naming structure, and campaign-level patterns — not just obvious typos or known-bad indicators.
| Naming Variant | Examples | Why It Looks Right |
| Suffix Addition | buffer-util-extend, buffer-utilities, express-denv, jwt-path, webpack-patch, chai-as-patch, chai-beta, react-next-dom |
Adds a believable capability or utility term to a trusted package or ecosystem name. |
| Typosquat | midcore, midcorp | Uses visually similar names that could be mistaken for legitimate packages or organizations. |
| Version Mimicry | node-background-invoker-v2 (versions 1.0.1 - 1.0.6) | Uses version-related naming (-v2) to create the appearance of an official successor or maintained package release. |
We examined buffer-utilities, a package in this campaign that adds a suffix to the legitimate buffer package in order to blend in. The malicious version contains legitimate code from the original package, but also functions as a dropper to fetch additional payloads.
Its secondary payload is a Node.js backdoor and downloader. It collects basic host information, including hostname, username, operating system, home directory, and process arguments, then beacons to command-and-control infrastructure to retrieve configuration data. After receiving instructions, it reports telemetry back to the operator, creates a hidden .vscode directory in the user's home folder, downloads additional files, and launches attacker-controlled code as a detached background process.
Those additional files include a third-stage JavaScript payload, f.js, and a package.json file. The malware then runs npm install --silent to fetch any required dependencies before launching f.js in the background, allowing the attacker-controlled code to continue running after the original process exits.
The payload also includes an update mechanism, allowing it to periodically reconnect to the command-and-control server, check for newer payload versions, and replace local files when updates are available. In effect, the payload functions as a persistent staging framework for delivering and maintaining attacker-controlled Node.js code on the infected system.
Code in the malicious buffer-utilities package includes material from the legitimate npm buffer package. But the two constants defined near the bottom of this image contain Base64-encoded URLs that link to payloads stored on www.jsonkeeper.com. We know that this is a service Lazarus Group has regularly used to store payloads.
As seen in the image above, the malicious package decodes the Base64-encoded URL with atob(tokenStringRe), fetches the remote content, stores it as codeString, and then executes it using eval(codeString).
That pattern is notable because it matches behavior Sonatype Research has observed across other packages in this Lazarus Group campaign: Base64-encoded www.jsonkeeper.com URLs, remote payload retrieval, and immediate execution through eval().
The package is impersonating buffer, one of the most widely used JavaScript infrastructure libraries, that allows developers to work with binary data, typed arrays, and streams.
That makes buffer-utilities look like a plausible companion package: a small helper or utility related to a widely used dependency. And that is the broader software supply chain pattern on display here. Attackers have moved beyond simple typos and are increasingly publishing packages that look plausible in the normal flow of development.
Open source malware increasingly depends on trust. Developers install packages because names look useful, familiar, or adjacent to work they are already doing. In ecosystems like npm, where small utilities, wrappers, plugins, and helpers are common, attackers can take advantage of that familiarity.
This incident is especially concerning because the activity connects to the Lazarus Group, underscoring that nation-state APTs see open source ecosystems as a path into developer machines through packages that may appear routine at first glance.
buffer-utilities fits that larger concern. The name is plausible. It sounds like a routine utility package. That is exactly the problem: modern package impersonation often does not look obviously suspicious at first glance.
Organizations that may have installed buffer-utilities version 1.0.0 or another package associated with sonatype-2026-003558 should take the following steps:
Remove the package from affected projects and dependency manifests.
Treat any host that installed the package as potentially compromised.
Investigate for evidence of second-stage or third-stage payload execution.
Review network activity, process execution, filesystem changes, and credential exposure on affected systems.
Look for the indicators of compromise listed above, including www.jsonkeeper.com payload URLs, command-and-control traffic to 45.59.163.198:1244, and unexpected .vscode files in user home directories.
Rotate credentials that may have been exposed from developer machines, CI/CD environments, or build systems.
Reconfirm dependency names before attempting to install any legitimate alternative package.
Add review friction for new, unfamiliar, or first-seen dependencies entering development and build environments.
Use malicious package protection that evaluates package behavior, provenance, naming patterns, and campaign-level signals, not only typosquatting indicators.
This is the next step beyond old-school typosquatting. Attackers are not just hoping a developer mistypes a package name. They are publishing packages that look like they belong in the surrounding ecosystem.
Viewed in isolation, a package like buffer-utilities may look like a plausible utility. Viewed alongside related packages, payload patterns, and shared infrastructure, it becomes part of a larger campaign designed to abuse developer trust.
Attackers are using copied legitimate code, plausible package names, and ecosystem-adjacent naming to blend into the normal flow of software development. Defending against that threat requires looking beyond misspellings and evaluating whether a package is trustworthy before it becomes part of the software supply chain.