JPCERT/CC がFortinetのFortiBleedで日本国内組織の被害を確認-JPCERT-AT-2026-0019|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年06月25日更新日時: 2026年06月25日

一般社団法人JPCERTコーディネーションセンター（JPCERT/CC）は2026年6月23日、FortiGate等のFortinet製品に関連する認証情報の大規模漏洩事案「FortiBleed」について、当該情報に国内企業に関連するものが含まれていることを確認したとして緊急の注意喚起（JPCERT-AT-2026-0019）を発出しました。

JPCERT/CCは本件を「過去情報の再流通としてのみ扱うべきではない」と明示しており、漏洩した認証情報が現在も有効な可能性が研究者によって指摘されています。

加えて、攻撃者はFortiGate機器上のパケットキャプチャ機能を利用して通過するKerberos・NTLMの認証ハッシュを傍受するツールを保有しており、FortiGateそのものへのアクセスだけでなく、内部のActive Directory全体が侵害されている事例が確認されています。本記事では、JPCERT/CC注意喚起の内容を軸に、日本組織が今すぐ実施すべき4段階の確認手順と対処を解説します。

サマリー

注意喚起：JPCERT/CC JPCERT-AT-2026-0019（2026年6月23日発出）
日本への影響：JPCERT/CCが当該情報に国内企業に関連するものが含まれていることを確認
攻撃の起点：FortiGate設定ファイルのエクスポートによる管理者パスワードハッシュの取得→オフラインクラッキング
被害の深さ：攻撃者はパケットスニッフィングでKerberos/NTLMハッシュを傍受、Active Directory全体のアカウントが危険にさらされた事例を確認
IPsec VPN経由の間接被害：検索ツールで自組織が該当しない場合でも、サイト間IPsec VPNの対向拠点が侵害されていれば被害が及ぶ可能性あり
SIer代行登録の落とし穴：Hudson Rock・SOCRadar検索ツールはFortiGuardライセンス登録ドメインを対象とするため、SIerが代行登録した組織ではエンドユーザーのドメインが検索対象外になる場合あり
PBKDF2の落とし穴：パスワード再設定後も旧SHA256ハッシュがold-passwordフィールドに残存するため、過去に設定ファイルが取得されていた場合はオフラインクラックのリスクが残る
4段階の確認手順：①設定エクスポート痕跡の確認 ②不審な管理者アクセスの調査 ③外部検索ツールによる照会 ④設定・DCログの検証

確認手順	確認の対象	具体的な方法
①設定エクスポート痕跡	FortiGateログ	System > Events > Messages を「Config」でフィルター。管理者・REST APIアカウント両方を確認
②不審な管理者アクセス	FortiGateアクセスログ	SOCRadar・Beaumont両IoCリストのIPアドレスと照合
③外部検索ツール	自組織ドメイン	Hudson Rock（hudsonrock.com/fortinet）・SOCRadar（socradar.io/free-tools/fortibleed）で検索 ※SIer代行登録の場合は非表示の可能性あり
④設定・DCログ検証	FortiGate設定・DC	forticloud等の不審アカウント確認・AD/LDAPアカウントの不正利用確認

1 何が起きたか
2 概要
3 原因
4 FortiGateを持たない組織も被害を受ける可能性 ─ IPsec VPN経由の間接的な波及
5 外部検索ツール使用前に知っておくべき「SIer代行登録」の落とし穴
6 JPCERT/CC注意喚起に基づく4段階の確認手順
7 侵害が確認された場合の対処
8 FAQ

何が起きたか

FortiBleedとは、2026年6月中旬に発覚した大規模なFortinet FortiGate認証情報窃取キャンペーンです。

194か国にまたがる86,644台以上の機器のログイン情報が攻撃者によって収集・保持されていたことが、セキュリティ研究者Volodymyr Diachenko氏がインターネット上に誤って公開された攻撃者のインフラを発見したことで明らかになりました。CISAは6月18日に緊急アラートを発出し、Fortinetは19日にPSIRTブログで公式見解を示しており、これらの詳細については当サイトの既報をご参照ください。

JPCERT/CCは6月23日の注意喚起において、日本国内にも影響が及んでいることを独自確認したと明示しています。日本のUTM・ファイアウォール市場においてFortiGateは大きなシェアを持つ製品であり、国内の多数の企業・官公庁・教育機関がこのキャンペーンの射程に入っています。

Huntressの調査によれば、攻撃のタイムウィンドウは2026年5月19日から6月7日の期間と推定されています。この期間にFortiGate機器にアクセスがあった場合、設定ファイルの持ち出しとパケットスニッフィングによる認証情報の収集が行われていた可能性があります。

概要

今回JPCERT/CCが特に注目するのは、攻撃の被害が「FortiGateへの不正ログイン」にとどまらず、内部のActive Directory全体にまで及んでいる事例が確認されている点です。攻撃連鎖は以下の4段階で構成されています。

第1段階は設定ファイルのエクスポートです。

攻撃者はFortiGate機器に何らかの手段でアクセスし、設定ファイルをエクスポートして取得します。FortiGateの設定ファイルには管理者パスワードのハッシュ値が含まれています。JPCERT/CCは「設定ファイルが取得された場合、デバイスへの直接アクセスがなくともオフライン解析によりパスワードが解読されている恐れがある」と明示しています。

第2段階はオフラインでのハッシュクラッキングです。

取得したハッシュを45台のNVIDIA RTX 4090で構成されたGPUクラスター（Hashtopolisで管理）にかけ、パスワードを平文に復元します。既知の漏洩パスワードリストと組み合わせることで、複雑なパスワードも短時間で解読されるケースがあります。

第3段階は機器へのアクセスと認証情報の傍受です。

有効な認証情報を使ってFortiGate機器に侵入した攻撃者は、FortiGateのカーネルレベルで動作するパケットキャプチャ機能（fg_capture.log等）を悪用します。VPNを通過するHTTP・FTP・SMTP・LDAP・SNMPなどのプロトコルのトラフィックを傍受し、平文の認証情報とKerberos・NTLMの認証ハッシュを収集します。この処理はFortiGate機器の内側で完結するため、内部のEDRや振る舞い検知ツールに検知されません。

第4段階はActive Directoryへの横展開です。

収集したKerberos・NTLMハッシュを前述のGPUクラスターでクラッキングし、有効なドメインアカウントの認証情報を取得した攻撃者は、LDAPやSMBを通じてActive Directoryをダンプし、ファイル共有からのデータ窃取、Kerberosチケットの窃取、グループポリシーテンプレートの収集へと進みます。AD/LDAP連携用のサービスアカウントがFortiGateに設定されている組織では、このアカウントが内部ADで不正利用されていないかの確認が特に重要です。

原因

この問題の技術的な核心は2点あります。

FortiOSのパスワードハッシュ保存方式の歴史的な問題については、FortiOS 7.2.11・7.4.8・7.6.1以降でパスワードハッシュの保存方式がSHA256からPBKDF2（計算コストが高く、オフラインクラッキングへの耐性が大幅に高い）に変更されています。

しかし旧バージョンから対応バージョンにアップグレードしても、管理者が一度ログインしなければ既存のパスワードハッシュはPBKDF2に変換されません。さらにJPCERT/CCが注意喚起で特記しているのは「管理者パスワードを再設定しても、既定では旧SHA256ハッシュがold-passwordに残存する」という点です。つまりパスワードを変更してもold-passwordフィールドに旧ハッシュが残り、過去に設定ファイルが取得されていた組織ではそのハッシュがクラッキングされるリスクが残ります。PBKDF2を強制的に適用するには、Fortinetが提供する追加の技術手順が必要です。

初期アクセス経路については、JPCERT/CCは「過去のインシデントで取得された情報の再利用が主因との見解を示しているが、一部の研究者は現在も有効な認証情報が含まれている可能性を指摘している」として、単純な過去情報の再流通とみなすべきではないとしています。インフォスティーラーマルウェアによる平文パスワードの窃取・過去のFortiGate関連CVEで漏洩したハッシュのクラッキング・設定ファイルの持ち出し、これらが組み合わさることで今日も有効な認証情報が攻撃者のデータベースに含まれている可能性があります。

FortiGateを持たない組織も被害を受ける可能性 ─ IPsec VPN経由の間接的な波及

今回のJPCERT/CC注意喚起が特に日本の情報システム部門に対して示す重要な警告が、IPsec VPN経由の間接被害です。

対向拠点を信頼ゾーンとして設定し、サイト間のIPsec VPNで常時接続する環境にある組織では、仮に自組織のFortiGateがFortiBleedの検索ツールで「該当なし」であっても、対向側の組織（取引先・グループ会社・委託先等）のFortiGateが侵害されていた場合、その機器を起点とした侵害が自組織の内部ネットワークに及ぶ可能性があります。

これはサイト間VPNの根本的な特性から生じるリスクです。IPsec VPNで常時接続された対向拠点は「信頼ゾーン」として扱われ、そのゾーンからの通信は内部ネットワークとして処理されます。対向側のFortiGateが攻撃者に侵害されていた場合、その攻撃者は信頼ゾーンからの通信として自組織の内部ネットワークにアクセスできる状態になります。グループ会社・取引先・データセンター接続など、IPsec VPNで常時接続している相手がFortiGateを使用しているかどうかを確認し、必要であれば接続ルールの見直しや異常なアクセスの確認を実施してください。

外部検索ツール使用前に知っておくべき「SIer代行登録」の落とし穴

Hudson Rock（hudsonrock.com/fortinet）とSOCRadar（socradar.io/free-tools/fortibleed）は、自組織のドメインがFortiBleedのデータセットに含まれているかを確認できるツールを公開しています。ただし、JPCERT/CCは日本組織特有の問題として、これらのツールの限界を明示しています。

両ツールの検索データベースは、FortiGuardライセンスの登録時に申請されたメールアドレスのドメイン部分を基準に照合しています。

日本では、FortiGateの導入をSIer（システムインテグレーター）や運用保守委託先が代行するケースが多く、FortiGuardライセンスの登録メールアドレスがSIerのドメインになっているケースがあります。

この場合、エンドユーザー（実際にFortiGateを使用している組織）のドメインで検索しても結果に表れません。つまり「検索して該当なし」が「被害なし」を意味しない可能性があります。

また一部の被害組織ではIPsec VPNトンネルへのログインが確認されており、ドメイン検索で結果が出なくても被害を受けている場合があります。外部ツールでの照会は4段階の確認手順のひとつに過ぎず、それだけで安全を判断することは避けてください。

JPCERT/CC注意喚起に基づく4段階の確認手順

JPCERT/CCが示す確認手順を優先度順に解説します。

確認手順①として設定情報のエクスポート痕跡を確認します。

FortiGateの管理コンソールで「System > Events > Messages」を開き、「Config」でフィルターしてください。設定ファイルのエクスポート（バックアップ操作）の履歴が表示されます。身に覚えのないエクスポート操作が記録されている場合は侵害の可能性があります。管理者アカウントとREST APIアカウントの両方の操作履歴を確認する必要があります。

確認手順②として不審な管理者アクセスを調査します。

SOCRadarが公開するホワイトペーパー「Dismantling FortiBleed」のIoCsセクションに記載のIPアドレス、およびKevin BeaumontのDoublePulsarブログ「Config dumping at scale」セクションに記載のIPアドレスからのアクセスがないか確認してください。これらは攻撃者が実際に使用したことが確認されているIPアドレスです。

確認手順③として外部検索ツールで照会します。

Hudson RockおよびSOCRadarが公開する検索ツールで自組織のドメインを確認します。前述の「SIer代行登録」の問題を考慮したうえで結果を解釈してください。

確認手順④として設定の検証とドメインコントローラーのログ調査を実施します。

FortiGateの設定に不正なアカウント追加がないかを確認します。特に「forticloud」「fortiuser」「fortinet-support」「fortinet-tech-support」という名称のアカウントは攻撃者が設置するバックドアアカウントとして確認されているため、これらが存在する場合は侵害済みとみなしてください。可能であれば、以前に取得した正常時の設定ファイルと現在の設定を比較することが推奨されます。AD/LDAP連携用のアカウントがFortiGateに設定されている場合は、そのアカウントのドメインコントローラー上での使用状況を確認し、不審なログインや設定変更がないかを調査してください。

侵害が確認された場合の対処

確認の結果、自組織の認証情報が漏洩している可能性が高いと判断した場合は、以下の対処を実施してください。

まずFortinetが提供する「機器侵害時の推奨手順（Technical Tip: Recommended steps to execute in case of a compromised host）」に従ってすべてのアクティブセッションを終了し、認証情報のローテーションを実施します。次にMFAをすべての管理者アカウントとVPNユーザーアカウントに有効化します。

PBKDF2への移行については、FortiOS 7.4・7.6・8.0の最新バージョンにアップグレードしたうえで、「Technical Tip: Enforcing PBKDF2 as hash function for administrator accounts in FortiOS v7.2.11 and later」に記載の手順を実施してください。パスワード再設定だけでは旧SHA256ハッシュがold-passwordに残存するため、この追加手順が必須です。

AD/LDAP侵害が疑われる場合は、FortiGate側の対処だけでは不十分です。FortiGateに設定されているAD連携アカウントを侵害済みとして扱い、Active Directory環境全体で不審なアカウント作成・権限昇格・ラテラルムーブメントの痕跡がないかを確認してください。侵害の規模によっては、Kerberos・NTLMのハッシュが広範に収集されている可能性があるため、影響の特定にはフォレンジック調査が必要になる場合があります。

情報の提供については、JPCERT/CCが本件に関して情報を求めており、提供できる情報がある場合は [email protected] へ連絡することを推奨しています。

FAQ

Q. JPCERT/CCの注意喚起は誰に向けたものですか？

A. FortiGate等のFortinet VPN/ファイアウォール製品を運用しているすべての組織が対象です。特に日本国内の組織の認証情報が含まれていることが確認されているため、日本国内でFortiGateを運用するすべての組織が影響を受けている可能性を念頭に置いてください。

Q. 自組織の機器がHudson Rockの検索ツールで「該当なし」でも対応が必要ですか？

A. 必要です。JPCERT/CCが明示しているように、ツールの検索対象はFortiGuardライセンス登録時のドメインであるため、SIer代行登録の場合はエンドユーザーのドメインが対象外になります。また検索ツールで見つからなくても、IPsec VPN対向拠点経由での侵害波及、またはデータベースに含まれていない経路での侵害が起きている可能性は否定できません。

Q. パスワードを変更したのに再設定が必要ですか？

A. PBKDF2対応バージョンへのアップグレードと専用手順の実施が別途必要です。パスワード変更だけでは旧SHA256ハッシュがold-passwordフィールドに残存し、過去に設定ファイルが取得されていた場合はそのハッシュがクラッキングのリスクにさらされ続けます。Fortinetの「Enforcing PBKDF2」技術ドキュメントに従った追加手順が必須です。

Q. FortiGateを保有していないが、取引先がFortiGateを使っています。どうすべきですか？

A. サイト間IPsec VPNで常時接続している相手がFortiGateを使用している場合、その対向機器が侵害されていれば自組織の内部ネットワークが攻撃者の起点になり得ます。取引先・グループ会社・SIerなどIPsec VPNで接続している組織にFortiGateユーザーがいないかを確認し、不審なアクセスがないか境界のログを確認してください。

出典