GhostActionのハッカー、790のGitHubリポジトリに悪意あるセキュリティワークフローを仕込む

認証情報窃取を狙う「GhostAction」が、規模を拡大して再び活動を始めました。2026年10月9日までに、790のリポジトリへ悪意あるGitHub Actionsワークフローが挿入されています。

GitGuardianは2025年にGhostActionを初めて報告しました。当時の被害は817のリポジトリ、窃取されたシークレットは3,325件でした。

今回の攻撃も、アカウント乗っ取りという同じ手口を使っています。攻撃者はまず、侵害したメンテナーが書き込み可能なリポジトリを洗い出します。続いて、セキュリティ対策を装ったワークフローを、プルリクエストやレビューを経ずにデフォルトブランチへ直接プッシュする場合もあります。

このワークフローは、プッシュ時または手動実行で起動します。攻撃者はこれにより、GitHub Actionsで利用できるシークレットを収集する機会を得ます。

以前のペイロードは、パッケージ公開用の認証情報、クラウドの認証情報、GitHubの認証情報へのアクセスなど、リポジトリの正規ワークフローにある特定名のシークレットを狙って作り込まれていました。

10月の亜種は収集範囲を広げています。security-audit.ymlワークフローは、fetch-depth: 0でリポジトリの全履歴をチェックアウトします。そして、作業ツリーと到達可能なGit履歴から認証情報のパターンを検索します。AWSキー識別子については、前後の文脈も取得します。

このため、過去にコミットされ、のちに現在のファイルから削除された認証情報まで漏えいするおそれがあります。収集したデータは、暗号化されていないHTTPで193.32.204[.]199へ送信されます。報告されている/?c=monamiのエンドポイントも使われています。

StoreBig Data

SocketとStepSecurityは、10月8日に2回の自動インジェクションを確認しました。

1回目は、侵害されたkitaoアカウントに関連する27のリポジトリが対象でした。2回目はhenrywooに関連する318のリポジトリで、279のフォークとUberのuber/athenadriverが含まれていました。

研究者は、このキャンペーンに関連する別のインジェクション群も見つけました。その結果、OpenSourceMalwareが検証した合計は790になりました。

これらの件数は、収集期間と手法が異なります。SocketとStepSecurityの346リポジトリというスナップショットは、10月8日の2回の攻撃を指します。より広範なデータセットには、追加で検証されたリポジトリと過去の活動が含まれます。

長期間更新されていないプロジェクトや多数のフォークが含まれていました。このことから、攻撃者は活発な標的を慎重に選んだのではなく、書き込み可能なリポジトリを自動的に列挙したとみられます。

OpenSourceMalwareの研究者によると、このキャンペーンは侵害した開発者アカウントを悪用します。自動実行されるワークフローを追加し、CI/CDのシークレットを盗みます。さらに、現在のソースコードとGit履歴から認証情報を探します。

GhostActionキャンペーン

uber/athenadriverのケースでは、ワークフローがメンテナーのIDでmasterブランチへ直接プッシュされていたと、StepSecurityは報告しています。プルリクエストもレビューもありませんでした。

また、窃取リクエストが収集サーバーに到達した実行例も報告しています。

Socketもワークフローの実行成功を確認しました。ただし、公開時点で、今回の10月の攻撃に起因する悪意あるPyPIやcrates.ioのリリースは確認されていません。だからといって、漏えいした認証情報が安全だということにはなりません。

2025年のGhostActionの初期ペイロードは、GitHub Actionsで利用できるシークレットに焦点を当てていました。

新たな履歴マイニング機能により、狙える認証情報の範囲が広がりました。AWS、GitHub、GitLabのトークンやAIサービスのキーも含まれます。

これは対処の考え方を変えます。リポジトリの最新版からシークレットを削除しても、履歴からは消えません。また、悪意あるワークフローを削除しても、すでに収集された認証情報が無効になるわけではありません。

OpenSourceMalwareは、最近登録されたコードホスティング風のドメイン2つにも注意を促しています。my-gitlab[.]comとmy-github[.]comです。

後者は、報告されている収集サーバーのIPに名前解決されるため、優先度の高い指標です。GitLab風のドメインは別のインフラを指しており、GhostActionとの関連は証明されていません。

ドメイン名や登録時期から、監視する理由は十分にあります。ただし、両ドメインが同一の攻撃者のものだという証拠にはなりません。フィッシングに使われたという証拠にもなりません。

各組織は、リポジトリ、ワークフローファイル、コミット履歴を検索してください。対象は193.32.204[.]199、security-audit.yml、github_actions_security.ymlのほか、AKIA_CTX_STARTや?c=monamiといった特徴的なペイロードの痕跡です。

ワークフローの実行履歴とアカウントの監査ログも確認してください。見るべき点は、不審なコミット、複数リポジトリへの短時間の連続プッシュ、手動でのワークフロー起動、ランナーから収集サーバーへの外部通信です。

悪意あるワークフローや実行成功の形跡が見つかった場合は、影響を受けたブランチとフォークからすべて削除します。侵害されたアカウントのトークンとセッションを失効させ、漏えいしたすべてのシークレットをローテーションしてください。

対象には、ワークフローで指定されていた認証情報だけでなく、リポジトリ履歴のどこかに現れた可能性のある認証情報も含まれます。これらの認証情報に紐づくパッケージのリリース、クラウドでの操作、その他のサービスに不正利用がないかも確認してください。

最大の教訓は、信頼できるメンテナーのIDから行われた変更でも、そのワークフロー変更が安全とは限らないことです。

.github/workflows/配下の変更にレビューを必須にすることが有効です。ランナーの外向き通信を承認済みの宛先に制限し、シークレットを必要なジョブだけに限定することも役立ちます。こうした対策で、侵害されたアカウントがより広範なサプライチェーンインシデントに発展する前に、攻撃の連鎖を断ち切れる可能性があります。

MTTRを21分短縮し、影響が出る前にサイバー脅威を阻止。ANYRUNのサンドボックスをSOCに導入。

Cybersecuritynews subscription

翻訳元: https://gbhackers.com/ghostaction-campaign/

本記事は gbhackers.com の記事を翻訳・要約したものです。