激増するAI悪用攻撃に対抗する守りのAI活用最前線 @ GMO IERAE HackNight #4 「AI時代のセキュリティ攻防戦」

激増するAI悪用攻撃に対抗する 守りのAI活用最前線 Shungo Kumasaka / @hinoshiba Shigefumi Sakata / @sys_socket

ディフェンシブセキュリティ部SOCイノベーション課 シニアエンジニア, CISSP 熊坂 駿吾 (Shungo Kumasaka) 2022年よりGMOイエラエSOC立ち上げメンバとして、自社SOC基盤の開発主幹。また、国内外での 大学にてサイバーセキュリティ講師経験を有する。直近の活動では、Botconf 2026 Sprint CFP 採 択される。前職では、大手電気通信事業者にて脆弱性調査分析環境を開発し、Apache HTTPDへの 脆弱性報告経験を持つ。 最近の趣味: Offsec 資格 RTA 2025/08 ~

自己紹介 GMO サイバーセキュリティbyイエラエ株式会社 ディフェンシブセキュリティ部フォレンジック課 坂田 成史 (Shigefumi Sakata) GREM, GCFA, GIAC Advisory Board, QSA, PCI PFI 2017年にセキュリティベンダに新卒で入社し、フォレンジック業務とIoTペネトレーションテスト業務を経て、2020 年から現職。フォレンジック調査やインシデントレスポンス支援業務を担当。IoTデバイスなどのフォレンジック技術 検証も担当しつつ、社内のフォレンジックツールの開発を主導する。 インシデント発生時の迅速な原因究明と被害拡大防止により、お客様のビジネス継続を 支えています ➢ 活動 • HITCON CYBER RANGE 2024 Final – 3 rd place • Hardening Project 2020(H3DX) – Participant of Marktplace • CODE BLUE 2019 ICS Cyber hacking Challenge – 1st place • CODE BLUE 2018 Car Hacking Village – 3 rd place

https://www.cve.org/About/Metrics

• https://www.cve.org/About/Metrics

攻めの一点突破 守りの全面防御 .

参考: NIST Cybersecurity Framework (CSF) 2.0 / NIST SP 800-61 Rev.3 (Incident Response) / NIST SP 800-86 (Digital Forensics)

量 速度 と が欲しい。 僕らもAI使おうZE

LTでは、ここらへんの一部！ 参考: NIST Cybersecurity Framework (CSF) 2.0 / NIST SP 800-61 Rev.3 (Incident Response) / NIST SP 800-86 (Digital Forensics)

参考: NIST Cybersecurity Framework (CSF) 2.0 / NIST SP 800-61 Rev.3 (Incident Response) / NIST SP 800-86 (Digital Forensics)

脆弱性検証の巣立ちを目指して。

脆弱性対応の平均日数 悪用 平均 -1日 防御者のパッチ適用平均 137日 4ヶ月以上 https://www.stingrai.io/blog/vulnerability-statistics-2026

• https://www.stingrai.io/blog/vulnerability-statistics-2026

企業のネットワークって、複雑

一次対応としてのシグネチャ配布 -1日 n日 137日 どれだけ早く配布できるかが勝負

収集 検証 配布 セキュリティ製品A 脆弱性A セキュリティ製品B セキュリティ製品C 脆弱性B セキュリティ製品D

収集 検証 配布 セキュリティ製品A 脆弱性A セキュリティ製品B セキュリティ製品C 脆弱性B セキュリティ製品D With AI

ニュースの集め方: BadWolf2 など

ニュースの集め方: Temporal Burst Filtering 話題A 話題B 話題C

ニュースの集め方: Temporal Burst Filtering 話題A 話題B 話題C

脆弱性検証: スダチテンプレート

脆弱性検証: スダチテンプレート https://developers.gmo.jp/technology/42691/

• https://developers.gmo.jp/technology/42691/

脆弱性検証: スダチテンプレート

脆弱性検証: スダチテンプレート x STYRAX STYRAX SRC Snort Rule 中間言語 DST Cloudflare WAF Rule

脆弱性検証: スダチテンプレート Fakenet-NG Victim SPAN(pcap) Snort Attacker

AIエージェント アーキテクチャ ア プ リ ケ ー シ ゲ ー ト オ ー ケ ウ ス ェ ト イ レ ー シ ョ プ ン ロ 層 キ シ 層 RAG Agents ョ ン 層 外部 リソース 推 基 論 盤 サ ー バ モ 層 デ ル 層

AIエージェント アーキテクチャ ア プ リ ケ ー シ ゲ ー ト オ ー ケ ウ ス ェ ト イ レ ー シ ョ プ ン ロ 層 キ シ 層 RAG Agents ョ ン 層 外部 リソース 推 基 論 盤 サ ー バ モ 層 デ ル 層

AIエージェント アーキテクチャと 誤差の累積の防止 ア プ リ ケ ー シ ゲ ー ト オ ー ケ ウ ス ェ ト イ レ ー シ ョ プ ン ロ 層 キ シ 層 RAG Agents ョ ン 層 外部 リソース 推 基 論 盤 サ ー バ モ 層 デ ル 層

AIエージェント アーキテクチャ と 誤差の累積の防止

AIエージェント アーキテクチャ と 誤差の累積の防止

AIエージェント アーキテクチャ と 誤差の累積の防止 • 何も出ない • CVE-xxxx-2026 と CVE-xxxx-20261 が混ざる • 近い製品の検証が混ざる （例: 月次パッチでWordを検証していたら、急にExcelを検証する） 生成 確認

スダチの実際のタスクフローイメージ サンプル 攻撃コード作成 選定 概要 ソフトウェア確認 攻撃検証 レポート作成 証跡の取得 レポート評価 詳細調査 シグネチャ案作成 パッチ前後 ソースコード入手 遮断試験 PoC入手 反復レビュー箇所

お次はこちら 参考: NIST Cybersecurity Framework (CSF) 2.0 / NIST SP 800-61 Rev.3 (Incident Response) / NIST SP 800-86 (Digital Forensics)

AIエージェントで 爆速フォレンジック調査

AGENDA 本日お話しする5つのこと 01 DFIRと、AI で何が難しいか 02 システム全体像 03 技術詳細 ① 〜 ③ 04 AI ができること / 人間がやること 05 まとめ ログ・バイナリの非構造性、痕跡の希少性、説明責任 — DFIRに特有の制約 プロンプト1行から レポーティングまで — エージェント連携の全体設計 コンテキスト管理 / claim と証拠の紐づけ / Wiki を AI に読ませる behaviors の構造化は AI、context と attribution の判断は人 LLM × DFIR の設計に収束した 3 つの原則

01 / 何が難しいのか フォレンジック調査での AI 利用の難点 #01 #02 #03 #04 #05 AIが読みづらい アーティファクト 数百 GB × 数万件 インシデント 情報の不足 ハルシネーション 機密性の壁 EVTX / Registry / $MFT / Prefetch は元はバイナリファイ ル AI 可読 (CSV / JSONL) へ の変換 パースしても EVTX 数十万行 / Registry 数万キー 何も考えずに入力すれば、コンテ キストテキストウィンドウが一発で 埋まる AIが出すエビデンスの根拠が曖 昧で間違っているケースがある それっぽく言ってくるので信じてし まう AIによるデータ学習、 AIエージェントによる勝手な操作 の懸念 データ持ち出し不可、ローカル完 結が前提 インシデント発生時は、インシデ ント発生した事業者も情報が把 握できていない。 断片的なインシデントの情報の みでは、AIによる調査でパフォー マンスが出せないケースもある → これらに対するアプローチを一部紹介

02 / 実機で動いているもの プロンプト 1 行から レポーティングまで 約30分 /full-investigate evidenes/diskimage_E01 ↓ orchestrator が指令塔 配下のエージェント (段階別 / 調査用エージェント / Validator) が動く ↓ 抽出 + バイナリ → CSV/JSONL 化 アーティファクト自動抽出 → 既存のツールやPowerShell で AI 可読化 ↓ データベース+ アーティファクトWiki + 根拠付け 検索 / 状態 / 主張の 3 軸 ↓ 概要/タイムライン/Attack Flow/IoC/ペイロード … レポートテンプレートを元に タイムライン / MITRE / 横展開 artifact を AI 可読化 → 検索 → claim 化 → レポート1 プロンプトで通す 対象 サンプルディスクイメージ https://www.iblue.team/ctf-challenges/compromised-windows-server-2022simulation

• https://www.iblue.team/ctf-challenges/compromised-windows-server-2022-

03 / バイナリ → AI 可読化 アーティファクトを AI が読める形に変換する ディスクイメージ → 抽出 → PowerShellやパーサでパース → CSV / JSONL に整形 ディスクイメージ (E01 / dd / VMDK) ↓ MCPサーバ で抽出 Artifacts MFT $UsnJrnl:$J Prefetch EventLog Registry Amcache Web Browsers ↓ PowerShellでパース CSV / JSONL (AI 可読な形式) ↓ データベース投入後、エージェントが SQL で検索 / 集計 AI エージェントが読む Recycle Bin

04 / コンテキストエンジニアリング ① — LLM の有限コンテキストをどう守るか 対策Ⅰ. 三段戦略 対策 Ⅱ. 状態を MD へ保存 叩く前に件数概算を取る MCP ツールを設計 会話履歴は信用しない。長時間調査での健忘耐性 basic / summary 全体感把握 MD 中間ファイル (人 + エージェントが読み書き) tasks/*.md : 調査作業の一覧、ステータス artifact-inventory.md : 調査対象アーティファクトの確認ステータス *_estimate timeline.md : 調査で発見した重要なイベントの整理 cost_hint = low / moderate / high / very_high report-claim-ledger.md : 主張・根拠・反証・制約の対応 queries/*.md : エージェントが使用したクエリを保存(再現性) mode="full" evidence-notes/E*.md : 主張の根拠(証拠)を記録 明細 + log_id 取得 DB 索引 (検索の自動足跡) low / moderate → 即 full / high → フィルタ追加 / very_high → summary に倒す investigation_log : search_* 呼び出しを記録で再現性確保 claim_ledger : レポートに乗せる主張を根拠付きで管理する台帳 「やってみてから後悔」を構造的に禁止。落ちても別のエージェントが再開

05 / ハルシネーション対策 ② — 主張を必ず証拠に紐づける 2 層分離： 発見 -> 解釈 finding (発見) — E001.. annotate_finding(logId=N, finding="...", mitre="...") 3段分離 Generator / Reviewer / Validator 3つの独立したコンテキストで「書く/全体俯瞰/個別に裏取り」を分業 Generator report-writer Claim→レポート文章を書く claim_001.. Reviewer state: hypothesis → supported → final disputed negative レポート + claimを読んで指摘 hypothesis : 仮説 / supported : 2 つ以上の artifact で裏付け final : 最終確定 / disputed : 仮説段階で反証発見 / negative : 痕跡なし supportingLogIds: [38, 39, ...] counterLogIds: [反証 log_id] evidence_refs: [E001, E002] mitreAttack: T1078.002, T1021.001 Validator review claim-validator Reviewerの指摘を1claim単位で再検証 裏付けの無い主張は構造的に書けない。どこかを間違えても self-check で弾く

06 / RAG とアーティファクト Wiki ③ — 調査員のナレッジWiki を AI に読ませる アーティファクト Wiki 調査を重ねるほど Wiki が育つ LLMがゼロベースで調査観点を検討するとトークン消費増加、調査作業のムラに 繋がる Wiki 差分提案ツール (半自動) base-info/ 基本情報 OS / TZ / ホスト / dataset priority 1 調査完了 MITRE Tactic 12 種 + 「痕跡なし観点」 2 既存のWikiとdiff 三段戦略 / artifact 別クエリ / IoC pivot 3 Wikiの更新を提案 4 人間がレビューし反映 重要な各チャネル / Registry / MFT artifacts/アーティファクト別 EVTX / USN / Prefetch ほか deep-dive/ tools/ playbooks/ 深堀調査 クエリのコツ シナリオ別 anti-patterns/ 失敗例 ランサム / フィッシング / DC 侵害ほか クエリ / 調査 / レポート / agent / 実行時の 典型的なミス 調査を平準化させる

07 / AI と人の境界 AI ができること / 人間がやること AI 人 エージェントに任せる 人間がやる ▸ 大規模ログの横断検索 estimate API で当たりをつけ、三段戦略で絞り込む ▸ 発見 → 主張の構造化 findings claims を紐づけ、 Generator / Reviewer / Validator で自己検証 ▸ Wiki RAG で観点漏れを防ぐ MITRE 12 種・anti-patterns・playbooks を役割×仮説で読み込み反映 ▸ 大枠のレポーティング レポートテンプレートベースのレポーティング 調査員の助けになるようなレポートの作成 ▸ 物理保全 / CoC 連鎖管理 オンサイトでの対応。Chain of Custody : 電子的証拠が法的効力を持つた めに必要。 ▸ インシデントのヒアリング インシデントの状況整理や今後の対応など ▸ 白証明 (観測範囲の定義) 消されたログ・契約で取れない artifact。「無かった」と「未確認」の線引きは 人が説明

Wrap-up まとめ — LLM × DFIR の設計に収束した 3 つ Context Grounding Learning コンテキストエンジニアリング estimate API で叩く前に件数概算 / MD 正本で会話履歴に頼らない / エージェントが落ちても再開できる 証拠と根拠を必ず紐づける + 3 段分離 主張は必ず証拠に紐づく / evidence_refsで実在検証 / 書き手・レビュー・検証を独立した役割に アーティファクト Wiki + 半自動還流 調査の均質化/ 調査完了時に Wiki 更新提案・調査すればするほど賢くなる仕組み LLM は誰でも使える — 差別化するためにはその領域の深い知識が必要

防御にAIを活用するデザインは、 いつから？

https://developers.gmo.jp/technology/42691/

• https://developers.gmo.jp/technology/42691/

https://developers.gmo.jp/technology/42691/

• https://developers.gmo.jp/technology/42691/

激増するAI悪用攻撃に対抗する 守りのAI活用最前線 Shungo Kumasaka / @hinoshiba Shigefumi Sakata / @sys_socket