何が起きたのか
2026年5月、Googleのセキュリティチームは「犯罪グループがAIを活用してゼロデイエクスプロイトを開発した」という前例のない事態を報告した。対象はオープンソースのWebベース管理ツールであり、攻撃者は2要素認証（2FA）を迂回するPythonスクリプトをAIに生成させ、大量悪用を企図していた。Googleはベンダーと協力して大規模な被害が起きる前に対応を完了したが、この事例は攻撃者によるAI利用が「フィッシング文面の作成」から「脆弱性の発見・武器化」まで到達したことを意味する。
AIが書いたコードの特徴
GoogleがエクスプロイトのPythonコードを解析したところ、通常の攻撃ツールとは明らかに異なる特徴が見つかった。
- 説明過多のdocstring: 各処理ブロックに丁寧な説明コメントが付与されていた。攻撃ツールとしては不自然なほど冗長な記述であり、LLMが「可読性の高いコードを書く」という訓練の産物だった
- 架空のCVSSスコア: 存在しないCVE番号に対してAIが"推定"したCVSSスコアがハードコードされていた。LLMが「CVEにはCVSSスコアが付く」という知識から捏造した
- 教科書的なコード構造: 変数命名・関数分割・エラーハンドリングがLLMのトレーニングデータに典型的な「模範的なPythonコード」の書き方だった
これらの特徴を根拠に、Googleは「攻撃者がAIモデルを活用して脆弱性の発見と武器化を支援させた可能性が高い」と結論づけた。使用されたAIはGoogle Geminiではないとされているが、具体的なモデル名は特定されていない。
技術的な解説
AIによるエクスプロイト開発の変化
従来、ゼロデイエクスプロイトの開発には高度な専門知識が必要だった。静的解析・動的解析・ファジング・デバッグを経てコードを手書きするプロセスは、熟練したリバースエンジニアが数週間〜数ヶ月かけて行うものだった。
LLMは大量のOSSコードを学習済みであるため、既知の脆弱性パターンと照合しながら候補となるコードパスを短時間で特定できる。AIが変えるのは主に「仮説立案」と「初期コード生成」のステップであり、中程度のスキルを持つ攻撃者でもゼロデイ発見に挑戦できる環境が整いつつある。
2FAバイパスの攻撃面
今回はWebベース管理ツールの2FA検証ロジックそのものの実装バグが狙われた。2FAバイパスには以下のような技術的アプローチがある。
| 手法 | 仕組み |
|---|---|
| AitM（Adversary-in-the-Middle） | フィッシングプロキシでセッションCookieを傍受 |
| 認証フロー脆弱性の悪用 | 検証ロジックのバグでOTPチェックを回避 |
| レース条件 | 検証タイミングの隙間を突く |
| トークン再利用 | 有効期限・使い捨てチェックの不備を悪用 |
AitM経由のフィッシング（Quishing や デバイスコードフィッシング）はMFAを「迂回」する手口だが、今回は検証ロジックのバグを「直接突く」タイプのゼロデイであり、より根本的な攻撃面となる。
「負のTime-to-Exploit」の現実
Mandiantが発表したM-Trends 2026レポートは、より深刻な傾向を示している。CVE公開から24時間以内に悪用が始まるケースが全体の28.3%に達しており、パッチを適用する前に攻撃が始まることが珍しくなくなっている。AIによるエクスプロイト開発の加速がこのトレンドをさらに押し進める可能性がある。
LLM製エクスプロイトの識別可能性は将来失われる
今回の発見で重要なのは、AIが生成したコードがある程度「識別可能だった」という点だ。しかしこれは現時点の話であり、モデルの進化に伴い、よりステルシーなコード生成が可能になれば識別は困難になる。また、攻撃者がAI生成コードを手動でリファクタリングすれば特徴を消すことも容易だ。
なぜ攻撃が成立したのか
OSSの管理ツールは多くの場合、セキュリティに特化したチームではなくコミュニティが開発・メンテナンスしている。2FA実装のような認証ロジックは、複雑なエッジケース（タイムゾーンの差異・タイミング・セッション管理）が存在しバグが潜みやすい。加えて、これらのツールが「デフォルトでインターネット公開されるケース」も多く、ゼロデイ発見後すぐに大量のターゲットを探せる状況がある。
攻撃者が「大量悪用」を企図していたことも重要だ。標的型の国家APTではなく、金銭目的の犯罪グループが大規模なスキャンとエクスプロイト配布を想定していたことは、AIがゼロデイ開発の「民主化」に寄与していることを示唆する。
日本企業への影響
日本企業でもWebminやCockpit、ISPConfigなどのWebベース管理パネルをインターネットに直接公開しているケースは少なくない。特にVPS・レンタルサーバーを活用する中小企業では、コスト削減のため管理ツールを直接公開することが多い。
AIがゼロデイ開発のスキルの壁を下げることは、以下の意味を持つ。
- 攻撃者の「裾野」が広がり、OSSの管理ツールを狙った機会主義的攻撃が増える
- パッチが出た後ではなく出る前から悪用が始まるケースが増える
- 「信頼できるOSSだから安全」という前提が通じなくなってくる
今すぐ確認すべきポイント
1. 管理ツールの公開範囲を最小化する
Webmin・Cockpit・ISPConfigなどの管理パネルがインターネットから直接アクセス可能になっていないかを確認する。アクセスはVPNまたはIP許可リスト（allowlist）経由のみに制限し、管理ポート（Webminは10000番等）をファイアウォールで遮断する。
2. 2FAの実装品質を評価する
内製または採用中の2FA実装に脆弱なレース条件や検証ロジックの欠陥がないか確認する。使用しているOSSの2FAライブラリが最新版であるかを確認し、2FAトークンに有効期限・使い捨て・リプレイ防止が実装されているかを検証する。
3. 脆弱性対応の高速化
CISA KEV（既知悪用脆弱性カタログ）を自動監視する仕組みを設ける。クリティカルパッチの適用を72時間以内に完了できる体制を整備し、使用中のOSSのCVEをDependabot等で継続追跡する。
4. 管理ツールのアクセスログを監視する
管理ツールへのアクセスログを定期的にレビューし、未知IPや深夜帯のアクセスを検知する仕組みを設ける。ログをSIEMに集約し、異常検知ルールを設定することが望ましい。
5. 万一の侵害を想定して対応手順を準備する
管理ツールが侵害された際のインシデント対応手順を事前に文書化する。サーバーの完全な再構築（ゼロから）ができるようにインフラのコード化（IaC）を検討する。インシデント対応の基本については セキュリティインシデント対応手順 も参照されたい。
参考情報
- The Hacker News: Hackers Used AI to Develop First Known Zero-Day 2FA Bypass for Mass Exploitation
- SecurityWeek: Google Detects First AI-Generated Zero-Day Exploit
- BleepingComputer: Google: Hackers used AI to develop zero-day exploit for web admin tool
- The Hacker News: 2026: The Year of AI-Assisted Attacks