Blog
公表情報からは見えないサイバー攻撃の裏側：原因と攻撃手法を徹底予測
前回の記事では、国内で相次ぐ被害の公表を1件ずつ調べた。
調べるほど、同じ一文に行き当たる。
「不正アクセスを受けました」
どこから入られたのか。何を使われたのか。
肝心なところは、公表文を読んでも分からない。
原因が明かされていない以上、個別の事件の答えは出せない。
だが、攻撃者の側を追った調査報告には、手掛かりが残っている。今回は、そこから原因と攻撃手法を予測する。
先に、分かったことを1つ。
入口は、最新の脆弱性とは限らなかった。
攻撃はどれほどの規模で観測されているのか
「1万を超える組織で、1万2,000を超えるメールボックスが侵害された」
Microsoft Security BlogMicrosoft「EvilTokensの調査報告」（2026年9月22日）Unmasking EvilTokens: Getting to the root of device code phishing | Microsoft Security Blog
EvilTokensは、犯罪者にフィッシングの仕組みを提供するサービスだ。Microsoftによれば、生成AIは誘導メールの作成だけでなく、奪ったメールボックスから財務担当者などを探すためにも使われていた。
「FortiGateの脆弱性の悪用は観測されなかった」
Amazon Web ServicesAWS「AIを利用した攻撃者によるFortiGateへの大規模侵入」（2026年2月20日）AI-augmented threat actor accesses FortiGate devices at scale | Amazon Web Services
AWSが観測したのは、2026年1月11日から2月18日の攻撃だ。55カ国以上で600台超のFortiGateが侵入された。入口は、外部に公開された管理画面と弱い認証だった。生成AIは、従来の手口を大規模に実行するために使われた。
「2026年1〜8月に公表・悪用された脆弱性は141件で、2025年通年の127件を上回った」
Google Cloud BlogGoogle「生成AI時代の脆弱性の発見と悪用の動向」（2026年9月30日）Vulnerability Discovery and Exploitation Trends in the AI Era | Google Cloud Blog
数えているのは、攻撃の回数や被害企業数ではなく、悪用が確認された脆弱性の種類数だ。Googleは、既知の脆弱性を攻撃に使う動きが増加の主因とみている。ただし、増えた分をすべて生成AIの影響と認定したわけではない。
我々は、攻撃の調査報告と公開ツールを確認した。以下では、それらを根拠に、侵入から被害に至る経路を考える。
生成AIは攻撃のどこを担うのか
攻撃の自動化は、生成AIが登場する前からある。大量の接続先を調べ、同じ処理を繰り返す。これは従来のプログラムでもできる。変わったのは、その途中の判断まで任せられる範囲だ。
先ほどのAWSの報告には、次の一文がある。
「より攻めやすい対象へ移った」
相手の防御を必ず突破する必要はない。試す相手を増やし、入れそうなところへ移ればよい。AWSの報告からは、少人数でも、この作業を広く回せるようになったことが分かる。
GitHubには、その作業を進めるための道具が公開されている。CyberStrikeAIの公開資料では、既存のセキュリティツールを生成AIの作業に組み込む構成が示されている。Strixの公開資料にも、ブラウザ、プロキシ、ターミナルなどを使い、対象を調べて検証する設計がある。いずれも防御側の検証に使える。人が調べていた作業を任せるための部品が、すでに公開されている。
公開ツール：判断と実行を繰り返す仕組み
この循環で省力化されるのは、「次に何を調べるか」「この応答は何を意味するか」と考える部分だ。大量実行は従来のプログラムが受け持ち、生成AIは結果の解釈や手順の調整を助ける。この組み合わせなら、対象ごとに環境が違っても、その結果に応じて手順を変えられると考えられる。
ただし、生成AIの能力を比べるときは、与えられた条件を見なければならない。コードを丸ごと読ませた実験と、外から通信だけを見て調べる攻撃は違う。ARTEMISと人間の侵入テストを比較した研究は実ネットワークを対象にしているが、防御側が試験を認識し、通常なら阻止する動作を許可した条件も含む。研究での成績を、そのまま一般企業への侵入成功率にはできない。
公開リポジトリについても同じだ。READMEに機能が書いてあること、実装されていること、実際の攻撃で成功したことは別々の証拠だ。この記事では公開資料から設計を確認しており、ツールを実行して性能を検証したわけではない。
相次ぐサイバー被害の原因と攻撃手法は何か
「不正アクセス」と聞くと、管理者のアカウントを奪う手口を思い浮かべるかもしれない。しかし、管理者にならなくても起きる被害がある。
「ログイン中の利用者が、その対象に対して要求された操作を行う権限を持つか、確認しなければならない」
api-security.owasp.orgOWASP「オブジェクト単位の認可の不備」（2023年版）API1:2023 Broken Object Level Authorization - OWASP API Security Top 10
ログインで本人を確認するのが「認証」だ。その人が、どのデータに何をしてよいかを確認するのが「認可」だ。会員本人でも、別の会員の注文履歴を読めてはいけない。この確認が抜けると、アプリとサーバーの窓口であるAPIを通じて、他人の情報の取得や変更に至ることがある。
PrivHunterAIの公開リポジトリには、異なる利用者の権限で得られる応答を生成AIで比較し、認可の不備を検出する設計が掲載されている。これは「その作業を生成AIに助けさせる仕組みが公開されている」証拠だ。国内の被害でこのツールが使われた証拠ではない。
侵入経路：何が入口になり、どんな条件で被害に至るか
利用者として入って、利用者の範囲を越える
会員向けアプリでは、この認可の不備が原因の候補になる。読み取りの不備なら情報漏洩、更新や削除の不備なら改ざんやデータ消失につながり得る。サーバー全体を乗っ取らなくても、事業に必要な情報が壊される可能性はある。
生成AIが助けるとすれば、機能や応答の意味を調べ、権限による違いを見つける段階だろう。同じ問い合わせを繰り返す処理まで生成AIで行う必要はない。したがって、「大量のデータが抜かれた」という結果だけで生成AI利用を推定するのは難しい。
確かめるには、利用者ごとの要求の記録と、サーバー側の権限確認を突き合わせる。WAFという通信の防御装置を置いていても、その要求が業務上許されるかまで把握できるとは限らない。
システムを破る前に、入れる鍵を手に入れる
もう一つは、すでに盗まれた認証情報を使う経路だ。Mandiantが2024年に調査したSnowflake顧客環境への攻撃では、対応した事案の入口は盗まれた顧客の認証情報にたどり着いた。Snowflake本体への侵害が入口だったことを示す証拠は見つかっていない。MandiantのUNC5537調査報告（2024年6月）は、端末から情報を盗むマルウェアと、その後のクラウド被害を結び付けている。
この事案で生成AIの利用が確認されたわけではない。だが、侵入経路を考える手掛かりにはなる。自社のサーバーを守っていても、従業員や委託先の端末から認証情報が漏れれば、正規の利用者として入られる場合がある。
鍵はパスワードだけでもない。冒頭で紹介したEvilTokensの入口は、正規の認証手続きだ。利用者に攻撃者のアクセスを承認させ、アクセス用のトークンを奪う。侵入先で、どの情報や相手を狙うか。その選別にも生成AIを使う攻撃は、今後も広がると考えられる。
原因を追うには、Webサーバーのログだけでは足りない。認証の履歴、接続した端末、外部サービスへの権限付与まで調査対象になるだろう。
更新の遅れを突く。修正前にも入り込む
既知の脆弱性も、有力な入口だ。AnthropicのN-day研究（2026年6月8日）は、公開済みの修正情報から攻撃コードを作る能力を評価している。Windowsの評価ではソースコードを渡さず、修正前後のバイナリなどを材料にしていた。
ただし、これは研究者が環境や資料を用意した実験だ。インターネットから対象を発見して侵入する全工程の実証ではない。それでも、公開された修正を攻撃者も分析できる点は変わらない。修正から手口を組み立てる時間が短くなれば、適用を待つ環境は狙われやすくなる。
冒頭のGoogleの報告には、修正公開前に悪用された脆弱性も含まれる。原因を一律に「更新を怠った」とは判断できない。パッチを適用した時点で、すでに別のアクセス手段が残されていた可能性も調べる必要がある。
侵入後にWebページを書き換えられる権限があれば、決済情報の窃取につながり得る。社内の管理基盤まで届けば、情報を盗むだけでなく、システムやバックアップを壊す方向にも進める。どこまで被害が広がるかを決めるのは、入口の種類に加え、その入口から届く権限と接続先だ。
なぜ、これほど多くの会社が狙われるのか
対象ごとの調査にかかる手間が下がれば、攻撃者が採算を取れる範囲は広がる。大企業だけを慎重に選ぶ必要はなくなる。入れるところを探し、見つかった環境から情報や金銭につながるものを探す、という順番でも動ける。
「これまでに公開された中で、最も高いサイバー能力を持つオープンウェイトモデル」
NISTNIST・CAISIによるGLM-5.3評価（2026年9月17日、評価時点の比較）CAISI’s Assessment of Z.ai’s GLM-5.3 Cyber Capabilities
モデルの重みが公開されれば、利用者は自ら用意した環境でも動かせる。公開ツールと組み合わせる選択肢も広がる。ただし、計算資源や運用の費用は必要だ。誰でも無料で高度な攻撃を成功させられる、という意味ではない。
Anthropicの評価（2026年9月29日）では、ChromeのV8にある既知の脆弱性から一連の攻撃コードを作る試験で、GLM-5.3が410試行中50回、Mythos Previewが410試行中56回成功した。限定された評価で近い結果が出たのであって、あらゆる攻撃能力が同等だとまでは言えない。
公開モデル：隔離環境で測った攻撃コードの生成能力
性能とともに見るべきなのは、その能力を誰が使えるかだ。特定のサービスが不正利用を止めても、別のモデルや自前の実行環境へ移る余地がある。
犯罪の道具を、自分で一から作る必要もなくなっている。Microsoftの犯罪対策部門の報告（2026年9月22日）によれば、冒頭のEvilTokensは、定額の利用料金、顧客サポート、管理画面を備えたサービスだった。攻撃に必要な機能を購入できれば、開発経験の乏しい者も利用できる。公開ツールの普及に加え、こうしたサービス化も、攻撃に参加する負担を下げると考えられる。
攻撃の拡大：探索・横展開・サービス化の組み合わせ
これらの情報から、入れる弱点を先に探し、侵入後に得られる価値を見て攻撃を進める場面が増えると予測する。「小さい会社だから狙われない」とは言えない。取引先への接続や業務用アカウントも、攻撃者には利用価値がある。
一方、ニュースが集中した日と、実際に侵入された日は一致しない。国内の公表件数だけで攻撃が何倍に増えたか、生成AIが何割を占めたかは出せない。公表の集中と攻撃の増加、生成AIの利用は、分けて判断する必要がある。
何を見直し、どう対策すべきか
入口が違えば、止める場所も違う。パスワードを強化しても認可の不備は残るし、盗まれたトークンが更新だけで無効になるわけでもない。第3章で考えた経路ごとに、対策を整理する。
「ネットワークの分割と、利用者の識別に基づくアクセス制御を整えるべきだ」
Googleは、修正を検証する間のアクセス制限や隔離を、迅速に実施できる手順も求めている。防御の設計には、更新前の時間と、侵入された後の時間を含める必要がある。
対策の位置：どこで防ぎ、どこで止めるか
「ログインできるか」の先をテストする
正常な利用ができることに加え、許されない操作が拒否されることを確かめる。
- 会員Aが会員Bの情報を読めないか。
- 閲覧だけの担当者が更新できないか。
- ある取引先のアカウントで、別の取引先のデータに触れないか。
誰が何をしてよいかを、利用者と操作の組み合わせで確認する。
そのためには、誰が何をしてよいかを言葉とテストで残す必要がある。OWASPの認可テスト自動化の指針も、この確認を継続するための参考になる。生成AIに検査を手伝わせる場合も、業務上の権限ルールを渡さなければ、どの動作が誤りか判断する材料が足りない。
更新・検知・隔離までを一本につなぐ
異常を検知しても、止める担当者や権限が決まっていなければ対応は進まない。運用では、次の点まで決めておく。
- 公開機器の一覧に担当者が書かれているか。
- 緊急時に接続を制限する判断を誰ができるか。
- アラートが出た後、夜間でもアカウントや端末を止められるか。
通知が届くだけで終わらず、停止や隔離まで動けるかが問題だ。
認証情報が漏れた疑いがあるなら、パスワード変更だけで解決するかも見極める。すでに発行されたトークンや外部連携の権限が残っていれば、その失効も必要になる。何を無効化し、どの記録で再侵入がないか確認するのかを、利用しているサービスごとに決めておく。
盗まれる量と、止まる範囲を小さくする
「機密情報を守る最善の方法は、そもそも保存しないことである」
cheatsheetseries.owasp.orgOWASP「保存データの暗号化に関する指針」（2026年10月6日確認）Cryptographic Storage - OWASP Cheat Sheet Series
何のために集める情報か、いつまで必要かを決める。決済情報を自社で扱う範囲を減らす方法も検討する。ただし、決済を外部へ委託しても、自社の画面の改ざんや連携権限の管理まで不要になるわけではない。
復旧については、バックアップが存在することと、攻撃後に使えることを分けて考える。CISAのランサムウェア対策ガイドは、オフラインの暗号化バックアップと、可用性・完全性を確かめる復旧テストを勧めている。日常の管理アカウントが奪われても復旧用データまで失わないか、実際に戻せるかを確認する。
今後、調査や試行を生成AIに任せる攻撃が増えるなら、年に一度確認した状態と、日々変わる実環境とのずれは、さらに狙われやすくなるだろう。防御側も、権限テスト、資産の把握、ログの確認を継続して回す必要がある。
公表文だけでは分からなかった「どこから入られたのか」に、今回は複数の経路を挙げた。どれが実際の原因だったかは、各社の調査を待つことになる。一方、自社に同じ条件が残っているかは調べられる。認可の確認が抜けたAPI、有効なままの古いアカウント、担当者の分からない公開機器。予測を対策に変える作業は、そうした箇所を一つずつ確かめることだ。
出典
調査報告・論文・公開資料を表示する（17件）
- Microsoft「EvilTokensの調査報告」（2026年9月22日）
- AWS「AIを利用した攻撃者によるFortiGateへの大規模侵入」（2026年2月20日）
- Google「生成AI時代の脆弱性の発見と悪用の動向」（2026年9月30日）
- Microsoft「犯罪向け生成AIサービスEvilTokensの停止」（2026年9月22日）
- CyberStrikeAIの公開資料
- Strixの公開資料
- ARTEMISと人間の侵入テストを比較した研究
- OWASP「オブジェクト単位の認可の不備」（2023年版）
- PrivHunterAIの公開リポジトリ
- MandiantのUNC5537調査報告（2024年6月）
- AnthropicのN-day研究（2026年6月8日）
- NIST・CAISIによるGLM-5.3評価（2026年9月17日、評価時点の比較）
- Anthropicの評価（2026年9月29日）
- Google「AIが脆弱性を発見する時代の企業防御」（2026年4月16日）
- OWASPの認可テスト自動化の指針
- OWASP「保存データの暗号化に関する指針」（2026年10月6日確認）
- CISAのランサムウェア対策ガイド