TL博士
2026年5月1日至5月6日期间，单个npm发布者， alone5511推送了八个零依赖软件包，这些软件包似乎旨在 Microsoft / Azure 风格的内部包命名空间。
这些软件包使用的名称如下： cosmos-explorer, ms.analytics-web, icons.generated, latency-tracking-internal, carbonite-internal和 carboniteapp多个版本使用了较高的语义版本号，例如： 99.9.0 以及 99.9.13这是一种常见的依赖关系混淆策略，旨在凌驾于私有内部包之上。
2026 年 5 月 1 日至 5 月 6 日期间，所有八个同级软件包均已被发布者从 npm 取消发布。直接注册表元数据证实，这些 tar 包现在从 npm CDN 返回 HTTP 404。
然而，集群仍然很重要。
典型样本中的有效载荷， carbonite-internal:99.9.0 以及 carboniteapp:99.9.0，在安装时通过一个 preinstall 钩子。它收集主机指纹数据，并从中获取机器的公网 IP 地址。 api.ipify.org伪造一份“专业级情报报告”，并将主持人标记为 RCE VERIFIED并通过 Telegram Bot API 将报告发送给 Telegram 机器人。
Xygeni 的恶意软件预警 (MEW) 系统将典型样本分类为可能恶意，得分高于 91/100。
我们正在追踪此事件，认为这是一起利用微软内部名称依赖关系混淆、安装时主机指纹识别和 Telegram 信标数据泄露的攻击活动。
集群：八个软件包，一个出版商
出版商账户 alone5511 使用的电子邮件地址：
raistargaming703@gmail.com该账户没有经过验证的电子邮件，也没有其他任何信息。 SCM 已验证，npm 信誉评分为 2。
引用的 GitHub 身份， alonebeast002/beastcrypt也出现在集群上下文中。
在六天的时间里，发布者发布了八个相关软件包。所有软件包均无任何依赖项，并遵循相同的模式：小型软件包、安装时脚本、主机指纹识别和 Telegram 信标。
| # | 小包装 | 恶意版本 | 创建于 UTC | 未发表，UTC | 有效载荷已确认 | 安装钩子 |
|---|---|---|---|---|---|---|
| 1 | 宇宙探索者 | 1.1.3 | 2026-05-01T18:26Z | 2026-05-01T19:01Z | 推断，同一发布者/集群 | 预安装，假定 |
| 2 | signalsdk-web | 1.0.0，10.0.0 | 2026-05-04T13:57Z | 2026-05-04T18:51Z | 推断 | 预安装，假定 |
| 3 | ms.analytics-web | 99.0.0，99.9.13 | 2026-05-04T18:47Z | 2026-05-05T10:07Z | 推断 | 预安装，假定 |
| 4 | 生成的图标 | 99.9.13 | 2026-05-05T10:02Z | 2026-05-05T12:57Z | 推断 | 预安装，假定 |
| 5 | 延迟跟踪 | 99.9.0 | 2026-05-05T11:57Z | 2026-05-05T12:57Z | 推断 | 预安装，假定 |
| 6 | 延迟跟踪-内部 | 从注册表记录中剥离版本信息 | 2026-05-06T06:02Z | 2026-05-06T08:35Z | 推断 | 预安装，假定 |
| 7 | carboniteapp | 99.9.0 | 2026-05-06T05:49Z | 2026-05-06T08:35Z | 是的，完整的扫描器代码流程 | 预安装：node index.js |
| 8 | 碳化物-内部 | 99.9.0 | 2026-05-06T06:14Z | 2026-05-06T08:36Z | 是的，完整的扫描器代码流程 | 预安装：node index.js |
集群中恶意版本元组的总数： 9+.
有些同级软件包记录在取消发布后版本信息被删除，这限制了仅凭公共注册表数据进行精确重建。
为什么名字很重要
软件包名称是最有力的信号。
它们看起来像是内部 SDK、遥测、图标生成、资源管理器或延迟跟踪软件包：
cosmos-explorer
signalsdk-web
ms.analytics-web
icons.generated
latency-tracking
latency-tracking-internal
carbonite-internal
carboniteapp这并非随意命名，而是经过精心校准的。 依赖混淆.
后来的几个软件包使用了较高的版本号：
99.0.0
99.9.0
99.9.13
10.0.0这一点很重要，因为依赖混淆攻击通常利用公共软件包的版本高于内部私有注册表软件包的版本。如果构建系统配置错误，包管理器可能会选择公共 npm 版本而不是预期的内部版本。
随着时间的推移，出版商的行为似乎也在不断升级。
早期的软件包使用外观正常的版本，例如： 1.1.3 以及 1.0.0后来的包裹搬进了 99.x.x 以及 99.9.x这种转变与某个行动者调整竞选策略以适应内部包裹处理行为的做法相一致。
安装时会发生什么
典型样本， carbonite-internal:99.9.0 以及 carboniteapp:99.9.0声明一个 preinstall 钩：
{
"scripts": {
"preinstall": "node index.js"
}
}这意味着有效载荷会在 npm 完成依赖项安装之前运行。
这是安装时最早可以采取的措施。开发者无需导入软件包，构建过程也无需执行应用程序代码，安装本身就足够了。
有效载荷很小，大约 2.4 KB，除了发送信标外没有其他功能用途。
有效载荷行为
此 index.js 文件执行四项主要操作。
首先，它调用 api.ipify.org 获取主机的公网 IP 地址：
https://api.ipify.org其次，它使用Node.js操作系统API收集基本的主机指纹数据：
os.userInfo()
os.hostname()
os.platform()
os.networkInterfaces()
os.uptime()第三，它将收集到的数据格式化为带有标题的多行报告：
PRO-LEVEL INTELLIGENCE REPORT报告最后写道：
Status: 🟢 RCE VERIFIED第四，它通过 Telegram 将报告发送至 sendTelegram(report) 使用 Telegram Bot API 端点的函数：
https://api.telegram.org/bot<token>/sendMessage确切的 Telegram 机器人令牌保存在未发布的 tar 包中，应该可以从 npm 内部存储中恢复。
“RCE 已验证”横幅为何重要
字面意义上的 RCE VERIFIED 标记具有操作指示意义。
该有效载荷不会部署后门，也不会持久化，更不会直接窃取云凭证。相反，它会确认在软件包安装过程中发生了代码执行。
这足以开展一次依赖关系混淆的执行证明活动。
如果攻击者收到来自目标环境的 Telegram 消息，他们就知道公共 npm 包已在真实主机、CI 运行器、开发人员工作站或构建环境中解析和执行。
换句话说，该恶意软件不仅仅是收集主机元数据，它还会验证目标的软件包解析是否存在可被利用的漏洞。
Xygeni MEW 分类
Xygeni MEW 将典型样本分类为 可能是恶意得分超过 91/100。
检测结果包括：
| 严谨求真 | 检测 | 意 |
|---|---|---|
| 危急 | 敏感数据泄露 | req.write(data) 将主机指纹报告写入到出站 Telegram POST 请求中。 |
| 高 | 恶意安装脚本 | 安装前：node index.js 会在安装时触发信标 |
| 低 | 可疑请求 | 通过 api.ipify.org 发现公共 IP 地址 |
| 低 | 可疑请求 | Telegram Bot API 出站端点 |
| 低 | 琐碎包 | 除了作为信标外，该软件包没有其他实际用途。 |
| 资料 | 敏感数据枚举 | 列出主机详细信息，例如运行时间、用户信息和主机名。 |
以上皆是 carbonite-internal:99.9.0 以及 carboniteapp:99.9.0 它们的载荷完全相同，包括相同的代码流 ID 和字节等效的安装脚本。
MEW 发布者项目索引将所有八个软件包标记为同一发布者/有效载荷集群的一部分。
为什么自取消发布模式很重要
所有八套同系列丛书都在出版后几分钟到几小时内被出版商撤回。
这种行为很重要。
合法的维护者有时确实会下架软件包，但这次的时机看起来像是攻击者在清理。这些软件包出现后，如果被目标解析，就会执行其安装时有效载荷，然后便从公共注册表中消失了。
这会给防守方带来两个问题。
首先，取消发布后，npm 的公共元数据会变得不完整。某些版本记录可能会被删除或难以重建。
其次，依赖当前注册表状态的防御者可能会错过在暴露窗口期间存在但现在已经无法安装的软件包。
因此，npm 应该将未发布的 tar 包在内部保存，以备取证之用。 Telegram 机器人 tar 包内的令牌可能有助于枚举接收信道并重建可能的受害者。
入侵和检测指标
出版商和帐户
| 领域 | 价值 |
|---|---|
| npm 用户名 | alone5511 |
| npm 发布者电子邮件 | raistargaming703@gmail.com |
| npm 声誉 | 2 |
| 电子邮件已验证 | 没有 |
| SCM 专利 | 没有 |
| 引用的 GitHub 身份 | alonebeast002/beastcrypt |
受影响的软件包名称
cosmos-explorer
signalsdk-web
ms.analytics-web
icons.generated
latency-tracking
latency-tracking-internal
carbonite-internal
carboniteapp可疑版本模式
10.0.0
99.0.0
99.9.0
99.9.13这些高版本在依赖关系混乱调查中尤其重要，因为它们的优先级可能高于私有软件包版本。
网络端点
| 类型 | 价值 |
|---|---|
| 公共 IP 探测 | https://api.ipify.org |
| 渗滤池 | https://api.telegram.org/bot<token>/sendMessage |
| 渗出法 | Telegram Bot API POST |
有效载荷标记
在安装脚本中搜索以下字符串：
PRO-LEVEL INTELLIGENCE REPORT
Status: 🟢 RCE VERIFIED
sendTelegram(同时标记此清单模式：
{
"scripts": {
"preinstall": "node index.js"
}
}尤其当与以下元素搭配时：
- 零依赖
- 包装尺寸小巧
- 内部软件包名称
- 高语义版本
- 主机指纹识别 API
- Telegram Bot API 流量
主机指纹识别 API
标准有效载荷使用：
os.userInfo()
os.hostname()
os.platform()
os.networkInterfaces()
os.uptime()它还联系了：
https://api.ipify.org获取主机的公网 IP 地址。
检测记录
有几条规则可以阻止这场运动及其变体。
首先，监控调用 Telegram 的 npm 安装脚本：
api.telegram.org软件包安装脚本几乎不应该向 Telegram 发送 POST 请求。除非有非常明确且经过审核的例外情况，否则应将其视为恶意行为。
第二，旗帜 preinstall 脚本位于零依赖的小型软件包中，名称看起来像是内部使用的。
小型软件包、较高的语义版本号和内部命名空间风格的名称相结合，是造成依赖关系混乱的强烈信号。
第三，要警惕那些看起来像是由信誉度低的公共 npm 帐户发布的私有工程模块的包名称。
该集群中的一些例子包括：
ms.analytics-web
latency-tracking-internal
carbonite-internal
icons.generated第四，在 CI 系统和开发人员工作站中查找对这八个软件包名称的 lockfile 引用。
使用以下 search 搜索栏来有系统地查看
package-lock.json
yarn.lock
pnpm-lock.yaml
npm-shrinkwrap.json任何匹配项都应触发依赖关系混淆审查。
建议的注册表操作
报告发布时，该集群已取消发布。但是，取消发布并不能消除风险。
建议在 npm 端执行的操作：
- 确认这些取消发布操作是攻击者发起的清理行动，还是合法的维护者操作。
- 暂停或封禁发布商帐户
alone5511. - 将发布者、电子邮件地址、软件包名称和有效载荷标记添加到滥用和供应链黑名单中。
- 将未发布的 tar 包保存在内部存储中，以备取证之用。
- 从保存的 tar 包中提取 Telegram 机器人令牌。
- 尽可能与 Telegram 合作，确定接收渠道并重建潜在受害者的遥测数据。
妥协应对清单
如果在暴露窗口期间，任何受影响的软件包出现在您的锁定文件、构建日志、软件包缓存或 CI 安装历史记录中，则将其视为依赖关系混乱执行事件。
建议回复：
- 确定软件包的安装位置：本地工作站、CI 运行器、构建代理或容器镜像。
- 保留锁定文件、npm 缓存、构建日志、shell 历史记录和包管理器输出。
- 检查出站网络日志
api.telegram.org以及api.ipify.org在安装窗口期间。 - 检查安装程序是否在包含敏感变量、凭据或内部网络访问权限的环境中运行。
- 如果主机是具有特权的 CI 运行器或开发人员工作站，则轮换暴露给安装环境的令牌。
- 审计包解析配置，以解决公共/私有注册表混淆问题。
- 强制执行作用域私有包和注册表锁定。
- 阻止符合内部命名模式的未经批准的公共软件包。
- 添加 guardrails 对于安装脚本，尤其是
preinstall,install和postinstall.
防守者应该吸取什么教训
这场活动在技术上并不复杂。正因如此，它才显得尤为重要。
该有效载荷体积小、操作直接且易于执行。攻击者无需持久化或高级恶意软件，只需一个配置错误的软件包解析路径即可。
真正的风险在于依赖关系混乱。
一个软件包，其名称听起来很熟悉，像是内部使用的，版本号很高，而且 preinstall 钩子可以变成普通的 npm install 从你的环境中进入信标。
对于 开发安全 各位团队，教训很明确：内部软件包名称是敏感资产。务必像对待攻击面一样对待它们。
已向 npm 报告，要求采取账户级强制措施、列入黑名单并保存未发布的 tarball 文件。
