APT31がGoogleのGeminiを偵察・作戦立案に悪用——汎用LLMの“軍民転用”が本格フェーズに入った可能性です

今日の深掘りポイント

• 供給側での抑止（アカウント無効化など）と、利用側での検知（TTPの観測）の“二段構え防御”が必須段階に入ったと見ます。攻撃者が汎用LLMを運用に組み込めば、偵察・資料要約・フィッシング文面・脆弱性トリアージといった“知的作業”のスループットが跳ね上がりますです。
• LLMはゼロデイ創出の魔法ではありませんが、計画立案と作戦運用（Ops）テンポの加速装置にはなり得ます。防御側も同じ土俵（AI）での自動化・最適化が求められますです。
• プロバイダによる不正利用検知は効きますが、回避として自己ホスト型モデル／オープンウェイトへのシフトが想定されます。攻撃者のモデル選好の多様化を前提に、ネットワーク境界外で最適化されるTTPを“結果から”検知する視点が重要です。
• いま優先すべきは、AI利用の社内ガバナンス（許可モデル・用途・ログの明確化）、LLM由来の攻撃増速を織り込んだプレイブック更新、そしてMITRE ATT&CK基準での検知・阻止ポイントの再マッピングです。

はじめに

Googleが、中国系脅威グループAPT31（通称Zirconium/Judgment Panda）によるGeminiの悪用を把握し、関連アカウントを無効化したと報じられています。報道ベースでは、米国の重要インフラを含む標的に対し、Geminiを用いた脆弱性の自動分析や攻撃計画の策定が行われていた可能性が示唆されています。ここで大事なのは「何を攻撃したか」より「どうOpsが変わったか」です。LLMは攻撃チェーンの“上流工程”を高速化し、下流の技術的手口（エクスプロイトや横展開）をより素早く、より多様に回せるようにしますです。

本件は新規性が高く、信頼度も高い部類と見えますが、即時の実害や全面的な能力飛躍を断じるのは早計です。むしろ、攻守いずれもAIを日常の運用に溶け込ませる“地味だが抜け目のない最適化競争”が本格化した、と腹落ちさせるべき出来事です。

参考：本件はGoogleの指摘を元に報じられており、一次情報の詳細は限定的です。以下の分析は公開報道を起点に、ATT&CK準拠の仮説で立体化しています。

深掘り詳細

事実関係（公開情報で確認できる範囲）

• 報道によれば、APT31がGoogleのLLM「Gemini」を用いて、米国組織を標的とする作戦立案（脆弱性の分析や攻撃計画の策定）を実施し、Googleは関連アカウントを無効化する対応をとったとされますです。The Registerの報道はGoogleの説明に基づくもので、詳細なプロンプト内容や具体的な成果物の有効性・攻撃の実施有無までは明らかにしていませんです。
• APT31は過去から西側政府・選挙関係者・企業を広く狙う国家支援グループとして認識され、制裁対象となった経緯が報じられてきました。本件もその延長線上で、LLMのオペレーション活用が新たに可視化された格好です（一次資料の技術的詳細は未公開のため、断定は避けます）です。

出所がGoogleであり、かつ事業者側の強制措置（アカウント無効化）まで踏み込んでいる点は、真実性の高さを示唆します。一方で、攻撃工程のどの段にどれほど寄与したか、再現性や有効性は不明確です。現時点で「Ops支援としてのLLM悪用が観測された」という確度の高いシグナル、と捉えるのが妥当です。

編集部の視点（インサイト）

• “LLMが攻撃を劇的に賢くした”のではなく、“攻撃運用の隙間時間を潰して密度を上げた”と見るべきです。脆弱性ブリーフィングの要約、PoCの差分検討、標的組織の人事・資産のOSINT整理、説得力のあるフィッシング文面の多言語生成——こうした工程が時短・多品種化されますです。結果として、初動から横展開までのリードタイム短縮と、同時並行案件数の増加が起きやすくなりますです。
• 供給者側（クラウドAI）のガバナンスが効く局面では抑止が期待できますが、攻撃者が自己ホストのオープンモデルやリージョンを跨ぐ迂回を選べば、検知面は被害者組織の“外”に逃げます。だからこそ、防御側はモデル利用の痕跡ではなく、ATT&CKで定義される下流の行動（偵察の粒度やメールの微調整パターン、スキャンの幅と深さのバランスなど）から“AIで増速された作戦”を逆算して捕捉する視点が重要です。
• なお、LLMがゼロデイを自動生成する、といったセンセーショナルな飛躍は現実的ではありません。むしろ既知脆弱性の選別・順序付けや、エクスプロイト適用条件の同定（「どのバージョン、どの設定が刺さるか」）の効率化が実害のドライバーになります。これは防御側のパッチ適用遅延や構成不整合の“つけ込みやすさ”に直結しますです。

脅威シナリオと影響

以下はMITRE ATT&CKに沿った仮説シナリオです。実際の手口は未公開のため、検知・防御の思考実験として提示しますです。

• シナリオA：LLM補助による高精度スピアフィッシングからの侵入

  • Reconnaissance: T1591（組織情報収集）、T1593（検索エンジン発見）、T1592（ホスト情報収集）
  • Resource Development: T1583（インフラ取得：ドメイン/クラウド）、T1587（能力開発：フィッシングキット調整）
  • Initial Access: T1566.001/002（添付/リンク型スピアフィッシング）
  • Execution: T1059（スクリプト実行：PowerShell等）
  • Defense Evasion: T1562（防御回避）、T1036（偽装）
  • Impact/Observation: 文面の自然さ・多言語最適化・役職/業務文脈の精度が上がり、クリック率上昇が懸念されますです。

• シナリオB：公開アプリ脆弱性の選別・適用条件の自動要約→迅速侵入

  • Reconnaissance: T1595（アクティブスキャン）
  • Resource Development: T1608（能力ステージング：エクスプロイト調整）
  • Initial Access: T1190（公開アプリケーションの脆弱性悪用）
  • Discovery/Lateral: T1046（ネットワークサービス探索）、T1021（リモートサービス）
  • Credential Access: T1003（資格情報ダンプ）
  • Command and Control: T1071/T1573（アプリ層/暗号化チャネル）
  • Observation: LLMによるCVE要約・前提条件抽出で、環境適合性の見極めが高速化し、初期アクセス成功率とテンポが向上しやすいです。

• シナリオC：OT/ICS含む重要インフラの“運用手順書化”

  • Reconnaissance: T1590（ネットワーク情報収集）、T1592（ホスト情報）
  • Discovery: T1082（システム情報）、T1018（リモートシステム発見）
  • Impact: 運用文書・標準手順の要約/手順化にLLMを使うことで、OT特有の慎重さが必要な工程でも“人間の計画作業”が時短されうる、という仮説です（実装可否・有効性は未知）です。

影響面では、攻撃の“質”というより“回転数”の上昇が肝です。標的領域が重要インフラに及ぶ場合、正常系運用に見える通信・文書のやり取りに巧妙に寄り添う形での作戦が増え、誤検知回避とのトレードオフを突かれやすくなります。サプライチェーンや共同運用（JV、米系SaaS活用）を通じ、日本拠点も巻き込まれる波及を前提に備えるべき局面です。

セキュリティ担当者のアクション

“AIで攻撃が速くなる”前提で、守りを“速く・安定に”するための具体策です。

• ガバナンスと可観測性

  • 生成AIの社内利用ポリシーを明文化し、許可モデルと用途、接続経路（SaaS/自己ホスト）を台帳化しますです。
  • LLMゲートウェイ/CASBを活用し、プロンプト/出力のメタデータ（ユーザ、時刻、用途分類）をログ化してSIEMに連携しますです（内容そのものではなく、ボリューム・頻度・用途傾向の可観測性を重視）です。
  • 取引先・委託先にもAI利用の最小基準（アクセス制御、ログ保持、異常時の遮断手順）を契約条項化しますです。

• 検知・レスポンスの再マッピング（MITRE ATT&CK準拠）

  • Recon/Resource Development段のアクティビティを“結果から”捉える検知を強化しますです（大量のOSINTアクセス痕、短期間で多言語のメールテンプレ更新、スキャンのレンジと深度の同時最適化などの行動特徴）です。
  • Initial Access以降は、T1190/T1566に対するユースケースを再評価し、コンテキスト強化（ユーザ役割・端末健全性・セッションリスク）で内在リスクを下げますです。
  • 既存プレイブックに“LLM補助が疑われる兆候”チェックリストを追加し、調査分岐と封じ込め判断の時限を短縮しますです。

• メール・ID・エンドポイントの堅牢化（“速さ”に耐える守り）

  • メールはDMARC・SPF・DKIMの整備は大前提として、言語・役職文脈の自然さに依存しないリンク実行/添付マクロ起点の動的検知（URLリライト＋サンドボックス）を既定化しますです。
  • IDはMFAをFIDO2へ段階移行し、リスクベース条件付きアクセスで地理・デバイス態様を統制しますです。
  • EDRはPowerShell等のスクリプト実行（T1059）と標準ツール悪用（LOLbins）を過剰検知にならぬ閾値で相関・封じ込めできるよう、例外管理を棚卸ししますです。

• 脆弱性管理の“順序付け”をAI前提で刷新

  • 攻撃者側の“適用条件の高速見極め”に対抗し、こちらも資産実態（バージョン/設定/露出）に基づく優先度付けを自動化しますです。
  • インターネット露出系（公開アプリ、境界機器）のCVEはSLAを短縮し、メンテナンス窓口の前倒し運用を検討しますです。

• プロバイダ連携と出口戦略

  • クラウドAI事業者からの不正利用シグナル（悪用検知、トークン停止等）の受信・エスカレーション経路を明確化しますです。
  • 事業者側の抑止が効かなくなった場合（自己ホスト型モデル悪用の台頭）に備え、社内検知を下流TTP中心に切り替える“出口戦略”を、年次演習に組み込みますです。

• ブルーチームのAI活用

  • IOC要約、ケースノート生成、YARA/Sigma作成支援など“知的作業”の自動化を推進し、インシデント当たりの解析時間短縮を数値管理しますです。
  • プロンプトはセキュア設計（社外秘流出防止、個人情報マスキング）を徹底し、モデル評価/モデル漂白（出力偏り・幻覚率の把握）を四半期レビューで実施しますです。

最後に、今回のメトリクス群が示唆するのは、“目新しさと信頼度が高い一方、行動転換は今すぐ始められる”という現実です。つまり「様子見」の余地は小さく、まずはプレイブックとポリシーを“AI時代のOpsテンポ”仕様に上方修正することが、最も費用対効果の高い一手です。攻守ともにAIが常在戦場化するほど、基本の徹底と可観測性の差が勝負を分けますです。

参考情報

• The Register: Google: China’s APT31 used Gemini to plan US cyber-attacks（Googleの説明に基づく報道）: https://go.theregister.com/feed/www.theregister.com/2026/02/12/google_china_apt31_gemini/