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, and carboniteapp. Several versions used high semver values such as 99.9.0 and 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 and 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.
Xygeni’s Malware Early Warning (MEW) 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
The publisher account alone5511 used the email address:
raistargaming703@gmail.comThe 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.
| # | Package | 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 | Inferred | preinstall, presumed |
| 3 | ms.analytics-web | 99.0.0, 99.9.13 | 2026-05-04T18:47Z | 2026-05-05T10:07Z | Inferred | preinstall, presumed |
| 4 | icons.generated | 99.9.13 | 2026-05-05T10:02Z | 2026-05-05T12:57Z | Inferred | preinstall, presumed |
| 5 | latency-tracking | 99.9.0 | 2026-05-05T11:57Z | 2026-05-05T12:57Z | Inferred | preinstall, presumed |
| 6 | latency-tracking-internal | Versions stripped from registry record | 2026-05-06T06:02Z | 2026-05-06T08:35Z | Inferred | 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
carboniteappThis is not random naming. It looks calibrated for dependency confusion.
Several later packages used high version numbers:
99.0.0
99.9.0
99.9.13
10.0.0That 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 and 1.0.0. Later packages moved into 99.x.x and 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 and carboniteapp:99.9.0, declare a preinstall hook:
{
"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.
Payload Behavior
The index.js file performs four main actions.
First, it calls api.ipify.org to fetch the host’s public IP address:
https://api.ipify.orgSecond, 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 REPORTThe report ends with:
Status: 🟢 RCE VERIFIEDFourth, it sends the report to Telegram through a sendTelegram(report) function, using the Telegram Bot API endpoint:
https://api.telegram.org/bot<token>/sendMessageThe 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:
| Severity | Detection | Meaning |
|---|---|---|
| Critical | sensitive_data_exfiltration | req.write(data) carries the host-fingerprint report into an outbound Telegram POST |
| High | malicious_installation_scripts | preinstall: node index.js triggers the beacon at install time |
| Low | suspicious_request | Public IP discovery through api.ipify.org |
| Low | suspicious_request | Telegram Bot API outbound endpoint |
| Low | trivial_package | Package has no meaningful purpose beyond beaconing |
| Info | sensitive_data_enumeration | Host details such as uptime, user info, and hostname are enumerated |
Both carbonite-internal:99.9.0 and 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.
Indicators of Compromise and Detection
Publisher and Account
| Field | Value |
|---|---|
| npm username | alone5511 |
| npm publisher email | raistargaming703@gmail.com |
| npm reputation | 2 |
| Email verified | No |
| SCM verified | No |
| Referenced GitHub identity | alonebeast002/beastcrypt |
Affected Package Names
cosmos-explorer
signalsdk-web
ms.analytics-web
icons.generated
latency-tracking
latency-tracking-internal
carbonite-internal
carboniteappSuspicious Version Patterns
10.0.0
99.0.0
99.9.0
99.9.13These high versions are especially relevant in dependency-confusion investigations because they may outrank private package versions.
Network Endpoints
| Type | Value |
|---|---|
| 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 dependencies
- 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.orgto capture the host’s public IP.
Detection Notes
Several rules can catch this campaign and close variants.
First, monitor for npm install scripts that contact Telegram:
api.telegram.orgA 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.generatedFourth, hunt for lockfile references to the eight package names across CI systems and developer workstations.
Search:
package-lock.json
yarn.lock
pnpm-lock.yaml
npm-shrinkwrap.jsonAny 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.
Compromise Response Checklist
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.
Recommended response:
- 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.organdapi.ipify.orgduring 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.
- Add guardrails for install scripts, especially
preinstall,install, andpostinstall.
What Defenders Should Take Away
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.
For 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.
