Npm alert: 800 malicious packages that are activated with required and deliver a dropper with multi-platform RAT

A large operation of malicious packages has flooded the npm record: about 800 modules - published under names that seem to be generated randomly or type-squatting - contain a charger that leads to a remote trojan (RAT) and a multiplatform infostealer. Researchers have confirmed that the infection chain is not based on installation hooks (pre-install / post-install) but on instructions for the developer to invoke () from its code, which activates a download called WEL1DROPPER.

How the campaign works technically: the malicious package introduces code that, once imported with required (), runs a dropper that detects CPU operating system and architecture. The dropper tries to download the next stage from three Cloudflare Workers (domains observed by researchers). If the HTTPS download fails, the sample uses an alternative mechanism based on DNS TXT records pointing to an infrastructure domain (wel1 [.] ru). In that flow, the dropper first requests a TXT record that indicates how many load fragments there are, requests those numbered fragments, concates the received chains and decodifies them from Base64 to rebuild the binary, which is then written in a temporary folder and runs with / bin / sh in Linux / macOS or cmd.exe in Windows.

In the final stage, according to Sonatype and other analyses, malware unfolds its own behaviors of persistent threats: the sample of Windows patches ETW and AMSI to evade detection, check analysis environments / sandbox, set persistence (Run key and programmed task), download an encrypted payload and run it; macOS follows a similar chain with LaunchAgent; Linux download a compressed ELF with UPX that ends up deploying Sliver, an open source C2 framework. The same publications also point out that many packages include a "lib / telemetry.js" file - an apparent telemetrical SDK - containing the same download but not imported by the entry, suggesting intention to camouflage the malicious purpose during a superficial review.

Confirmed facts: the existence of hundreds of malicious npm packages with the pattern described, the Cloudflare Workers domains involved, the use of wel1 [.] ru for delivery by DNS TXT, the Base64 fragment reconstruction technique and the detection of Sliver in the Linux chain. Public sources that cover the operation and explain similar techniques include public response and analysis research ( BleepingComputer coverage) and documentation of the platform used as infrastructure (Cloudflare Workers: official documentation).

Estimates and uncertainties: some indicators found within macOS binaries refer to domains with Russian financial service names, so analysts believe that the actor could be interested in objectives of the Russian financial sector; this is an inference based on internal artifacts, not a statement by the attacker or proof of specific objectives. It has also been commented that the campaign could be an evolution of another operation called "Moika" observed earlier, but the relationship between campaigns is a reasonable hypothesis based on tactics and objectives, not a proven certainty.

Who does this affect? Developers and projects that import npm packages without strict vets, CI / CD environments that run pipeline unit code, and operations equipment that do not filter out to external infrastructure are exposed. In addition, any workstation or server where a developer requires a compromised package (locally or in automated building) can end up running the dropper and receiving the malicious load. Organizations with public or private repositories that allow unchecked third party packages are high risk.

Real consequences: the campaign allows for the exfiltration of credentials and environment (according to previous analysis of similar campaigns), remote execution and persistence of the attacker on Windows, macOS and Linux machines, and the possible incorporation of equipment into a botnet or a C2 infrastructure (Sliver) that facilitates side movements and data theft. For development teams, this also involves the risk of compromising secrets and credentials used on CI / CD, deployments and repositories.

Specific and urgent measures to be taken by readers and technical equipment:

1) Do not require () unknown packages or suspicious names. If a new package should be evaluated, review it locally in an isolated environment or sandbox and not import it directly into production pipelines.

2) Implement allowlist / denylist policies in repository and package managers. Use controls in the npm organization, an internal registration proxy (e.g. Nexus, Artifactory) or name-blocking to prevent external packages from being downloaded directly into build environments.

3) Protect CI / CD pipelines and avoid execution of unit code without revision. Do not run scripts or third-party processes in stages that have access to secrets; enable the separation of credentials and environment variables, and apply the principle of minor privilege.

4) Apply unit scan and static / dynamic analysis. Integrate tools such as Snyk, Dependabot, or SCA (Software Composition Analysis) solutions to detect malicious or unusual packages; complement with EDR / antivirus capable of detecting traps such as ETW / AMSI manipulation and opussed binary / UPX.

5) Restrict output traffic and block suspicious domains / infrastructure. Filter egress with proxy / firewall to avoid downloads from Cloudflare Workers / unauthorized external domains and block communications to wel1 [.] ru to investigate. Record and review outgoing connections from compilation systems and development stations.

(6) Review the persistence and artifacts in endpoints. In Windows look for Run keys, recent scheduled tasks and unusual child processes; in macOS list LaunchAgens / Daemons; in Linux review temporary binaries, chrontabs and processes that speak with external infrastructures. Use forensic tools to detect active Sliver or C2.

7) Rotate exposed credentials and secrets. If a project or pipeline used compromised packages, immediately rotate keys, tokens and certificates that could have been accessible and audit access logs for unusual activity.

Finally, it is key to adopt a sustained practice of minimization of units, manual review of critical packages, and segregation between development and production environments. Campaigns like this exploit implicit confidence in open ecosystems: mitigating them requires technical controls and process changes in unit management. For those who need a broader technical vision of malicious packages in public records, research of response teams and technical blogs continue to update IOCs and operational recommendations ( Unit 42 of Palo Alto Networks and other specialized sources).