WeaselBiscuit Turns npm Imports Into a Chrome Extension Data-Theft Channel

Thirteen packages deliver a previously undocumented stealer

Cybersecurity researchers have recently identified 13 npm packages that deploy WeaselBiscuit, a previously undocumented JavaScript information stealer targeting Chrome extension data.

The affected packages are:

• @biz44/id10-client
• @biz44/id12-client
• @biz44/id44-client
• @biz44/id79-client
• @biz44/id95-client
• @biz44/id99-client
• @biz44/process-runtime-utils
• @biz44/runtime-utils
• engin1
• id79-client
• process-lhpm
• process-mite
• process-tailwind

The malicious code activates when a targeted package is imported. That behavior makes the campaign relevant not only to developers running unfamiliar tools locally, but also to organizations whose automated build systems install and execute npm dependencies.

The exact malicious package versions have not been disclosed. It is also not known whether every package has been removed from npm, how many times they were downloaded, or how many systems were compromised.

This is not a conventional software vulnerability. No CVE, CVSS score, vendor patch, or formal severity rating has been provided. Instead, the incident is a software supply-chain attack in which packages act as the initial delivery mechanism.

The loader retrieves its payload from Npoint

The infection chain begins with a file named loader.js. Once executed through a package import, the loader contacts an Npoint dead-drop location, retrieves the main WeaselBiscuit code and runs it directly in memory.

Npoint is an online service for storing and retrieving JSON data. In this campaign, it provides an intermediary layer between an infected system and the attacker-controlled configuration, allowing operators to change delivery details without republishing the npm packages.

After starting, WeaselBiscuit obtains its command-and-control configuration from a separate Npoint URL. It then profiles the host and performs nested public-IP and geolocation checks using api.ipify.org and ip-api.com.

The malware includes a numeric campaign or installation identifier. Researchers observed the values 10, 12, 44, 79, 95, and 99, several of which appear directly in package names such as @biz44/id44-client and id79-client. OpenSourceMalware compared this mechanism with the tagging approach used by PolinRider.

One identified command-and-control endpoint is:

103.170.217[.]184:8787

Running the main payload in memory may reduce the evidence available to security tools focused primarily on newly written executable files. The npm package, loader activity, network connections and JavaScript runtime behavior can still provide detection opportunities.

Chrome’s extension database is the primary target

WeaselBiscuit searches for Chrome extension information on Windows, macOS, and Linux. Its central collection routine walks through Chrome’s Local Extension Settings directory and uploads every file that is both readable and non-empty.

Those files form raw LevelDB key/value databases used by installed extensions. Depending on the extension, the stored content may include application state, account-related information, session material, configuration data or information associated with cryptocurrency wallets.

The stealer does not appear to parse only a predetermined list of wallet extensions. Its broad file-collection method instead captures available extension storage and leaves analysis of the stolen LevelDB content to the operators.

That creates a financial threat without requiring built-in wallet-draining code. If a wallet extension keeps sensitive state in the affected browser profile, attackers may obtain material that supports subsequent account theft, impersonation or other unauthorized activity.

Windows victims face two additional collection capabilities. Commands sent by the C2 server can enable:

• Clipboard capture
• Keystroke logging

Clipboard monitoring could expose passwords, tokens, private corporate data or cryptocurrency addresses copied by the user. Keylogging expands the risk to information typed during the infection, including credentials that were not already stored in Chrome.

The available findings do not specify whether these Windows-only functions were enabled on every compromised host.

Similar code does not establish a North Korean operation

WeaselBiscuit has technical characteristics resembling BeaverTail and OtterCookie, malware associated with the DPRK-linked Contagious Interview campaign. The overlap is meaningful, but it is not sufficient for a conclusive attribution.

BeaverTail is a cross-platform stealer and downloader used against software developers, IT workers and cryptocurrency users. It has been active since at least late 2022 and can support the delivery of additional malware such as InvisibleFerret.

OtterCookie combines information theft with remote-access functions, including the ability to execute commands on an infected system. NTT Security Holdings first publicly documented it in December 2024.

WeaselBiscuit is more constrained than either family. Its known code does not provide persistence, general remote access, dedicated cryptocurrency-wallet draining or a mechanism for deploying secondary payloads. It appears to preserve selected collection techniques while discarding the broader post-compromise feature set.

According to the research describing the npm campaign, investigators found no decisive links involving operator infrastructure, victim profiles, campaign metadata, code signing or other signing material.

Several details are nevertheless consistent with previously reported DPRK-associated activity. These include Npoint usage, the paired public-IP and geolocation queries, C2 design similarities to OtterCookie, and numeric identifiers resembling PolinRider tags.

Npoint had previously been connected to Contagious Interview activity by NVISO in November 2025. A hybrid design would also have precedent: in October 2025, Cisco Talos reported that the npm package node-nvm-ssh appeared to combine BeaverTail and OtterCookie elements.

The responsible operator remains unknown.

Developers and build systems carry the immediate exposure

The primary victims are people and organizations that imported one of the 13 packages. Developers are especially exposed because their workstations frequently contain source-code credentials, package registry tokens, cloud sessions and privileged access to internal systems.

Automated environments are also at risk. A dependency installed inside a CI/CD worker could execute during a build, profile the host and establish outbound communications, although the value of Chrome extension collection would depend on whether a browser profile existed in that environment.

Cryptocurrency users face a more direct financial concern because WeaselBiscuit specifically captures extension storage that may belong to browser wallets. However, the presence of wallet data does not by itself prove that funds were stolen.

No victim count, download total or geographic distribution is known. The observed identifiers suggest that operators distinguished between installations or campaign segments, but their precise meaning has not been established.

Containment requires dependency review and secret rotation

There is no vendor-issued patch or dedicated cleanup utility. Organizations should treat any confirmed import of the listed packages as a potential endpoint compromise rather than simply deleting the dependency and continuing to use the same environment.

Defenders should first search dependency manifests, lockfiles, npm caches, developer workstations and build logs for all 13 package names. Affected applications should be rebuilt using reviewed dependencies from trusted sources.

Endpoint and network investigations should look for:

• Execution of loader.js
• Suspicious in-memory JavaScript activity
• Unexpected access to Chrome’s Local Extension Settings
• Connections to unapproved Npoint endpoints
• Traffic involving 103.170.217[.]184:8787
• Unexplained queries to api.ipify.org and ip-api.com
• Suspicious clipboard access or keylogging behavior on Windows

Credentials, session material and other secrets accessible through an affected Chrome profile should be rotated. Wallet-extension information requires separate review because the appropriate response depends on what the extension stored and what data may have been exposed.

Longer-term controls should include npm allowlists, lockfile enforcement, package provenance checks, isolated build environments and review of newly introduced dependencies. Blocking one C2 address is not enough: the use of Npoint means delivery and configuration locations can be changed without altering the malicious packages’ basic design.