--- title: 激増するAI悪用攻撃に対抗する守りのAI活用最前線 @ GMO IERAE HackNight #4 「AI時代のセキュリティ攻防戦」 tags: author: [GMOサイバーセキュリティ byイエラエ株式会社](https://www.docswell.com/user/ierae) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/37K9N48M7D.jpg?width=480 description: GMO IERAE HackNight #4 「AI時代のセキュリティ攻防戦」 https://ierae.connpass.com/event/391105/ published: June 05, 26 canonical: https://www.docswell.com/s/ierae/Z3JE11-hacknight04-ds --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/37K9N48M7D.jpg) 激増するAI悪用攻撃に対抗する 守りのAI活用最前線 Shungo Kumasaka / @hinoshiba Shigefumi Sakata / @sys_socket # Page. 2 ![Page Image](https://bcdn.docswell.com/page/LJ3WVL22J5.jpg) ディフェンシブセキュリティ部SOCイノベーション課 シニアエンジニア, CISSP 熊坂 駿吾 (Shungo Kumasaka) 2022年よりGMOイエラエSOC立ち上げメンバとして、自社SOC基盤の開発主幹。また、国内外での 大学にてサイバーセキュリティ講師経験を有する。直近の活動では、Botconf 2026 Sprint CFP 採 択される。前職では、大手電気通信事業者にて脆弱性調査分析環境を開発し、Apache HTTPDへの 脆弱性報告経験を持つ。 最近の趣味: Offsec 資格 RTA 2025/08 ~ # Page. 3 ![Page Image](https://bcdn.docswell.com/page/8JDK8NZ6EG.jpg) 自己紹介 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 # Page. 4 ![Page Image](https://bcdn.docswell.com/page/VEPK85YZ78.jpg) # Page. 5 ![Page Image](https://bcdn.docswell.com/page/27VVNPGM7Q.jpg) https://www.cve.org/About/Metrics # Page. 6 ![Page Image](https://bcdn.docswell.com/page/5JGLKP8X7L.jpg) # Page. 7 ![Page Image](https://bcdn.docswell.com/page/47QYN295EP.jpg) 攻めの一点突破 守りの全面防御 . # Page. 8 ![Page Image](https://bcdn.docswell.com/page/KE4WGLXVJ1.jpg) 参考: NIST Cybersecurity Framework (CSF) 2.0 / NIST SP 800-61 Rev.3 (Incident Response) / NIST SP 800-86 (Digital Forensics) # Page. 9 ![Page Image](https://bcdn.docswell.com/page/L71YDLN4JG.jpg) 量 速度 と が欲しい。 僕らもAI使おうZE # Page. 10 ![Page Image](https://bcdn.docswell.com/page/G7WGYV4ZE2.jpg) LTでは、ここらへんの一部！ 参考: NIST Cybersecurity Framework (CSF) 2.0 / NIST SP 800-61 Rev.3 (Incident Response) / NIST SP 800-86 (Digital Forensics) # Page. 11 ![Page Image](https://bcdn.docswell.com/page/4JZLX42LE3.jpg) 参考: NIST Cybersecurity Framework (CSF) 2.0 / NIST SP 800-61 Rev.3 (Incident Response) / NIST SP 800-86 (Digital Forensics) # Page. 12 ![Page Image](https://bcdn.docswell.com/page/YE6W43VMEV.jpg) 脆弱性検証の巣立ちを目指して。 # Page. 13 ![Page Image](https://bcdn.docswell.com/page/GE5MQLDQE4.jpg) 脆弱性対応の平均日数 悪用 平均 -1日 防御者のパッチ適用平均 137日 4ヶ月以上 https://www.stingrai.io/blog/vulnerability-statistics-2026 # Page. 14 ![Page Image](https://bcdn.docswell.com/page/9729PL8WJR.jpg) 企業のネットワークって、複雑 # Page. 15 ![Page Image](https://bcdn.docswell.com/page/DJY45Q697M.jpg) 一次対応としてのシグネチャ配布 -1日 n日 137日 どれだけ早く配布できるかが勝負 # Page. 16 ![Page Image](https://bcdn.docswell.com/page/V7NYNKZDE8.jpg) 収集 検証 配布 セキュリティ製品A 脆弱性A セキュリティ製品B セキュリティ製品C 脆弱性B セキュリティ製品D # Page. 17 ![Page Image](https://bcdn.docswell.com/page/YJ9PRVZ873.jpg) 収集 検証 配布 セキュリティ製品A 脆弱性A セキュリティ製品B セキュリティ製品C 脆弱性B セキュリティ製品D With AI # Page. 18 ![Page Image](https://bcdn.docswell.com/page/GJ8DWP1ZJD.jpg) ニュースの集め方: BadWolf2 など # Page. 19 ![Page Image](https://bcdn.docswell.com/page/LJLMN1Q1ER.jpg) ニュースの集め方: Temporal Burst Filtering 話題A 話題B 話題C # Page. 20 ![Page Image](https://bcdn.docswell.com/page/47MYXW157W.jpg) ニュースの集め方: Temporal Burst Filtering 話題A 話題B 話題C # Page. 21 ![Page Image](https://bcdn.docswell.com/page/P7R9NYLZE9.jpg) 脆弱性検証: スダチテンプレート # Page. 22 ![Page Image](https://bcdn.docswell.com/page/PJXQNGW17X.jpg) 脆弱性検証: スダチテンプレート https://developers.gmo.jp/technology/42691/ # Page. 23 ![Page Image](https://bcdn.docswell.com/page/3JK9N4VMJD.jpg) 脆弱性検証: スダチテンプレート # Page. 24 ![Page Image](https://bcdn.docswell.com/page/LE3WVLM2E5.jpg) 脆弱性検証: スダチテンプレート x STYRAX STYRAX SRC Snort Rule 中間言語 DST Cloudflare WAF Rule # Page. 25 ![Page Image](https://bcdn.docswell.com/page/8EDK8N667G.jpg) 脆弱性検証: スダチテンプレート Fakenet-NG Victim SPAN(pcap) Snort Attacker # Page. 26 ![Page Image](https://bcdn.docswell.com/page/V7PK8NZZJ8.jpg) AIエージェント アーキテクチャ ア プ リ ケ ー シ ゲ ー ト オ ー ケ ウ ス ェ ト イ レ ー シ ョ プ ン ロ 層 キ シ 層 RAG Agents ョ ン 層 外部 リソース 推 基 論 盤 サ ー バ モ 層 デ ル 層 # Page. 27 ![Page Image](https://bcdn.docswell.com/page/2JVVNKWMJQ.jpg) AIエージェント アーキテクチャ ア プ リ ケ ー シ ゲ ー ト オ ー ケ ウ ス ェ ト イ レ ー シ ョ プ ン ロ 層 キ シ 層 RAG Agents ョ ン 層 外部 リソース 推 基 論 盤 サ ー バ モ 層 デ ル 層 # Page. 28 ![Page Image](https://bcdn.docswell.com/page/5EGLKQDXJL.jpg) AIエージェント アーキテクチャと 誤差の累積の防止 ア プ リ ケ ー シ ゲ ー ト オ ー ケ ウ ス ェ ト イ レ ー シ ョ プ ン ロ 層 キ シ 層 RAG Agents ョ ン 層 外部 リソース 推 基 論 盤 サ ー バ モ 層 デ ル 層 # Page. 29 ![Page Image](https://bcdn.docswell.com/page/4JQYNK157P.jpg) AIエージェント アーキテクチャ と 誤差の累積の防止 # Page. 30 ![Page Image](https://bcdn.docswell.com/page/K74WGPRVE1.jpg) AIエージェント アーキテクチャ と 誤差の累積の防止 # Page. 31 ![Page Image](https://bcdn.docswell.com/page/LJ1YD9Q4EG.jpg) AIエージェント アーキテクチャ と 誤差の累積の防止 • 何も出ない • CVE-xxxx-2026 と CVE-xxxx-20261 が混ざる • 近い製品の検証が混ざる （例: 月次パッチでWordを検証していたら、急にExcelを検証する） 生成 確認 # Page. 32 ![Page Image](https://bcdn.docswell.com/page/GJWGYQMZ72.jpg) スダチの実際のタスクフローイメージ サンプル 攻撃コード作成 選定 概要 ソフトウェア確認 攻撃検証 レポート作成 証跡の取得 レポート評価 詳細調査 シグネチャ案作成 パッチ前後 ソースコード入手 遮断試験 PoC入手 反復レビュー箇所 # Page. 33 ![Page Image](https://bcdn.docswell.com/page/4EZLXWQL73.jpg) お次はこちら 参考: NIST Cybersecurity Framework (CSF) 2.0 / NIST SP 800-61 Rev.3 (Incident Response) / NIST SP 800-86 (Digital Forensics) # Page. 34 ![Page Image](https://bcdn.docswell.com/page/Y76W4G6M7V.jpg) AIエージェントで 爆速フォレンジック調査 # Page. 35 ![Page Image](https://bcdn.docswell.com/page/G75MQV6Q74.jpg) AGENDA 本日お話しする5つのこと 01 DFIRと、AI で何が難しいか 02 システム全体像 03 技術詳細 ① 〜 ③ 04 AI ができること / 人間がやること 05 まとめ ログ・バイナリの非構造性、痕跡の希少性、説明責任 — DFIRに特有の制約 プロンプト1行から レポーティングまで — エージェント連携の全体設計 コンテキスト管理 / claim と証拠の紐づけ / Wiki を AI に読ませる behaviors の構造化は AI、context と attribution の判断は人 LLM × DFIR の設計に収束した 3 つの原則 # Page. 36 ![Page Image](https://bcdn.docswell.com/page/9J29P3MWER.jpg) 01 / 何が難しいのか フォレンジック調査での AI 利用の難点 #01 #02 #03 #04 #05 AIが読みづらい アーティファクト 数百 GB × 数万件 インシデント 情報の不足 ハルシネーション 機密性の壁 EVTX / Registry / $MFT / Prefetch は元はバイナリファイ ル AI 可読 (CSV / JSONL) へ の変換 パースしても EVTX 数十万行 / Registry 数万キー 何も考えずに入力すれば、コンテ キストテキストウィンドウが一発で 埋まる AIが出すエビデンスの根拠が曖 昧で間違っているケースがある それっぽく言ってくるので信じてし まう AIによるデータ学習、 AIエージェントによる勝手な操作 の懸念 データ持ち出し不可、ローカル完 結が前提 インシデント発生時は、インシデ ント発生した事業者も情報が把 握できていない。 断片的なインシデントの情報の みでは、AIによる調査でパフォー マンスが出せないケースもある → これらに対するアプローチを一部紹介 # Page. 37 ![Page Image](https://bcdn.docswell.com/page/DEY451X9JM.jpg) 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 # Page. 38 ![Page Image](https://bcdn.docswell.com/page/VJNYN21D78.jpg) 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 # Page. 39 ![Page Image](https://bcdn.docswell.com/page/YE9PR158J3.jpg) 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 : レポートに乗せる主張を根拠付きで管理する台帳 「やってみてから後悔」を構造的に禁止。落ちても別のエージェントが再開 # Page. 40 ![Page Image](https://bcdn.docswell.com/page/GE8DW4YZED.jpg) 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 で弾く # Page. 41 ![Page Image](https://bcdn.docswell.com/page/LELMN6417R.jpg) 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 / 実行時の 典型的なミス 調査を平準化させる # Page. 42 ![Page Image](https://bcdn.docswell.com/page/4JMYX5K5JW.jpg) 07 / AI と人の境界 AI ができること / 人間がやること AI 人 エージェントに任せる 人間がやる ▸ 大規模ログの横断検索 estimate API で当たりをつけ、三段戦略で絞り込む ▸ 発見 → 主張の構造化 findings claims を紐づけ、 Generator / Reviewer / Validator で自己検証 ▸ Wiki RAG で観点漏れを防ぐ MITRE 12 種・anti-patterns・playbooks を役割×仮説で読み込み反映 ▸ 大枠のレポーティング レポートテンプレートベースのレポーティング 調査員の助けになるようなレポートの作成 ▸ 物理保全 / CoC 連鎖管理 オンサイトでの対応。Chain of Custody : 電子的証拠が法的効力を持つた めに必要。 ▸ インシデントのヒアリング インシデントの状況整理や今後の対応など ▸ 白証明 (観測範囲の定義) 消されたログ・契約で取れない artifact。「無かった」と「未確認」の線引きは 人が説明 # Page. 43 ![Page Image](https://bcdn.docswell.com/page/PJR9N3XZ79.jpg) Wrap-up まとめ — LLM × DFIR の設計に収束した 3 つ Context Grounding Learning コンテキストエンジニアリング estimate API で叩く前に件数概算 / MD 正本で会話履歴に頼らない / エージェントが落ちても再開できる 証拠と根拠を必ず紐づける + 3 段分離 主張は必ず証拠に紐づく / evidence_refsで実在検証 / 書き手・レビュー・検証を独立した役割に アーティファクト Wiki + 半自動還流 調査の均質化/ 調査完了時に Wiki 更新提案・調査すればするほど賢くなる仕組み LLM は誰でも使える — 差別化するためにはその領域の深い知識が必要 # Page. 44 ![Page Image](https://bcdn.docswell.com/page/PEXQN461JX.jpg) 防御にAIを活用するデザインは、 いつから？ # Page. 45 ![Page Image](https://bcdn.docswell.com/page/3EK9NZ1MED.jpg) https://developers.gmo.jp/technology/42691/ # Page. 46 ![Page Image](https://bcdn.docswell.com/page/L73WVDQ275.jpg) https://developers.gmo.jp/technology/42691/ # Page. 47 ![Page Image](https://bcdn.docswell.com/page/87DK8P96JG.jpg) 激増するAI悪用攻撃に対抗する 守りのAI活用最前線 Shungo Kumasaka / @hinoshiba Shigefumi Sakata / @sys_socket # Page. 48 ![Page Image](https://bcdn.docswell.com/page/VJPK8N9ZE8.jpg)