Black Hat USA 2026参加レポート｜AIエージェント・パスキー・AD脆弱性など注目5セッションと企業の対策

世界最大級のサイバーセキュリティイベントである「Black Hat USA 2026（2026年8月、米ラスベガス）」では、「AI, ML & Data Science」が最多のテーマとなり、AIエージェントの隔離設計、パスキーの実装不備、Active Directoryの新たな脆弱性が注目を集めました。本記事では、現地に参加した当社メンバーが注目の5セッションを解説し、企業に求められる3つの防衛シフトを整理します。 

※本稿の内容は各講演の内容について筆者の知見を基に見解や解釈を加えたものであり、必ずしも内容の正確性を保証するものではありません。あらかじめご了承ください。

Black Hat USA 2026とは？

Black Hatは、RSA Conferenceなどと並ぶ「世界最大級のサイバーセキュリティカンファレンス」の一つであり、サイバーセキュリティ従事者が世界中から集結する一大イベントです。

毎年アメリカ、アジア、ヨーロッパ、中東の4地域で開催されており、今回参加したのはその中で最大規模のBlack Hat USAです。

Black Hat USAではサイバーセキュリティに関連する多様なコンテンツが扱われ、例えばサイバーセキュリティに関する最新の研究成果が発表されるBriefingsや、各ベンダー出展ブースにて最新ソリューションの紹介が行われるBusiness Hall、セキュリティ技術に関するハンズオントレーニングを行うTrainings、そしてオープンソースのセキュリティツールをデモ形式で紹介するArsenalなどが提供されます。

今年の開催状況と現地の様子

今年のイベントは8月1日〜6日の日程で、例年通りラスベガスのMandalay Bay Convention Centerにて開催されました。

8月1日〜4日には実践的な技術習得を目的としたTrainingsが行われ、8月5日〜6日にはメインカンファレンスであるBriefingsやBusiness Hallの展示、Arsenalのデモ公開が行われました。

会場は、最先端の脅威研究を求めて世界中から集まった2万3,000人以上（主催者発表）の技術者や専門家の熱気に包まれていました。

Keynoteの様子

Business Hallの様子

Briefingsセッションの紹介

最新の研究成果が発表されるBriefingsでは、今年も多岐にわたる分野から非常に多くの発表がありました。今年の傾向を掴むため、カテゴリ別の統計データを見てみましょう。

カテゴリ別のセッション数（Briefings/Sponsored/Arsenal）

今年のセッションカテゴリ別の内訳（主要なものを抜粋）は以下の通りとなっています。

上記の統計からも明らかなように、Briefings、Sponsored、Arsenalの全領域において「AI, ML & Data Science」が最多（または最上位）を占めています。

特にSponsored SessionsにおけるAIセッション（77件）とSOC/IR（Security Operations & Incident Response）セッション（75件）がともに多いことは、AI技術をいかに実務（特に脅威検知・対応）へ落とし込むかという業界の強い関心を反映しています。

ここからは、当社メンバーが聴講・調査したセッションのうち、特に日本のエンタープライズ企業にとっても重要となる5つの注目セッションを詳しくご紹介します。

セッション紹介①（AIセキュリティ）：“Threat Modeling LLMs: The PHANTOM-B model”

◆概要

脅威モデリングの第一人者で、著書『Threat Modeling: Designing for Security』などで知られるAdam Shostack氏による、大規模言語モデル（LLM）を組み込んだシステムに特化した新しい脅威モデリングフレームワーク「PHANTOM-B」に関するセッションです。

本セッションでは、AIの利活用が急速に拡大する中、Shostack氏が従来アプローチの課題を踏まえて新たに開発したフレームワークについて解説されました。

◆AI投資の圧力と既存フレームワークの限界

昨今のAIの潮流により、多くの組織において競合に先んじてLLMをプロダクトや業務プロセスに組み込もうとする「IT戦略上の圧力」はかつてないほど強くなっています。その一方、AIシステムを狙う脅威も日々拡大しており、AI自体が新たな攻撃対象となっています。

こうした状況下で、AIに係るセキュリティを確保するための既存リソースとして、MITRE ATLASやNIST AI RMFなどが提供されています。しかしながら、これらは網羅性や詳細さを重視して整備されている分、導入コスト（学習・適用コスト）が高く、開発現場には適合しにくいと指摘しています。

また、従来システム向けの標準的な脅威モデリングフレームワークであるSTRIDEは、LLM固有の脅威（プロンプトインジェクションやハルシネーションなど）を直接考慮して設計されたわけではないため、AI固有の脅威を見落とすおそれがあるとしています。

◆PHANTOM-B：LLM固有の脅威を洗い出すための8つの観点

Shostack氏が新たに開発した「PHANTOM-B」は、LLM固有の脅威にフォーカスを絞り、STRIDEと同様に記憶しやすいニーモニック（頭文字）として構成されたフレームワークです。このように記憶しやすいフォーマットにすることで、設計・開発現場への導入負荷を軽減するとしています。なお、PHANTOM-Bには、LLM固有の脅威に特化するため、基本的なセキュリティ観点はあえて除外されています。

PHANTOM-Bが定義する8つの脅威観点は以下の通りです。

◆発表を聴講した当社メンバーによる感想

AIを取り巻く動向は変化が非常に速く、その背景にある理論も重厚で理解が容易ではありません。そうした中で、膨大なAIセキュリティ研究のエッセンスが8つの観点に集約されている点は、非常に扱いやすく、まさに今求められていた実用的なフレームワークだと感じました。

当フレームワークは、データフローやアーキテクチャに依らないため、プロジェクトの企画段階などソフトウェアライフサイクルの初期段階での活用が期待できる内容と考えられます。なお、PHANTOM-BがLLM固有の脅威に絞られているため、従来のSTRIDEと併用し、相互に補完する使い方が有効だと感じました。

◆参考文献

• ・PHANTOM-B Briefing Slides（https://i.blackhat.com/BH-USA-26/Presentations/BHUS26-Shostack-Threat-Modeling-PHANTOMB.pdf）

• ・PHANTOM-B Whitepaper（https://i.blackhat.com/BH-USA-26/Presentations/BHUS26-Shostack-ThreatModelAI-PHANTOMB-WP.pdf）

• ・Adam Shostack Blog-Why PHANTOM-B（https://shostack.org/blog/why-phantom-b/）

• ・MITRE ATLAS（https://atlas.mitre.org/）

• ・OWASP Top 10 for LLM Applications（https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/）

• ・NIST AI Risk Management Framework（AI RMF）（https://www.nist.gov/itl/ai-risk-management-framework）

セッション紹介②（認証・クラウドセキュリティ）：“Pass-the-Passkey Family of Attacks”

◆概要

本セッションではSpecterOps社のMichael Grafnetter氏により、Microsoftクラウドエコシステムで普及が進むパスキー（Passkey）技術の基礎と、SpecterOps社の研究資料『Pass-the-Passkey』に基づく新たな攻撃手法・脆弱性が解説されました。

パスキーは、Webアプリ、ブラウザ、Windows OS、プラットフォーム認証器（TPMなど）、CTAPプロトコルが連携する公開鍵暗号ベースの認証機構です。従来のパスワードなどの知識認証と異なり、フィッシング耐性や中継攻撃（Relay）への防御を標準で備えます。

しかし、研究により、OSのWebAuthn APIの実装仕様、パスキーのクラウド同期構造、エンドポイント上のマルウェアやサードパーティ製パスワードマネージャーの処理を突いた、新しい攻撃手法（Pass-the-Passkeyなど）の存在が明らかになりました。

◆パスキーの安全性と実装上の課題

パスキーは、FIDO2/WebAuthn規格に基づく公開鍵暗号を用いた高度な認証技術であり、中継攻撃（Relay）や一般的なフィッシングに対して極めて強い耐性を持つよう設計されています。

しかし、Grafnetter氏の研究により、規格を実際のシステム（OS、ブラウザ、クラウドサービス）に組み込む際の実装の不備や、複数デバイス間での共有（同期型パスキー）という利便性への妥協が、新たな脆弱性の温床となっていることが指摘されました。

◆脆弱性を生む3つの背景

１．同期型パスキー（Synced Passkeys）のセキュリティ限界：特定のデバイスに紐づく鍵（Device-bound）とは異なり、Apple iCloudやGoogle、Microsoftなどのクラウドを介してデバイス間で同期されるパスキーは、エンドポイントのメモリ管理やファイル保護が不十分な場合、マルウェアなどによって鍵データや生成されたアサーション（Assertion：認証器が署名して返す認証応答）が横取りされるリスクがあります。

２．サーバ/OS側の検証不備・省略：パフォーマンスの追求や古い実装との互換性維持のため、一部の主要クラウドサービスやWindows WebAuthn APIの実装において、生成されたアサーション（JSON形式）の再利用チェック（Replay Detection）や署名カウンタ（Signature Counter）の厳格なチェックが免除・省略されているケースが存在します。

３．ローカルプロセスとUIの不十分な分離：Windowsのwebauthn.dll APIが、任意のWindow Handleの指定を受け入れて認証ダイアログを表示する仕様になっているため、同じPC上で動く非特権の攻撃プロセスが簡単にUIを乗っ取り、偽装ダイアログを提示しやすい環境になっています。

◆攻撃手法の詳細、バリエーション

Grafnetter氏は概念実証（PoC）を行いながら、多岐にわたる攻撃手法を実演していました。

・パスキーのリプレイ（再利用）＆リレー（中継）攻撃：Windows 11がイベントログ（Microsoft-Windows-WebAuthN/Operational）に完全なWebAuthnアサーションを記録する不備と、サーバ側の再利用検証の緩さを突き、有効時間内（約10分間）に抽出したJSONデータを再利用してなりすましログイン（Replay）を成立させます。また、カスタムブラウザでチャレンジを横取り・中継（Relay）して認証を奪取する手法も示されました。

・パスワードマネージャーの標準フォーマット悪用：サードパーティ製のパスワードマネージャー（KeePassXC、Bitwardenなど）がパスキーのインポート/エクスポートに使用する標準フォーマット「CXF（Credential Exchange Format）」のJSONファイルを侵害済みのエンドポイント上で窃取し、そこから直接不正な署名を生成する手法です。

・APIを悪用した高度なUIスプーフィング（フィッシング）：WebAuthnがブラウザで行う通常のオリジン（ドメイン）検証を回避するため、攻撃者がOSのAPIを直接呼び出し、認証ダイアログを起動します。その際、Edgeなどの信頼されたブラウザのプロセスハンドルを偽装指定することで、ユーザーに正規ブラウザからのダイアログだと信じ込ませて署名を強制させます。

・プロセスインジェクション：正規ブラウザプロセスへインジェクションを行い、アサーションのキャプチャやチャレンジの注入を自動化します。さらに、Windows APIに登録するカスタム認証プラグインの作成、パラメータ改ざん・ファジング、および管理者権限APIを悪用したバックドアの永続化手法にも言及されました。

◆防御観点（多層防御の設計）

パスキーを導入すれば全ての認証攻撃を防げるわけではありません。セッションでは以下の具体的な多層防御（Defense-in-Depth）としての対策が推奨されました。

１．サービス側のバインディング検証の強化：Webアプリ（Relying Party）側で、認証チャレンジを現在のアクティブなセッション状態（CookieやTLSセッションなど）と厳密にバインド（Session Binding）し、アサーションの使い回しや異常な署名カウンタを検知した場合に拒否する。

２．高権限アカウントに対するハードウェアバインド（Device-bound）の強制：Domain Adminや特権クラウド管理者などの重要アカウントには、クラウド同期型パスキーを禁止し、iCloud同期などを行わないTPMや物理的なFIDO2セキュリティキー（YubiKeyなど）のみを許可する。また認証時のアテステーション（Attestation）検証を徹底する。

３．イベントログ問題の修正とエンドポイントの監視：Windows 11を最新パッチ（ログ記録不備が修正されたもの）に更新することに加え、EDRなどでブラウザなどへの不審なプロセスインジェクションや、WebAuthn APIの異常な直接呼び出し、イベントログファイルへの不審なアクセスを監視する。

◆発表を聴講した当社メンバーによる感想

フィッシング耐性により各所にて導入が進んでいるパスキーにおいて、Pass-the-HashやNTLMリレーといった従来のAD環境における攻撃になぞらえた形で攻撃の前提条件の整理や実演を行う、大変興味深い内容でした。高いフィッシング耐性が謳われるパスキー関連の発表であったためか会場は盛況で、攻撃実演の場面では成立した瞬間に大きな拍手も起こっていました。

また、対応する防御観点にも触れ、WebAuthn APIの異常呼び出しをEDRの振る舞い検知で捕捉するべきポイントなどを挙げていた点に、セキュリティリサーチャーとしての真摯な姿勢も感じ取ることができました。

◆参考文献

• ・Pass-the-Passkey Briefing Slides（https://i.blackhat.com/BH-USA-26/Presentations/BHUS26-Grafnetter-Pass-the-Passkey-Slides.pdf）

• ・SpecterOps Research-Pass-the-Passkey Whitepaper（https://specterops.io/wp-content/uploads/sites/3/2026/08/Pass-the-Passkey_A4_v2.pdf）

セッション紹介③（AD・ペネトレーションテスト）：“Identity Crisis: Novel Vulnerabilities Leading to Kerberos Downgrade, DoS, and Full Domain Takeover”

◆概要

本セッションでは、Active Directory（AD）の安全性を揺るがす2つの重大な脆弱性、「KerberLoss（CVE-2026-25177）」と「ResetNightmare（CVE-2026-27912）」が発表されました。いずれも従来のパッチや検証メカニズムを迂回し、サービス拒否（DoS）からドメイン全体の完全奪取（Full Domain Takeover）に至る深刻な影響を及ぼすおそれがあります。

具体的には、KerberLossでは不可視文字を用いてSPNを重複登録させ、特定のサービスを停止させる攻撃（DoS）やセキュリティ強度の低いNTLM認証へのダウングレード（強制降格）を引き起こします。一方のResetNightmareでは、UPN登録時の検証不備と、Kerberosパスワード変更におけるSID検証の回避を突き、一般ユーザー権限でありながらドメイン管理者のパスワードを強制的に書き換えてドメイン全体を乗っ取る（Full Domain Takeover）手法が実証されています。

両脆弱性ともにすでにCVEとして報告され、Microsoftから修正パッチが公開されています。対策として、更新プログラムの迅速な適用に加え、イベントログ（Event ID 5136など）による属性変更監査などを徹底することが重要です。

◆KerberLoss（CVE-2026-25177）

KerberLossは、Active Directory（AD）における「不可視のUnicode文字」の処理不備を突いた脆弱性です。ADのLDAPサーバが特定コードのUnicode文字を無視して処理するため、SPNに不可視文字を含めることで、重複防止チェック（Uniqueness Check）をすり抜け、別のアカウントへ他サーバのSPNを重複登録できてしまいます。

SPNの重複登録が成功すると、攻撃者は状況に応じて以下の3つの攻撃が可能になります。

①サービス停止（DoS）

HOSTエイリアスなどで解決されるはずのSPNを、攻撃者が不可視文字を用いて明示的SPN（Explicit SPN）として別アカウントに登録することで発生します。KDCの検索処理順序において「明示的SPN」は「エイリアス（Alias）解決」よりも優先してマッチする仕様となっているため、誤ったアカウントの鍵でチケットが発行され、正規サーバでの復号エラー（KRB_AP_ERR_MODIFIED）によるサービス停止を引き起こします。

②NTLM認証へのダウングレード

KDCの検索処理でSPNの重複が明示的に検出された場合に発生します。KDCがチケットの発行自体を拒否するため、Kerberos認証が失敗します。その結果、クライアントはNTLM認証へフォールバックし、認証方式のダウングレードが発生することがあります。

③ターゲットサーバの乗っ取り（SPN-Jacking）

従来のSPN-Jackingは被害サーバ側のSPN属性を削除・変更する高い権限が必要でしたが、KerberLossを組み合わせることで属性削除を行うことなく、別サーバ（ServerB）へターゲットサーバ（ServerA）のSPNを重複登録できます。これにより、DCにServerA宛ての管理者チケットをServerBの暗号鍵で誤発行させ、ServerB上で復号することで管理権限を奪取します。

◆ResetNightmare（CVE-2026-27912）

ResetNightmareは、UPN登録時の検証不備と、Kerberosパスワード変更におけるSID検証の回避を突いた脆弱性です。一般ユーザー権限からドメイン管理者のパスワードを直接書き換え、ドメイン全体の奪取（Full Domain Takeover）を可能にします。

本攻撃は、以下の技術的トリックを組み合わせることで成立します。

①ドメイン名を削ったUPN登録と管理者名を含むTGTの取得

ADのUPN重複チェックは「他アカウントのUPN」とのみ比較され、「アカウント名（sAMAccountName）」との重複は検証されません。攻撃者は管理者の完全なUPN（例：Admin@corp.local）との衝突を避けるため、ドメイン名を削ったAdminを自身のUPNに設定して登録します。

この状態で、UPN照合を指示するEnterprise UPN（NT-ENTERPRISE）形式を使い、パスワード変更サービス（kadmin/changepw）宛てに認証要求（AS-REQ）を送信します。KDCは攻撃者のアカウントで認証を通しますが、TGT生成時には、要求されたEnterprise UPN（Admin）がクライアント名（cname）として反映されたチケットが発行されるため、結果として「管理者名（Admin）を含むパスワード変更用TGT」が攻撃者に発行されてしまいます。

②UPN削除による「管理者アカウントへの誤特定」

TGT取得直後、攻撃者は自身のUPNを消去します。その後、TGTを添えてパスワード変更プロトコル（ポート464）を実行すると、パスワード変更処理において本来の管理者アカウントが対象として解決されます。その結果、管理者本人に対するパスワード変更として処理され、管理者のパスワードが強制的にリセットされます。

③TGSを経由しないことによる「SID検証」の回避

過去になりすまし対策として導入されたPAC_REQUESTOR_SIDの検証は、KDCがTGSリクエスト（TGS-REQ）を処理するタイミングでのみ実行される仕様となっていました。

しかし、パスワード変更プロトコルはTGSからサービスチケットを取得する工程がなく、TGTを添えたAP-REQで直接処理されます。そのため、TGS側に仕込まれたSID検証ロジックが一度も呼び出されず、「TGT内の攻撃者SID」と「リクエスト宛先（管理者）のSID」の不一致が検出されないまま、管理者本人のパスワードが強制リセットされます。

◆発表を聴講した当社メンバーによる感想

KerberLossはSPN重複登録による名前解決の不整合を突く攻撃であり、ResetNightmareはUPN登録時の検証不備とSID検証経路の抜け道を突く攻撃です。いずれも「属性上の名前識別」と「内部での照合・検証処理」の間に生じるギャップを悪用している点で共通しており、単なる個別パッチの適用にとどまらず、プロトコル全体の処理フローを網羅的に検証することの重要性を実感させられた発表でした。

◆参考文献

• ・Black Hat USA 2026: Identity Crisis Detail
  （https://blackhat.com/us-26/briefings/schedule/index.html#identity-crisis-novel-vulnerabilities-leading-to-kerberos-downgrade-dos-and-full-domain-takeover-53466）
  ・Semperis Blog-Identity Crisis Research Detail
  （https://www.semperis.com/blog/identity-crisis-novel-vulnerabilities-leading-to-kerberos-downgrade-dos-and-full-domain-takeover/）

セッション紹介④（AIエージェントセキュリティ）：“Caging the Agent: How Roblox Built Multi-Layer Sandboxes to Secure Claude Code at Enterprise Scale”

◆概要

Roblox社のJaskaran Singh氏、Harshit Kumar氏による、Claude Codeを企業環境で安全に利用するための多層サンドボックスの設計・実装に関するセッションです。プロンプトインジェクションなどによって各防御層が突破される可能性を前提に、実行環境（インフラ）側の制御も組み合わせ、わずか4週間で安全なエージェント利用の再開を実現した実践事例です。

◆背景：開発ツール自身が攻撃の踏み台になるリスク

Roblox社内のレッドチームによる検証において、プロンプトインジェクションによってAIエージェントが悪用され、機密情報が流出するリスクが明らかになりました。ゲームエンジンのソースコードや開発者の認証情報の流出、CI/CDシステムへの影響が懸念されたことから、AIエージェントの利用を安全に再開するための対策が必要になりました。

そこで、「エージェントの利用再開」「開発者の生産性維持」「セキュリティ確保」という3つの要件を満たすため、多層サンドボックスの整備に取り組みました。エージェントへの指示だけに頼らず、実行環境側で操作やアクセスを制限することで、開発者の使いやすさと安全性の両立を図りました。

◆サンドボックス設計の4つの基本原則

サンドボックスの設計にあたり、以下の4つの基本原則が示されました。

１．Strong Host Isolation：エージェントの実行環境をホストOSから厳格に分離し、権限昇格につながる経路を設けない。

２．Immutable Configuration：設定をイメージに組み込む、またはroot所有として保護し、実行中の設定変更を認めない。

３．Deny-by-Default Permissions：明示的に許可された場合を除き、すべてのシステムリソースへのアクセスを拒否する。

４．Network Egress Allowlisting：エージェントの通信先を、あらかじめ許可した宛先に限定する。

◆多層防御アーキテクチャ「Multi-Layered Agent Sandboxing」

これらの設計原則に加え、本セッションでは「Multi-Layered Agent Sandboxing」という多層防御アーキテクチャが紹介されました。各層（Ring）が突破される可能性を前提に、以下の5つの防御層を組み合わせてエージェントを保護する構成です。

１．Ring 1: Behavioral Guardrails：CLAUDE.mdや設定ファイルを会社側で管理し、エージェントの行動ルールやアクセス可能な範囲を制限する層。

２．Ring 2: Host Isolation：クラウド上の隔離環境、Docker Sandbox・WSLのmicroVM、macOSのSeatbeltなどを利用し、プロセス・ネットワーク・ファイルシステムへのアクセスを制限する層。

３．Ring 3: Network Segmentation：専用VPNプロファイルやプロキシによる通信先の制限を組み合わせ、エージェントから社内システムへの不要なアクセスや情報流出の経路を制限する層。

４．Ring 4: Centralized Control：LLM Gatewayで通信を集中管理し、プロンプトインジェクションや個人情報の検出を行う層。

５．Ring 5: Global Visibility：エージェントの識別情報を利用者に紐付け、サンドボックスの稼働状態を監視する層。

◆認証情報を保護する仕組み「Credential Injection」

また、認証情報を保護するための対策として紹介されたのが、サードパーティサービスとの連携時に、サービス側の認証情報をエージェントへ直接渡さない「Credential Injection」です。

エージェントがJiraやGitHubなどへアクセスする際、アクセストークン（PATなど）を自身で保持していると、プロンプトインジェクションによって盗み出される危険があります。

これを防ぐため、エージェント環境には外部サービスの認証トークンを直接渡さず、代わりに「MCP Gateway」を配置します。エージェントが利用者に紐付く有効期間の短いJWTを使ってリクエストを送ると、MCP Gatewayが中継時に外部サービスの認証トークンを代理で付与して送信します。これにより、エージェントは外部サービスの認証トークンを保持・参照することなくアクセスできます。

◆発表を聴講した当社メンバーによる感想

エージェントに高い自由度を与えながらセキュリティも確保するという、一見すると両立が難しい課題に対して、エージェントの振る舞いを制限するだけではなく、実行環境の隔離やアクセス制御を組み合わせるアプローチが特に印象に残りました。

また、外部サービスの認証情報をエージェントに保持させないCredential Injectionの考え方や、各層が突破される可能性を前提とした5つの防御層からなるアーキテクチャには、AI駆動開発向けのルールや実行環境の整備を検討するうえで参考になる点が多くありました。さらに、生産性と安全性の両立を図りながら、4週間という短期間でここまでのアーキテクチャを実現した点にも驚きました。

◆参考文献

• ・Caging the Agent Briefing Slides（https://i.blackhat.com/BH-USA-26/Presentations/US-26-Kumar-Caging-The-Agent-Thur.pdf）

• ・Black Hat USA 2026 Briefings Schedule: Caging the Agent（https://blackhat.com/us-26/briefings/schedule/index.html?day=thursday#caging-the-agent-how-roblox-built-multi-layer-sandboxes-to-secure-claude-code-at-enterprise-scale-53708）

セッション紹介⑤（脅威インテリジェンス）：“A Front-Row Seat to APT Operations: How OPSEC Failures Exposed a Malware Supplier”

◆概要

セキュリティリサーチャーのWei-Chieh Chao氏、Zhao-Min Chen氏による、攻撃者に対してマルウェアやバックドアツールを開発・提供している「マルウェアサプライヤー」のOPSEC上のミスを突き、マルウェアサプライヤーの開発インフラや組織構造を1年以上にわたって追跡した研究成果を共有するセッションです。

従来の「個別の攻撃作戦を追いかける」アプローチから、「攻撃ツールの供給網を特定する」アプローチへのシフトが、防御側にいかに強力で長期的に有効なインテリジェンスをもたらすかが示されました。

◆前提：OPSEC（Operations Security）とは何か

NIST SP 800-53では、OPSECを『潜在的な敵対者に対して、自組織の能力や意図に関する情報を与えないようにするための体系的なプロセス』と定義しています。

サイバーセキュリティにおいては、セキュリティリサーチャーが調査時に自身の身元や技術を攻撃者に悟らせないために重要である一方、攻撃者側にとっても、自身の本拠地（国、組織、関与している企業など）や、開発しているマルウェアのソースコード、開発体制の内情を露呈させないために極めて重要な活動となります。

◆設定不備から始まった監視

APTグループに対してツール供給を行っている特定のマルウェアサプライヤーが、内部インフラをパブリックなネットワーク上に構築し、設定不備によってインターネットから閲覧可能な状態にしてしまうというOPSEC上の失敗を犯しました。

これを発見したリサーチチームは、攻撃者に気づかれることなく、1年以上にわたりマルウェアサプライヤーのインフラを静かに監視し、詳細に分析しました。これにより、以下の事実が明らかになりました。

１．高度に産業化・組織化された「マルウェア開発企業」の実態：ハッカーの個人的な活動ではなく、明確に役割分担されたチーム体制（R&D、QAテストチーム、フロントエンド/バックエンド開発、インフラチームなど）を持ち、一般的な商用ソフトウェアベンダーと変わらないソフトウェア開発プロセスや品質管理に沿ってマルウェアが組織的・ビジネス的に製造・販売されていることが判明しました。

２．複数のAPTグループに対するツールの提供：1つのサプライヤーが開発したマルウェアが、複数のAPTグループなどに「製品」として提供されていました。攻撃者はこのツールをポストエクスプロイトや永続化（Persistence）のパーツとして各々の攻撃活動で利用していました。

３．個別CTI（脅威インテリジェンス）の限界とサプライヤー追跡の価値：従来の、被害組織側のインシデントログやIOC情報から追跡を行うアプローチでは、攻撃者が使い捨てるC2インフラなど有効期間が短い情報が多く、攻撃者がインフラを切り替えるたびにインテリジェンスが失効してしまいます。

しかし、マルウェアの供給元を特定して追跡し続けることで、インフラが変化してもマルウェアの特性や新機能の開発状況などから、複数の攻撃活動に横断的かつ長期的に活用できるインテリジェンスの作成に寄与することが期待できます。

◆登壇者らによるまとめ

・攻撃者側であっても設定ミス（OPSECの不備）は起こり得ます。防御側はこれをリサーチの手がかりとして活用し、サプライヤーの内部活動を把握できる場合があります。

・単一のマルウェアファミリーが複数のAPTグループによって利用されるため、被害の発生パターン、活動時間帯、サポートツールの差異、インフラ構造の重ね合わせなどを用いて、同一ツールを使う異なる攻撃者を見分けるきっかけとなります。

◆発表を聴講した当社メンバーによる感想

攻撃者組織では役割分担が進んでいるとよく言われますが、その一端を示した非常に興味深いリサーチであったと感じています。企業では設定の不備が攻撃につながると言われるのと同様に、攻撃者も設定の不備などが原因で外部に情報が露呈することがあり、今後もリサーチの切り口となり得る見方だと考えています。

◆参考文献

• ・NIST CSRC Glossary - Operations Security Definition 
  （https://csrc.nist.gov/glossary/term/operations_security ） 
  ・Black Hat USA 2026 Session Detail: A Front-Row Seat to APT Operations 
  （https://blackhat.com/us-26/briefings/schedule/?#a-front-row-seat-to-apt-operations-how-opsec-failures-exposed-a-malware-supplier-51877） 

まとめ：Black Hat USA 2026が突きつける「3つの防衛シフト」

 今年のBlack Hat USA 2026におけるセッションを総合的に分析すると、サイバー脅威が「マシンスピード」かつ「自律的な判断（AIエージェント）」を伴って実行される時代に本格的に突入したことが鮮明になりました。

AIエージェントはプロンプト一つで踏み台になる。パスキーやActive Directoryのような、固いはずの認証基盤も実装や仕様の隙を突かれる。そしてその裏側では、攻撃ツールが一般企業さながらの体制で開発・供給されている。攻撃は速く、自律的で、組織的になっている――これが現地で聴講した筆者らの率直な実感です。

これに伴い、企業のセキュリティリーダーは、これまでの防衛思想を以下の「3つの大きな防衛シフト」へ転換することが求められます。 

１．「テキスト制限（Moderation/Guardrails）」から「インフラ隔離と決定論的制限」へ

プロンプトインジェクションに対する「AIモデル自体のアライメントや入力禁止ワードの登録（Ring 1ガードレール）」のみに頼るアプローチは、攻撃者が様々な記述法を駆使するため、突破される可能性を前提にする必要があります。

 セッション④（Caging the Agent）で示されたように、「エージェントを動かす実行環境自体をコンテナや一時VMで強固に隔離する」「Credential Injection（API/MCP中継）によってエージェントの実行環境に認証情報を持たせない」といった、インフラ側（Ring 2〜4）で境界を引く、という考え方がAI時代の有力な設計アプローチになりつつあります。

２．「認証成功＝安全という前提」から「継続的なセッション検証とハードウェアバインドの強制」へ

フィッシングに極めて強固であるとされてきたパスキーであっても、セッション②（Pass-the-Passkey）で示されたように、OS層でのアサーション（認証応答）がイベントログに平文で記録される不具合、およびサーバ側でのリプレイ検証の省略、UIの偽装といった「実装の隙間」によってリプレイや中継攻撃が成立してしまいます。

また、Active Directoryにおいても、セッション③（Identity Crisis）で示された「不可視文字を用いた一意性チェックのバイパス（KerberLoss）」や「TGSをスキップすることによるSID検証のバイパス（ResetNightmare）」のように、名前解決と照合プロセスのギャップ（Identity Confusion）を突く攻撃がドメイン全体の奪取を招くおそれがあります。

防御側は、認証を「成功して終わり（静的な関門）」と捉えるのではなく、アクセストークンの有効期間を短く設定し、セッション状態と認証要求の継続的なバインディング検証を行うとともに、極めて重要な特権アカウント（Tier-0など）には、クラウド同期型を排除した「ハードウェアバインド（TPMやセキュリティキー固定）型」パスキーをアテステーション検証付きで強制する必要があります。

３．「被害ごとの対処（受動的CTI）」から「サプライチェーンの上流（アップストリーム）を捉えるインテリジェンス」へ

セッション⑤（A Front-Row Seat to APT Operations）で明らかになったように、一部のサイバー犯罪・国家支援型の攻撃グループでは、分業化・産業化が進んだ独自のソフトウェア開発・供給エコシステムが構築されています。

IOC（不審なIPやファイルのハッシュ値）を追ってその都度パッチやルールを適用するような受動的で「下流」の対処だけでは、高速化する攻撃に後れを取るおそれがあります。

攻撃側の「設定不備（OPSEC失敗）」などの隙を見逃さず、マルウェアの「供給網の上流（アップストリーム）」そのものを捉えることで、使い捨てられる個別の攻撃を超えて、攻撃者が将来使おうとしている共有ツールや開発動向を先回りして把握し備える、長期的に有効な「プロアクティブな脅威インテリジェンス（CTI）」を整備することが重要です。