供应链安全威胁档案周报——W46

原创 威胁情报中心 2026-11-13 18:10 北京

本周 4 起事件分别落在 npm 与桌面端发布、GitHub Actions、PyPI 软件包和第三方云信任。攻击者直接复用合法 CI、被盗 Token 与既有 IAM 角色，因此版本核对之外，还需审查发布提交、生命周期脚本、跨账号角色和凭证暴露范围。

阅读方式：A 看情报与影响，B 按痕迹排查，C 按顺序处置。执行文中命令前请结合业务环境核验。

披露时间：2026年11月09日　/　PUBLIC DISCLOSURE

■  情报来源： / SOURCE REGISTER

■  相关信息： / WHAT HAPPENED

2026年11月9日，Ethersphere发布管道遭入侵，两个GitHub账号被控，攻击者借合法CI发布恶意@ethersphere/bee-js 13.3.0和Swarm Desktop 0.56.2。前者将版本生成脚本改为postinstall远程加载器，从api.frameworkmetrics.xyz获取并执行JavaScript，约75分钟后下架；后者由项目自身CI构建、签名和公证，经自动更新推送给macOS和Windows用户，约8.5小时后移除。加载器与SleepyDuck/EtherDuck共享以太坊合约C2、钱包和第三阶段植入，第二阶段窃取Bee节点config.yaml及swarm.key，第三阶段在macOS和Linux安装solidity持久化Go后门，在Windows静默部署ScreenConnect。SLSA来源证明真实但仅证明构建位置，不能证明源码已审。建议排查相关版本和持久化痕迹，轮换凭据并转移节点钱包资产；维护者应校验发布提交位于受保护分支，并保护发布环境与签名材料。

■  遭受投毒/有被投毒风险的供应商： / AFFECTED ECOSYSTEM

本次供应链投毒事件里，遭受直接投毒的供应商为 Ethersphere，攻击者攻陷其项目发布机器人账号，向 npm 发布恶意版本 @ethersphere/bee-js@13.3.0，同时放出植入恶意载荷的 Swarm Desktop 0.56.2；所有依赖该 SDK 的上游周边组件（swarm‑cli、bee‑dashboard 等）以及拉取该版本的 npm 依赖链、CI/CD 流水线都属于存在被投毒风险的供应链分支，只要在风险时间窗口内解析、安装并执行了该恶意包或启动过该版本桌面客户端，就有可能触发恶意加载逻辑，进而让使用这些组件的开发者、节点运营者成为受害者。

01风险前提

02检查 npm 项目环境

01检查 lock 文件是否解析出恶意版本

查找版本号：13.3.0，出现即代表依赖解析到恶意版本。

02检查本机全局 npm 安装

03检查 npm 缓存

查看缓存中是否存在bee‑js‑13.3.0.tgz，存在需要清理缓存。

04检查 npm 日志，确认 postinstall 脚本是否运行

npm 调试日志目录：

搜索日志关键词： postinstall: node scripts/generate‑version.cjs、FrameworkMetrics analytics v2.3.1 is up to date，出现代表第一阶段加载器已经执行。
注意：部分包管理器默认关闭脚本（npm12+、pnpm10+、Bun），不会执行 postinstall；旧版本 npm/yarn classic 默认执行脚本。

03Swarm Desktop 用户检查

01查看应用版本：设置界面查看版本号，如果是 0.56.2，已经处于高风险；

02查看应用日志：

04系统文件：检查后门持久化痕迹

01Linux 系统检查

a)检查后门目录

若存在 linux_amd64 / linux_arm64、.run.py 则确认后门文件落地。

b)检查 systemd 用户服务持久化项

02macOS 系统检查

a)检查后门目录

存在darwin_arm64/darwin_amd64、.run.py / .run.cjs 为恶意文件。

b)检查 LaunchAgent 持久化

03Windows 系统检查

a)检查临时目录恶意暂存文件：查找文件名前缀.stuffed‑ 。路径：%TEMP%

b)检查隐藏后门目录：%LOCALAPPDATA%\.<32位十六进制GUID>\

c)检查恶意 ScreenConnect 服务

d)检查 UAC 劫持相关注册表

若 HKCU\Software\Classes\CLSID\{GUID}\InprocServer32 指向%TEMP%\uac39‑* 路径为入侵痕迹。

05检查网络连接和安全日志

在 DNS、代理、防火墙、EDR 或上网行为管理日志中搜索：

当前连接可作为辅助检查，但不能替代历史日志，因为后门会休眠，控制地址也可能变化。

06判断钱包和其他凭据是否暴露

检查 Swarm Desktop 数据目录中是否曾存在：

如果恶意代码执行期间这两个文件存在，应直接认定钱包密钥及密码已经泄露。同时梳理该用户或 CI 任务可访问的 GitHub、npm、SSH、云平台、代码签名和部署凭据，列入轮换范围。

01应急隔离

01断网隔离：立即断开有线 / 无线网络，阻断 C2 通信，防止攻击者下发更多插件、窃取数据或内网横向移动。

02保留现场：不要立即重启或删除文件，先备份可疑文件、进程内存 dump，便于后续溯源。

02清除系统持久化后门

01Linux

02macOS

03Windows（PowerShell 管理员）

03钱包资产处置

攻击者会窃取：config.yaml（可能明文保存钱包密码） + swarm.key（以太坊 V3 加密密钥库）。

04清理项目依赖，锁定安全版本

删除项目node_modules、lock 文件，清理 npm 缓存：

修改 package.json，固定@ethersphere/bee-js版本为安全版本13.2.0，禁止解析 13.3.0。

05凭证轮换

受入侵机器上所有密钥全部视为泄露：

必须在一台干净机器生成新凭证，不能在被攻陷主机生成新密钥。

06系统重建建议

存在 stage‑3 完整远控 shell，攻击者已经获取本机用户权限。最高安全实践：备份业务文档，重装操作系统。单纯删除 IOC 不能 100% 排除攻击者其他潜伏手段。

07CI / 流水线专项处置

01CI 机器如果在受影响时间执行过安装，CI Runner 视为被攻陷；CI 的 OIDC token 权限可能泄露；

02清除 CI 缓存的 node_modules；轮换全部 CI secrets、OIDC 角色信任条件；

03在 CI 开启脚本阻断，限制 npm 生命周期脚本执行；

04检查 CI 日志是否出现FrameworkMetrics analytics v2.3.1 is up to date特征字符串，出现代表 CI 流水线已经运行恶意载荷。

END OF FILE 01 / 04

披露时间：2026年11月12日　/　PUBLIC DISCLOSURE

■  情报来源： / SOURCE REGISTER

■  相关信息： / WHAT HAPPENED

WFX‑Phantom 是 2026‑11‑10 爆发的 GitHub Actions 密钥窃取攻击，攻击者利用被盗 GitHub Token 向仓库植入约 1500 行 shell 恶意脚本wfx。攻击存在npm postinstall 钩子传播路径：恶意package.json增加postinstall脚本，执行隐藏脚本.ci‑xxxxxx.sh，开发者本地执行npm install就会在本机运行恶意载荷，并非仅危害 CI 服务器。恶意程序会读取内存、环境变量、各类凭证文件（SSH、云密钥、AI API 密钥、kubeconfig、Vault 凭证、shell 历史等）并外泄，还会配置云平台持久化后门，即便密钥轮换后门依旧有效。

■  遭受投毒/有被投毒风险的供应商： / AFFECTED ECOSYSTEM

GitHub 是一个在线软件源代码托管服务平台，用于公开程序或软件的代码。使用Git作为版本控制软件，由开发者克里斯·汪斯崔斯（Chris Wanstrath）、P·J·海特（P. J. Hyett）和汤姆·普雷斯顿·沃纳（Thomas Preston-Werner）使用Ruby on Rails编写而成。在2018年，GitHub被微软公司收购。截至2022年6月，GitHub已经有超过5700万注册用户和1.9亿代码库（包括至少2800万开源代码库），事实上已经成为了世界上最大的代码托管网站和开源社区。截至2023年1月26日，已经有超过1亿开发人员使用GitHub。

GitHub Actions 是 GitHub 提供的一种自动化工具，用于在 GitHub 代码仓库中实现软件开发工作流程的自动化。它支持持续集成和持续部署（CI/CD），能够帮助开发者自动化构建、测试和部署代码。通过 GitHub Actions，开发者可以编写一系列的工作流程（workflows），这些工作流程由一个或多个任务（jobs）组成，每个任务又可以包含一个或多个步骤（steps）。

01风险前提

在受攻击时间窗口（2026‑11‑10 UTC 之后）拉取过被入侵仓库代码，并且在仓库目录执行过npm install / npm ci，才存在本机被感染风险；单纯git clone不执行安装命令不会触发恶意脚本执行。

02排查是否拉取过受污染代码仓库

01检查本地 git 仓库历史，确认是否拉取过包含攻击特征的提交

特征提交信息：

在本地 git 仓库执行：

02检查是否存在恶意脚本文件 在项目目录查找恶意命名模式文件：.ci‑{6位随机字符}.sh

03检查项目package.json脚本段，查看是否存在恶意postinstall钩子

手动打开package.json查看scripts.postinstall；也可命令行检索：

恶意postinstall钩子样例：

04检查是否安装受污染发布包

受污染公开包列表：

03本机系统痕迹检查（判断载荷是否已经执行）

恶意脚本执行会创建临时目录：$RUNNER_TEMP/.wfx‑<pid>/、/tmp/wfx‑scan‑<pid>/，在 Linux/macOS 本机对应/tmp/下临时目录，进程会读取/proc/*/mem内存读取密钥（Linux）。

01检查临时目录残留

检查是否存在wfx‑scan‑*、.wfx‑*目录，若存在，提示载荷曾执行。

02检查进程审计日志（Linux）：是否存在读取进程内存行为

恶意脚本会读取进程内存提取密钥：访问/proc/<pid>/mem

03检查网络连接日志

01应急隔离

01断开受影响主机对外网络（如虚拟机、开发机），阻止恶意程序继续向外发送数据；

02关闭所有终端，停止 npm、node 相关进程：

03备份系统日志、bash/zsh 历史、审计日志用于溯源，不要修改原始日志；

04不要直接继续在被感染的 shell 会话操作云控制台，内存中可能残留泄露凭证。新开一台干净机器执行凭证轮换操作。

02清理本地恶意文件

01删除恶意仓库中识别到的.ci‑xxxxxx.sh文件，删除恶意postinstall脚本；

02清除 npm 缓存，删除 node_modules，不要继续在污染 commit 版本执行任何 npm 命令：

03删除/tmp下所有 wfx 开头的临时目录

04git 操作：回滚到干净 commit，丢弃恶意提交；不要保留攻击者注入的任何 commit。

03全面轮换所有泄露凭证

01GitHub

02SSH 密钥

03AWS

04Azure

05GCP

06HashiCorp Vault

07包管理器（npm/PyPI/Composer）

08AI API 密钥（OpenAI 等）

04系统层面处置（开发主机）

01Shell 历史：将~/.bash_history、~/.zsh_history备份后清空，历史记录存在明文密钥风险；

02检查 crontab、systemd 服务，确认攻击者没有植入持久化本地后门：

03如果机器是高价值开发机，且确认恶意脚本完整执行过，最高安全等级建议：备份数据后重装操作系统。因为恶意脚本具备内存读取，无法 100% 确认是否留下其他隐蔽后门。

05上游仓库联动（仓库维护者）

01检查 GitHub 仓库的 Actions 运行记录：寻找缺失的 Workflow run 编号（攻击者执行完会删除 run 日志，run 序号出现跳号是攻击强证据）；

02关闭探针 PR：关闭标题docs: dependency audit notes来自wfx‑docs分支的探测 PR，删除wfx‑docs、chore/8位随机字符分支；

03检查 bot 账号权限：如果攻击者使用 bot 账号提交恶意 commit，收回 bot「绕过分支保护」权限；

04通知团队成员：提醒团队所有人，不要拉取、不要在受污染 commit 版本执行npm install，全员自查开发机；

05扫描 git 全部历史：检索 git 历史是否存在 IoC 特征字符串：WF_CALLBACK、WF_TG_BOTS、.ci‑*.sh；

06发布安全通告，锁定受污染包版本，避免其他开发者中招。

END OF FILE 02 / 04

披露时间：2026年11月10日　/　PUBLIC DISCLOSURE

■  情报来源： / SOURCE REGISTER

■  相关信息： / WHAT HAPPENED

SafeDep披露PyPI上的fragment-api-py软件包14.4.2版本被植入后门，该包是Telegram Fragment市场的Python客户端，为支付功能会保存用户的TON区块链钱包助记词。分析发现恶意版本实为13.0.0旧版代码篡改三个文件后冠以更高版本号发布，以保证升级时优先安装，后门代码于10月12日编写，约四周后上传。攻击者伪装成资金归集功能的函数会硬编码攻击者钱包地址，在客户端正常初始化阶段自动将用户钱包中全部泰达币和几乎全部TON代币以单笔交易转移，仅保留少量手续费。两名受害者共损失约44.8个TON，后门在上传后六小时内即首次得手，其中一名受害者未主动报案而被链上分析发现。发布渠道缺少对应标签且使用长期有效的令牌，无法确定是环境被入侵、凭据被盗还是内部人员所为，事件凸显持有用户密钥的加密工具包需防范发布链被劫持。

■  遭受投毒/有被投毒风险的供应商： / AFFECTED ECOSYSTEM

PyPI（英语：Python Package Index，简称PyPI）是Python的正式第三方（ official third-party）软体套件的软件存储库，它类似于CPAN（Perl的存储库）。一些软件包管理器例如pip，就是默认从PyPI下载软件包。此案例中，攻击者在PyPI官方仓库上传恶意包进行供应链投毒攻击。

由于国内开源镜像站均同步于PyPI官方仓库，所以该问题不仅会通过官方仓库，还可能通过各个开源镜像站影响广大用户。常用的国内镜像列表如下：

本次攻击中，fragment‑api‑py 开源项目本身成为被投毒的直接上游供应商，攻击者疑似通过窃取项目 PyPI 长期发布 Token、攻陷维护者本地主机或是内部人员途径，绕过 GitHub 代码仓库，无对应 Git 提交与 Tag 的情况下向 PyPI 发布恶意版本 14.4.2，该恶意包基于旧版 13.0.0 篡改植入 TON 钱包窃取后门；PyPI 作为公共包托管平台本身未被攻破，但会分发该恶意构件，企业内部 PyPI 镜像、CI/CD 制品仓库、Docker 镜像缓存若同步拉取并留存 14.4.2 制品，也演变为存在投毒扩散风险的中间供应商；下游使用该库的开发者、业务系统、脚本程序属于受害消费方，只要项目依赖引入该恶意版本，一旦运行并传入 TON 钱包助记词就会触发资产窃取，攻击风险可沿依赖链向下传导至开发机、测试、生产环境。

01风险前提

01Python 环境安装了版本为 14.4.2 的fragment‑api‑py包；

02业务代码实例化FragmentClient时传入了 TON 钱包助记词 seed，使用async with FragmentClient(seed=...)；或者调用execute_prepared()接口（不使用 async‑with 也会触发后门）；

03程序实际运行过该恶意版本代码（仅安装未运行代码不会触发转账）。

02检查当前安装的 fragment‑api‑py 版本

01方式 1：pip 查询包版本

02方式 2：扫描锁文件（项目依赖清单，检查是否被引入）

检查项目requirements.txt、pyproject.toml、poetry.lock、requirements-lock.txt、Pipfile.lock，确认是否锁定版本14.4.2。使用 vet 工具扫描：

03扫描 site-packages，检索后门特征 IOC

通过恶意代码字符串特征检索 Python 包安装目录，确认是否存在后门代码文件，支持多 Python 环境：

特征包括：

04校验 whl/tar.gz 安装包哈希

恶意包文件哈希 IOC：

05审计应用运行日志 & TON 链上交易记录

01应用日志

检索程序启动日志，确认是否执行过FragmentClient初始化逻辑；后门函数执行不会输出明显业务日志，日志无法完全确认是否转账；

02链上查询钱包交易记录

使用 tonviewer 查询你业务使用的 TON 钱包地址，检查交易历史：

01隔离主机并停止业务

停止相关服务、容器和定时任务，暂时禁止自动部署或自动重启；必要时先进行网络隔离。在处置完成前，不要再次运行带有真实助记词的客户端。

02保留证据

保存以下内容，便于内部调查或向平台报案：

03卸载恶意包

04清理项目依赖锁文件：

01修改requirements.txt、pyproject.toml，固定版本为安全版本（例如 14.4.1，不要使用pip install -U无约束升级，防止再次拉取恶意版本，虽然已经下架，但缓存 / 私有镜像可能留存）；

02重新生成 lock 锁文件，删除本地 pip 缓存中 14.4.2 版本包：

05核查 CI/CD 流水线、构建镜像

检查 docker 镜像、CI 缓存、私有 PyPI 镜像是否缓存 14.4.2 恶意 wheel 包，予以删除；

06安全版本重装

07处理相关密钥和凭据

原 TON 助记词无法通过“修改密码”恢复安全，应直接更换钱包。如果受影响的是构建或发布机器，还应轮换 PyPI API Token、GitHub 凭据及发布工作流中的相关密钥，并检查是否存在异常发布记录。

08验证清理结果后恢复业务

确认以下事项后再恢复服务：

恢复后持续观察应用日志和新钱包交易，不要使用真实资产进行触发测试。

END OF FILE 03 / 04

披露时间：2026年11月09日　/　PUBLIC DISCLOSURE

■  情报来源： / SOURCE REGISTER

■  相关信息： / WHAT HAPPENED

10月14日至26日间一名攻击者利用被盗的大数据平台Qubole的AWS身份凭据，通过第三方集成固有的跨账户信任关系实施大规模云入侵。企业常创建跨账户IAM角色并配置信任策略允许Qubole账户扮演，攻击者使用安全令牌服务的AssumeRole接口，假借Qubole身份进入数十家客户的AWS环境，在权限范围内开展侦察，从密钥管理服务及参数仓库窃取机密，利用TruffleHog工具验证发现的各类密钥，随后以机会主义方式下载所有可访问的S3存储桶数据，而非定向窃取，单家客户即有数百万文件被窃。整个攻击路径未突破任何边界，完全依赖客户预配置的合法信任链。AWS回应称自身服务未被入侵，行为符合设计，建议客户审查跨账户角色、移除闲置集成并施加最小权限及来源限制。

■  遭受投毒/有被投毒风险的供应商： / AFFECTED ECOSYSTEM

本次事件中遭到凭证泄露的供应商为大数据云处理平台Qubole，该攻击并非软件包投毒，属于身份凭证类供应链风险；攻击者窃取了Qubole AWS账号下两枚IAM用户凭证，利用企业客户预先配置、用于对接Qubole的AWS跨账号IAM信任关系（即便配置ExternalId防护），通过sts:AssumeRole接口批量跳转进入客户AWS云环境，大量受害企业早已停用Qubole服务，但未删除对应的IAM信任角色，遗留的信任关系成为攻击入口，只要企业AWS账号存在对Qubole AWS账号（805246085872）的跨账号信任配置，无论当前是否还在使用该厂商服务，均具备被本次攻击利用的风险，攻击者无需攻破客户侧账号，仅凭被盗的供应商身份凭证即可枚举资源、窃取密钥与S3敏感数据，形成一商失陷、多家客户受牵连的供应链危害。

01风险前提

01AWS 账号中存在 IAM 角色信任策略允许 Qubole AWS 账号 ID：805246085872 执行sts:AssumeRole；

02该角色配置了ExternalId用于 Qubole 集成（即便配置 ExternalId，攻击者拿到该值即可绕过，ExternalId 不能作为唯一防护手段）；

03该 IAM 角色具备读取 S3、Secrets Manager、SSM Parameter Store、Lambda 配置、数据库快照等敏感权限；

02检索异常 AssumeRole（角色接管）事件

在 CloudTrail 查找如下特征事件，只要命中任意一条，代表存在攻击者活动痕迹：

01userIdentity.accountId = 805246085872（Qubole 源 AWS 账号）且 sourceIP 不是 AWS 官方 IP 段，事件名AssumeRole

02主体 ID 匹配攻击者使用 IAM 用户：

03角色会话名称（sessionName）以quiam‑开头（攻击者固定标记，如quiam‑enum、quiam‑scope‑full）

04攻击相关恶意网络 IOC（CloudTrail 的sourceIPAddress）

注意：Mullvad 为公共 VPN，仅仅出现该 IP 不等于被入侵；必须同时匹配 Qubole 账号 ID/quiam 会话名才是本次攻击活动。

03检索攻击后续恶意行为

攻击者入侵角色后会执行下面 API，筛选来自可疑会话 ID 的调用：

01凭证窃取行为

02云资源探测行为

03凭证有效性校验

04清点 IAM 信任关系

遍历所有 AWS 账号 IAM 角色信任策略：查找信任策略中 Principal 包含arn:aws:iam::805246085872:root，或者允许该账号执行 sts:AssumeRole 的全部 IAM 角色。

05本地主机 / EC2 实例排查（针对恶意 ISO 镜像sso_agent.iso）

攻击者在 OVH 服务器托管恶意可引导 Linux 镜像，SHA‑256： 65f061281c9a712e9502793dc4c5035cae490b84da05f7d4223cefa65ad396e4

01阻断攻击访问路径

01移除 Qubole 的 IAM 信任关系

02吊销所有攻击者生成临时会话凭证：AWS IAM 撤销活跃会话，已经颁发的临时 STS 凭证不会自动失效，必须执行吊销。

03安全组、网络 ACL 层面阻断攻击 IOC IP（57.129.54.120等）的入站访问。

02证据保全

01冻结 CloudTrail、S3 访问日志、VPC 流日志，禁止日志过期删除；将日志导出到隔离、不可修改存储桶，用于取证；

02导出所有可疑quiam‑*会话的完整 API 调用记录，记录会话 ID、时间、源 IP、调用的 API；

03如果开启 S3 数据事件日志，导出全部GetObject记录，明确哪些 S3 对象被读取下载；

04导出 Secrets Manager、SSM Parameter Store 的访问审计日志，记录被 GetSecretValue 读取的密钥清单；

05检查是否存在sso_agent.iso恶意镜像，留存文件哈希、下载日志。

03全面轮转泄露密钥 & 凭证

01AWS 侧密钥轮换

02外部身份系统密钥

04评估数据泄露范围

01通过 CloudTrail 加密解密日志：加密 S3 对象下载会产生解密日志，可以确认哪些加密文件被窃取；默认 S3 SSE‑S3 加密没有独立解密日志，泄露文件数量会高于可审计数量；

02梳理被访问 S3 桶内容：区分 PII 个人身份信息、PCI 支付卡、PHI 健康数据、IP 知识产权；

03合规评估：如果包含受监管敏感数据，按照当地法规完成泄露评估，准备事件通报。

05深度狩猎排查横向扩散

01检查所有账号 CloudTrail，查找 Trufflehog 相关 User‑Agent，查找攻击者利用窃取密钥进行横向移动痕迹；

02审计 EC2 实例用户数据（User‑Data），攻击者会抓取此处存储的密钥；

03检查 RDS 快照、备份文件是否被下载；

04全盘检索环境中是否存在sso_agent.iso恶意镜像，排查 PXE / 远程启动日志，确认是否存在本地主机投毒；

05检查所有外部跨账号信任 IAM 角色，防止攻击者利用本次窃取的凭证开辟其他后门。

06事后加固与持续监控

01若业务必须继续使用 Qubole，修改 IAM 角色信任策略增加网络条件限制：aws:SourceIp约束为 Qubole 官方公布出口 IP，拒绝 VPN/VPS 来源；

02严格最小权限原则：Qubole 角色删除不必要权限，禁止读取全部 Secrets Manager、全部 S3 资源；

03开启全组织 CloudTrail，强制开启敏感 S3 桶 S3 数据事件日志；

04配置告警：监控异常sts:AssumeRole、外部 VPN 来源跨账号角色接管、quiam‑*会话名称；

05第三方安全工具：启用数据检测响应 DDR 能力，监控身份异常行为。

END OF FILE 04 / 04

阅读原文

跳转微信打开