ataque de confusão de dependência npm alone5511

ataque de confusão de dependência npm alone5511

TL, DR

Between May 1 and May 6, 2026, a single npm publisher, alone5511, pushed eight zero-dependency packages that appear to target Microsoft / Azure-style internal package namespaces.

The packages used names such as cosmos-explorer, ms.analytics-web, icons.generated, latency-tracking-internal, carbonite-internal e carboniteapp. Several versions used high semver values such as 99.9.0 e 99.9.13, which is a common dependency-confusion tactic designed to outrank private internal packages.

All eight sibling packages were already unpublished from npm by the publisher between May 1 and May 6, 2026. Direct registry metadata confirmed that the tarballs now return HTTP 404 from the npm CDN.

However, the cluster still matters.

The payload in the canonical samples, carbonite-internal:99.9.0 e carboniteapp:99.9.0, runs at install time through a preinstall hook. It collects host fingerprint data, fetches the machine’s public IP from api.ipify.org, builds a fake “PRO-LEVEL INTELLIGENCE REPORT,” marks the host as RCE VERIFIED, and sends the report to a Telegram bot through the Telegram Bot API.

Alerta Antecipado de Malware (MEW) da Xygeni system classified the canonical samples as probably malicious with a score above 91/100.

We are tracking this as a Microsoft internal-name dependency-confusion campaign with install-time host fingerprinting and Telegram beacon exfiltration.

The Cluster: Eight Packages, One Publisher

A conta do editor alone5511 used the email address:

raistargaming703@gmail.com

The account had no verified email, no SCM verification, and an npm reputation score of 2.

A referenced GitHub identity, alonebeast002/beastcrypt, also appeared in the cluster context.

The publisher released eight related packages over a six-day window. All packages had zero dependencies and followed the same general pattern: small package, install-time script, host fingerprinting, and Telegram beaconing.

# Pacote Malicious Version Created, UTC Unpublished, UTC Payload Confirmed Install Hook
1 cosmos-explorer 1.1.3 2026-05-01T18:26Z 2026-05-01T19:01Z Inferred, same publisher / cluster preinstall, presumed
2 signalsdk-web 1.0.0, 10.0.0 2026-05-04T13:57Z 2026-05-04T18:51Z Inferido preinstall, presumed
3 ms.analytics-web 99.0.0, 99.9.13 2026-05-04T18:47Z 2026-05-05T10:07Z Inferido preinstall, presumed
4 icons.generated 99.9.13 2026-05-05T10:02Z 2026-05-05T12:57Z Inferido preinstall, presumed
5 latency-tracking 99.9.0 2026-05-05T11:57Z 2026-05-05T12:57Z Inferido preinstall, presumed
6 latency-tracking-internal Versions stripped from registry record 2026-05-06T06:02Z 2026-05-06T08:35Z Inferido preinstall, presumed
7 carboniteapp 99.9.0 2026-05-06T05:49Z 2026-05-06T08:35Z Yes, full scanner code-flow preinstall: node index.js
8 carbonite-internal 99.9.0 2026-05-06T06:14Z 2026-05-06T08:36Z Yes, full scanner code-flow preinstall: node index.js

Total malicious version-tuples across the cluster: 9+.

Some sibling package records had versions stripped after unpublish, which limits exact reconstruction from public registry data alone.

Why the Names Matter

The package names are the strongest signal.

They look like internal SDK, telemetry, icon-generation, explorer, or latency-tracking packages:

cosmos-explorer
signalsdk-web
ms.analytics-web
icons.generated
latency-tracking
latency-tracking-internal
carbonite-internal
carboniteapp

This is not random naming. It looks calibrated for confusão de dependência.

Several later packages used high version numbers:

99.0.0
99.9.0
99.9.13
10.0.0

That matters because dependency-confusion attacks often rely on public packages having higher versions than internal private-registry packages. If a build system is misconfigured, the package manager may choose the public npm version over the intended internal one.

The publisher also appears to escalate over time.

Early packages used normal-looking versions, such as 1.1.3 e 1.0.0. Later packages moved into 99.x.x e 99.9.x. That shift is consistent with an actor tuning the campaign for internal package resolution behavior.

What Happens at Install Time

The canonical samples, carbonite-internal:99.9.0 e carboniteapp:99.9.0, declare a preinstall gancho:

 
{
  "scripts": {
    "preinstall": "node index.js"
  }
}

That means the payload runs before npm finishes installing dependencies.

This is the earliest possible install-time foothold. The developer does not need to import the package. The build does not need to execute application code. The install itself is enough.

The payload is small, around 2.4 KB, and has no functional purpose beyond beaconing.

Comportamento da carga útil

O processo de index.js file performs four main actions.

Primeiro, ele chama api.ipify.org to fetch the host’s public IP address:

https://api.ipify.org

Second, it collects basic host fingerprinting data using Node.js OS APIs:

os.userInfo()
os.hostname()
os.platform()
os.networkInterfaces()
os.uptime()

Third, it formats the collected data into a multi-line report with a literal banner:

PRO-LEVEL INTELLIGENCE REPORT

The report ends with:

Status: 🟢 RCE VERIFIED

Fourth, it sends the report to Telegram through a sendTelegram(report) function, using the Telegram Bot API endpoint:

https://api.telegram.org/bot<token>/sendMessage

The exact Telegram bot token is preserved inside the unpublished tarballs and should be recoverable from npm internal storage.

Why the “RCE VERIFIED” Banner Matters

The literal RCE VERIFIED marker is operationally telling.

The payload does not deploy a backdoor. It does not persist. It does not steal cloud credentials directly. Instead, it confirms that code execution occurred during package installation.

That is enough for a dependency-confusion proof-of-execution campaign.

If the attacker receives a Telegram message from a target environment, they know the public npm package was resolved and executed inside a real host, CI runner, developer workstation, or build environment.

In other words, the malware is not just collecting host metadata. It is validating whether the target’s package resolution is exploitable.

Xygeni MEW Classification

Xygeni MEW classified the canonical samples as probably malicious, with a score above 91/100.

The detections included:

Gravidade Detecção Significado
Críticas sensitive_data_exfiltration req.write(data) carries the host-fingerprint report into an outbound Telegram POST
Alto malicious_installation_scripts preinstall: node index.js triggers the beacon at install time
Baixo suspicious_request Public IP discovery through api.ipify.org
Baixo suspicious_request Telegram Bot API outbound endpoint
Baixo trivial_package Package has no meaningful purpose beyond beaconing
Info sensitive_data_enumeration Host details such as uptime, user info, and hostname are enumerated

Ambos carbonite-internal:99.9.0 e carboniteapp:99.9.0 had identical payloads, including the same code-flow ID and byte-equivalent install scripts.

The MEW publisher-projects index marked all eight packages as part of the same publisher / payload cluster.

Why the Self-Unpublish Pattern Matters

All eight sibling packages were unpublished by the publisher within minutes to hours of publication.

That behavior is important.

Legitimate maintainers do sometimes unpublish packages, but the timing here looks like attacker cleanup. The packages appeared, executed their install-time payload if resolved by a target, and then disappeared from public registry access.

That creates two problems for defenders.

First, public npm metadata becomes incomplete after unpublish. Some version records may be stripped or harder to reconstruct.

Second, defenders relying on current registry state may miss packages that were present during the exposure window but are no longer installable.

For that reason, npm should preserve the unpublished tarballs internally for forensics. The Telegram bot token inside the tarballs may help enumerate the receiving channel and reconstruct possible victims.

Indicadores de comprometimento e detecção

Publisher and Account

Campo Valor
npm username alone5511
npm publisher email raistargaming703@gmail.com
npm reputation 2
Email verificado Não
SCM verificado Não
Referenced GitHub identity alonebeast002/beastcrypt

Affected Package Names

cosmos-explorer
signalsdk-web
ms.analytics-web
icons.generated
latency-tracking
latency-tracking-internal
carbonite-internal
carboniteapp

Suspicious Version Patterns

10.0.0
99.0.0
99.9.0
99.9.13

These high versions are especially relevant in dependency-confusion investigations because they may outrank private package versions.

Pontos finais de rede

Formato Valor
Public IP probe https://api.ipify.org
Exfiltration sink https://api.telegram.org/bot<token>/sendMessage
Exfiltration method Telegram Bot API POST

Payload Markers

Search install scripts for these strings:

PRO-LEVEL INTELLIGENCE REPORT
Status: 🟢 RCE VERIFIED
sendTelegram(

Also flag this manifest pattern:

{
  "scripts": {
    "preinstall": "node index.js"
  }
}

Especially when paired with:

  • Zero dependências
  • Tiny package size
  • Internal-looking package name
  • High semver version
  • Host fingerprinting APIs
  • Telegram Bot API traffic

Host Fingerprinting APIs

The canonical payload uses:

os.userInfo()
os.hostname()
os.platform()
os.networkInterfaces()
os.uptime()

It also reaches out to:

https://api.ipify.org

to capture the host’s public IP.

Notas de Detecção

Several rules can catch this campaign and close variants.

First, monitor for npm install scripts that contact Telegram:

api.telegram.org

A package install script should almost never POST to Telegram. Treat this as hostile unless there is a very clear and reviewed exception.

Second, flag preinstall scripts in tiny zero-dependency packages with internal-looking names.

The combination of a small package, a high semver version, and an internal namespace-style name is a strong dependency-confusion signal.

Third, alert on package names that look like private engineering modules published by low-reputation public npm accounts.

Examples from this cluster include:

ms.analytics-web
latency-tracking-internal
carbonite-internal
icons.generated

Fourth, hunt for lockfile references to the eight package names across CI systems and developer workstations.

Pesquisa:

package-lock.json
yarn.lock
pnpm-lock.yaml
npm-shrinkwrap.json

Any match should trigger dependency-confusion review.

Suggested Registry Actions

This cluster was already unpublished at report time. However, unpublish does not remove the risk.

Recommended npm-side actions:

  • Confirm whether the unpublishes were attacker-initiated cleanup rather than legitimate maintainer action.
  • Suspend or ban the publisher account alone5511.
  • Add the publisher, email address, package names, and payload markers to abuse and supply-chain blocklists.
  • Preserve unpublished tarballs in internal storage for forensics.
  • Extract the Telegram bot token from the preserved tarballs.
  • Work with Telegram, where possible, to identify the receiving channel and reconstruct potential victim telemetry.

Lista de verificação para resposta a compromissos

If any of the affected packages appeared in your lockfiles, build logs, package cache, or CI install history during the exposure window, treat it as a dependency-confusion execution event.

Resposta recomendada:

  • Identify where the package was installed: local workstation, CI runner, build agent, or container image.
  • Preserve lockfiles, npm cache, build logs, shell history, and package manager output.
  • Check outbound network logs for api.telegram.org e api.ipify.org during the install window.
  • Review whether the install ran in an environment with sensitive variables, credentials, or internal network access.
  • Rotate tokens exposed to the install environment if the host was a privileged CI runner or developer workstation.
  • Audit package resolution configuration for public/private registry confusion.
  • Enforce scoped private packages and registry pinning.
  • Block unapproved public packages that match internal naming patterns.
  • Adicione guardrails for install scripts, especially preinstall, install e postinstall.

O que os defensores devem levar consigo

This campaign is not technically complex. That is exactly why it matters.

The payload is small, direct, and easy to run. The attacker does not need persistence or advanced malware. They only need one misconfigured package-resolution path.

The real risk is dependency confusion.

A package with a familiar internal-looking name, a high version number, and a preinstall hook can turn a normal npm install into a beacon from inside your environment.

Para DevSecOps teams, the lesson is clear: internal package names are sensitive assets. Treat them like attack surface.

Reported to npm for account-level enforcement, blocklisting, and unpublished tarball preservation.

sca-tools-software-composição-análise-ferramentas
Priorize, corrija e proteja seus riscos de software
você recebe uma avaliação gratuita de 7 dias da nossa licença Business Edition e pode aproveitar alguns dos recursos avançados da plataforma SecurityScorecard.
Não é necessário cartão de crédito

Proteja seu desenvolvimento e entrega de software

com o Suíte de Produtos da Xygeni