What happened (and how it worked)

Researchers found a cluster of dodgy npm packages pretending to be part of Alibaba’s developer tooling. These impostors were designed to slide malicious bits into developer environments via a carefully staged dependency chain. The end result: a nasty RAT that runs on Windows, Linux, and macOS.

The attackers used lookalike package names (mimicking private @ali-scoped modules) as bait. At first some of these packages looked harmless, but recent updates added a loader that reaches out to fetch JavaScript payloads and executes them. The loader was split across multiple packages so the malicious behavior only appears when the whole dependency tree is installed — cleverly hiding in plain sight.

A middle-layer component acted like a bridge, chaining the top-level decoys to lower-level modules that actually contain the loader. One of those lower pieces pulls a rule configuration from a repository and uses Node’s sandboxing features to decide what to do next. Based on that rule engine it then pulls platform-specific binaries or scripts from an Alibaba-like storage endpoint to blend in with normal traffic.

  • Windows: the payload can kill certain enterprise apps, replace code with a trojanized version, and persist inside common tools.
  • Linux: a binary is dropped to /tmp, launched in the background, and then removed from disk after loading into memory.
  • macOS: the attack injects a background script into the user shell startup file and registers a Launch Agent to keep itself running.

The final-stage backdoor is feature-packed: remote command execution, file upload/download, host reconnaissance, staging additional payloads, lateral movement, and persistence by tampering with widely used collaboration apps. The campaign appears targeted at Chinese-speaking developer communities — source code comments and timestamp patterns point that way — and its motive seems aligned with industrial espionage rather than random vandalism.

Packages tied to the campaign include (but may not be limited to):

  • 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
  • uniapi-bridge

What to do (don’t panic, but don’t nap either)

If you or your team installed any of the above packages, assume the worst and act quickly:

  • From a clean machine, rotate all sensitive credentials and secrets that might have been used on the compromised host (API keys, cloud keys, SSH keys, tokens).
  • Audit developer workstations and build servers for signs of persistence, unexpected processes, or altered application files.
  • Revoke and reissue any CI/CD secrets that could have been exposed. Inspect self-hosted runners and any publishing automation for abuse.
  • Limit access to private npm scopes, enable two-factor authentication for maintainers, and review publish permissions.
  • Scan dependency trees for suspicious lookalike packages and prefer scoped/private mirrors or verified publishers where possible.
  • Monitor network egress for unusual destinations and check endpoint telemetry for processes that behave like backdoors.

Bonus reality check: this isn’t an isolated trend. There have been other recent supply-chain incidents where legitimate-seeming package releases were swapped for trojanized versions that steal credentials and maintain persistence. The takeaway is simple: supply-chain attacks are getting craftier, so developer hygiene and aggressive auditing are the new normal.