Gheist：CI/CD ワークフローを隠れ蓑にする脅威｜ブログ(ほぼこもセキュリティニュース)

クラウドセキュリティ企業 Wiz Research は、盗まれた GitHub トークン（Personal Access Token 等）を悪用し、アクセス可能なリポジトリから機密情報を組織的に窃取するサイバー攻撃キャンペーン「Gheist」に関する調査レポートを公開しました。

攻撃者は、インフォスティーラー型マルウェアや過去のサプライチェーン侵害を通じて流出した開発者の GitHub トークンを入手し、自動化ツールを用いてアクセス可能な全リポジトリ（プライベートリポジトリを含む）に対して悪意ある GitHub Actions ワークフローを注入します。
ワークフロー経由で環境変数やシークレット情報を収集し、さらに GitHub Actions の OIDC（OpenID Connect）連携を悪用して接続先のクラウド環境（AWS 等）の一時認証情報を取得・窃取することで、組織のインフラ全体への不正侵入を狙っています。
特徴的な部分をみてみましょう。

C2（コマンド＆コントロール）サーバを使用しないデータ持ち出し
通常のマルウェアのように攻撃者管理の外部サーバや C2 ドメインへ通信を送るのではなく、GitHub 自体の公式 API を経由してデータを取得します。
ワークフローの実行ログに出力されたデータを API 経由でダウンロードするため、外向き通信（Egress）の遮断や不審な外部ドメインのブロックといった従来の境界防御では検知・阻止が困難です。
Base32 エンコードによるシークレットのマスキング回避
GitHub Actions には、登録されたシークレット情報がログに出力される際に自動で伏せ字（***）にするマスキング機能が備わっています。
攻撃者は環境変数やシークレット全体を Base32 形式でエンコードした上でログに出力させることで、このマスキング機構を完全に回避して平文を復元可能にしています。
実行証跡の即時自動削除
API 経由でログをダウンロードした後、攻撃者は数秒以内に該当のワークフロー実行ログおよび作成したブランチを自動で削除します。
これにより、開発者や管理者がダッシュボードを目視で確認しても異変に気付きにくく、事後調査の難易度を高めています。
プライベートリポジトリにおける防御の隙を悪用
GitHub のワークフロー保護や承認プロセスは主に外部フォークからの PR を想定しており、盗難トークンを用いて直接リポジトリ内にブランチを作成・実行される場合、特にプライベートリポジトリでは制限をすり抜けて即座に実行されてしまう隙を悪用しています。
攻撃者はこの仕様を突き、組織内部の重要な本番環境シークレット（Environment-scoped secrets）を含むプライベートリポジトリを重点的に狙っています。
セルフホストランナー（Self-hosted Runner）への侵害拡大
キャンペーンの進展に伴い、ランナー環境自体を狙うペイロードが追加されました。
共有されたセルフホストランナー上で動作する Docker ソケットを悪用してホストマシン内のファイルシステムを探索し、ローカルに保管されたトークンや認証鍵の奪取を試みます。
一貫した攻撃インジケーター（IoC）
自動化スクリプトには共通の特徴が見られ、特定フォーマットのブランチ名（ci-sync-[0-9a-z]{6}）、ワークフローファイル名（.github/workflows/sync-check.yml）、および特定の User-Agent（gheist）が観測されています。

「Gheist」キャンペーンは、「正規のトークン」と「正規の CI/CD プラットフォーム（GitHub Actions）」を悪用することで、外部インフラを介さずに機密情報を吸い上げる高度なサプライチェーン／アイデンティティ攻撃です。
開発者の単一トークンの漏洩が、リポジトリのシークレットを経由して AWS 等のクラウドアカウント全体へ侵害が波及するリスク（Blast Radius の拡大）を浮き彫りにしました。

一方で、本キャンペーンの多くは OIDC のブランチ制限やプラットフォーム側の検知によって空振りに終わっており、基本に忠実なアクセス制御がいかに攻撃の阻止・失敗（Stumbles）に直結するかを証明した事例でもあります。

組織における対抗策として、以下の対応が推奨されます。

インジケーターの監視・検知
GitHub 監査ログ（User-Agent: gheist）やクラウド監査ログ（CloudTrail 等で ci-sync-* ブランチからの OIDC ロール引受がないか）の確認。
トークン運用と OIDC の最小権限化
長期有効なパーソナルアクセストークン（PAT）を廃止し、きめ細かなアクセス権（Fine-grained PAT）や GitHub Apps を採用すること。
また、OIDC の信頼ポリシーは保護ブランチや特定の環境のみに限定し、攻撃者が作成した任意ブランチからのロール引き受けを拒否する設定とすること。
侵害時の迅速なローテーション
万一関連するブランチや不審なワークフローの痕跡が発見された場合は、影響を受けるトークンを直ちに失効させ、リポジトリ・組織・環境レベルの全シークレットを即座に再発行（ローテーション）すること。

システムを使う側が『ワークフローの安全性までが自分の仕事だ』と意識し続けるのは、重要性を骨身に染みて理解していないと、正直なかなかハードルが高いと感じます。

Gheist: Attempted Scaled Abuse of Stolen GitHub Tokens Stumbles
https://www.wiz.io/blog/gheist-attempted-scaled-abuse-of-stolen-github-tokens-stumbles