{"id":22900,"date":"2026-07-30T01:25:01","date_gmt":"2026-07-30T01:25:01","guid":{"rendered":"https:\/\/scannn.com\/distributed-npm-package-cluster-delivers-cross-platform-rat\/"},"modified":"2026-07-30T01:25:01","modified_gmt":"2026-07-30T01:25:01","slug":"distributed-npm-package-cluster-delivers-cross-platform-rat","status":"publish","type":"post","link":"https:\/\/scannn.com\/lv\/distributed-npm-package-cluster-delivers-cross-platform-rat\/","title":{"rendered":"Distributed npm Package Cluster Delivers Cross-Platform RAT ..."},"content":{"rendered":"\n
\n

Unknown threat actors distribute malicious downloader functionality separated across several npm packages targeting users of Alibaba tools. The final payload is a covert and highly targeted RAT capable of data exfiltration, command execution and lateral spreading using DingTalk tools<\/em><\/p><\/blockquote>\n

Analysis of a malicious npm package lib-mtop<\/code> containing a simple downloader malware led to an investigation into a targeted campaign that remained undetected for 3 months.<\/p>\n

The lib-mtop<\/code> package, originally published three years ago, had three new versions published at the end of March, 2026. This indicates a potential maintainer account takeover, but the possibility of a maintainer going rogue can\u2019t be excluded. Whichever the case, it is not that relevant for the story, since there was only one version of the lib-mtop<\/code> package initially published, with no functionality and an insignificant number of downloads. The only reason why this package is relevant for the research is the fact that it is an unscoped package name imitating a private package from the @ali<\/code> scope. This scope is not available for registration on npm, and is most likely reserved for security reasons or already registered by Alibaba Group. Code references to packages from this scope can be found across several GitHub repositories. The @ali<\/code> scope is used for hosting Alibaba’s private packages used in internal projects and tooling.<\/p>\n

The malware in the lib-mtop<\/code> package is a classic malicious loader fetching a hardcoded remote JavaScript payload using curl, and executing it via require()<\/code> from the disk. It doesn\u2019t use any novel or interesting techniques. The same maintainer account<\/a> published 4 other packages, aone-kit<\/code><\/a>,<\/strong> aone-kit-cli<\/code><\/a>,<\/strong> aone-sandbox<\/code><\/a> and ****local-config-parser<\/code><\/a> . The first three are empty wrappers that have the same name as private, @ali<\/code>-scoped packages which they declare as a dependency in the package.json file. The last package, local-config-parser<\/code> is the most interesting one.<\/p>\n

Described as \u201cJSON configuration file parser with built-in rule evaluation engine.<\/em>\u201d it truly implements that logic. It parses rules from a local json config file and evaluates them using Node.js vm<\/code> module for isolated expression evaluation. Nothing suspicious to observe, a regular package doing exactly what it describes, communicates only with the local system and even performs execution of untrusted code in an isolated environment. A typical analyst verdict would be non-malicious. But the context around the package led to a different classification. Examination of the dependency tree revealed the malicious nature of several, on their own, innocent-looking packages, published from different user account. Combined together they deliver an advanced remote access tool (RAT) in a campaign targeting developers most likely working in companies that are part of the Alibaba Group.<\/p>\n

Individual Non-Malicious Packages Combine Together to Provide Loader Functionality#<\/a><\/h2>\n

The malicious loader functionality is distributed into several packages delivered to the targets as part of the same dependency tree. The top-layer packages serve as lures that trigger the installation of the dependency tree. They implement the same tactic observed in the lib-mtop<\/code> package – an unscoped package name impersonating private packages from the @ali<\/code> scope and including them as a dependency. When such package is installed in an environment that has access to impersonated, scoped private packages, the dependency resolution works as expected, with a little extra functionality delivered through additional dependencies that get installed.<\/p>\n

\n

Loader malware gets delivered through several modules, implementing their part of the functionality. The top-layer packages serve as lures and implement no functionality. They include dependencies on packages from the targeted @ali scope and the middle-layer package which delivers the rest of the malicious packages containing the functional loader logic.<\/em><\/p>\n<\/figcaption><\/figure>\n

All 10 top-layer lure packages depend on the same middle-layer package smart-config-manager<\/code>. It defines two dependencies – cloud-config-fetcher<\/code> containing configuration fetching logic and local-config-parser<\/code> containing rule evaluation logic. Packages were published by different npm maintainer accounts in an attempt to hide the connection between them and make them look unrelated. But the time information about user account creation and package publishing surfaces the relation between them.<\/p>\n

The campaign appears to have been staged across April 27 and 28. The actors first published node-data-utils<\/code> and fast-transform-pipeline<\/code>, which appear to have served as tests of the multi-package delivery mechanism. The rest of the dependency chain followed on April 28 across several publisher accounts. Most were newly created for the campaign, while local-config-parser<\/code> was published by the older ch4ce<\/code> account, suggesting a possible account takeover.<\/p>\n