GhostActionキャンペーン、GitHubアカウントを乗っ取りCI/CDおよびAIの秘密情報を窃取

2026年10月、GhostActionとして知られる組織的なサイバー攻撃キャンペーンにより、約1,900件のGitHubアカウントが侵害されました。攻撃者はこのアクセス権限を利用し、30,000以上のリポジトリに悪意あるGitHub Actionsワークフローを注入し、クラウドアクセスキーやAIプロバイダーのAPIトークンなどの機密認証情報を外部へ持ち出そうとしました。

何が起きたか

この攻撃は2026年10月8日と9日に激化し、脅威アクターは約3,000人のユーザーおよび組織のリポジトリを標的にしました。このピーク期間中、悪意あるワークフローは3,174件の異なるシークレット（秘密情報）の抽出を試みました。このキャンペーンを追跡したGitGuardianによると、攻撃者はペイロードを複数の段階で展開しました。まず、以前に被害を受けた約160件のアカウントに対して初期プッシュが行われ、その20分後に28,000件の新規リポジトリに影響を与える大規模な展開が続きました。

tj-actions/changed-filesの侵害など、共有アクションの脆弱性を悪用した従来のサプライチェーン攻撃とは異なり、GhostActionは盗まれた開発者の認証情報に依存していました。StepSecurityによる10月9日の分析では、攻撃者がおそらくクレデンシャルダンプから取得したパーソナルアクセストークンを活用した可能性が高いと示唆されていますが、これらの認証情報の当初の出所は確認されていません。有効な書き込み権限を持っていたため、攻撃者はリポジトリのワークフローを直接変更し、GitHub Actionsプラットフォーム自体の脆弱性を利用する必要はありませんでした。

悪意あるファイルはsecurity-audit.ymlやgithub_actions_security.ymlといった無害な名前で偽装されていました。これらの偽ジョブは正当なビルドプロセスで使用されているシークレットを参照しており、即座に疑念を抱かれることなくバックグラウンドで認証情報を収集しながら実行されることを可能にしていました。GitHubの承認制御により多くのワークフローがブロックされましたが、攻撃者は適応し、一部のものは2025年9月から稼働していたものも含め、過去の攻撃からの92件の古いワークフローを再利用しました。

仕組み

この攻撃の中核的なメカニズムには、標準的なチェックアウトアクションをアグレッシブな履歴取得設定付きで実行するYAMLワークフローファイルの注入が含まれていました。具体的には、ワークフローはパラメータfetch-depth: 0とともにactions/checkout@v4を使用していました。この構成は、ランナーに対し最新のコミットだけでなく、完全なGit履歴をダウンロードするように指示します。完全な履歴にアクセスすることで、悪意あるスクリプトは現在の作業ツリーだけでなく、ハードコードされたシークレットを探すために過去のコミットもスキャンできました。

スキャナーはAWSキー、GitHubおよびGitLabのパーソナルアクセストークン、GoogleおよびFirebaseキー、Anthropic、OpenAI、OpenRouterなどのAIプロバイダーのAPIトークンを含む広範な認証情報を検索しました。マルウェアの後続のイテレーションでは、周囲のコード行を捕捉することで抽出ロジックが改善され、ファイル構造内で分離されていた場合でも、AWSキーIDと対応するシークレットアクセスキーをペアリングできるようになりました。

収集された認証情報は、IPアドレス193.32.204.199にある攻撃者管理サーバーへHTTP経由で送信されました。この方法により、攻撃者は数ヶ月前または数年前に現在のコードベースから削除されたものの、Git履歴に残存しているキーを取得できました。データ流出のプロセスは静かで、GitHub Actionsの正当な実行環境を活用して通常のCI/CDトラフィックに紛れ込んでいました。

主要な詳細

• この攻撃を促進するために約1,900件のGitHubアカウントが侵害されました。
• 悪意あるワークフローは、3,000人のユーザーおよび組織にまたがる30,000以上のリポジトリに注入されました。
• 攻撃者はクラウドキーやAIプロバイダーのAPIトークンを含む3,174件のシークレットを標的にしました。
• ワークフローはfetch-depth: 0を使用して、以前に削除された認証情報を検出するために完全なGit履歴をスキャンしました。
• 流出したデータはHTTP経由でIPアドレス193.32.204.199へ送信されました。
• 以前のフェーズで影響を受けたリポジトリのうち、10月5日までにクリーンアップされていたのはわずか16%でした。

なぜ重要なのか

この事案は、現代の開発セキュリティにおける重大な盲点、すなわちGit履歴内のシークレットの永続性を浮き彫りにしています。多くのチームは、現在のブランチからハードコードされたキーを削除すればリスクが解消されると考えています。しかし、Gitは設計上不変であるため、明示的にパージされない限り、それらのシークレットは履歴に残り続けます。GhostActionキャンペーンは、攻撃者がこのギャップを積極的に悪用し、標準的なCI/CDツールを使って開発者が忘れていた古い認証情報を掘り起こしていることを実証しています。

エンジニアリングリーダーやDevOpsチームにとって、GitHubのネイティブ承認制御への依存は不十分です。GitHubは多くの悪意ある実行をブロックしましたが、攻撃者が古いワークフローを再利用し、有効な認証情報を使用できたため、一部のデータ流出は依然として発生しました。最初の検出から数ヶ月経過しても、以前影響を受けたリポジトリのわずか16%しかクリーンアップされていなかったという事実は、エコシステム全体におけるインシデント対応と修復努力の著しい遅延を示唆しています。

さらに、AIプロバイダーのキーを狙ったことは、攻撃者の優先事項の変化を示しています。企業が製品により多くのAIサービスを統合するにつれて、OpenAIやAnthropicなどのプロバイダーのAPIトークンは高価値な標的となっています。これらのキーが侵害されると、不正使用による金銭的損失だけでなく、キーが独自モデルやこれらのサービスによって処理される顧客データへのアクセスを許可する場合、潜在的なデータ漏洩にもつながります。

対策

• GitHub監査ログとパーソナルアクセストークンのアクティビティを監査し、最近.github/workflows/を変更したアカウントがないか特定してください。
• GitHub Actionsの実行履歴を確認し、予期せず実行されたジョブや、必要のないシークレットにアクセスしたジョブを検出してください。
• 悪意あるワークフローがすでに削除されている場合でも、侵害されたアカウントの認証情報を直ちに失効させてください。
• 露出した可能性のあるすべてのクラウドキー、デプロイメント認証情報、レジストリートークン、AIプロバイダーのAPIキーをローテーション（更新）してください。
• 深い履歴検査用に設計されたツールを使用し、現在のヘッドだけでなく、完全なGit履歴内のハードコードされたシークレットをスキャンしてください。
• ワークフロー変更に対する厳格な承認要件を実装し、CI/CDで使用されるパーソナルアクセストークンのスコープを制限してください。