悪意あるデータセットが起点、クラスタ内を横方向に移動

Hugging Faceによれば、侵入は同社ならではの弱点であるデータ処理パイプラインから始まりました。悪意あるデータセットが、データセット処理における2つのコード実行経路（リモートコード実行型のデータセットローダーと、データセット設定ファイル内のテンプレートインジェクション）を悪用し、処理ワーカー上でコードを実行しました。そこから攻撃者はノードレベルのアクセス権限へとエスカレーションし、クラウド・クラスタの認証情報を収集した上で、週末にかけて複数の内部クラスタへ横方向に移動したといいます（出典）。

公開されているユーザー向けのモデル・データセット・Spacesへの改ざんの証拠は見つかっておらず、コンテナイメージや公開パッケージを含むソフトウェアサプライチェーンもクリーンであることを確認済みとしています。パートナー・顧客データへの影響についてはまだ調査中で、影響が確認された場合は直接連絡するとしています。

「エージェント型攻撃者」シナリオが現実に

今回の攻撃キャンペーンで最も注目すべき点は、その実行主体です。

攻撃は自律型エージェントフレームワーク（エージェント型のセキュリティ研究用ハーネスを基盤にしていると見られるが、使用されたLLMは依然として不明）によって実行され、使い捨てのサンドボックス群にまたがる数千件もの個別アクションを実行し、自己移動型のコマンド&コントロール（C2）を公開サービス上にステージングしていた。これは業界がかねて予測してきた「エージェント型攻撃者」のシナリオと一致する。

Hugging Faceはこの侵入を、AI支援型の異常検知パイプライン（LLMベースのトリアージでセキュリティテレメトリを日常のノイズと実際のシグナルに分離する仕組み）によって最初に検知したといいます。

フォレンジック分析でも「AI対AI」——17,000件超のイベントを数時間で分析

侵入を検知した後、Hugging Faceは1万7000件を超える攻撃者アクションの記録全体をLLM駆動の分析エージェントで解析し、タイムラインの再構築・侵害指標（IoC）の抽出・関連する認証情報のマッピング・実害と陽動活動の切り分けを行いました。この手法により、通常なら数日かかる作業を数時間で終えることができたといいます（出典）。

興味深いのは、このフォレンジック分析で商用APIのフロンティアモデルが使えなかったという「非対称性の問題」です。分析には大量の実際の攻撃コマンド・エクスプロイトペイロード・C2アーティファクトを送信する必要がありますが、これらのリクエストはプロバイダーの安全ガードレールによってブロックされてしまいました。

ガードレールはインシデント対応者と攻撃者を区別できないためです。結局、自社インフラ上でオープンウェイトモデルのGLM 5.2を使って分析を行うことになり、副次的な利点として攻撃者データや関連する認証情報が自社環境の外に一切出ないという結果も得られました（出典）。

対応内容とコミュニティへの推奨事項

Hugging Faceが実施した対応は次の通りです。

  • データセットのコード実行経路（初期侵入に使われた脆弱性）の修正
  • 影響を受けたクラスタ全体からの攻撃者の足場の排除、侵害されたノードの再構築
  • 影響を受けた認証情報・トークンの失効と再発行、予防的な認証情報の広範なローテーション
  • クラスタへの追加のガードレールと、より厳格なアドミッション制御の導入
  • 高深刻度のシグナルが曜日を問わず数分以内に対応者へエスカレーションされるよう検知・アラート体制を改善

外部のサイバーセキュリティフォレンジック専門家と協力して調査・セキュリティポリシーの見直しを進めており、法執行機関にも報告済みとのことです。コミュニティに対しては、アクセストークンのローテーションと自分のアカウントの直近のアクティビティの確認を推奨しています（出典）。

これはかなり衝撃的な事例です。攻撃側が自律エージェントで数千件のアクションを自動実行する一方、防御側も商用APIのガードレールに阻まれてオープンウェイトモデルでの自前分析に頼らざるを得なかったという構図は、AIセキュリティの最前線が今どこまで来ているかを如実に示していると感じます。フォレンジック分析にすら「オープンモデルでないと自由に使えない」という制約があるというのは、正直あまり知られていなかった盲点だと思います。