GhostAction 供应链攻击卷土重来：伪装“安全审计”的恶意工作流正在批量搬空 GitHub 仓库的云凭证

原创 威胁情报中心 2026-10-10 15:09 北京

两个被入侵的维护者账户、约 40 分钟内 340+ 仓库被批量注入；本轮新增对完整 Git 历史的凭证扫描，目标直指 AWS 云凭证与 AI 服务 API 密钥。

事件速览：2026 年 10 月 8 日，供应链攻击活动 GhostAction 的新一轮爆发被多家安全厂商捕获。攻击者利用两个被入侵的开源维护者账户，在总计约 40 分钟的两个自动化时间窗口内，向超过 340 个 GitHub 仓库批量提交了伪装成“安全审计”的恶意 GitHub Actions 工作流。与以往不同的是，本轮载荷在窃取 CI/CD Secrets 的基础上，新增了对工作目录和完整 Git 历史的凭证扫描能力，目标直指 AWS 云凭证与 AI 服务 API 密钥。截至 10 月 9 日，已有超过 500 个 GitHub 账户被确认提交了该恶意工作流，波及仓库数以万计。

01 从两条诡异的提交记录说起

10 月 8 日 13:20 UTC，开源游戏引擎 pyxel（GitHub 星标约 1.8 万）的作者 Takashi Kitao 的账户，开始向自己名下的仓库推送一个名为 security-audit.yml 的工作流文件，提交信息是再普通不过的 “Add security audit workflow”。约 24 分钟内，27 个仓库被植入该文件，仅 pyxel 仓库就收到三次提交。

8 小时后，21:10 UTC，另一位维护者 Henry Wu（henrywoo）的账户开始了更大规模的扫荡：16 分钟内，318 个仓库（39 个源仓库 + 279 个 fork）被注入同一载荷。这一窗口的最后两秒，攻击落在了 Uber 旗下的 uber/athenadriver 仓库上——henrywoo 是该项目的原作者，保留着对组织仓库的写权限。没有 PR，没有评审，恶意文件以维护者本人的身份直接推入 master，提交未签名，审计日志中没有任何异常痕迹。

这些提交呈现出鲜明的自动化特征：跨越十年未更新的“僵尸仓库”与活跃项目被无差别处理，所有载荷文件除渲染进去的 Secret 名称外逐字节一致。Socket 在 10 月 9 日的更新中确认，自 10 月 7 日以来已有超过 500 个 GitHub 账户向数以万计的仓库提交了该恶意工作流，其中包括通过被入侵贡献者触及的组织仓库。截至发稿，恶意工作流仍存在于多个受影响仓库的默认分支上，且已成功运行。

02 GhostAction：一场从未停止的供应链攻击

GhostAction 并非新面孔。2025 年 9 月，GitGuardian 首次披露了这一针对 GitHub 的大规模凭证窃取活动：攻击者入侵 FastUUID 项目维护者账户作为起点，最终波及 327 名用户、817 个仓库，窃取 3,325 个密钥，涵盖 PyPI、npm、DockerHub、GitHub、Cloudflare 令牌及 AWS 密钥、数据库凭证等，多家公司的整套 SDK 产品线同时沦陷。PyPI 事后作废了所有被盗令牌，并确认攻击者未利用其发布恶意包。

一年多过去，这条攻击链几乎没有变过，始终是四步：

真正变化的是基础设施与载荷能力。2025 年 9 月，外泄端点是 bold-dhawan.45-139-104-115.plesk.page 等域名（指向 45.139.104.115）；而自 2026 年 9 月初起，端点切换为裸 IP 193.32.204.199（80 端口，及 3000 端口的 /api/workflow/receive?inj=<id> 接口），不再产生 DNS 查询，基于域名的防御手段被整体绕过。2025 年版旧载荷至今仍在与新载荷并行投递。

03 解剖“安全审计”：一个工作流里的两套窃取引擎

以 pyxel 仓库 commit 97670a55 中的完整载荷为样本，这个名为 “Security Audit” 的工作流触发条件为 workflow_dispatch + 无任何分支/路径过滤的 push，整个任务只做一件事——收集凭证并外泄。其内部由两代技术拼接而成。

3.1 继承自 2025 年的部分：点名窃取 Actions Secrets

载荷中的这段逻辑是 GhostAction 的标志性手法：

投递前侦察的成果在这里兑现：pyxel 的载荷中精确写死了四个 Secret 名称——crates.io 发布令牌、GitHub 个人访问令牌、PyPI 用户名与密码，恰好覆盖该项目双注册中心的全部发布凭证。这类凭证的价值在于，攻击者可以冒用一个用户已信任的项目的名义发布恶意版本，把单点账户失陷放大为下游供应链事件。若侦察未发现任何 Secret，模板会优雅降级为空判断 [ -n "" ]（athenadriver、pyllama、chatllama 等仓库即是如此），工作流照常运行。

3.2 本轮新增的部分：把工作树和 Git 历史翻个底朝天

从 fetch-depth: 0 开始的一切都是新能力，也是本轮升级的核心：

五个变量分工明确：grepped 扫工作树，gl 缓存全量历史的补丁文本，hist 在历史中重跑同一套正则，ctx/hctx 则对 AWS 密钥做专门的上下文捕获。

fetch-depth: 0 是整个设计的支点：它让 Runner 拿到仓库的每一个分支和标签，git log -p --all 随之可以读取完整历史的补丁文本——哪怕某个密钥 2019 年提交后第二天就被删除，哪怕它只存在于一条早已废弃的分支或旧标签上，也会被原样收割。这正是维护者最可能误以为“已经清理干净”的那类凭证。

3.3 AWS 密钥配对：从“孤儿 ID”到可用凭证

两组上下文捕获是新增部分中最具针对性的设计。AKIA/ASIA 只是密钥标识符，本身无法通过认证；真正的 40 位 Secret Access Key 在实践中往往就躺在它上下一两行——.env 文件、AWS credentials 文件、Terraform 变量文件或 CI 配置块里。载荷对每个 AWS Access Key ID 抓取前后两行上下文，并用 AKIA_CTX_START / AKIA_CTX_END 分隔符包裹，以便接收端单独解析，从而重建完整可用的 AWS 密钥对，而非收回来一堆无法使用的孤立 ID。

3.4 十三类凭证正则：AI 密钥成为一等目标

工作树与历史两个扫描通道共用以下 13 个正则模式：

模式清单与受害仓库画像高度吻合：henrywoo 名下星标最高的 pyllama（约 2,800 星）与 chatllama（约 1,200 星）均为机器学习项目，其贡献者与 fork 者恰恰最常持有 AWS 密钥与各家 AI 服务密钥。

3.5 带内遥测与单次请求外泄

两类窃取结果拼接进同一个变量，一次 HTTP POST 全部带走。更有意思的是 URL 中的查询标记：模板渲染了具名 Secret 的仓库 POST 到 /?c=monami，仅有历史扫描结果的 POST 到 /?c=new——攻击者无需打开请求体，仅凭 URL 就能把回传数据按“含金量”分拣。同时，无论是否有所收获，每次运行都会回传仓库标识符，攻击者因此持有一份“可触达执行环境”的实时地图。所有流量走明文 HTTP 直连裸 IP，产生不了任何可供域名安全设备检查的 DNS 记录。

04 运行取证：三个仓库，三种结局

uber/athenadriver —— 外泄确认成功

StepSecurity 提取了恶意运行的日志（Run ID 37846728441，由注入提交后 3 秒触发）。日志显示 checkout 拉取了仓库全部 13 个分支和 20 个标签——包括 henry.wu/* 开发分支和一个名为 s3-bucket-compromised-2023-03 的分支，全部进入历史扫描范围。三段 grep 执行后，日志中出现一行 OK：工作流脚本本身不打印任何输出，这是 C2 服务器的 HTTP 响应体被 curl -s 回显进了日志。21:26:04Z，运行开始后仅 4 秒，POST 已送达并被确认接收。同一份日志还暴露了两个细节：AWS Secret Key 正则因使用了 POSIX ERE 不支持的非捕获组 (?:...) 而部分失配（日志中的 grep: warning 即源于此），但所有字面量前缀模式工作正常；本次运行的 GITHUB_TOKEN 权限仅为 contents: read，工作流自身无法推送或发布——权限提升完全依赖偷到的凭证，这正是 pyxel 发布令牌的价值所在。

kitao/pyxel —— 攻击者回来“手动按了按钮”

pyxel 的恶意工作流共运行 5 次且全部成功：3 次由攻击者推送触发，2 次为手动 workflow_dispatch（13:36:32Z 与 13:42:35Z），均在每次工作流更新后立即从被入侵的 kitao 会话发起。自动化扫荡之外，这是明确的“人在回路”操作——攻击者手动重跑外泄工作流以验证或重复收集。

typecho-fans/plugins —— 一个配置项拦断了攻击链

该仓库自 9 月 5 日起就被 xxyangyoulin 账户注入了旧版载荷。10 月 7 日，攻击者先后推送一个零文件变更的空提交（“Update Github Actions Security workflow”）和一次三行 README 修改（“Trigger security scan”），目的纯粹是重新触发工作流。但两次运行全部卡在 action_required 状态——该仓库启用了工作流运行审批，外泄未能执行。一个设置，击穿了整条攻击链。

05 影响面研判

• 爆炸半径不取决于个人项目，而取决于凭证能写到哪。 henrywoo 因原作者身份保有 Uber 组织仓库写权限，一次个人账户失陷直接把载荷送进了财富 500 强代码库。

• pyxel 是暴露面最高的目标。 约 1.8 万星、966 个 fork，Rust + Python 双语言，经 PyPI 与 crates.io 双渠道分发；载荷中点名的四个 Secret 正是两个注册中心的发布凭证加一个 GitHub PAT。
• 279 个被注入的 fork 构成次生风险。 若启用 Actions，后续推送即可触发凭证收割；下游 fork 在新建或与上游同步时也会继承恶意工作流，而私有 fork 和下游镜像最为危险——真正被提交进仓库的凭证恰恰集中在私有仓库里。
• 发布凭证的暴露窗口仍然敞开。 截至发稿，未观测到利用被盗凭证在 PyPI 或 crates.io 发布恶意版本：pyxel 最后版本为 8 月 12 日的 v2.9.9（失陷前），其 crates.io 发布停留在 2019 年，athenadriver 最后发布于 2024 年 3 月。但只要相关令牌未轮换，风险就持续存在——这与 2025 年波次的情况如出一辙，当时同样“只偷不用”，而“尚未滥用”从来不是凭证安全的证据。
• 规模仍在扩大。 截至 10 月 9 日，GitHub 代码搜索显示默认分支上仍存活的恶意工作流覆盖 378 个仓库，其中 182 个带有 AKIA_CTX_START 历史扫描标记，88 个带有 ?c=monami 标记（即具名 Secret 已被模板化并外泄）；该数字不含 fork，henrywoo 名下 279 个被感染 fork 需额外计入。

06 自查与应急处置建议

快速自查

在 GitHub 代码搜索中检查以下特征（登录后 Code 标签页）：

零命中是好迹象；任何命中即意味着存在被感染仓库或携带恶意工作流的 fork。若仓库自 2026 年 8 月 31 日以来出现过名为 “Security Audit”（security-audit.yml）或 “Github Actions Security”（github_actions_security.yml）的工作流，应按已确认失陷处置：所有已配置的 Actions Secret 与 Git 历史中存在的任何凭证都已被提供给攻击者，且工作流每次运行都会回连——哪怕一无所获。

若载荷中渲染了具名 Secret（Set A 暴露）

1. 轮换文件中点名的每一个 Secret；对个人访问令牌应吊销而非轮换；
2. 审查 PyPI / crates.io / npm 等注册中心在暴露窗口内的发布历史，比对发布产物与自有构建输出；
3. 检查注入工作流的运行记录，任何已完成的运行均视为对应 Secret 已被外泄。

若载荷扫描了仓库（Set B 暴露）

1. 用 git log -p --all 扫描完整历史而非仅当前 HEAD，包含不可达对象与废弃分支/标签；
2. 凡是在历史中出现过的凭证，无论当前树中是否存在，一律按已暴露处理并轮换，覆盖上述全部 13 类；
3. 对历史中发现过 AWS 密钥的，回溯审查暴露窗口及之后的 CloudTrail 日志，排查新增 IAM 用户、访问密钥与异常区域活动。

两种情况通用

1. 从所有分支（不止默认分支）删除恶意工作流并回滚提交，包括组织仓库；
2. 将被入侵账户视为完全失陷：吊销全部会话、PAT、OAuth 授权与 SSH 密钥，启用防钓鱼多因素认证并重新登记；
3. 审查组织审计日志中的推送窗口，按账户权限枚举而非按预期排查所有可写仓库的工作流新增记录；
4. 在出口日志（含自托管 Runner 网段）中排查与 193.32.204.199 的连接并实施阻断；
5. 开启 GitHub Secret Scanning 的推送保护，要求外部协作者的工作流运行需审批——本轮事件中，审批门是唯一被观测到直接阻断外泄的控制项；
6. fork 所有者：在任何来自受影响命名空间的 fork 上启用 Actions 前，先检查是否存在 .github/workflows/security-audit.yml；
7. 清理完成前不要发布任何新版本：若配置了发布类 Secret，应假定攻击者已能以你的身份发包。

07 技术附录

7.1 MITRE ATT&CK 技术映射

7.2 失陷指标（IoC）

网络指标

主机 / 代码指标

审计日志排查要点：维护者身份直接向默认分支提交工作流文件（绕过 PR）、新建“audit”工作流上的 workflow_dispatch 事件、数分钟内跨多仓库的密集未签名提交。

08 参考链接

1. Socket — New GhostAction Wave Hits Hundreds of Repos, Expanding Beyond CI/CD Secrets to Cloud Credentials
https://socket.dev/blog/ghostaction-cloud-credentials

2. StepSecurity — GhostAction Returns: Malicious “Security Audit” Workflows Now Mine Credentials from Entire Git Histories
https://stepsecurity.io/blog/ghostaction-returns

3. GitGuardian — The GhostAction Campaign: 3,325 Secrets Stolen Through Compromised GitHub Workflows（2025 年 9 月首次披露）
https://blog.gitguardian.com/ghostaction-campaign-3-325-secrets-stolen/

4. StepSecurity — GhostAction Campaign: Over 3,000 Secrets Stolen Through Malicious GitHub Workflows（2025 年 9 月）
https://www.stepsecurity.io/blog/ghostaction-campaign-over-3-000-secrets-stolen-through-malicious-github-workflows

5. The Hacker News — Credential-Stealing GitHub Actions Workflows Planted in Tens of Thousands of Repositories
https://thehackernews.com/2026/10/credential-stealing-github-actions.html

6. BleepingComputer — Hackers steal 3,325 secrets in GhostAction GitHub supply chain attack
https://www.bleepingcomputer.com/news/security/hackers-steal-3-325-secrets-in-ghostaction-github-supply-chain-attack/

7. FreeBuf — 泛滥的供应链攻击又一例：GhostAction 行动窃取凭证信息事件解析（2025 年 9 月）
https://www.freebuf.com/news/448136.html

阅读原文

跳转微信打开