Cyberdudebivash

Malicious npm Packages Delivering AdaptixC2 Malware – Is Your Project Infected?

, , , ,
CYBERDUDEBIVASH

Malicious npm Packages Delivering AdaptixC2 Malware – Is Your Project Infected?

Updated: Oct 22, 2025 • Author: CyberDudeBivash • Category: Supply‑Chain & DevSecOps

Executive Summary 

  • What happened: Threat actors uploaded at least one malicious npm package (e.g., https-proxy-utils, now removed) that executed a post‑install script to fetch and run an AdaptixC2 agent on developer machines and CI runners.
  • Why it matters: AdaptixC2 is a powerful post‑exploitation/C2 framework. If the agent lands on a developer endpoint or CI, adversaries can exfiltrate tokens, SSH keys, cloud creds and pivot into your software supply chain.
  • Risk level: Critical for JavaScript/TypeScript teams using npm/Yarn/PNPM and CI pipelines that build unpinned or un‑vetted dependencies.
  • Immediate actions: Freeze releases, audit lockfiles, check for malicious post‑install behavior, rebuild from clean cache, rotate npm/GitHub/cloud tokens, and scan endpoints.

Table of Contents

  1. Background: Modern npm Supply‑Chain Threats
  2. What Is AdaptixC2?
  3. Incident Timeline & What We Know
  4. Affected Surfaces & Exposure Scenarios
  5. How the npm Infection Works (Post‑Install Path)
  6. Indicators of Compromise (IoCs)
  7. Am I Infected? Triage Worksheets
  8. Emergency Response (First 60 Minutes)
  9. Deep Forensic Steps (Day 1–3)
  10. Credentials & Secrets Rotation Runbook
  11. CI/CD Recovery & Build Integrity
  12. Detection Engineering (SOC Playbooks)
  13. Hardening npm/Yarn/PNPM (Defensive Configs)
  14. Long‑Term Architecture to Tame Supply‑Chain Risk
  15. Developer Training: Spotting Malicious Packages
  16. Communications & Legal (Templates)
  17. Appendix A: Command Cheatsheets
  18. Appendix B: Sample SIEM Queries
  19. Appendix C: YARA/Regex Snippets (Safe)
  20. FAQ
  21. Services, Affiliate Picks & Next Reads

1) Background: Modern npm Supply‑Chain Threats

Software supply‑chain attacks now routinely target package managers. npm’s scale and convenience (scripts, transitive deps, rapid updates) provide an ideal substrate for credential theft and C2 beacons at build time. Recent incidents (e.g., worm‑like campaigns and token‑harvesting packages) show a clear trend: compromise the developer to compromise the enterprise.

2) What Is AdaptixC2?

AdaptixC2 is an open‑source, modular post‑exploitation framework with agents, listeners and operator tooling. While legitimate for red‑team use, criminals abuse it for persistence, command execution, file exfiltration, and lateral movement. Its modularity makes it easy to embed or side‑load in trojanized packages.

3) Incident Timeline & What We Know

  • Discovery: October 2025 — security researchers found an npm package masquerading as proxy utilities which ran a post‑install fetch + execute sequence.
  • Evasion tricks observed: Obfuscated JS, fallback download URLs, DLL side‑loading on Windows (via a living‑off‑the‑land binary), and minimal/no README to avoid scrutiny.
  • Current status: The named package(s) were removed. However, forks/clones or similarly named packages may appear. Treat this as an ongoing ecosystem risk, not a one‑off event.

4) Affected Surfaces & Exposure Scenarios

  • Developer laptops/workstations: Install hooks run with developer privileges; tokens and SSH keys often present.
  • CI/CD runners: Secrets (cloud keys, signing certs, npm tokens) are exposed during builds; post‑install can run non‑interactive.
  • Self‑hosted build agents: Often persistent and less locked‑down than ephemeral runners.
  • Air‑gapped or proxy‑restricted builds: Attackers sometimes stage payloads on domains that bypass filtering (e.g., CDNs, code hosting mirrors).

5) How the npm Infection Works (Post‑Install Path)

  1. Typosquat/masquerade: Package name looks legitimate (e.g., a proxy/helper module).
  2. postinstall script: In package.json, attacker declares scripts.postinstall to execute on install.
  3. Payload retrieval: Script downloads an agent (e.g., DLL/EXE/JS) from attacker infrastructure.
  4. Execution & persistence: On Windows, may copy a signed OS binary (LOLBIN) to a writable path and DLL sideload; on nix/macOS, may drop a launch agent or cron entry.
  5. C2 handshake: Agent reaches out to a listener, awaits commands (enumerate, steal tokens, move laterally).

Key takeaway: CI and developer endpoints must treat postinstall as dangerous; use install‑scripts blocking in production pipelines.

6) Indicators of Compromise (IoCs)

Customize these with your telemetry. Keep an evidence log.

File/Process Hints

  • New files under build caches (e.g., ~/.npm/_npx, project node_modules/.bin, temp dirs) created around the install time.
  • Windows: unexpected binaries/DLLs in %ProgramData%, %AppData%, %TEMP%, %WINDIR%\Tasks along with renamed LOLBINs (msdtc.exe, etc.).
  • macOS/Linux: new launch agents in ~/Library/LaunchAgents, /Library/LaunchDaemons, systemd units in user scope.

Network Hints

  • Outbound to unfamiliar hosts shortly after npm install / pnpm i / yarn add.
  • TLS SNI/JA3 anomalies or uncommon ports from CI runners.

npm/Repo Hints

  • Package with minimal docs, recent creation, few downloads but privileged‑looking name.
  • package.json includes scripts.postinstall, obfuscated inline code, or external JS fetch.

7) Am I Infected? Triage Worksheets

Use this quick worksheet per project:

  • A. Dependency audit: export full tree (npm ls --all), mark new/changed packages since last clean build.
  • B. Scripts scan: grep lockfile and package.json for postinstall, preinstall, install hooks.
  • C. Timeline correlation: map suspicious installs to endpoint/EDR alerts and proxy/DNS logs.
  • D. Endpoint sweep: run AV/EDR + YARA (see Appendix C) on developer and CI hosts.
  • E. Token exposure: list tokens present on affected hosts (npm, GitHub, cloud, signing).

8) Emergency Response (First 60 Minutes)

  1. Freeze releases and block publishing from possibly exposed accounts.
  2. Quarantine suspect hosts (dev laptops, CI runners). Preserve volatile data before reboot.
  3. Rebuild artifacts from trusted base images with cache disabled.
  4. Rotate tokens immediately (npm, GitHub PATs, cloud credentials, CI secrets). Invalidate old tokens.
  5. Alert stakeholders (engineering, security, legal, customer support). Use the templates in §16.

9) Deep Forensic Steps (Day 1–3)

  • Pull full npm logs (install times), shell history, browser download histories for devs who installed the suspect package.
  • Parse build logs from CI to reconstruct the sequence (which job fetched what, network traces).
  • Memory capture (if feasible) on CI or dev endpoints that showed beaconing.
  • Hash and copy suspicious binaries/scripts; store under chain‑of‑custody.

10) Credentials & Secrets Rotation Runbook

  • Rotate npm tokens: organizational and user tokens; enforce automation tokens with least scope.
  • Rotate GitHub: PATs, deploy keys, Actions secrets; reset SSO sessions.
  • Rotate Cloud (AWS/GCP/Azure): issue short‑lived credentials; rotate access keys; re‑seal CI secrets from a vault.
  • Invalidate signing certs/keys exposed on CI; re‑sign critical artifacts.

11) CI/CD Recovery & Build Integrity

  • Switch CI to ephemeral runners; avoid reuse.
  • Enforce network egress allow‑lists for build jobs.
  • Disable lifecycle scripts (--ignore-scripts) for production builds; maintain a separate dev profile if needed.
  • Use Provenance/SLSA: attestations for builds, signed artifacts (Sigstore/cosign), SBOM generation per release.

12) Detection Engineering (SOC Playbooks)

High‑signal detections

  • Alert when npm/yarn/pnpm installs invoke child processes beyond node, npm, git.
  • Detect postinstall spawning network utilities (curl, powershell, bitsadmin).
  • Watch for LOLBIN sideload patterns on Windows (copy of signed EXE + adjacent unknown DLL).

Hunting seeds (pseudocode)

where process.parent.name in ("npm","node","yarn","pnpm")
  and process.name has_any ("curl","powershell","bitsadmin","wget")
  and timestamp within 10m of package install event

13) Hardening npm/Yarn/PNPM (Defensive Configs)

  • Pin dependencies with lockfiles; require PR review for lock changes.
  • Run installs with --ignore-scripts in CI; explicitly allow only vetted scripts.
  • Mirror dependencies to a private registry with malware scanning and allow‑list policy.
  • Enable 2FA for registry accounts; use scoped automation tokens.
  • Add pre‑commit hooks to block addition of packages that trigger lifecycle scripts unless approved.

14) Long‑Term Architecture to Tame Supply‑Chain Risk

  • SBOM + attestations published for every release.
  • Central artifact repository with quarantine stage and static/dynamic scanning.
  • Runtime egress controls on CI with DNSSEC/DoH and domain allow‑lists.
  • Continuous dependency health reporting (age, maintainer score, known risks).

15) Developer Training: Spotting Malicious Packages

  • Red flags: brand‑new packages with generic names, few downloads, typosquats of popular utilities.
  • Always inspect package.json scripts and install hooks.
  • Prefer well‑maintained, audited libraries; avoid “just published” utilities in production.

16) Communications & Legal (Templates)

Customer Notice (short)

We identified and mitigated a supply‑chain risk in our JavaScript build system related to a malicious dependency. No customer data has been confirmed impacted. We rotated credentials, rebuilt from clean images, and enabled additional detections. We will update this notice with new findings.

Regulator/Partner Notice

Outline timeline, affected components, mitigations, and assurance measures (SBOM, attestations).

17) Appendix A: Command Cheatsheets

  • List all packages & scripts quickly:
jq -r '.packages[].packageJSON.scripts // empty' package-lock.json
  • Install with scripts blocked in CI:
npm ci --ignore-scripts
pnpm i --ignore-scripts
yarn install --ignore-scripts
  • Find postinstall in repo:
git grep -n "postinstall"

18) Appendix B: Sample SIEM Queries

// Network beacon near install
where event.type == "process_start" and process.parent in ("npm","node")
| join kind=leftouter (
  where dns.query_time within 10m and device.id matches
) on device.id

19) Appendix C: YARA/Regex Snippets (Safe)

  • Simple regex to flag suspicious lifecycle hooks in diffs:
^(\+\s*"(postinstall|preinstall|install)"\s*:\s*")
  • YARA (sketch) for obfuscated curl+PowerShell combo in Node install contexts (customize for your org).

20) FAQ

Is AdaptixC2 itself illegal?
No. It’s a dual‑use framework. The risk arises when attackers deploy it covertly via supply‑chain routes.

Do I need to wipe all developer machines?
Not automatically. Prioritize those that executed the suspect package or show beaconing. Rebuild CI runners.

Will --ignore-scripts break builds?
Sometimes. Use it for production pipelines and create an allow‑list for vetted cases.

21) Services, Affiliate Picks & Next Reads

CyberDudeBivash — Services & CTAs

  • Supply‑Chain IR & Hardening: Rapid response for npm incidents, SBOM+SLSA rollout, CI egress control. Explore services
  • Consulting: Secure developer workflows, secret zero‑trust, registry policy design. Book a consult
  • Newsletter: Weekly intel for eng leaders and SOCs. Join now

Partner Picks (Monetized)

  • Edureka — DevSecOps & Supply‑Chain Security courses. Upskill the team
  • Kaspersky — Endpoint/EDR to catch post‑install payloads on dev machines. Protect endpoints
  • Alibaba Cloud — Hardened infra for private registries and CI. Build secure infra
  • Turbo VPN — Gate admin/registry access behind ZTNA/VPN. Isolate access
  • Rewardful — Monetize internal tools & training. Start now

Recommended by CyberDudeBivash 

Hashtags

#CyberDudeBivash #AdaptixC2 #npm #SupplyChain #DevSecOps #JavaScript #C2 #ThreatIntel #CI #SLSA #SBOM

This defense‑first guide omits exploit specifics and focuses on detection, containment and hardening.

Leave a comment

Design a site like this with WordPress.com
Get started