A malicious npm package hidden three dependencies deep: the ulid-xyz delivery chain

Summary

SafeDep malicious package analysis flagged ulid-xyz on npm in June 2026. It typosquats ulidx, a library that generates sortable unique identifiers, and it is a cross-platform remote access trojan.

The postinstall hook reads as a guard that checks a build file exists. It actually launches dist/node/utils.js as a detached background process, which starts dist/node/payload.js, a 467 KB bundled trojan. That bundle decodes an obfuscated configuration and beacons to a hardcoded command server over WebSocket. It then installs persistence on Windows, macOS and Linux under the name MicrosoftSystem64. The package grew from 64 KB to 536 KB when the payload arrived.

We reported it as MAL-2026-6672.

We traced the delivery path. It runs through three npm packages:

28 attacker-created GitHub repositories
  └─ ioredis-xyz        the dependency a developer adds
      └─ redis-type-xyz  npm resolves this one
          └─ ulid-xyz     npm resolves this one, and it carries the payload

None of these repositories is a compromised legitimate project. Each is an application the operator wrote or copied and published, then used to advertise ioredis-xyz. A developer who installs ioredis-xyz gets the other two packages without naming them, and no single package in the chain looks malicious on its own.

The three packages

Layer 1: ioredis-xyz

ioredis is a Redis client for Node.js. ioredis-xyz is the same package. Each archive holds the same 89 files, and every file except package.json is identical, so it works exactly like the real client. Only the name changes. The rest of the metadata still points at the real project, so the npm page looks genuine.

Version 5.11.2 adds one dependency, redis-type-xyz@^1.10.5. Nothing in the package imports it. npm installs it anyway, which is its only purpose.

Layer 2: redis-type-xyz

This package presents itself as Redis OM, the object mapping library for Redis. Its archive holds 33 files and none of them run. It contains no .js, .ts, .mjs or .cjs file. package.json declares "main": "dist/index.js", and no dist directory exists, so importing the package fails.

It is a manifest and nothing else. Version 1.10.5 declared no dependency. Version 1.10.6 added ulid-xyz@^2.12.2. Its advisory is MAL-2026-11205.

The README file still tells you to install redis-type-os. npm had removed that package 18 hours earlier, under advisory MAL-2026-5882. The operator rebuilt under a new name and reused the documentation.

Layer 3: ulid-xyz

This one imitates ulidx, which generates sortable unique identifiers. The real ulidx ships no runtime dependencies. This version declares ten, including a WebSocket client and a package named postinstall.

The trigger is the postinstall script in the 2.12.x releases:

1
"postinstall": "node -e \"...check dist/node/utils.js exists...\" && node dist/node/utils.js"

The check in the first half is a screen. The command after it runs the payload. That same check text also appears in ioredis-xyz, which ties together two packages published by two different npm accounts.

The publisher accounts tie the lower two layers together as well. ulid-xyz came from [email protected] and redis-type-xyz from [email protected], two disposable addresses on the same domain root.

The payload was added after publication

A review of ioredis-xyz on the day it shipped would have found nothing. The payload arrived 19 minutes later.

At 07:37 the chain was harmless. [email protected] was the only version in the 1.x line, and it declared no payload dependency. The range ^1.10.5 matches any 1.x version at or above 1.10.5, so once 1.10.6 existed, every resolution pulled in ulid-xyz.

The operator never republished ioredis-xyz. The visible package did not change. They completed the chain from one layer below it, where nobody was looking.

The operator planted the chain in 28 repositories

These are not compromised upstream projects. They are purpose-built repositories.

The payload

The launcher exits when the machine reports fewer than four processors, which evades analysis machines and continuous integration runners. It then starts the agent as a detached process that survives the installing shell.

The agent is 467 KB. It opens a WebSocket to the command server and runs tasks:

1
exports.CAPABILITIES = ['ping', 'get_system_info', 'list_drives', 'list_dir', 'deploy_binary', 'remove_agent'];

This bundle does not steal credentials itself. It holds no wallet, browser or keychain strings. It is the first stage of a full remote access trojan: it fingerprints the host, lets an operator read the file system, and then takes whatever the operator sends. deploy_binary accepts a base64 field, writes it to disk, installs persistence and restarts into that code, so the operator chooses the capability set per machine after reading the reconnaissance.

The agent persists as MicrosoftSystem64 on all three operating systems, through a scheduled task on Windows, a LaunchAgent on macOS and a systemd user unit on Linux. Base64 and a repeating XOR key hide its two command servers, 65.21.30.171 and 95.216.232.162, both at Hetzner in Germany. MAL-2026-6672 records only the second address.

The implant matches a DPRK-linked cluster

MicrosoftSystem64 is a name we have analysed before. In May 2026 we published a binary analysis of MicrosoftSystem64, an 81 MB Node.js single executable delivered through the js-logger-pack and terminal-logger-utils packages. That implant steals browser credentials, more than 80 cryptocurrency wallet extensions, Telegram sessions and SSH keys, and exfiltrates to HuggingFace. kmsec.uk and OX Security attribute the cluster to FAMOUS CHOLLIMA, also tracked as Contagious Interview, a DPRK-linked group.

Four things tie this chain to that cluster:

• The same implant name, MicrosoftSystem64, and the same persistence design across Windows, macOS and Linux.
• The same command server port, 8010. The earlier binary used 195.201.194.107:8010.
• The same hosting provider, Hetzner, for all three addresses.
• whisdev, the persona JFrog traced through copilot-ai.whisdev.org on that earlier command server, owns two of the 28 repositories listed above.

That last point is a direct overlap rather than a shared technique. The likely second stage delivered through deploy_binary is the credential stealer documented in that earlier post.

Limit of this analysis: no second stage appears in any published archive of these three packages, so we cannot say what reached any specific machine.

Timeline

That last commit preceded the removal by 7 hours and 55 minutes.

Indicators of compromise