自2026年9月15日以来，Wiz Research一直在追踪Gheist：一个利用被妥协的GitHub令牌进行大规模滥用的新活动。该攻击将一个名为sync-check的工作流程提交到每个每个令牌可以访问的代码库。该工作流程试图将代码库的秘密打印到其自己的工作流程日志中。然后，该工具通过GitHub API下载日志，并在几秒钟后删除运行。该工具的API请求携带用户代理gheist，赋予该活动其名称。我们已经从850多个被妥协的账户中恢复了超过13,500个植入的分支，这些分支涉及个人项目到企业组织的私有代码库。最近的GitHub控制已在公共代码库中阻止了利用，但我们已观察到在私有代码库和GitHub企业环境中成功的利用和后续活动。截至10月24日：攻击仍在进行并演变，大约⅔的涉事账户在GitHub上已不再可用。这可能表示响应活动，因为我们已将此活动报告给GitHub。攻击如何运作 对于每个代码库，该工具创建一个名为ci-sync-加六个随机字符的分支，然后提交.github/workflows/sync-check.yml，提交信息为ci: sync config。该提交是未签名的，署名为令牌的所有者。推送事件触发工作流程：有三个细节使其有效：GitHub仅在秘密值逐字出现时才在日志中掩盖秘密值。一个base32编码的秘密不匹配，因此会完整打印。虽然permissions: {} 限制了作业的GITHUB_TOKEN，攻击者并不需要它，但它并未限制秘密上下文。当一个代码库具有部署环境时，该工具会在作业矩阵中列出它们，环境: ${{ matrix.environment }}，因此环境范围的秘密，通常是生产凭证，也会被打印。由于秘密通过GitHub自己的API泄露，因此没有攻击者域或出站连接可以阻止。在企业组织中，我们看到该工具在几分钟内循环通过多个用户和自动化账户的令牌，在植入工作流程之前克隆私有代码库，数小时后，来自同一组织的云凭证用于枚举AWS Secrets Manager。有效负载如何演变 观察到该攻击的两种变体并行运行。它们可以通过分支名称进行区分。工具A使用十六进制后缀和原始有效负载。工具B使用base36后缀，添加了timeout-minutes: 6和环境矩阵，在9月28日首次运行的几个小时内，并根据每个代码库修改所选有效负载。10月19日，工具B在转储之间添加了echo X | base32 -w 120，这会输出LAFA====作为分隔符，可能用于操作员的日志解析器。数小时后，它推送了一个第二个作业sync-host，使用runs-on: self-hosted，显然仅限于具有注册自托管运行者的代码库。它写入三个辅助文件（.gdmp_pat，.gdmp_patg，.gdmp_sweep），并在每个阶段下记录每个阶段，使用===== gdmp-pivot: <stage> =====头：主机详细信息和crontab。对主目录、工作区和系统路径中31种令牌格式（包括AI提供者如Anthropic、Hugging Face、Groq和NVIDIA的密钥）、私钥、.env文件、Terraform状态和shell历史的递归搜索。每个进程的环境，从 /proc/*/environ。通过Docker套接字，挂载带有主机根文件系统的容器，以便在主机上重复搜索。AWS实例角色凭证，加上GCP和Azure元数据。GitHub Actions和GitLab runner凭证文件。Kubernetes服务账户令牌。然而，这个作业存在bug：它寻找错误的运行者密钥文件，它的URL凭证正则表达式损坏，并且它没有收集GCP或Azure令牌。GitHub的审批保持和私有代码库 自2026年7月28日起，GitHub在公共代码库中对潜在恶意工作流程运行进行保持，直到合作者批准它们。我们检查的每个公共Gheist运行，包括所有变体（包括自托管作业），都处于action_required状态。该控制有效，恶意有效负载从未运行。不幸的是，该保持不适用于私有代码库或GitHub Enterprise Server。在那里，GitHub审计日志显示，在ci-sync-*分支上运行完成后被gheist用户代理删除。CloudTrail显示组织自己的工作流程在这些分支上运行并假设AWS角色，这证明在未经批准的情况下执行了Actions。对于防御者来说，最后一个信号在没有任何GitHub日志的情况下找到Gheist，如下所示。其他账户上的活动 此活动正在利用被妥协的GitHub访问。相同的账户被其他行为者和活动使用，这表明被妥协的凭证如何在威胁行为者生态系统中迁移。我们观察到与以下活动的重叠：诱饵代码库（恶意软件分发）。