Gheist攻击活动:利用窃取的GitHub令牌植入泄密工作流

Gheist 攻击利用窃取的 GitHub 令牌植入恶意 Actions 工作流,借平台自身能力隐蔽外泄数据。
Gheist 攻击活动揭示了一种新型供应链威胁:攻击者首先窃取 GitHub 令牌获取仓库写权限,随后在仓库中植入恶意的 GitHub Actions 工作流文件,利用 GitHub 托管运行器执行数据收集与外传。由于恶意工作流寄生在合法 CI 流程中,流量来自 GitHub IP 段,且触发方式可绑定 push、pull_request 或定时任务,传统边界防护和日志分析极难识别。防护重点应转向令牌生命周期治理(最小权限、短有效期、细粒度令牌)和工作流文件变更审批与定期审计。该活动在公开社区讨论热度低,安全团队需主动排查可疑配置。
GitHub 作为全球最大的代码托管平台,其 Actions 自动化流水线已成为 CI/CD 的标准组件。但这套便利的机制正被攻击者武器化。近日曝光的「Gheist」攻击活动,展示了攻击者如何利用窃取的 GitHub 令牌,将仓库变成秘密泄露的管道。
攻击链的核心:从令牌盗窃到工作流植入
Gheist 活动的第一步是获取有效的 GitHub 令牌(personal access token 或 OAuth token)。这类凭证一旦泄露,攻击者便获得了对目标仓库的写权限。与传统的直接窃取代码不同,Gheist 的意图更加隐蔽——它在仓库中植入恶意的 GitHub Actions 工作流文件,借助平台自身的自动化能力完成数据外泄。
这种手法的精妙之处在于「寄生性」:恶意工作流以正常 CI 脚本的面目存在,运行在 GitHub 提供的基础设施上,流量来自 GitHub 的 IP 段,传统的网络边界防护很难将其与合法构建活动区分开。
GitHub 令牌主要分为个人访问令牌(PAT)和 OAuth 令牌。PAT 由用户手动创建,用于替代密码进行 Git 操作或调用 API,其权限通过 scope 精细控制(如 repo、workflow、admin:org 等)。OAuth 令牌则通过 OAuth 应用授权流程获取,代表用户或组织对第三方应用的临时授权。两类令牌均以 Bearer 形式在 HTTP 头部传输,一旦泄露,攻击者可在有效期内直接调用 GitHub API 或克隆/推送代码。尤其危险的是,具有 workflow scope 的令牌允许修改 Actions 工作流文件,这正是 Gheist 攻击的关键前提。
秘密泄露工作流如何运作
工作流被触发后,会执行一系列收集动作,将仓库中的敏感信息——环境变量、访问密钥、配置文件、甚至仓库历史中的硬编码凭证——打包并回传到攻击者控制的端点。由于工作流在 GitHub 的托管运行器上执行,攻击者无需自建 C2 基础设施,也无需在目标网络中维持持久化据点。
更值得警惕的是触发机制的设计。攻击者可以将工作流绑定到 push、pull_request 或定时任务上,这意味着一次看似普通的代码提交,就可能悄然启动数据外泄流程。受害者在日常开发中几乎不会察觉异常。
GitHub Actions 工作流由仓库根目录下 .github/workflows/ 中的 YAML 文件定义,每个文件包含触发器(on)、作业(jobs)和步骤(steps)。步骤可以执行 shell 命令、调用预构建的 Action 或运行自定义脚本。工作流在 GitHub 托管的运行器(Ubuntu、Windows 或 macOS 虚拟机)上执行,这些运行器预装了常见工具链,并能访问仓库 secrets(通过 ${{ secrets.NAME }} 引用)。攻击者正是利用这些特性,在合法工作流中插入数据收集与外传步骤,而无需直接接触目标网络。
为什么这类攻击难以发现
Gheist 活动的隐蔽性来自三个层面。其一,工作流文件本身是明文 YAML,但它们以正常的自动化脚本形式存在,审查时容易被当作基础设施代码而忽略。其二,数据外泄混入 GitHub Actions 的正常出站流量中,日志分析工具若不专门针对工作流行为建模,几乎无法识别。其三,令牌被盗后,攻击者的操作与合法开发者的操作在权限层面完全一致,缺乏行为异常信号。
这也解释了为什么该类攻击在社区讨论中被视为供应链安全的新盲区——防护重心长期放在依赖包和构建产物上,而对「构建流程本身被篡改」的检测能力相对薄弱。
GitHub Actions 的审计日志(Audit Log)记录了组织内成员执行的关键操作,如工作流文件的创建、修改、删除,以及令牌的生成和使用。但默认情况下,审计日志仅对组织所有者可见,且保留期有限(GitHub Enterprise Cloud 为 180 天)。此外,工作流运行日志(Run Logs)会记录每个步骤的输出,但若攻击者将外传数据编码或混淆,仍难以直接识别。因此,单纯依赖平台日志不足以发现 Gheist 类攻击,需结合工作流文件的静态分析和出站流量的行为建模。
防护建议:从令牌治理到工作流审计
针对此类威胁,防御应从凭证生命周期入手。缩短 GitHub 令牌的有效期、按最小权限原则分配 scope、强制启用细粒度令牌,都能显著降低凭证泄露后的爆炸半径。同时,建议为敏感仓库启用工作流文件的变更审批,任何新增或修改的 Actions 配置都应经过人工复核。
审计层面,可对仓库中所有 workflow 文件做定期扫描,重点关注异常的外连地址、可疑的 secrets 读取模式,以及未经 CI 负责人审批的定时任务。GitHub 本身提供的审计日志也应纳入监控,尤其是令牌使用来源 IP 的突变。
细粒度令牌(Fine-grained PAT)是 GitHub 于 2022 年推出的改进型凭证,允许将权限精确限定到特定仓库、特定操作(如仅读取内容、仅写入 Actions),并支持设置更短的有效期(最长 1 年,可自定义)。相比经典 PAT 的粗粒度 scope(如 repo 涵盖所有仓库读写),细粒度令牌能大幅降低泄露后的影响范围。同时,GitHub 建议对组织启用 SAML SSO 和强制令牌过期策略,并为高敏感仓库启用「要求工作流文件变更需审批」的分支保护规则(需 GitHub Enterprise)。
供应链安全的下一战场
Gheist 活动提醒我们,CI/CD 流水线已经成为攻击面的一部分。当攻击者能够借用平台自身的执行能力时,传统「信任内部、防御外部」的模型随之失效。对开发团队而言,把工作流文件当作生产代码来治理,可能比想象中更紧迫。
据 Hacker News 社区讨论,该活动目前在公开渠道的讨论热度有限(19 分、零评论),这意味着相关情报尚未广泛传播,安全团队应主动排查自身仓库中的可疑工作流配置。
相关推荐

腾讯WorkBuddy实测:AI Agent如何碾压传统聊天助手
腾讯WorkBuddy实测对比豆包:AI Agent如何直接操作电脑完成PPT转PDF、文件归档等任务。从安装门槛、国内生态、价格、插件市场四方面分析WorkBuddy优势,并给出AI Agent选择建议。

奥特曼称个人PC囤RAM“相当糟糕”,数据中心利用率更高
OpenAI CEO萨姆·奥特曼在Reddit引发热议的表态中称,个人PC配备大量RAM是“相当糟糕”的资源利用方式,数据中心凭借集中调度能实现更高内存利用率。本文解析这一观点背后的技术逻辑与行业信号。

付费5美元教AI说话:一场关于AI训练本质的社会实验
一位开发者搭建了运行真实语言模型的「假AI实验室」,用户支付5美元即可教模型一句话。这个社会实验揭示了AI训练中数据成本、用户参与和话语权的深层关系。