Blog

なぜAIハッキングによるサイバー攻撃は、既存のセキュリティ対策で防げないのか

なぜAIハッキングによるサイバー攻撃は、既存のセキュリティ対策で防げないのか。防御の穴を、公開事例から読み解く。南京錠と壁の隙間を通る矢印の紙コラージュ。

企業はこれまで、次のような手法で、サイバー攻撃への対策を重ねてきたはずだ。

  • 脆弱性診断:ツールや専門家の検査で、システムの欠陥や設定上の問題を探す。
  • ペネトレーションテスト(侵入テスト):攻撃者の立場で侵入や情報取得を試し、どこまで成立するかを確かめる。
  • ファイアウォール・WAF:通信を制御し、Webアプリへの不正な要求を遮断する。
  • 多要素認証:パスワードだけに頼らず、複数の要素で本人を確認する。
  • 不審な通信や操作の監視:通信やログを調べ、侵入や情報の持ち出しの兆候を見つける。

それなのに、なぜ侵入や情報漏えいを防ぎきれないのか。
生成AIを使う攻撃者は、診断やテストで見つからなかった何を見つけているのか。

診断の対象外にある機器や、診断後に追加した機能には、弱点が残ることがある。
生成AIは、攻撃者がそうした弱点を探し、攻撃方法を考える作業を助ける。

診断やテストが何を確認できるのかを整理する。
公開事例をもとに、既存の対策を講じていても攻撃を防ぎきれない理由を説明する。

診断や侵入テストで防ぎきれない箇所とその理由

脆弱性診断や侵入テストで弱点を探し、ファイアウォールや監視で不正な通信・操作に対応する。
手法主に確かめること・担うこと実施・導入だけでは分からないこと
脆弱性診断
  • ○指定されたシステムの欠陥を探す
  • ○設定上の問題を探す
  • ×未登録の資産にある問題
  • ×検査に用意しなかった権限で起きる問題
  • ×検査項目の外にある問題
ペネトレーションテスト(侵入テスト)
  • ○合意した範囲で攻撃を試す
  • ○侵入や情報取得がどこまで成立するかを確かめる
  • ×対象外の経路からの侵入
  • ×期間内に試せなかった弱点の組合せ
  • ×実施後の変更で生じた問題
通信の防御・監視
  • ○通信を制御する
  • ○不審な操作を遮断・検知する
  • ×正規の接続を悪用した行為を識別できるか
  • ×自社固有の業務ルールへの違反を識別できるか

各手法が確認・制御する範囲

脆弱性診断は、指定したシステムの欠陥や設定上の問題を、ツールや人の検査で探す。

ペネトレーションテスト(侵入テスト)は、攻撃者の立場で侵入や情報取得を試す。複数の弱点を組み合わせ、調査結果に応じて攻め方を変える検証も行う。

ファイアウォールやWAFは通信を制御し、不正な要求を遮断する。監視は通信や操作の記録から異常を見つける。

検査対象・項目から漏れる弱点

脆弱性診断では、機器の登録漏れや、検査に使うアカウントの権限によって、調べる対象に漏れが生じる。検査項目に含まれない問題も残る。
生成AIを使うと、Webアプリの画面や応答から問題の候補を大量に洗い出し、確かめる手順を作れる。検査ツールと組み合わせることで、当初の検査項目に含まれない問題にも、調査を広げやすくなる。

侵入テストでは、対象外の経路や、期間内に試せなかった組合せ、実施後の変更で生じた弱点が、検証の範囲から漏れる。
生成AIに試行結果を読み取らせ、次に試す手順や弱点の組合せを考えさせると、攻め方を組み立てる手間が減る。生成AIが挙げた入力値や操作の組合せを自動ツールに渡せば、候補を総当たりに近い形で試せる。人手では検査期間中に試しきれなかった組合せにも、調査を広げやすくなる。

正規の通信で通る不正な操作

通信の防御や監視では、正規の接続を悪用した操作が、通常の通信として扱われることがある。また、「誰が、どの情報を操作してよいか」という業務ルールの確認が抜けていると、不正な操作も通ってしまう。
生成AIは、画面や通信の内容を読み取り、利用者の権限と実際にできる操作の食い違いを探す作業にも使える。こうした調査を自動化できれば、形式上は正常な通信で成立する不正な操作を、繰り返し試しやすくなる。

診断範囲の外にある侵入経路

脆弱性診断と侵入テストには、対象と期間、許可された操作がある。
米国国立標準技術研究所(NIST)のセキュリティ評価ガイド(SP 800-115)は、脆弱性診断や侵入テストの計画・実施から、結果の分析、対策の検討までをまとめた指針だ。
このガイドでは、検査する範囲や操作の制約を事前に合意するよう求めている。診断の対象が顧客向けのWebアプリに限られていても、攻撃者は公開された管理画面や社外接続用の機器まで調べる。診断の対象から外れた場所に弱点が残っていれば、そこを侵入の入口として狙える。
生成AIで調査用のソフトウェアを作り、見つかった機器やサービスを整理すれば、少人数でも大量の機器やサービスを調べやすくなる。AWSの報告でも、生成AIで作ったソフトウェアが、侵入後のネットワーク調査や検査対象の整理を自動化していた。

修正や遮断までに攻撃が進む

診断で見つけた弱点も、修正を待っている間は攻撃を防げない。
攻撃者が弱点の情報を得た後、生成AIで攻撃手順の検討やコード作成を進めれば、準備にかかる手間が下がる。その分、修正が終わる前に攻撃を試される可能性が高まる。

監視で警告が出ても、通信の遮断やアカウント停止までに時間がかかれば、その間に情報を取得される可能性がある。
生成AIは、侵入後に得た大量の情報から、金銭や機密に関わる内容を選び出す作業も助ける。Microsoftの報告では、EvilTokensがメールの分析や次の標的選びを自動化していた。防御側が遮断するまでに、情報の取得から悪用の準備まで進められる恐れがある。

ソフトウェアの外にある脆弱性は防げない

顧客向けのWebアプリを診断する際、社内接続用の機器や、従業員が使うクラウドの認証手続きは対象外になることがある。管理画面、認証手続き、ログイン後の権限に分けて、侵入経路が残る理由を見ていく。

管理画面:守るための機器自体が入口になる

FortiGate:通信制御と管理アクセスAWS
確認・防御している範囲
外部からの通信
ファイアウォールの通信制御ルールに従って通信を許可・遮断
許可された社内接続
残り得る穴
攻撃者からの管理アクセス
管理インターフェースの外部公開管理アクセス制御・認証設定の不備
機器の管理権限を取得
2026年1月11日〜2月18日
侵入が確認された国
55カ国以上
侵入されたFortiGate
600台超

「話題のAIハッキング、その手口を特定してみた」でも取り上げたのが、FortiGateへの侵入だ。FortiGateは、通信の制御や社外からの接続に使うセキュリティ機器である。

AWSの報告(2026年2月20日)では、外部に公開された管理画面と弱い認証が侵入の入口になった。FortiGateの脆弱性の悪用は観測されていない。

この攻撃者は、生成AIで調査用ソフトウェアや攻撃計画を作成していた。作成したソフトウェアは、侵入後のネットワークを調べ、機器やサービスの発見、脆弱性スキャン、次に狙う対象の整理を自動化していた。こうして攻撃の道具や手順を生成AIで用意し、技術的な経験の少ない攻撃者でも、大量の機器を狙う活動を進めていた。

ファイアウォールが社内への通信を制御していても、その管理画面へのログインが弱ければ、機器自体が侵入の入口になる。Webアプリへの入力だけを調べていると、機器の管理画面にある弱点を見落とすためだ。

認証手続き:本人が攻撃者の接続を承認してしまう

Microsoft:正規の認証手続きMicrosoft
確認・防御している範囲
利用者がサインイン
正規の画面で本人確認利用者自身が認証を完了
本人として認証される
残り得る穴
攻撃者が認証コードを提示
デバイスコードフィッシング本人が攻撃者の接続を承認
攻撃者がトークンを取得

「話題のAIハッキング、その手口を特定してみた」でも紹介したEvilTokensは、正規のサインイン手続きを悪用した。Microsoftの報告(2026年9月22日)によると、利用者をだましてMicrosoftの本物の画面にコードを入力させ、攻撃者にメールへのアクセス権を渡していた。

この手口では、本人が正規の画面で認証を済ませ、攻撃者の接続を承認してしまう。多要素認証で本人を確認できても、承認した接続を攻撃者が利用するため、メールへの不正アクセスを防ぎきれない。ログイン画面の欠陥を調べる検査だけでは、こうした利用者の判断を悪用する手口を見落とす。

メールへのアクセス権を得た後、攻撃者は、乗っ取ったアカウントの受信箱や組織内のやり取りを生成AIで高速に解析し、送金に関する情報や請求書、支払いを担当する人物を探していた。大量のメールを人が一通ずつ読む作業を自動化し、金銭に直結する情報や、なりすましの標的を素早く絞り込む手口だ。

認可:本人確認だけでは他人の情報へのアクセスを止められない

Webアプリ:認証とデータへのアクセス権OWASP
確認・防御している範囲
利用者がログイン
認証による本人確認利用者が誰かを確認
Webアプリの利用を許可
残り得る穴
認証済みの利用者が操作
オブジェクト単位の認可不備(BOLA)対象データへのアクセス権検証の欠落
他人のデータへアクセス

「認証」と「認可」は、一文字違いで仕事が違う。認証は「あなたは誰か」の確認。認可は「そのデータに、その操作をしてよいか」の確認だ。他人の注文履歴へのアクセスは、認可で制限する。

認証:あなたは誰か田中さん本人だと確認
認可:何をしてよいか注文履歴を読む権限を確認
自分のデータ田中さんの注文履歴
許可読む権限がある
他人のデータ佐藤さんの注文履歴
拒否読む権限がない

「話題のAIハッキング、その手口を特定してみた」でも扱った、データごとの権限確認が抜ける欠陥を、OWASPはBOLAと呼んでいる。WAFはWebアプリへの通信を検査する。「誰が、どの顧客情報を読んでよいか」という業務ルールは、Webアプリ側で確認する必要がある。

実際の製品でも、この差は現れる。Appsmithの公式勧告(2026年3月24日)では、復元処理にある権限確認が、保存状態のコピーを削除する処理では抜けていた。

「話題のAIハッキングを攻撃者視点で実際に検証してみた」でも、我々が作った試験用のWebアプリで、生成AIを使うエージェントが認可の欠陥などを突いて顧客情報を取得した。

管理者アカウントだけで診断すると、データの取得は権限どおりの正常な動作に見える。一般利用者のアカウントで同じ操作を試すことで、権限の不備が見つかる。OWASPの業務ロジックに関する指針も、汎用スキャナーは業務ルールを持たず、欠陥を見逃す場合があると説明している。通信の形式が正しくても、その人に許されない操作が通る。この違いが、診断やWAFの導入だけでは防ぎきれない理由になる。

生成AIを使うと、利用者ごとの応答を読み比べ、認可の不備が疑われる箇所を探す作業も自動化できる。PrivHunterAIは、別の利用者の認証情報でリクエストを送り直し、生成AIで応答を比較・分析する。こうした仕組みで大量の応答を比較・分析する作業を自動化すれば、人が一件ずつ確認する負担が減り、診断で試されなかった利用者と操作の組み合わせまで調べやすくなる。

診断で問題がなくても、その後に侵入されるのはなぜか

診断で確認できるのは、診断した時点のシステムだ。そのとき問題が見つからなくても、後から機能を追加したり設定を変えたりすれば、新たな弱点が生まれることがある。NISTのセキュリティ評価ガイド(SP 800-115、6.2節)も、評価結果は検査した時点の状態を示すものだと説明している。

たとえば、診断後に顧客情報を出力するAPIを追加する。保守のために管理画面の接続制限を一時的に緩め、そのままになる。利用中の製品に新しい脆弱性が公表される。こうした変更や新たな情報によって、前回の診断結果と現在の状態にずれが生まれる。

診断を実施検査した範囲で問題は見つからず
診断後の変化機能・設定・公開情報が変わる
機能の追加顧客情報を出力するAPIを追加
未検査の処理が増える追加したAPIの弱点は前回の診断では分からない
設定の変更管理画面の接続制限を緩和
アクセスできる範囲が広がる制限を戻し忘れると、外部から狙われる入口が残る
新たな情報の公表利用中の製品に脆弱性が公表
既存の弱点が明らかになる前回の診断で把握できなかった問題が攻撃に使われ得る

まとめ

企業が対策を重ねても、検査から漏れる場所や、認証だけでは止められない操作が残る。既存の対策で防ぎきれない理由は、次の5点にまとめられる。

  • 検査する範囲に限りがある:
    対象外の管理画面や機器、期間内に試せなかった操作の組み合わせを全て網羅して検証することが困難。
  • 本人の承認が悪用される:
    多要素認証があっても、利用者が騙されて、メールへのアクセス権を渡してしまう。システムに脆弱性がなくても、人間側のリテラシーが課題となる。
  • ログイン後の権限確認が抜けている:
    本人確認や通信の検査を通過しても、データごとの認可が欠けていれば、他人の情報を取得できてしまう。
  • 修正や遮断が攻撃に間に合わない:
    弱点を見つけても修正が終わる前に攻撃され、不審な操作を検知しても止める前に情報を持ち出されることがある。
  • 診断後に状態が変わる:
    機能追加や設定変更、新たな脆弱性の公表によって、前回の診断では把握できなかった問題が生じる。

さらに生成AIにより、以下の操作が可能になる。

  • 調査用ソフトウェアや攻撃手順を作成する:
    調査結果をもとに次の手順を考え、作業を自動化するソフトウェアを用意する。
  • 試す操作の組み合わせを増やす:
    入力値や操作の候補を大量に挙げ、自動ツールと組み合わせて検証を広げる。
  • 利用者ごとの応答を比較・分析する:
    大量の応答から、認可の不備が疑われる箇所を絞り込む。
  • 侵入後のメールを高速に解析する:
    大量のメールから、送金に関する情報や請求書、なりすましの標的となる人物を探す。
  • 専門知識が少なくても攻撃を試せる:
    生成AIに調査結果の読み取りや攻撃手順の作成を任せることで、自分では手順を組み立てられない攻撃者でも、攻撃を進めやすくなる。
  • 常時稼働で調査や試行を続ける:
    エージェントを継続して動かす仕組みを用意すれば、夜間や休日も調査や試行を続けられる。人が操作していない間も、残された弱点を探し続けられる。
  • 複数のエージェントで並列実行する:
    対象や作業を複数のエージェントに分担させ、異なる対象や攻撃方法を同時に調べられる。順番に試す場合より、同じ時間内に検証できる範囲が広がる。

対策を導入していても、攻撃者が使える入口や権限が残っていれば、被害は起こり得る。生成AIで調査や試行が自動化・並列化されると、検査で確認しきれなかった箇所も狙われやすくなる。自社の公開機器やWebアプリに、いま攻撃に使える弱点が残っていないかを確かめることが重要だ。

ブログ一覧へ