The Asurion impersonation campaign: eight days, four fake packages, and a Slack webhook

Between April 1 and April 8, 2026, a campaign pushed four npm packages impersonating Asurion and its subsidiaries. The packages later turned into credential harvesters. The patient part is the lesson.

By David Gil Pérez · Happyberg Labs

TL;DR

For eight days at the start of this month, a single attacker (or coordinated group) pushed four npm packages styled to look like internal tooling from Asurion, the US phone insurance company. The packages were named sbxapps, asurion-hub-web, soluto-home-web (Soluto is an Asurion subsidiary), and asurion-core. Each contained a multi-stage credential harvester that exfiltrated harvested data first to a Slack webhook, then to an AWS API Gateway endpoint when the Slack webhook went down.

The packages were aimed at developers, not at Asurion as a corporate victim. They were not malicious immediately. They sat on npm for days, accumulated a little age and plausibility, and then the malicious updates landed.

What happened

The campaign was first documented by Panther Labs and picked up by The Hacker News and Cloudsmith. Approximate timeline (UTC):

  • April 1: sbxapps published to npm. Name is plausibly an internal initialism; nothing in the package screams “malicious” on a casual look. Initial version is a thin wrapper around legitimate axios calls with no malicious code.
  • April 2–4: asurion-hub-web published. Same pattern: an initial version that is benign, set up to attract installs from Asurion developers or their contractors who might assume it is an internal mirror.
  • April 4–5: soluto-home-web published. Soluto is an Asurion subsidiary that does smart-home support; the impersonation here is more targeted.
  • April 6: asurion-core published.
  • April 7: malicious update pushed to all four packages. The new versions add a credential harvester to the install hook. The harvester scans for ~/.npmrc, ~/.aws/credentials, ~/.ssh/, GitHub Actions environment variables, and a list of common cloud-credential paths. It serializes findings and POSTs them to a hardcoded Slack webhook.
  • April 7, late: Slack disables the webhook, presumably after automated abuse detection. The malicious packages had a fallback: a hardcoded AWS API Gateway URL that received the same payload.
  • April 8: Cloudsmith and others publish advisories. npm pulls the four packages. The active window for the malicious updates was about 18 hours.

The 18-hour active window is longer than the axios and Bitwarden windows, but the setup phase is the important part. From April 1 to April 7 there was nothing obviously malicious in the early versions. A simple “package has existed for a week” signal can be gamed by waiting a week.

What was supposed to stop this

npm audit does not catch packages that are not yet in the advisory database. Sigstore provenance is irrelevant here because the packages were under attacker control end-to-end, including any signatures attached. The packages were published with manufactured author handles, and npm audit did not flag them as suspicious during the benign phase.

Several scanners (Socket in particular) use heuristics that incorporate “package age” and “publisher reputation”. Both of these heuristics treated the benign phase as a positive signal. Once the malicious update landed, the packages had a week of existing on npm, which the heuristics took as evidence of trustworthiness. This is the patience attack pattern, and it tells us that age-based signals need to be paired with diff-based signals (what changed between this version and the previous one).

The harder problem here is impersonation. Asurion-the-company did not publish these packages. There is currently no way for a real company to claim its name space on npm and prevent typosquats. The npm @org scope can be reserved by paying for an org account, but Asurion does not currently have one, and even if they did, the malicious package names (sbxapps, asurion-hub-web, etc.) are not exact org-prefix matches; they are name-shaped impersonations.

For developers consuming packages, the practical question is: did you install any of these? Symptom check:

npm ls sbxapps asurion-hub-web soluto-home-web asurion-core 2>/dev/null | grep -v "(empty)"

If anything shows up, treat the host as compromised: rotate every credential the developer machine has touched in the last week, audit the AWS account, audit any GitHub tokens that might have been on the box.

What would have changed the outcome

The same answer as the axios writeup last week: a release-age cooldown.

The malicious update to all four packages went live on April 7. By April 8, npm had pulled them. A four-day cooldown would have kept cooldown-enabled machines from installing the malicious version during the active window. The cooldown does not detect malice. It buys time for detection and takedown.

There is a subtlety for this campaign that does not apply to the others: the early versions of these packages, before the malicious update, were benign. A developer who pulled [email protected] on April 2 ended up with a non-malicious package on their machine. The compromise happened on update. Cooldowns help here too: most teams do not pin every version, so when a developer runs npm update (or when CI does), the cooldown delays the pull of any version published in the last four days. The malicious updates would have been blocked at update time.

The other piece is: do not install packages you have not heard of. Easy to say, hard to enforce. The sbxapps name in particular is the kind of thing a developer might paste into their terminal without much thought, especially if they are working on an Asurion project and an internal Slack message tells them “we use sbxapps for the sandbox API”. That is the social-engineering surface. A typo-squat checker on package names against a known-good list helps a little, but the names here are not typos; they are plausible-sounding names. The defense against this is process, not tooling: a fresh package name should require justification before it lands in any project’s dependency list.

Where I am with the tool I have been working on

I shipped @happyberg/pkg-quarantine because this setup is annoying to keep correct by hand. quarantine init writes the settings, quarantine audit verifies they are actually enforced. A configured-looking cooldown that is silently ignored is worse than no cooldown, because it lets you believe the gate exists.

npm install -g @happyberg/pkg-quarantine
quarantine init
quarantine audit

If the audit reports green for the managers you use, fresh malicious updates have to survive the cooldown before reaching you. That will not catch the slow-burn impersonation play during the benign phase, but it does catch the malicious update when it lands.

What this campaign tells us about the next wave

The pattern to watch is a combination of the last three: Shai-Hulud-style propagation, axios-style install volume, and Asurion-style naming patience. The defenses differ, but the release-age layer still helps at the version boundary: it delays the malicious update even when the package name itself has been sitting around.

References