18 Malicious npm Packages Deliver Cross-Platform RAT to Alibaba Developer Tools

#npm #security #malware

Eighteen malicious npm packages published in a coordinated supply-chain attack delivered a cross-platform remote access trojan targeting developers in Alibaba's ecosystem. The campaign, staged in late April 2026, used dependency-tree splitting across fake @ali-scoped packages to reach internal Aone R&D tooling, then persisted through DingTalk, Wukong, and Qoder AI editors.

A coordinated campaign of 18 malicious npm packages delivered a cross-platform RAT to developers using Alibaba Group's internal tooling. The attack impersonated private @ali-scoped packages, split its loader across multiple dependencies, and used a live GitHub configuration file to maintain flexibility after publishing. Security researchers at Socket.dev first analyzed the campaign and published findings on July 28, 2026. The Hacker News reported the story on August 4, 2026.

The packages target Chinese-speaking developers and companies within the Alibaba ecosystem specifically. The attacker used @ali scope impersonation and references to Aone, Alibaba's internal R&D platform, to make the packages appear legitimate to target users. Socket.dev assessed the campaign goal as industrial espionage.

Key Takeaways

18 malicious npm packages formed a dependency-tree supply-chain attack
Final payload is a cross-platform RAT with command execution, file transfer, and lateral movement
Attack specifically targets Alibaba ecosystem developers using @ali-scoped packages and Aone tooling
Malicious rules were fetched live from GitHub, allowing post-publish updates
Persistence injected Python snippets into .skills directories of DingTalk, Wukong, and Qoder
Maintainer account ch4ce published multiple packages; npm profile now redirects to "not found"
Campaign staged April 27-28, 2026; initial package lib-mtop published as early as November 2023

How the Attack Was Structured

The campaign split its malicious logic across 18 packages to avoid detection. Top-layer packages impersonated private @ali-scoped package names using unscoped copies. Package names like lib-mtop, aone-kit, and feedback-ai-sdk mimicked tools Alibaba developers would recognize and trust installing.

smart-config-manager acted as a middle-layer bridge connecting top-lure packages to lower-layer payload packages. cloud-config-fetcher auto-fetched attacker-controlled rule configuration from a public GitHub repository (smi1e2u/smart-config-manager, path: defaults/preferences.json). This live-fetch design meant the attacker could update attack rules after the packages were already published to npm.

local-config-parser evaluated the fetched rules using Node.js vm module sandboxing. The malicious rule exploited a sandbox escape: items.constructor.constructor to reach the global process object and access Node.js loader systems. This bypassed the vm module's intended isolation.

The full package list includes: lib-mtop, aone-kit, aone-kit-cli, aone-sandbox, local-config-parser, smart-config-manager, cloud-config-fetcher, fast-transform-pipeline, aone-cloud-cli, colder-cli, def-open-client, feedback-ai-sdk, flight-compare-analyzer, lwp-web-client, lzd-unified-station-sdk, open-worker-cli, test-skill-zip, and uniapi-bridge.

The Delivery Chain and Persistence Mechanisms

The second-stage loader fetched setting.js from an attacker-controlled Alibaba Cloud OSS endpoint: aone-cli-next.oss-cn-beijing.aliyuncs.com. From there, the RAT performed platform-specific persistence:

On Windows, the malware killed Alilang security tools, VPN clients, and office applications. It then replaced app.asar files with trojanized copies, ensuring the RAT loaded whenever those applications started.

On Linux, the malware dropped a binary into /tmp, ran it in a detached process, then deleted the file from disk. This left no persistent file behind while maintaining execution.

On macOS, the RAT injected a background script into ~/.zshrc and installed a Launch Agent configured to run every 10 minutes. This ensured persistence across reboots and shell sessions.

The final RAT payload provided command execution, file upload and download, system reconnaissance, encrypted reverse TCP proxy connections, payload staging, and lateral movement capabilities. C2 traffic used fake Origin and Referer headers pointing to https://alidocs.dingtalk.com to blend in with legitimate Alibaba office traffic.

For lateral spread, the malware injected Python snippets into .skills directories of DingTalk, Wukong, and Qoder. These are AI-powered development tools used within Alibaba. By poisoning their skills directories, the attacker gained additional execution pathways and persistence mechanisms.

Timeline and Attribution

The earliest trace of the campaign dates to November 2023, when lib-mtop was first published with no apparent functionality. This suggests the attacker was laying groundwork well before the main attack.

Malicious versions of lib-mtop (v1.0.1, v1.0.2, v1.0.3) were uploaded in March and April 2026. Socket.dev states the full campaign was staged on April 27-28, 2026, when all 18 packages were published.

The maintainer account ch4ce published lib-mtop, aone-kit, aone-kit-cli, aone-sandbox, and local-config-parser. The ch4ce npm profile currently redirects to "not found" on npmjs.com, suggesting the account may have been deleted or suspended.

A GitHub account smi1e2u hosts the malicious rule and configuration repositories used in the attack. The exact identity of the threat actor remains unknown. Attribution is inferential, based on language patterns and timezone indicators pointing to Chinese-speaking operators. It remains unresolved whether ch4ce was a compromised account or a rogue actor.

Why This Matters for Supply-Chain Security

Supply-chain attacks are spreading beyond code dependencies; for example, see how AI-generated code can create hidden cross-team risk in development workflows. This campaign demonstrates several concerning trends in supply-chain attacks. Splitting malware across many packages makes individual static analysis less effective. Each package may appear benign in isolation, but the combined dependency tree delivers the full payload.

Using live GitHub configuration files for rules allows post-publish modifications. Even after packages are published and downloaded, the attacker can change behavior by updating the remote configuration. This creates a moving target for security tools that only analyze package contents at publish time.

Targeting internal enterprise tooling through scope impersonation is increasingly sophisticated. The @ali prefix mimics Alibaba's private package namespace. Developers familiar with internal tooling may install these packages without scrutiny, especially if they appear in dependency trees of legitimate projects.

The persistence mechanism through .skills directories of AI coding tools is novel. Earlier research on enterprise developer tooling integrations shows how these workflows are being embedded into corporate environments. DingTalk, Wukong, and Qoder are widely used within Alibaba. Compromising their skills directories gives the attacker execution in contexts where developers expect legitimate tool behavior.

FAQ

Q: How can developers identify if they are affected?

A: Check your project dependencies for the 18 packages listed in this article. Run npm ls to inspect installed package versions. Look for packages published by the ch4ce account. Scan for suspicious entries in ~/.zshrc (macOS), /tmp binaries (Linux), or replaced app.asar files (Windows).

Q: What is the vm module sandbox escape used in this attack?

A: The malware exploited items.constructor.constructor to escape Node.js vm module sandboxing. By accessing the constructor property of array items, it reached Function constructor, which has access to the global process object. This is a known vm sandbox limitation that researchers have warned about for years.

Q: Why were the packages not detected by npm or security scanners?

A: The packages were split across 18 dependencies, each appearing relatively benign. The malicious logic required the full dependency tree to activate. Live configuration fetching from GitHub meant static analysis of package contents alone could not detect the full attack chain.

Q: What steps should Alibaba developers take now?

A: Remove the 18 malicious packages immediately. Audit your .skills directories in DingTalk, Wukong, and Qoder for injected Python snippets. Check for unexpected entries in ~/.zshrc and Launch Agents on macOS. Monitor /tmp for suspicious binaries on Linux. Review Windows app.asar files for modifications. Consider rotating any credentials that may have been exposed.

Q: Is this attack related to any known threat groups?

A: Attribution remains unconfirmed. The campaign targets Chinese-speaking developers and uses Alibaba-specific tooling, suggesting familiarity with the ecosystem. However, it is unresolved whether this is a state-sponsored operation, a criminal group, or an insider threat. The ch4ce account status (deleted or compromised) adds to the uncertainty.

Conclusion

The 18-package npm supply-chain attack represents a sophisticated operation targeting Alibaba ecosystem developers. The campaign combined dependency-tree splitting, live remote configuration, scope impersonation, and novel persistence through AI coding tools. Its focus on industrial espionage against a specific enterprise ecosystem demonstrates the growing precision of supply-chain attacks.

Security teams should treat dependency trees as attack surfaces. Package-level analysis is insufficient when malware is distributed across multiple dependencies. Live configuration fetching complicates detection further. The persistence mechanisms through popular AI tools like DingTalk and Wukong show how attackers target the developer workflow itself, not just the code being written.