Malicious npm Packages Deploy RedShell (RedC2): Check If You're Exposed

Short answer: A newly disclosed campaign (TrendAI, late August 2026) hides the RedShell Linux implant inside decoy npm packages named around "streak," "map," and "calc" — including streak-metrics-math, streak-map-cache, streak-map-kit, map-streak-kit, streak-cache-map, streak-calc-metrics, and kit-map-vim. They ship real date/streak functions to look legit, then run malicious code on import that steals SSH keys, browser credentials, and database files. If your project or CI installed any of these, grep your lockfiles now, rotate credentials, and check for the indicators of compromise (IOCs) below.

What happened: RedShell npm packages deliver a RedC2 Linux implant

In late August 2026, researchers at TrendAI disclosed a software supply-chain campaign that publishes trojanized npm packages to deliver RedShell — a Linux implant associated with the RedC2 4.0 command-and-control framework. The trick is disguise: each package includes working streak-calculation and date-math utilities, so a quick glance at the code (or an AI coding agent auto-installing a dependency) sees legitimate functionality. The malicious payload runs quietly in the background when the module is imported.

Why this is nastier than a typical install-hook attack: the payload executes on import from the package's entry file (dist/index.mjs), not from a postinstall lifecycle hook. That means npm install --ignore-scripts does not stop it, and a single import anywhere in your dependency graph — even a deep transitive one — is enough to trigger it. It then daemonizes via a double-fork so it keeps running after the importing Node process exits.

This is a malicious-package campaign — attacker-published packages designed to be installed — not a hijack of a trusted, popular library like the keyv worm earlier this month. The download counts are low, but the danger is targeting: typosquat- and confusion-style names that get pulled in by mistake, by a careless copy-paste, or by an autonomous agent resolving a plausible-sounding package.

Which npm packages are affected?

TrendAI identified 14 trojanized packages (all version 1.0.0, except streak-metrics-math, which also shipped 1.0.1):

• streak-metrics-math@1.0.0, streak-metrics-math@1.0.1
• kit-map-vim@1.0.0
• streak-map-cache@1.0.0
• streak-map-kit@1.0.0
• map-streak-kit@1.0.0
• streak-cache-map@1.0.0
• streak-calc-metrics@1.0.0
• streak-calc-math@1.0.0
• streak-math-abz@1.0.0
• streak-metricsaz@1.0.0
• streak-math-metrics@1.0.0
• streak-metricazbd@1.0.0
• streak-metricsazb@1.0.0
• streak-kit-map@1.0.0

Because the campaign spins up name variants, treat any unfamiliar package matching those "streak" / "map" / "calc" / "metrics" patterns as suspect until you've verified it.

What the RedShell implant does

Once it executes, the RedShell payload:

• Steals secrets — SSH private keys, browser-stored credentials, and local database files.
• Establishes persistence — via cron jobs, shell startup files (.bashrc/.profile), and service configurations, so it survives reboots.
• Pivots through your network — SOCKS5 proxying and TCP port forwarding to reach internal hosts from the compromised machine.
• Uses AI-assisted tasking — a "Red Agent" component that generates reconnaissance and credential-harvesting commands on the fly.
• Beacons to C2 — separate HTTP paths for data exfiltration and second-stage payload downloads.

How do you check if you're exposed?

Run these checks on every developer machine, build agent, and CI runner that installs npm dependencies:

1. Look for the bundled payload files. The packages ship the implant as a binary under dist/ or dist/internal/, loaded by dist/index.mjs. Flag these names inside any suspect package: math-core.bin, math-calc.bin, calc-math.dat, calc-cache.bin, calc.bin, calc-mapping.bin.
2. Watch for Node writing executables — flag any node process that modifies bundled .bin files and sets them executable during install.
3. Inspect persistence — review crontabs (crontab -l, /etc/cron.*), shell startup files, and newly added systemd services.

Check outbound connections to the known C2 endpoints:

217.60.77.63:8792
217.60.77.63:8060
217.60.77.63:8888

Search firewall/proxy logs and run ss -tanp | grep 217.60.77.63 on Linux hosts.

Hunt the RedShell binary across endpoints by SHA-256 hash:

4537B1189CE419F1A595CF47216C03F80E9170CE80DAD8D9227A1E52F9CB3466

Grep your lockfiles and caches for the affected names. From a repo root:

grep -rniE "streak-|kit-map-vim|map-streak-kit" \
  package-lock.json yarn.lock pnpm-lock.yaml package.json

Also check the global cache: npm ls --all 2>/dev/null | grep -iE "streak|kit-map-vim" and inspect ~/.npm/_cacache.

Remediation: what to do if you find it

1. Isolate the affected host from the network immediately — don't let it keep beaconing or pivoting.
2. Preserve evidence (memory, logs, the offending package) before you wipe, if you may need to investigate.
3. Rotate every credential that touched the machine: SSH keys, npm/GitHub tokens, cloud keys, database passwords, and anything cached by a browser.
4. Remove persistence — clear malicious cron entries, shell-startup lines, and services.
5. Review CI/CD logs and build artifacts for signs the payload ran in your pipeline or poisoned a build.
6. Rebuild compromised systems from a known-good image rather than trusting a cleanup.
7. Tighten controls — pin versions, require dependency review/approval, and put a gate in front of the registry (see below).

How a registry firewall helps against malicious npm packages

The core problem with this campaign is that npm install will happily fetch and execute any package your resolver names — on your laptop, in CI, or triggered by an AI coding agent. A registry firewall sits between your install command and the public npm registry and refuses to serve versions that are flagged as malicious, so the bad tarball never reaches your machine in the first place.

InstallSafe is a drop-in registry firewall for npm. You point your resolver at it once:

npm config set registry https://r.installsafe.io

From then on, every install — human or agent, local or CI — goes through the same install-boundary check, and flagged versions are blocked with byte-for-byte tarball integrity on everything it does pass through. It draws on OSV.dev advisory data, so honesty check: it blocks known-flagged versions, not zero-hour unknowns. Behavioral scanners like Socket and Snyk can catch some malicious packages before a CVE exists; InstallSafe's edge is the form factor — one enforcement point covering developers, CI, and autonomous agents alike. The two approaches complement each other.

Not sure whether anything already slipped in? Run the free InstallSafe scan against your project to check your dependency tree against current advisories.

FAQ

Are these RedShell packages still on npm?

Malicious packages are typically removed after disclosure, but removal doesn't undo installs that already happened. If any affected version reached your machine or CI, assume the payload ran and follow the remediation steps.

I only installed it once and removed it. Am I safe?

Not necessarily. RedShell establishes persistence (cron, shell startup, services) and steals credentials on first run. Uninstalling the package does not remove persistence or un-leak secrets — check the IOCs and rotate credentials.

Does this only affect Linux?

The disclosed implant, RedShell, is a Linux payload tied to RedC2. Linux developer machines, containers, and CI runners are the primary risk. Treat any Linux host that ran an affected install as potentially compromised.

How did a package with almost no downloads reach my project?

Confusion- and typosquat-style names get pulled in by copy-paste errors, mistaken dependency names, or AI coding agents resolving a plausible-sounding package. Low download counts don't mean low risk — they mean targeted.

How do I stop this class of attack going forward?

Pin exact versions, require review for new dependencies, and put a registry firewall in front of installs so flagged versions are blocked before they execute. That single install-boundary check covers humans, CI, and agents at once.

Advisory framing: this post is a defensive explainer based on the TrendAI disclosure in late August 2026. Verify affected package names against the original advisory and your own environment before acting.