Inside DPRK’s npm malware factory: 108 packages, 261 versions, and a 31-day campaign wave

TL;DR — Over approximately 30 days, Panther Threat Research monitored, clustered, and tracked a DPRK-linked npm malware campaign spanning 108 malicious packages and a total of 261 package versions. The broader campaign graph below contains 261 observed package-version nodes across multiple operational clusters. The common thread was simple: lure developers into running malicious packages, execute code on trusted developer or CI systems, then steal credentials, wallet private key, sessions, and establish persistent access. If your teams leverage the npm ecosystem, include packages in CI/CD tooling, or have crypto-adjacent developer workflows, treat this as active exploitation of developer environments leading to credential theft, footholds, and follow-on access.

Cluster graph for the campaign

This graph shows the campaign as connected operational clusters rather than isolated packages. The structure is the key to understanding both potential exposure and adversary targeting strategy.

Interactive view: use the slider to rewind the campaign day by day.

A month-long package factory, not a one-off backdoor

From 2026-03-20 to 2026-04-20, Panther Threat Research monitored and clustered the campaign’s high-tempo publishing wave. The sustained activity was consistent with an organized operation. The campaign averaged more than three new package names per day during that period, with repeated version cycling to rotate payload endpoints, swap dead-drops, and keep malicious updates moving even as individual packages were removed.

The business risk is straightforward: developers are lured into executing malicious packages on trusted machines, giving the threat actor code execution inside developer and CI environments before theft, remote access and persistence begin. Across the decoded samples, the actor targeted crypto wallets and key material, cloud provider credentials, SSH private keys, browser credentials and cookies, Telegram Desktop sessions, .npmrc credentials, local .env files, as well Solana key material related to Polymarket.

The dominant clusters in this wave centered on classic OtterCookie (Cluster A) and BeaverTail (Cluster B) delivery chains, alongside crypto-focused OtterCookie-like variants (Cluster F) and a Windows PyInstaller branch with PYDROP-like characteristics. Multiple clusters also wrote attacker-controlled SSH keys into authorized_keys, which turns credential theft into a longer-lived foothold. In other words, this campaign is not only about what can be stolen immediately, but about what access can be retained after initial compromise.

This wave also includes behavior that pushes beyond the “standard” npm stealer pattern. We observed one cluster using blockchain transaction data as a dead-drop channel for second-stage payload resolution, and we also observed a separate device-farm-themed package set with iOS WebDriverAgent signing/build logic and hub/node orchestration features.

For teams that have followed Panther’s earlier jsonspack reporting and OtterCookie reporting, the continuity is strong, but the campaign scale is much larger. Known malware families and known operator patterns are present, but the operation expanded into more delivery clusters and more specialized targeting logic during this window.

Why this campaign stands out

Most public supply chain incidents are described as isolated package events. This one behaved more like a distributed production system: multiple clusters, shared components, rotating infrastructure, and enough separation between branches to survive partial takedowns.

At campaign scale, the actor showed clear operational discipline. Two sensitive C2 IPs associated with high-value clusters had never been submitted to VirusTotal at snapshot time, while heavily obfuscated payloads still drew little to no detection. The practical takeaway is that defender response has to be campaign-aware: removing one package name or one domain may only prune a cluster while leaving the operational trunk intact.

What defenders should do first

• Hunt and block by campaign patterns, not single package names. Prioritize dead-drop and C2 infrastructure linked to repeated cluster activity. High-confidence examples include jsonkeeper[.]com paste IDs, api.npoint[.]io paste endpoints, 107.189.20[.]115, 216.126.237[.]71, 95.216.26[.]109:6211, and analyse sessions on port 1244; see Indicators of Compromise below for the fuller list used in this post.

• Treat exposed developer hosts as credential-compromised until proven otherwise. Rotate cloud credentials, registry tokens, and any local secrets stored in .env, .npmrc, or shell history; again see Indicators of Compromise for a full list. For wallet exposure, move balances, rotate signers where possible, and review or transfer contract ownership, admin roles, deployer authority, and other sensitive smart-contract permissions.

• Audit and review SSH. Inspect ~/.ssh/authorized_keys for unauthorized additions and rotate private keys if suspicious writes are found.

• Review dependency update windows from 2026-03-20 through 2026-04-20. Focus on CI runners and developer endpoints that installed suspicious utility, chai-*, Tailwind-themed, lint/build, or logging-adjacent packages during this period.

• Add runtime-aware detections. This campaign includes clusters that avoid obvious install hooks and trigger at require-time or first runtime function use, so static install-script checks alone are insufficient.

Even if you did not install one of the headline package names, similar delivery mechanics can appear under new names quickly. Response should center on behavior and infrastructure overlap, not packages alone.

Attribution

Our attribution confidence is high: this campaign is consistent with DPRK’s Famous Chollima / DeceptiveDevelopment activity.

That assessment is based on converging evidence, including BeaverTail-consistent behavior and keying patterns, OtterCookie-consistent delivery and C2 characteristics, and infrastructure/operator overlap with previously documented DeceptiveDevelopment-linked npm activity.

This assessment also builds on strong prior public research by other teams, especially KMSEC. Their public DPRK package mapping work materially overlaps with the cluster structure we observed here, which increases confidence that these packages fit the same broader DPRK developer-targeting ecosystem. Our contribution in this post is the campaign-wide 31-day view and the cluster-level synthesis across the retained package, payload, and infrastructure evidence.

If you want to dive deeper

The rest of this post dives deeper into the operational clusters. Instead of listing every package, we map how representative clusters operated, what they were optimized to steal, and what that says about the actor’s campaign design. We use 108 malicious package names for the reconciled campaign set and 261 observed package-version nodes for the broader rendered campaign graph shown here. For supporting evidence in the published piece, see Indicators of Compromise below, where the package, version, network, and host indicator sets are grouped by type.

The cluster map: a coordinated campaign ecosystem

This campaign includes 14 operational groupings in the full dataset. The deepest technical visibility sits in a nine-cluster execution graph; below, we focus on five representative clusters that best explain the campaign’s scale, delivery diversity, and detection challenges.

We used Louvain community analysis as a starting point, then checked the retained package, infrastructure, and payload evidence manually before assigning the public clusters.

The useful mental model is a malware factory with reusable parts. Operators appear to choose from a shared toolkit, loader templates, obfuscation primitives, dead-drop patterns, then assemble cluster-specific delivery chains aligned to different victim workflows.

Cluster A: the OtterCookie-centered loader ecosystem

Cluster A is the largest and most connected cluster in this campaign, and it includes multiple OtterCookie-linked variants rather than one uniform payload. Within the same cluster we recovered several require-time loader variants, the XB9WY / 2IG6W stage-2 stager branch, and the 0001.dat socket.io RAT branch.

Packages such as mongoose-lean-hooks, request-js-validator, vite-enhancer-config, and winston-prism fired at require() time with no postinstall hook, pulled stage content from jsonkeeper[.]com, and then evaluated the returned JavaScript with new Function(...). Across these variants, the actor reused markers such as x-secret-key: _ and bearrtoken: logo, which makes the packages look different at the npm layer while still tying them back to the same operator-controlled delivery system.

In the confirmed Cluster A chains, the npm package is the initial loader: on require(), it fetches stage-2 JavaScript from the C2 and evaluates it. That stage-2 code then quietly installs axios and socket.io-client, downloads 0001.dat from 216.126.237[.]71, and launches it with Node.js.

From there, decoded follow-on payloads converge on OtterCookie-linked infrastructure at 216.126.224[.]220:5976 using /api/service/process/ and /api/service/makelog, which is why this cluster is best understood as both a loader ecosystem and a deeper RAT-stage branch rather than one uniform script family. The later-stage behavior went well beyond wallet theft, targeting AI IDE material such as .cursor, .windsurf, .claude, and .pearai; smart-contract and developer key material such as .sol, .move, .avm, and .eigent; and data including clipboard contents, screenshots, OpenZeppelin code, and GPG keys.

Cluster B: BeaverTail delivery at scale

Cluster B is the campaign’s BeaverTail cluster, built around repeated port 1244 delivery patterns, dead-drop retrieval, fallback IP logic, and Vercel front-end hops. Some packages used compact XOR-decoded loaders that polled http://<IP>:1244/s/<token>, while others fetched from jsonkeeper[.]com or coingecko-liard[.]vercel[.]app before pivoting to the same BeaverTail infrastructure.

Across decoded samples, the shared XOR key [0x70, 0xa0, 0x89, 0x48], the mySrv() IP-assembly routine, and the repeated port-1244 pathing show this was not one-off reuse but an operational delivery cluster.

In practical terms, this cluster looks like a mature theft pipeline: staged payload pulls, local drop-and-execute behavior, and follow-on collection from browser and developer contexts. Decoded loaders dropped BeaverTail into paths such as .vscode/f.js, then handed execution to deeper stages. Some chains also performed victim triage before deeper payloading, including ipinfo[.]io lookups and Telegram beacons that notified the operator when a new victim executed the package.

Cluster F: SSH persistence and Solana/developer key theft

Cluster F used a custom, base91-obfuscated stealer family rather than a simple loader. In the best-decoded samples, the malware exposed two main behaviors: one function fetched /api/ssh-key, /api/scan-patterns, and /api/block-patterns from cloudflareinsights[.]vercel[.]app, then stole ~/.ssh material and any server-selected files; the other recursively searched the working directory for developer secrets such as id.json, config.toml, Config.toml, and .env, with a clear emphasis on Solana keypairs and project configuration.

The same decoded payloads also contained Windows drive-enumeration logic, which shows the operator was thinking beyond a single platform even though the SSH abuse path was Unix-focused.

The persistence angle is what makes Cluster F especially dangerous. Some packages attempted to append attacker-controlled public keys to authorized_keys, change ownership, and run commands such as sudo ufw enable and sudo ufw allow 22/tcp to keep SSH reachable after the initial compromise. The delivery model was layered as well: direct postinstall packages, trojanized big.js-style droppers that injected malicious require() calls into arithmetic code, and companion payload packages such as the plaintext levex-press and the J2TEAM-obfuscated gleb-js.

Those companion payloads exfiltrated to themed Vercel endpoints such as wallet-management-tg-bot[.]vercel[.]app and polymarkettrading[.]vercel[.]app, reinforcing that this cluster was built to steal developer secrets and convert them into durable follow-on access. This is also the broader tradecraft Panther Threat Research highlighted in our separate Polymarket-focused writeup, Polymarket Trader Funds at Risk: DPRK npm Package Steals Wallet Keys and Installs SSH Backdoor. On affected Linux hosts, a successful authorized_keys write means the attacker may retain SSH access even after the npm package is removed, so response has to include key and access review rather than package cleanup alone.

Cluster H: runtime-triggered debug library trojanization

Cluster H is small by package count but strategically important. Instead of relying on obvious install hooks, it trojanized the legitimate debug library by injecting an asynchronous backdoor into enable() inside src/common.js. In byteboxlab and byteutilsbox, that modified file was identical, and the malicious path stayed dormant until a real application called debug.enable(namespaces).

When it fired, the injected code contacted axioshealthcheck[.]vercel[.]app/debugCheck?id=<namespaces> — or logkit-tau[.]vercel[.]app in the sibling package — pulled a large base64 payload from the JSON message field, and executed it with new Function('require', decodedCode)(require). That timing matters. It can evade defenses focused on install hooks or one-time import checks, and it also leaks the victim’s debug namespace string as a side-channel that can tell the operator what kind of application just executed the package.

For defenders, this cluster widens the threat model for npm incidents. If your controls assume malicious code appears only during install or immediate require-time execution, this cluster is likely to pass through that gap.

Cluster I: Blockchain dead-drop C2

Cluster I introduced one of the campaign’s more interesting mechanics: using blockchain transaction data as a dead-drop for next-stage instructions. The trojanized Tailwind packages were not empty shells; they were real utility plugins with a malicious block appended after the legitimate export, often separated by long runs of spaces so the payload sat off-screen in casual review. Once executed, the payload polled attacker-controlled TRON and Aptos addresses through api.trongrid[.]io and fullnode.mainnet.aptoslabs[.]com.

The handoff works as a two-step chain lookup. First, the malware polls the latest outbound TRON and Aptos transactions. In the live transactions we checked, the relevant TRON field was raw_data.data: a hex-encoded ASCII string that reverses into a valid BSC transaction hash.

Querying BSC for that hash returns a real zero-value transaction to 0x000000000000000000000000000000000000dead carrying a large input blob. After stripping a leading ?.? delimiter and XORing with the embedded key 2[gWfGj;<:-93Z^C, that BSC input decodes to an async JavaScript loader rather than opaque filler. In the recovered loader, the actor populates initial blockchain state from an embedded bootstrap, selects direct follow-on C2 candidates at 166.88.54[.]158:443, 198.105.127[.]210:443, and 23.27.202[.]27 on 443 or 27017, rotates the next-cycle TRON pointer wallet, and assigns a next-stage BSC transaction hash before requesting and evaluating the next layer.

We statically recovered this outer BSC-resolved loader, but not the final stage-three payload it requests and evaluates. That makes this operationally useful and worth tracking, but not a claim of exceptional novelty by itself. OpenSourceMalware separately documented a Neutralinojs compromise that used the same broader TRON/Aptos/BSC staging pattern in a different intrusion context, which is a useful reminder that defenders should treat this as a reusable technique rather than a one-off curiosity. Even so, the design value to the operator is clear: the malware can move from package execution to blockchain lookups, then to direct C2 infrastructure, while rotating the next retrieval values inside the decoded loader itself.

The cluster still serves the same campaign objective — theft and follow-on access — but it does so through a transport and staging model that can sidestep conventional IOC-centric blocking. For threat detection programs, this is a signal to track emerging cross-domain tradecraft where software package delivery, financial-chain telemetry, and payload staging intersect.

Additional clusters and campaign breadth

Other clusters in this campaign add breadth rather than changing the core objective. Taken together, they are consistent with multiple delivery branches operating in parallel, including direct TypeScript credential stealers, Cloudflare Pages-linked droppers, IP-gated delivery logic, and the atddevs device-farm-themed branch, where we observed iOS signing/build logic, hub/node orchestration features, and LLM API key interception logic.

Not every package in these clusters had equal analytical depth at publication time. A small subset remains unresolved due to deleted artifacts or incomplete payload recovery, but those gaps do not materially change the campaign-level assessment.

What the cluster breakdown says about campaign operations

The cluster view suggests a coordinated campaign ecosystem rather than a single linear malware chain. The actor did not rely on one malware path, one host, or one package-naming pattern.

Instead, the evidence is consistent with parallel delivery branches built from a shared toolkit: overlapping loader patterns, recurring dead-drop practices, repeated infrastructure choices, and the same broad goals of credential theft, follow-on access, and in some cases persistence. Some differences between clusters may also reflect different victim workflows or execution contexts, not just simple redundancy. If your environment touched this campaign, the strongest defense posture is campaign-level: cluster-aware hunting, cross-cluster infrastructure blocking, and incident response that assumes layered theft with possible persistence attempts, including RAT loading and, in some branches, SSH persistence.

Indicators of Compromise

The IOC corpus below groups 697 indicators by type and cross-checks them against the campaign SQLite DB plus retained source artifacts. Package names, publisher emails, and observed package versions are included because they are operationally useful for scoping, retroactive dependency review, and publisher pivots. The package-version section reflects the broader rendered campaign graph, not a 1:1 expansion of the reconciled 108-package name set. Generic shared infrastructure such as public DNS, CDN edge IPs, public blockchain API roots, and similar non-unique execution dependencies has been excluded where it does not uniquely identify campaign activity.

Package names (108)

Publisher emails (64)

Observed package versions in the rendered campaign graph (261)

SHA-256 hashes (65)

SHA-256

SHA-1 hashes (25)

SHA-1

Domains and DNS hosts (30)

Domain / host

api-sub[.]jrodacooker[.]

api-sub[.]jrodacooker[.]

api-sub[.]jrodacooker[.]

api-sub[.]jrodacooker[.]

api[.]mywalletsss[.]

api[.]mywalletsss[.]

api[.]mywalletsss[.]

api[.]mywalletsss[.]

apiscriptv3[.]vercel[.]

apiscriptv3[.]vercel[.]

apiscriptv3[.]vercel[.]

apiscriptv3[.]vercel[.]

axioshealthcheck[.]vercel[.]

axioshealthcheck[.]vercel[.]

axioshealthcheck[.]vercel[.]

axioshealthcheck[.]vercel[.]

chalk-logger[.]vercel[.]

chalk-logger[.]vercel[.]

chalk-logger[.]vercel[.]

chalk-logger[.]vercel[.]

changelog[.]

changelog[.]

changelog[.]

changelog[.]

cloudflare-protection[.]vercel[.]

cloudflare-protection[.]vercel[.]

cloudflare-protection[.]vercel[.]

cloudflare-protection[.]vercel[.]

cloudflarefirewall[.]vercel[.]

cloudflarefirewall[.]vercel[.]

cloudflarefirewall[.]vercel[.]

cloudflarefirewall[.]vercel[.]

cloudflareguard[.]vercel[.]

cloudflareguard[.]vercel[.]

cloudflareguard[.]vercel[.]

cloudflareguard[.]vercel[.]

cloudflareinsights[.]vercel[.]

cloudflareinsights[.]vercel[.]

cloudflareinsights[.]vercel[.]

cloudflareinsights[.]vercel[.]

cloudflaresecurity[.]vercel[.]

cloudflaresecurity[.]vercel[.]

cloudflaresecurity[.]vercel[.]

cloudflaresecurity[.]vercel[.]

cloudflareshield[.]vercel[.]

cloudflareshield[.]vercel[.]

cloudflareshield[.]vercel[.]

cloudflareshield[.]vercel[.]

coingecko-liard[.]vercel[.]

coingecko-liard[.]vercel[.]

coingecko-liard[.]vercel[.]

coingecko-liard[.]vercel[.]

deoft[.]

deoft[.]

deoft[.]

deoft[.]

isillegalregion[.]

isillegalregion[.]

isillegalregion[.]

isillegalregion[.]

jsonspack[.]

jsonspack[.]

jsonspack[.]

jsonspack[.]

locate-my-ip[.]vercel[.]

locate-my-ip[.]vercel[.]

locate-my-ip[.]vercel[.]

locate-my-ip[.]vercel[.]

log[.]pricesheet[.]

log[.]pricesheet[.]

log[.]pricesheet[.]

log[.]pricesheet[.]

log[.]pricesheet[.]

log[.]pricesheet[.]

log[.]pricesheet[.]

log[.]pricesheet[.]

logger[.]clob[.]

logger[.]clob[.]

logger[.]clob[.]

logger[.]clob[.]

logkit-tau[.]vercel[.]

logkit-tau[.]vercel[.]

logkit-tau[.]vercel[.]

logkit-tau[.]vercel[.]

nexafilm[.]

nexafilm[.]

nexafilm[.]

nexafilm[.]

npmjs-doc-builder[.]vercel[.]

npmjs-doc-builder[.]vercel[.]

npmjs-doc-builder[.]vercel[.]

npmjs-doc-builder[.]vercel[.]

payloads-el[.]pages[.]

payloads-el[.]pages[.]

payloads-el[.]pages[.]