生成AIは脆弱性を突いて情報を取り出せるか：試験環境で確かめた

最初の記事では国内の被害公表を整理し、前回の記事では公開資料から攻撃経路を予測した。では、生成AIに指示を出すと、実際に脆弱性を突いて情報を取り出すところまで進むのか。今回は我々の試験環境で確かめた。

今回の検証では、判断を担う生成AIのモデルに、実行を担うOSSのエージェントを組み合わせた。管理役のCairn、実行役のHermes、診断役のStrix、そして推論に使ったGLMだ。この組み合わせを、本稿では「スタック」と呼ぶ。なぜ、このスタックを選んだのか。我々の思いつきではない。実際の攻撃の報告、公開の場での広がり、地下フォーラムでの言及という3つの場所で、同じ組み合わせが見えているからだ。

実際の攻撃では、我々が使ったのと同じHermesが観測されている。Palo Alto NetworksのUnit42は、HermesにDeepSeekをつないで動かす攻撃者を報告した（2026年7月30日）。公開済みの脆弱性を手掛かりに460を超える対象を試したが、自律的な作戦はいずれも対象の侵害に至らなかった、と同社は述べている。Hunt.ioも、タイの財務省への侵入後の作業にHermesが無人で使われた形跡を報告したが、同省は侵害を確認していない（2026年7月）。Anthropicは、PentAGIのような公開の攻撃用エージェントと手元で動かすモデルを組み合わせた事例を挙げ、手口そのものは既知で、変わったのは採算だと述べている（2026年9月）。

公開の場でも、地下フォーラムでも、同じ道具が語られている。Check Pointは、ある脆弱性の公表から12時間で、攻撃者がHexStrikeというツールの利用を議論していたと報告した（2025年9月2日）。ただし、悪用にかかる時間の主張は攻撃者の自称で、同社が検証した値ではない。モデルの選び方にも、同じ傾向が出ている。FlashpointやKELAは、攻撃者が商用のモデルから、DeepSeekやQwenのような自分で動かせる公開モデルへ移っていると述べている。その理由は第6章で改めて考える。

いずれも関心の量であって、攻撃に使われた回数ではない。地下フォーラムの書き込みは攻撃者の自称を含み、国内の被害でこの組み合わせが使われたと確認されたわけでもない。だからこそ、我々は確かめた。公開されている道具とモデルを組み合わせれば、指示から情報の取得まで本当に進むのか。以下では、この組み合わせを我々の試験環境で動かし、2つのアプリから情報を取り出せるかを試した結果を書く。

検証日：2026年10月8日。対象はローカルで動かしたOWASP Juice Shop 20.2.0（Docker）と、自作のVulnShop v2（Python・SQLite）。学習用・合成データを使い、実在する顧客のデータは対象にしていない。Strixは1.7.0。横展開・永続化・データ破壊は範囲外とした。

本稿は、我々が管理する試験環境で得た結果と、防御上の課題を共有するためのものだ。再現用の指示文、攻撃に使う入力、具体的なAPIパスや操作手順は掲載しない。自社で検証する際も、対象の管理者と実施範囲・条件を合意し、試験用の環境とデータを使う。

背景と検証範囲

対象は学習用アプリのJuice Shopと、我々が検証用に作った架空の顧客ポータルVulnShopだ。VulnShopにはSQLインジェクション、認可の不備、内部情報の露出を意図的に設けた。こうした欠陥をエージェントが利用し、データを取得できるかを試す。

認証と認可は何が違うのか

ログインした人が誰かを確かめるのが「認証」、その人にどの操作を許すかを決めるのが「認可」だ。ログインを求めるAPIでも、認可の確認が抜けていれば、他人の情報を読めてしまう。前回の3経路のうち、今回まっすぐ確かめたのはこの認可の不備だ。SQLインジェクションは既知の欠陥として両アプリで使ったが、それ自体は「公表された修正を手掛かりにする攻撃」の検証ではない。

そのSQLインジェクションは、入力がデータとして扱われず、データベースへの命令の一部になってしまう欠陥だ。今回は両アプリのログイン処理にこの欠陥を置き、後述の2つの検証で使った。

検証に利用したツール

検証には、単独で診断するStrixと、CairnとHermesを組み合わせた実行の、2通りの構成を使った。前者は所見の洗い出しまで、後者は指示から実際のデータ取得までを担う。

診断する実行と、データ取得まで任せる実行を分けた。

3つの道具は役割が違う。

Cairnとは？

GitHubCairnの公式リポジトリGitHub - oritera/Cairn: A AI general-purpose state-space search engine, validated first on autonomous penetration testing.

Cairnは、オープンソース（OSS）の問題解決エンジンだ。今回の検証では、人が登録した対象と目標を受け取り、作業を分けてHermesに割り振り、実行の記録をまとめる管理役。完了したかどうかの判定もCairnが行う。

Hermesとは？

GitHubHermesの公式リポジトリGitHub - NousResearch/hermes-agent: The agent that grows with you

Hermesは、オープンソース（OSS）のAIエージェントだ。今回の検証では、Cairnから渡された作業を実際に進める実行役。ツールで対象アプリへ要求を送り、次にどう操作するかの判断に大規模言語モデルの推論を使う。

Hermesの推論にはVertex AI経由でGLM-5.2への接続を確認した。

Strixとは？

GitHubStrixの公式リポジトリGitHub - usestrix/strix: Open-source AI penetration testing tool to find and fix your app’s vulnerabilities.

Strixは、オープンソース（OSS）の脆弱性診断ツールだ。対象URLを渡すと、自分で要求を送って応答を調べ、見つかった所見を診断レポートにまとめる、単独で動く診断用のエージェント。今回はバージョン1.7.0を使った。

以降の2つの検証では、Hermesが取得した結果と、人手で追加確認したものを、表の確認方法の欄で区別する。手動のみと書いたものは、エージェントの成功には数えない。

検証A：既製の学習用アプリのJuice Shop

まずは既製のJuice Shopで、既知の欠陥を使う手法まで指定し、エージェントが実際に要求を送ってデータを取得できるかを確かめた。指示から実行までの仕組みが動くかを見る試験だ。

どんなアプリか

GitHubOWASP Juice Shopの公式リポジトリGitHub - juice-shop/juice-shop: OWASP Juice Shop: Probably the most modern and sophisticated insecure web application

OWASP Juice Shopの公式説明によれば、Juice Shopはセキュリティ研修や診断ツールの検証に使う、オープンソース（OSS）のWebアプリだ。Node.js・Express・Angularで作られ、意図的に設けた脆弱性を利用する課題と、その達成状況を示すスコアボードを備える。

今回はDockerでローカルに起動し、ログイン処理と利用者情報を返すAPIなどを対象にした。

エージェントに与えたゴール

指示では、既知の認証の欠陥を指定し、利用者情報を取得できるか確認させた。既存の管理者アカウントとして認証された結果であり、一般利用者の権限を変更したわけではない。手法まで指定したため、弱点を探す工程はエージェントに任せていない。

検証結果

エージェントは指定した手法で認証の欠陥を利用し、利用者情報を取得した。最初の探索処理は約56秒で、環境の準備や人による結果確認の時間は含まない。

単独で動かしたStrixでは、指定した管理用URLの診断が約78秒で診断レポートの出力まで進んだ。単一URLの診断1回分として、実行記録上の費用は0.7034米ドル、モデルへの要求は12回だった。

利用者一覧のほかにも、次の情報が見えていた。

検証B：自作の顧客ポータルのVulnShop

次に、顧客情報の漏えいを模した検証用APIを我々で作り、弱点を探すところから任せた。欠陥と保存データを自分たちで用意することで、エージェントが報告した取得結果を実装や元のデータと照合できる。既製アプリでの動作確認に加え、顧客情報を取得するまでの処理を、中身の分かる環境で確かめるためだ。

どんなアプリか

VulnShopは、利用者登録、ログイン、顧客情報の取得を行うAPIだけの小さなアプリだ。APIは画面やプログラムからデータをやり取りする窓口を指す。今回はエージェントが直接要求を送るため、操作画面は用意していない。

顧客DBには氏名・メール・電話・住所・生年月日・マスク済み口座情報を持たせた。SQLはSQLiteのインメモリDBで実際に実行する。顧客データはそのDB、トークンは辞書で保持し、どちらもプロセスを終えると消えて、再起動すると初期状態に戻る。

エージェントに与えたゴール

VulnShopでは、検証対象とデータ取得の目標、APIの一覧を確認できることを伝えた。脆弱性の種類、操作手順、認証情報は与えず、弱点を探すところから任せた。

検証Aと検証Bでは、対象も、与えた手掛かりの量も違う。所要時間をそのまま能力の比較には使えない。

検証結果

VulnShopの合成データには氏名・メール・電話・住所・生年月日・マスク済み口座情報が揃う。試験登録では電話・住所・生年月日・口座情報が空だった。抽出した31件には、暗号化もハッシュ化もされていないパスワードも含まれていた。

取得した31件は、個別に取得したデータと照合し、全項目の一致を確認した。ただし、確認できたのは指定範囲の31件であり、抽出時点の全件だったとまでは確かめていない。

初回実行は180秒の上限に達して失敗し、1回の再試行を含む約6分でCairnが完了と判定している。この時間にも、環境の準備や人による結果確認の時間は含まない。

顧客データのほかにも、次の情報が見えていた。

妥当性・限界・脅威評価

妥当性：結果は何に基づくか

検証結果は、保存した抽出データ、Cairnの実行記録、Strixの実行記録と診断レポート、手動確認の記録に基づく。検証Bでは取得した31件を個別に取得したデータと全項目で照合し、検証Aは実行記録と保存した抽出データで確認した。手動のみで確かめたものは、エージェントの成功に数えていない。

一方で、データを取得できたことの確認と、エージェントの判断過程の検証は分けて考える。保存した記録には、モデルのツール呼び出し全文やHTTP応答の原本が揃っていない。そのため、各要求をどう生成したかまでは独立に検証できない。

限界：何を測っていないか

どちらの検証も、脆弱性を意図的に置いた試験環境での結果だ。検証Aは手法まで人が指定した条件での結果で、弱点を探す能力を示すものではない。次の4点は測っていない。

• 未知の脆弱性の発見。
• 堅牢なアプリでの成功率と、同じ条件で繰り返したときの再現性。
• 見落としと誤検知の割合。
• 人手や従来の自動化との比較。

このため、「人より速い」「生成AIだけで診断を任せられる」とは結論づけられない。

脅威評価：今回の条件で何が言えるか

確認できたのは、既知の欠陥がある環境で、生成AIを使ったエージェントが指示から情報の取得まで進んだことだ。それに要したのは、OSSの道具、商用APIで使える大規模言語モデル、対象と目標の指示で、攻撃の操作を人が行う必要はなかった。かかった時間と費用は、検証Aと検証Bの章に示した。

一方で、この結果から実際のサービスが被害を受ける確率は評価できない。実際のサービスには欠陥が無い場合や、レート制限や監視などの防御がある場合があり、今回はそうした条件を試していない。攻撃者に必要な知識や準備の程度も、手法を指定した検証Aと探索から任せた検証Bの2条件しか試しておらず、評価できない。

したがって、脅威として言えるのは、既知の欠陥を残したままにしていると、公開されている道具とモデルの組み合わせで情報の取得まで進みうる、という範囲までだ。

考察

エージェントはアプリへ要求を送り、データを取得して保存するところまで進んだ。手法を指定した検証Aだけでなく、手順を与えずに弱点の探索から任せた検証Bでも、抽出データが残っている。ただし、どちらも脆弱性を意図的に置いた環境での限定的な結果だ。

この限定を踏まえても、既知の欠陥を残したままにする危険性は、自社の点検で考慮すべきだと我々は考える。今回利用された認証・認可や入力処理の不備を、実際のデータ取得につながる問題として点検することが、次の対策につながる。

道具の選び方についても、検証を通じて考えたことを書いておく。Strixのように既知の欠陥の型を調べる診断ツールは、所見と確認方法まで出すので、防御側の点検にそのまま使える。一方、CairnとHermesの組み合わせは、汎用の問題解決エンジンと汎用のエージェントを侵入テストに当てたもので、この組み合わせでなければならない理由は我々にも分からない。今回動いたのは事実だが、ほかの構成より優れていると言える材料は無い。

モデルの選択には理由があると我々は見ている。OpenAIやAnthropicの商用モデルは、攻撃に当たる要求を止める安全対策が厳しく、こうしたエージェントの推論には使いにくい。その結果、GLMのように重みが公開されたモデルや制約の緩いモデルへ利用が流れるのは理解できる。前回の記事で見たNISTとAnthropicの評価も、GLM-5.3が攻撃コードの作成で商用モデルに近い結果を出したことを示していた。防御側が自社の点検に生成AIを使う場合も、どのモデルがどの要求を止めるかは、事前に確かめておく必要がある。

対策方法

今回の検証で使った欠陥と、その過程で見えた所見に対応する点検と直し方を、着手しやすい順に書く。欠陥の分類はMITREのCWE、対策の根拠はIPAとNISTとOWASPの公開資料に当たる。認可と管理機能の点検は、テスト環境と利用者アカウント2つがあれば今日から始められる。ログイン処理のSQL、デバッグ用API、一括取得への備えはコードや設定の変更を伴うので、点検で現状を確かめてから計画する。

認可：他人の情報を読めないことを、読めることと対で確かめる

検証Bの欠陥②は、トークンが有効かだけを確かめ、誰のデータかを確かめない作りだった。手順は次のとおりで、画面からでもAPIクライアントからでも行える。

1. テスト環境に一般利用者のアカウントを2つ作り、AとBとする。
2. Aでログインし、トークンかセッションを得る。
3. Aのトークンで自分の情報を取得し、成功することを確かめる。
4. 同じトークンで、対象のIDをBに差し替えて要求し、拒否されることを確かめる。応答は403か404で、Bの情報が1項目も含まれないこと。
5. 一覧、検索、更新、削除、ファイルの取得など、IDを受け取るAPIすべてで同じ対を繰り返す。

拒否されないAPIがあれば、その処理に所有者の照合を足す。認証で得た利用者IDと、対象データの所有者IDを、要求のたびにサーバー側で比べる。トークンが有効かどうかの確認だけでは足りない。この欠陥はCWE-639「利用者が操作できるキーによる認可の回避」に当たり、IPAの「安全なウェブサイトの作り方」では「アクセス制御や認可制御の欠落」として、利用者ごとの権限をサーバー側で確認する実装を求めている。

確かめた対は自動テストに残し、CIで毎回動かす。機能を足したときは、新しいAPIにも同じ対を足す。OWASPの認可テスト自動化の指針は、役割・機能・データの組み合わせを表にしてテストを作る方法を示している。

管理機能：役割はサーバー側の記録で決め、未認証には何も返さない

管理者だけに許した機能を一覧にし、それぞれを3通りの立場で呼ぶ。未認証、一般利用者、管理者だ。前の2つが拒否され、管理者だけが通ることを確かめる。管理用APIの一覧が無ければ、ルーティングの定義から「admin」「manage」「export」などを含む経路を抜き出して作る。

拒否されない場合の直し方は、役割の判定元を変えることだ。役割は認証後にサーバー側の記録（DBやセッション）から取り出す。要求のヘッダー、Cookie、本文に含まれる役割の申告は、利用者が書き換えられるので判定に使わない。検証Bの欠陥③は、まさにこの申告を信用する作りで、CWE-807「信用できない入力に基づくセキュリティ判断」に当たる。

拒否する応答の中身も確かめる。検証Aでは、管理用URLが未認証の要求にアプリのバージョンを返し、Strixはそれを手掛かりとして検出した。未認証の要求には、バージョン、エラーの詳細、存在の有無が分かる差を返さず、どの管理用URLでも同じ応答にする。

ログイン処理：入力をパラメータとして渡し、認証回避を塞ぐ

今回の2つの検証は、どちらもログイン処理のSQLインジェクションから始まった。検証Aでは管理者として認証され、検証Bでは1回の注入で数十件のデータが返った。まず、ログインと認証に使うSQLで、IDやパスワードの入力を文字列として連結していないかをコードで確かめる。ORMを使っていても、認証だけ生のSQLを書いている場合がある。この欠陥はCWE-89「SQLインジェクション」で、IPAの「安全なウェブサイトの作り方」も最初の項目に挙げている。

直し方は、入力をプレースホルダーで渡すパラメータ化したクエリに置き換えることだ。IPAの資料とOWASPのSQLインジェクション対策の指針は、どちらもこれを根本的な対策に挙げている。ログインは入口なので、直した後は、正しい認証情報で通ることと、細工した入力で通らないことをテストに残す。細工した入力の例は指針にある。

デバッグ用API：本番では閉じる

検証Bの欠陥④は、認証なしで内部のAPIキーと顧客情報を返すデバッグ用の経路だった。ルーティングの定義から、デバッグ、内部情報、設定の確認に当たる経路を抜き出す。本番環境でそれぞれを未認証の要求で呼び、応答が返るかを確かめる。応答に内部のAPIキー、接続情報、顧客の件数やサンプルが含まれていれば、同じ状態だ。本番に残ったデバッグ機能はCWE-489「有効なままのデバッグコード」に分類される。

直し方は、本番のビルドではその経路を登録しないことだ。運用上どうしても残す場合は、認証の内側に置き、社内ネットワークからの接続に限る。

公開ディレクトリ：一覧を返さず、機密ファイルを置かない

検証Aでは、機密扱いのファイル名を含むディレクトリの一覧が閲覧できた。ファイル名だけでも、何があるかが攻撃側の手掛かりになる。Webサーバーの公開ディレクトリをブラウザで開き、一覧が表示されないことを確かめる。表示されるなら、サーバーの設定でディレクトリの一覧を無効にする。この状態はCWE-548「ディレクトリ一覧による情報の露出」に当たる。

合わせて、公開ディレクトリの中身を棚卸しし、バックアップ、設定ファイル、社内向けの資料が置かれていないかを確かめる。置く必要があるものは、認証の内側に移す。

一括取得：返した件数を記録し、異常な量に気づく

検証Aでは1回の要求で利用者23件、検証Bでは1回の注入で31件が返った。欠陥が残っていた場合に備え、取得の痕跡を残し、量で気づけるようにする。アクセスログに、認証した利用者、要求したAPI、返した件数を残しているかを確かめる。記録が無い、または要点が欠けている状態はCWE-778「不十分なログ記録」に当たる。

残っていなければ、一覧や検索のAPIで返した件数をログに書く。その上で、1回の応答で返す件数に上限を設け、短時間に件数が膨らんだ利用者や、ログインの失敗が続いた接続元に通知が出るようにする。検証での取得はどちらも数分以内に終わっており、人が後から気づくには記録が要る。何を記録し、どう見直すかの基準は、NISTのSP 800-53 Rev.5の監査と説明責任（AU）の管理策が参考になる。

続け方：直した後も同じテストを残す

認可と管理機能の点検は手で始められるが、1回で終わらせない。確かめた対を自動テストにし、CIで毎回動かす。機能を追加したときに、他人の情報を再び読めるようになっていないかを、その都度確かめるためだ。生成AIの道具で自社を点検する場合も、同じテストを先に用意しておくと、道具の報告を自分たちで照合できる。

出典・検証資料

検証結果は、我々が2026年10月8日に実施した社内検証の保存データ、Cairnの実行記録、Strixの実行記録・診断レポート、手動確認の記録に基づく。