A new wave of malicious npm packages has appeared on the npm registry, bringing a cross-platform campaign that targets Windows, macOS, and Linux. Security researchers say the nearly 800 packages deliver both a remote access capability and an infostealer payload, using a delivery flow that differs from many classic npm supply-chain tricks.
Instead of relying on common npm lifecycle hooks to trigger execution, the packages instruct developers to load them in a way that leverages Node.js module importing. Once running, the malware stages down to an OS- and architecture-specific payload fetched from remote infrastructure.
Why these malicious npm packages stand out
Researchers describe the campaign as one that uses automated techniques to create convincing package names. The names are reported to look like “AI slop” or randomized variants of existing popular or typo-squatted names. However, the key detail is consistent: the packages all lead to the execution of the same malicious logic.
Many npm-focused supply-chain attacks trigger payloads via lifecycle scripts such as preinstall or postinstall. In this case, the packages include instructions in their README telling developers to pull them in using require()—a built-in function for importing modules and local files.
That shift matters. It suggests the success of the campaign may depend on how developers interact with the package and whether they follow the README guidance.
From require() to the WEL1DROPPER downloader
According to analysis, loading the package via require() leads to execution of a downloader known as WEL1DROPPER. From there, the malware identifies the host operating system and CPU architecture.
Next, it attempts to fetch a compatible second-stage payload from one of three Cloudflare Workers endpoints. The reported domains are:
- oob-worker.cf103-070.workers[.]dev
- oob-worker.cf102-baf.workers[.]dev
- oob-worker.cf99-9b3.workers[.]dev
If the HTTPS downloads do not succeed, the malware changes tactics. It falls back to platform-specific delivery using DNS TXT records. The next-stage is obtained from a base domain referenced as wel1[.]ru.
TXT record chunking and Base64 decoding
The DNS-based workflow is described as a multi-step process. The malware first requests a TXT record from a domain formatted as c.<domain>. It then interprets the response as the number of payload chunks, accepting values in the range of 1 to 2,000.
After determining the chunk count, it requests additional numbered TXT records. The returned strings are concatenated and then Base64-decoded to reconstruct a binary buffer that becomes the next-stage payload.
OS-specific payload delivery
The campaign uses different payload domains depending on the victim’s system and architecture. The reported mapping looks like this:
- Linux x64: sdk.dl.wel1[.]ru
- Linux ARM64: ext.dl.wel1[.]ru
- macOS: pkg.dl.wel1[.]ru
- Windows: net.dl.wel1[.]ru
This design allows the same overall downloader logic to produce a correct payload for each platform, increasing the campaign’s chance of working across diverse environments.
Final execution steps differ by platform
After the malware reconstructs the payload, it writes it to a temporary location and then executes it using platform-appropriate commands.
On Linux and macOS, execution is described as using /bin/sh. On Windows, it uses cmd.exe.
Windows: stealth, monitoring interference, and persistence
For Windows, the final stage is reported to run as a detached process. Researchers also noted that the Windows version attempts to interfere with host monitoring by taking steps related to Event Tracing for Windows (ETW) and Antimalware Scan Interface (AMSI). The chain includes checks aimed at detecting sandboxes or virtualized environments.
To keep access after reboot, it establishes persistence via a Registry Run key and a scheduled task. It also downloads an encrypted payload noted as /pkg/update_win.exe and executes it.
macOS: similar logic plus LaunchAgent persistence
The macOS infection chain is described as broadly similar to the Windows flow. It includes logic intended to look for debugging and analysis artifacts before pulling a compatible payload (reported as /pkg/beacon_mac.bin).
If that direct retrieval fails, it uses the same DNS TXT delivery approach mentioned earlier. It then sets up persistence using a LaunchAgent and starts the executable as a detached process.
Linux: UPX-packed ELF and Sliver deployment
The Linux sample is reported as an UPX-packed ELF binary. It is configured to download auxiliary payloads from a Cloudflare Worker URL (including the endpoint oob-worker[.]cf99-9b3.workers[.]dev), ultimately leading to deployment of Sliver.
Sliver is described as an open-source command-and-control (C2) framework, which would allow the attacker to manage infected systems.
Extra noise: a fake telemetry file
Beyond the loader and downloader behavior, researchers found a file called lib/telemetry.js within some of the packages. This file implements what appears to be a plausible telemetry software development kit.
The catch is that it also contains the same downloader logic. Researchers suggest the oversized and realistic telemetry implementation could be intended to add “noise” and make the malicious behavior look like legitimate analytics on a quick review. The entry point of the package reportedly does not import this file, which can further delay detection.
Possible financial targeting and evolution from earlier campaigns
Analysis of the macOS payload references domains that appear tied to Russian financial services and mobile payments, including strings like tcsbank[.]ru and cloudpayments[.]ru. That observation leads to speculation that the campaign may be aiming at financial institutions or related payment infrastructure.
Researchers also suspect this campaign may represent an evolution of an earlier dependency confusion effort codenamed Moika, which was reported earlier in April. That earlier activity involved publishing over 250 packages to npm to steal environment information and deliver operating system-specific second-stage payloads.
Related activity: npm and PyPI campaigns beyond this wave
The news also points to broader supply-chain activity documented by other threat researchers. Palo Alto Networks Unit 42 described multiple campaigns targeting both npm and the Python Package Index (PyPI).
One example involved npm packages that download an obfuscated cryptocurrency stealer and remote access trojan from an external server. Another set of malicious packages spanning npm and PyPI was described as capable of cloud credential exfiltration, delivering blockchain-related C2 droppers, stealing Solana wallet keys via Telegram, exfiltrating secrets from .env files, and using fake CAPTCHA-style social engineering to enable remote code execution.
Chrome extensions used as web crawling proxies
Separately, researchers observed threat actors using Google Chrome extensions marketed as tools such as game emulators, password managers, productivity utilities, CSS inspectors, and markdown converters. In practice, some extensions turned the browser into a web crawling proxy.
The crawl commands are described as received remotely through a persistent WebSocket connection. These extensions embed a commercial web bandwidth-sharing SDK that connects the user’s browser to a third-party residential proxy network for scraping.
Some extensions include disclosure about these behaviors in their Chrome Web Store descriptions or privacy policies. Still, once installed, the SDK may prompt users to opt in, and researchers noted that some extensions frame the opt-in as necessary for uninterrupted service. One example mentioned is InstaSkip.
What developers and teams should do now
If you maintain projects that install dependencies from npm, the safest approach is to audit dependencies and verify package legitimacy. Pay attention to packages that try to persuade you to load them through README instructions, especially when the behavior is unusual for the claimed purpose.
Teams should also treat supply-chain events like any other security incident: review logs around installs and dependency changes, restrict what runs during builds, and validate that your CI/CD pipeline pulls from trusted sources only.
Conclusion
This campaign highlights how quickly malicious npm packages can be created to blend in, then deliver a structured cross-platform infection chain. By moving away from lifecycle-hook execution and toward require()-based loading paired with DNS TXT and staged payload retrieval, the attackers increased their chances of reaching victims across Windows, macOS, and Linux.
As npm dependency risk grows, active dependency hygiene, careful review of new packages, and strong build controls remain essential to reduce the likelihood of compromise.
Source: https://thehackernews.com/2026/08/nearly-800-malicious-npm-packages.html
