TL;DR

Eight days before the Bitwarden CLI attack went live, a quieter but methodologically identical campaign ran against the npm ecosystem. Between April 1–8, 2026, four npm packages — sbxapps, asurion-hub-web, soluto-home-web, and asurion-core — impersonated internal tooling belonging to Asurion, a Fortune 500 company that handles device protection and tech support for T-Mobile, AT&T, and Verizon. The packages deployed a multi-stage credential harvester that evaded automated scanning, self-propagated through stolen npm tokens, crossed into PyPI, and tunneled exfiltrated data through obfuscated AWS API Gateway endpoints.

The campaign was not caught in real-time. It was revealed retrospectively in Unit 42's April 24 threat landscape analysis as one of three simultaneous supply chain operations running in the same two-week window. Attribution remains ambiguous — the TTPs overlap with TeamPCP infrastructure but no definitive link has been publicly confirmed.

This post reconstructs the full kill chain, explains why scanners missed it, and draws out the lessons that the npm ecosystem still hasn't absorbed six months after Shai-Hulud proved all of this was possible.

---

Background: Asurion and the Value of the Impersonation Target

Asurion is not a household name in the security community, but it is deeply embedded in enterprise developer ecosystems. The company is the world's largest device insurance and tech support provider, processing tens of millions of support transactions per year across the three largest US carriers. Critically, Asurion operates Soluto — an enterprise IT platform — and a suite of internal developer tooling that its engineering teams publish to npm under organizational scopes and private-looking names.

Attackers chose Asurion for a reason: the company publishes legitimate packages with names like soluto-home-web, making impersonation packages nearly indistinguishable from real internal builds. A developer who sees asurion-hub-web in a colleague's pull request or a CI/CD dependency file has no inherent reason to question it. Unlike classic typosquatting (targeting lodash or express with one-character variants), this is organizational namespace impersonation — a much more surgical attack class that exploits the trust networks of specific companies.

This also fits into a larger pattern Unit 42 documented in April 2026: the post-Shai-Hulud npm threat landscape has matured beyond opportunistic typosquatting into targeted organizational impersonation campaigns with hand-curated target lists, multi-stage payloads, and cross-ecosystem propagation logic.

---

Technical Analysis: The Kill Chain in Five Stages

Stage 1 — Package Placement and Discovery

The four malicious packages were published to the public npm registry between April 1 and April 8, 2026:

| Package Name | Published | Weekly Downloads (legitimate analog) |

|---|---|---|

| sbxapps | April 1 | N/A (internal branding) |

| asurion-hub-web | April 2 | N/A |

| soluto-home-web | April 3 | N/A |

| asurion-core | April 8 | N/A |

None of these are direct typosquats of high-traffic packages. The attackers relied on dependency confusion and private package impersonation — two techniques that standard npm scanners historically struggled to distinguish from legitimate internal packages published to the public registry.

The packages used convincing README files, realistic version histories, and package.json metadata that mirrored the structure of legitimate enterprise npm packages. The soluto-home-web package even included partial UI component code — real-looking React components — to pass casual inspection.

Stage 2 — The postinstall Hook and Initial Dropper

Every malicious package contained a postinstall script in package.json. When a developer or CI/CD system ran npm install, the script fired automatically — before the developer's main build process, outside the main code flow, and typically without triggering any console output visible to the developer.

The initial dropper performed four tasks:

1. Environment fingerprinting: Collected OS type, Node.js version, username, hostname, environment variables, and the contents of ~/.npmrc (which contains npm authentication tokens).

2. CI/CD detection: Checked for the presence of common CI/CD environment variables (GITHUB_TOKEN, GITLAB_CI, CIRCLE_CI, JENKINS_URL, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, SLACK_TOKEN) and adjusted its exfiltration logic based on context.

3. Dormancy check: If the package was being installed in an environment that matched known automated scanning signatures (sandbox hostnames, specific Docker image labels), the payload silently exited — a behavioral dormancy check consistent with the "sleeper dependency" pattern Unit 42 flagged as an emerging post-Shai-Hulud TTP.

4. Primary exfiltration: Credentials and environment data were dispatched to a Slack webhook URL hardcoded in the dropper's obfuscated payload. This is a significant operational security choice — Slack traffic rarely triggers egress-based firewall blocks.

Stage 3 — The XOR'd AWS Gateway Relay

Rather than using a raw attacker-controlled server (which would appear in DNS/threat intel feeds), the campaign used a two-hop exfiltration relay:

Victim machine → Slack Webhook → AWS API Gateway (XOR-obfuscated endpoint) → C2

The AWS API Gateway endpoints used in this campaign are a documented evasion technique: Lambda functions behind API Gateway generate execute-api.amazonaws.com URLs that appear legitimate to proxy filters and DLP tools that whitelist AWS traffic. The XOR obfuscation on the Gateway endpoint URL further prevented static string scanning from identifying the C2 destination inside the payload.

This architecture means:

• No raw attacker IP ever appears in network logs
• Egress traffic looks like normal AWS API calls
• The Slack webhook initial layer creates a further buffer between the victim and the infrastructure

The combination is sophisticated: a defender monitoring outbound connections would see a Slack webhook call (legitimate-looking) and, if they followed the chain, an AWS API Gateway call (also legitimate-looking). Without behavioral analysis of what data those calls carried, the exfiltration would be invisible.

Stage 4 — npm Token Harvest and Self-Propagation

Once environmental data was extracted, the payload pivoted to worm propagation mode — the defining characteristic of the post-Shai-Hulud npm attack generation.

The worm logic:

1. Read ~/.npmrc to extract the victim's _authToken or NPM_TOKEN credentials.

2. Enumerate all npm packages the victim account has publish rights to using the npm API.

3. For each package, download the latest version, inject a modified version of the dropper into its postinstall hook, and publish a new patch version.

The injected dropper was semantically identical to the original — same exfiltration infrastructure, same dormancy logic — but obfuscated with different variable names and string encoding to avoid hash-based matching against the already-detected campaign.

In environments where developers had broad publish rights across organizational scopes, a single compromised developer account could cascade into dozens of downstream packages, each now carrying the payload to all their downstream consumers. This is the npm registry used as a force multiplier for malware distribution — exactly what Shai-Hulud proved was possible in September 2025.

Stage 5 — PyPI Cross-Ecosystem Propagation

The campaign included a final stage that no previous npm campaign had publicly documented: cross-ecosystem propagation into PyPI.

If the victim's environment contained Python credentials (specifically, a .pypirc file or TWINE_PASSWORD environment variable), the payload invoked twine — Python's package publishing CLI — to publish malicious PyPI packages. The generated packages were named using a plausible Python analog of the compromised npm package name (e.g., a backdoored asurion-core npm package would attempt to publish an asurion_core Python package to PyPI).

This cross-ecosystem propagation is architecturally significant:

• A single compromised developer who publishes to both npm and PyPI becomes a vector for both ecosystems simultaneously
• The attack surface expands from the npm registry (2.1 million packages) to PyPI (500,000+ packages) within a single infection chain
• Organizations relying on ecosystem-specific security controls (npm-only SCA scanning, for example) have a systematic blind spot

---

Why Scanners Missed It

Four distinct detection layers failed to catch this campaign in real-time:

1. Behavioral dormancy: The payload checked for sandbox signatures before executing. Most automated scanning tools run in exactly the kinds of environments the dormancy check was designed to detect — isolated containers with generic hostnames.

2. No-traffic static analysis: The XOR-obfuscated AWS Gateway URL prevented static string matching from identifying the C2 infrastructure. Without dynamic execution in a realistic developer environment, the C2 endpoint was invisible.

3. Organizational namespace trust: Dependency confusion and private package impersonation attack vectors are difficult to detect without a SBOM or allowlist of expected private packages. Most organizations do not maintain these.

4. Legitimate-looking metadata: The packages contained real-looking code, valid package.json structure, and no obvious red flags. The first-pass heuristic checks most npm security tools apply — malformed JSON, empty packages, no readme — all passed.

This failure cascade explains why Unit 42 was only able to retrospectively document the campaign on April 24, after the exfiltration had already run for more than a week.

---

Attribution: TeamPCP Overlap, Unconfirmed

The campaign shares infrastructure and TTP fingerprints with TeamPCP — the threat actor Unit 42 and Socket identified as responsible for the September 2025 Shai-Hulud worm, the March 2026 Axios compromise, and the April 22 Bitwarden CLI attack.

Overlapping indicators include:

• Identical XOR-based AWS Gateway URL obfuscation scheme
• Same behavioral dormancy check logic (sandbox fingerprint detection)
• npm-to-PyPI propagation logic first documented in Shai-Hulud 2.0
• Slack webhook as primary initial exfiltration channel

However, the sbxapps/asurion-hub-web packages contained no explicit attribution strings (the xinference PyPI campaign, by contrast, contained # hacked by teampcp — which even TeamPCP later disputed as a false flag). The organizational targeting (Asurion rather than generic scoped packages) suggests either a targeted intelligence operation against Asurion's developer network specifically, or a copycat actor deploying the same worm framework.

Attribution confidence: medium-low. The TTPs fit TeamPCP but the targeting logic does not match their previous broad-spectrum developer community attacks.

---

IOCs / Indicators

Malicious npm packages (removed):

• sbxapps (published April 1, 2026)
• asurion-hub-web (published April 2, 2026)
• soluto-home-web (published April 3, 2026)
• asurion-core (published April 8, 2026)

Exfiltration mechanism:

• Slack webhook (hardcoded, now burned)
• AWS API Gateway relay endpoint — execute-api.amazonaws.com (specific endpoint burned, pattern persists)
• XOR-key obfuscated URL string in postinstall payload

Behavioral indicators:

• Unexpected postinstall script spawning node child process after npm install
• Outbound Slack webhook calls from CI/CD runner environments
• npm registry API calls enumerating user's publishable packages (GET /org/{org}/package, GET /-/npm/v1/packages)
• New minor/patch versions of legitimate internal packages published without matching Git tags or changelog entries
• .pypirc access followed immediately by twine upload in environments where no Python package publish was scheduled

---

Lyrie Take

This campaign demonstrates something the security community has not fully processed: the npm ecosystem is now a hostile network for unguarded developer credentials, and the attack sophistication has outpaced the defenses by a full generation.

The self-propagating worm pattern, first confirmed by Shai-Hulud in September 2025, has become a commodity capability. The April 2026 campaign window saw at least three simultaneous operations (Axios-derived worms, Bitwarden CLI, Asurion impersonation) running against different target populations with architecturally identical payloads. This isn't one threat actor pushing the frontier — it's a template that has been operationalized and replicated.

The PyPI cross-ecosystem propagation is the most alarming evolution. Until now, organizations could reason about supply chain risk on a per-registry basis. That model is broken. A developer who has publish rights on both npm and PyPI — an extremely common configuration at companies that maintain polyglot monorepos — is now a dual-ecosystem attack vector from a single credential compromise event.

From Lyrie's autonomous defense perspective: the detection gap here is not a scanner problem — it's an identity and authorization problem. If npm publish tokens were scoped to specific packages (not org-wide), if CI/CD tokens had read-only by default, if package publish events triggered real-time SBOM diff analysis, the worm propagation stage would collapse. The technology exists. The industry just hasn't enforced it.

---

Defender Playbook

Immediate (if you use any of the four packages):

• Rotate all credentials (npm tokens, GitHub PATs, AWS keys, Slack tokens) on any machine where these packages were installed between April 1-8, 2026
• Audit npm publish logs for unexpected new versions across all your organizational packages
• Check PyPI for any new packages with names matching your npm package names (Python-equivalent naming)
• Treat any machine that ran npm install during this window as potentially compromised

Structural (to prevent recurrence):

1. Enforce granular npm token scoping: Never use org-wide publish tokens in CI/CD. Use automation tokens scoped to specific packages only.

2. Block dependency confusion vectors: Configure .npmrc with @your-org:registry= pointing to your private registry, and set --registry explicitly in CI/CD pipelines. Use npm config set @your-org:registry=https://your-private-registry.example.com.

3. Allowlist expected packages: Maintain a SBOM and alert on any new package name that appears in your dependency graph that is not on the allowlist.

4. Monitor postinstall script execution: Use npm install --ignore-scripts in CI/CD where possible. For packages that require scripts, audit the scripts before allowing them.

5. SBOM diff on every publish: Any new package version published to your npm org should trigger automated diff analysis comparing the new postinstall script against the previous version.

6. Cross-ecosystem monitoring: If your developers have PyPI publish rights, monitor for unexpected PyPI package creation events correlated with npm install activity.

7. Network egress controls: Block outbound Slack webhook calls from CI/CD runners unless explicitly required. Alert on AWS API Gateway calls from build environments.

8. Separate publish credentials from developer machines: npm publish tokens should live in a secrets manager, never in .npmrc on developer workstations.

---

Sources

1. Unit 42 / Palo Alto Networks — "The npm Threat Landscape: Attack Surface and Mitigations" (April 24, 2026): https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/

2. Endor Labs — "The Bitwarden CLI Supply Chain Attack: What Happened and What to Do" (April 23, 2026): https://www.endorlabs.com/learn/shai-hulud-the-third-coming----inside-the-bitwarden-cli-2026-4-0-supply-chain-attack

3. The Hacker News — "Self-Propagating Supply Chain Worm Hijacks npm Packages to Steal Developer Tokens" (April 25, 2026): https://thehackernews.com/2026/04/self-propagating-supply-chain-worm.html

4. The Register — "Ongoing supply-chain attack 'explicitly targeting' security, dev tools" (April 27, 2026): https://www.theregister.com/2026/04/27/supply_chain_campaign_targets_security/

5. OX Security — "Shai-Hulud: The Third Coming — Bitwarden CLI Backdoored in Latest Supply Chain Campaign" (April 22, 2026): https://www.ox.security/blog/shai-hulud-bitwarden-cli-supply-chain-attack/

6. iSec News — "Malicious npm packages spread self-propagating worm through stolen developer tokens" (April 23, 2026): https://www.isec.news/2026/04/23/malicious-npm-packages-spread-self-propagating-worm-through-stolen-developer-tokens/

7. Rankiteo — "Asurion, npm and GitHub: Self-Propagating Supply Chain Worm Hijacks npm Packages to Steal Developer Tokens" (April 22, 2026): https://blog.rankiteo.com/gitnpmasu1776918263-asurion-npm-github-cyber-attack-april-2026/

---

Lyrie.ai Cyber Research Division — Senior Analyst Desk