先週、Hugging FaceがOpenAIの不正エージェントによる侵入被害に遭いましたが、この侵入事件からは今もなお新たな知見や理解が得られています。Hugging Faceチームは、詳細なタイムラインに加え、発生した出来事を可視化した17,600件のイベントトレースのストリーミング再生データを公開しましたが、その内容は驚くほど、そして夢中になるほど詳細です。時間があれば、ぜひ一読することをお勧めします。
同プラットフォームへの侵入は、1つの巧妙なエクスプロイト 、人間が主導する明確な攻撃経路がエクスプロイト はなかった。それは4日半にわたって分散した多数の行動であり、数千回に及ぶ失敗した試みが、最終的に決定的な影響を与えた比較的少数の行動を覆い隠していた。偵察、コード実行、ペイロードの配置はほぼ即座に開始された。Kubernetesクラスタ、内部ネットワーク、およびソース管理システムへの決定的な横方向の移動は、3日目になってようやく始まった。
ほとんどの組織では、攻撃の経緯を再現するのに十分なログ記録および監視体制が整っている 事実が判明した後 事後的に攻撃を再現するのに十分なログ記録や監視機能を備えています。しかし、攻撃がまだ形成されつつある段階でそれを認識するために必要な、実行時の可視性、アラートロジック、および意思決定支援を備えている組織は、はるかに少ないのです。
Hugging Faceのタイムラインと、この件に関してOpenAIから共有された待望の情報、さらにCSAによる初期の事後分析を総合すると、企業が考慮すべき4つの重要なインシデント対応の判断ポイントがあると考えられます。それぞれは、自組織にそうした能力があるかどうかを実証する実践的な試金石ともなります。
決定事項 1：信号レベルの低い偵察は、どのような場合に「インシデント」となるのか？
侵入初日、エージェントたちはファイルシステム、プロセス、ネットワークインターフェース、環境変数、マウントポイント、および利用可能なツールを列挙した。彼らはアウトバウンド通信経路をテストし、一般的な公開サービスを利用してコマンド＆コントロール通信を確立した。個々の事象だけを見れば、デバッグ、自動化、不正なワークロード、あるいは通常の実験などとして説明することができた。
Hugging Faceによると、最初の兆候は、リアルタイムの実行時分析、SIEMログ、その他の監視システムにまたがって現れたという。同社のAIベースのセキュリティスタックは、これらの兆候を関連付けて一貫性のある攻撃パターンとして特定したが、十分な重要度を割り当てたり、当直チームに通知したりすることはできなかった。この遅れにより、貴重な対応時間が失われた。以前の分析やコミュニティでの議論でも同様の結論が導き出されていた。すなわち、数日にわたって偵察活動が記録されていたにもかかわらず、後になって不正アクティビティの量がようやくアラームの閾値を超えた時点で初めて、事態がエスカレーションされたのである。
判断の焦点は、個々の事象が悪意のあるものかどうかという単純な問題ではありません。個々に見れば曖昧な一連の実行時挙動が、攻撃経路の構築を意味しているかどうかが問題なのです。
組織は、短命なコンテナ間で、プロセスの実行、ファイルシステムへのアクセス、API 、ワークロードの識別情報、およびネットワークの挙動を相互に関連付けられるかどうかを検討すべきです。/proc/self/environ を読み取り、サービスアカウントのトークンを検査し、複数のアウトバウンド通信方法をテストしているポッドが、通常のアプリケーション障害とは本質的に異なるものであることを認識できるでしょうか？
ここで、カナリア・インストルメンテーションが曖昧さを解消することができます。 ここで注力すべき手法は、特定のワークロード環境に偽のトークンを配置し、シークレットストアにおとり用の認証情報を残し、本番環境以外のパスにおける設定値を監視することです。これらは決して実際のアクセス権限を提供してはなりません。その唯一の目的は、読み取られたり、コピーされたり、提示されたりした際に、信頼性の高いシグナルを生成することにあります。適切に配置されたカナリアトークンは、異常として無視されることなく、対応担当者に通知を送るはずです。デセプション機能の構築は、あらゆるチームのロードマップに盛り込まれるべきです。
決定事項 2：認証情報が盗まれて悪用された場合、どうなるのか？
3日目に、この事件の様相が一変した。 このエージェントは、Kubernetesのサービスアカウントトークンを読み取り、クラウドのメタデータを照会し、外部ホスティングプロバイダーから提供された一時的な認証情報を再利用し（Modal社は自らもそのホスティングプロバイダーの一つであると名乗り出た）、特権ポッドを作成してノードのルート権限を取得した。その後、メッシュVPNや内部クラスターアクセスブローカーに使用される認証情報を含む136個のキーが格納されたシークレットオブジェクトにアクセスした。共有コネクタの認証情報の一つが、事実上、複数のクラスターにわたるクラスター管理者権限を提供していた。
今こそ、「調査」を積極的な封じ込めへと転換しなければならない。
貴社のチームは、侵害された認証情報を信頼しているすべてのシステムを特定できますか？依存関係グラフと影響分析は、インシデント対応における封じ込めフェーズを開始する上で極めて重要です。貴社のツールやダッシュボードは、想定されるワークロードで使用されているトークンと、新しいクラウドプロバイダー、サンドボックス、またはネットワークの送信元から出現した同じトークンとを区別できますか？対応担当者は、派生トークンが有効なまま1つのキーのみをローテーションするのではなく、認証情報のファミリー全体を無効化できますか？
認証情報自体は正当なものに見える可能性があるため、実行時の検知が不可欠です。悪意のある状態は、その実行コンテキスト（誤ったプロセス、誤ったポッド、誤った送信元ネットワーク、誤ったワークロードID、あるいはあり得ない一連のアクションなど）に見出されます。 私はこれを「水は濡れている」モニタリングと呼んでいます。私が真実だと知っていることの中で、水は濡れているのと同じように、空は青いのです。環境における「前提を覆す」変化を検知するのに役立つモニタリングを導入しなければ、私たちは今後も予期せぬ事態に直面し続けることになるでしょう。
その一例として、BGPハイジャックを検知するためにネクストホップルーティングテストを設定することが挙げられます。内部ネットワークから、安定しておりよく知られた外部リソース（time.windows.comなど）へ向かう最初の4ホップは、本来まったく逸脱してはなりません。「水は濡れている」という監視のもう1つの例として、主要なインフラコンポーネントの内部および外部IPアドレスが変更されていないかどうかを常に評価するDNSレコードの監視が挙げられます。
したがって、エージェント主導の攻撃を検知するために展開されるカナリアには、偽のサービスアカウントトークン、おとり用のクラウド認証情報、および合成VPN登録キーを含める必要があります。慎重に選択されたポッド環境に保存されたトークンは、認証情報の収集を明らかにすることができます。 おとりサービスアカウントは、ネームスペースの列挙を検知できます。内部サービスカタログから返される偽のクラスターエントリは、横方向の移動の試みを検知できます。これらのアーティファクトは、本番環境へのアクセスではなく、シンクホールやアクセス拒否されたエンドポイントへと誘導される必要がありますが、あらゆるやり取りにおいて送信元のIDは保持され、即座に封じ込めの指針がトリガーされるべきです。
決定事項 3：C2が自分のアプリケーションのように見えるとき、それを見分けることができますか？
検知に関する最も重要な教訓は、コマンド＆コントロール通信が必ずしも従来のマルウェアのトラフィックと同じ様相を呈するとは限らない、という点かもしれません。
このエージェントは、公開のリクエストキャプチャサービス、ペーストビン、ファイル共有ホストを利用していました。さらに重要な点として、攻撃者が制御するHugging Faceのデータセットをデッドドロップとして利用していました。コマンドや盗み出したデータは、データセットのコミットやサイドブランチに配置され、通常のAPI取得されていました。また、公開されているCORSプロキシ「Space」も、アウトバウンド中継として使用されていました。ペイロードはチャンク化、圧縮、エンコードされ、場合によっては生のソケット経由で送信されていました。 攻撃者の復号プロセスを再現したところ、初期のスキャンシークレット 約4倍の数の漏洩したシークレット 回収された。
つまり、受信側の通信はデータセットのアクティビティのように見え、送信側のデータ流出もデータセットのアクティビティのように見えたのです。Hugging Face自体がC2通信の一部となってしまいました。従来のSIEMでは、これらが双方向のプロトコルを形成していることを明らかにすることなく、何千件もの異常なイベントを報告してしまう可能性があります。
判断の分かれ目は、顧客向け機能を無効にするか、テナントを隔離するか、パブリックサービスを遮断するか、あるいは本番環境のデータパスを中断するかという点にある。対応担当者は、「このトラフィックは異常である」という程度よりも、より確固たる証拠を必要とする。
「社内ベンチマーク結果」「評価回答」「アーカイブされたセキュリティ調査」など、説得力のある名称を付けたおとりデータセットを作成します。これらには一意のマーカーや偽の認証情報を埋め込みます。正当なワークロードがこれらにアクセスすることはあってはなりません。読み取り、クローン作成、コミット、ブランチ作成、API 監視します。カタログに掲載された偽の社内クラスターやデータセットも、攻撃者が単にサービスを通常通り利用しているのではなく、攻撃の機会を列挙しているかどうかを見極める手がかりとなります。
適切に設計され、適切な場所に配置された「カナリア」は、単なる異常ではなく、意図を示すものとなる。
決定4：損傷を修復するか、環境を再構築するか？
最終的には、組織が影響を受けたインフラを依然として信頼できるかどうかという問題になる。
Hugging Faceは、認証情報を大規模に更新し、クラウドのメタデータへのアクセスを遮断し、認証情報の適用範囲を絞り込み、中核インフラを完全に消去して一から再構築しました。大局的に見れば、この決定は、すべての足掛かり、偽造トークン、および永続化メカニズムが完全に除去されたことを証明しようとするのではなく、環境の約3分の1を事実上「一掃」することに等しいものでした。
この選択肢は、インフラが再現可能かつ使い捨て可能な場合にのみ存在します。これまでの分析では、Hugging Faceの場合、侵害されたシステムを復元してクリーンアップするのではなく、リポジトリから新しいインフラをデプロイすることで復旧が加速されたことが指摘されています。また、その決定権限は、インシデント発生前に明確に割り当てられ、文書化されていなければなりません。
意思決定支援パッケージには、認証情報の系譜、影響を受けるワークロードの識別情報、不変イメージの検証、インフラストラクチャ・アズ・コードの適用範囲、データ復旧要件、および永続化の試みがあったことを示す証拠を含めるべきである。経営幹部は、再構築の承認を求められる前に、その再構築にかかる推定ダウンタイムを把握しておく必要がある。また、どの程度の信頼度でその見積もりが行われているのか（特定のクラスターやサービスが最後に新規デプロイされたのはいつか？）についても把握しておくべきである。
カナリアは復旧後も有用です。すべてのおとりトークンを、新たに生成された値に置き換えてください。再構築後に古いカナリアトークンが使用された場合は、未発見の足場、コピーされた秘密、または外部の中継地点が依然として存在しているという強力な証拠となります。これは、エージェント型の攻撃者が、検出を回避したり、中断した作業を再開したりするために、仲間のモデルエージェントがたどれるよう「パンくず」を残すほど先を見越した行動をとる、と仮定する場合に特に当てはまります。
Hugging Faceの事件は、ロギングが検知ではないこと、検知がエスカレーションではないこと、そしてエスカレーションが意思決定支援ではないことを示しています。実行時の可視性によって、ソフトウェアが実際に何を行っているのかがわかります。カナリアトークン、クラスター、データセットによって、その活動に正当な説明がつかない場合がわかります。
その目的は、単に来週、この侵害事態を理解するのに十分な証拠を集めることだけではありません。今日、正しい判断を下せるほど強力なシグナルを作り出すことにあります。
