Fortinetは2026年6月19日、同社製品を標的とした大規模な認証情報収集キャンペーン「FortiBleed」について、PSIRT(製品セキュリティインシデント対応チーム)の公式ブログで分析と対応措置を公表しました。
Fortinetは「本件は新たなFortinetの脆弱性とは関係がなく、最近のインシデントや勧告とも無関係」と明言しており、過去に公開された3件のFortiCloud SSO認証バイパス脆弱性(CVE-2026-24858・CVE-2025-59718・CVE-2025-59719)から漏洩した認証情報の再利用と、MFAが未設定・パスワードが脆弱な機器へのブルートフォースの組み合わせが起点であると分析しています。
Fortinetはすでに影響を受けた可能性のある機器を特定し、該当顧客への能動的な通知と、関係する政府機関・法執行機関との連携を開始しています。
サマリー
- Fortinet公式声明日:2026年6月19日(SecurityWeek報道:2026年6月22日)
- 結論:FortiBleedは新規ゼロデイ脆弱性の悪用ではなく、過去CVEからの認証情報再利用とブルートフォースによるもの
- 起点となった過去CVE:
- CVE-2026-24858(FG-IR-26-060):FortiCloud SSO認証バイパス(2026年1月にパッチ適用)
- CVE-2025-59718・CVE-2025-59719(FG-IR-25-647):重大な認証バイパス脆弱性(2025年12月にパッチ適用)
- ブルートフォースの手口:2026年3月に同社が警告したAIを使用した高速パスワードスプレー攻撃と同一手法
- Fortinetの対応:影響機器の特定済み、影響顧客への個別通知開始、法執行機関と連携して調査中
- IoC:不審なアカウント名として「forticloud」「fortiuser」「fortinet-support」「fortinet-tech-support」などが確認されている
- 公式推奨対応:セッション終了・認証情報リセット・MFA有効化・PBKDF2対応バージョンへのアップグレード・設定検証・ログ確認・管理アクセスのロックダウン
- 参考:当サイト既報 FortiBleed第一報(86,644台への影響・手口・初期対策)
何が起きたか
Fortinetは2026年6月19日、PSIRTブログで「FortiGateデバイスの認証情報侵害の報告に関する分析」と題した公式声明を公開しました。
これは同月16日にSOCRadarが大規模な認証情報収集キャンペーン「FortiBleed」の詳細を公表し、194か国・86,644台分の有効な認証情報がデータベース化されているとの報告が世界的な注目を集めたことへの公式な対応です。
Fortinetの声明で最も重要な点は、本件の性質の明確化です。同社は「初期分析に基づき、この活動は脅威アクターが過去のインシデントから認証情報を再利用し、MFAが設定されていない・パスワード管理が不十分なデバイスに対してブルートフォース技術を使用しているものと考えている」と述べており、新たなFortinetの脆弱性が悪用されたものではないと明言しました。
あわせて、Fortinetはすでに侵害された可能性のあるシステムを特定し、影響顧客への能動的な通知を開始していること、および調査を開始した当初から関係する政府機関との連携を進めていることも明らかにしています。
概要
FortiBleedの起点として特定された過去のインシデントは、いずれもFortiCloud SSOの認証に関わる脆弱性です。
1件目はCVE-2026-24858(FG-IR-26-060)で、FortiCloud SSOの管理者ログインにおける認証バイパスの脆弱性として2026年1月にパッチが提供されました。
2件目と3件目はCVE-2025-59718およびCVE-2025-59719(FG-IR-25-647)で、こちらも重大な認証バイパスとして2025年12月にパッチが提供されています。
これらのCVEが公開された際にFortinetは詳細な対処ガイダンスを提供しており、「当時の修正手順の完了を引き続き強く推奨する」としています。
言い換えれば、FortiBleedで使用された認証情報の多くは、これら過去3件のCVEを通じて漏洩し、その後もパスワードが変更されないまま残存していたものです。パッチを適用しても認証情報を更新しなかった組織が、今回の大規模な認証試行キャンペーンの標的になった構造です。
また、Fortinetは2026年3月に公開したブログ記事「Attacks at the Speed of AI」で、AIを使って標的の識別とパスワードスプレーを自動化し、防御が不十分なエッジデバイスを狙う大規模攻撃について警告していました。FortiBleedで使用されているブルートフォース技術は、この警告と同一の手法です。AIによる自動化が攻撃の規模と速度を飛躍的に拡大させているという2か月前の予告通りの事態が現実となったと言えます。
原因
FortiBleedが新規脆弱性ではないというFortinetの見解は、セキュリティ運用の観点から重要な示唆を持っています。
根本的な問題は2層構造です。第1層は過去CVEのパッチ適用後に認証情報を更新しなかったことです。FortiCloud SSO認証バイパスを修正するパッチを適用しても、すでに漏洩していた認証情報をリセットしなければ、攻撃者はその情報を使い続けることができます。パッチ適用と認証情報ローテーションは別の作業として完結させる必要がありますが、現実には後者が見落とされがちです。
第2層はMFA未設定とパスワード管理の不徹底です。強固なパスワードが設定されていても、インフォスティーラーなどによって平文で窃取されていれば意味をなしません。MFAが設定されていれば、認証情報が漏洩していても不正ログインを防ぐ最後の防壁として機能します。Fortinetが推奨対応の冒頭でMFA実装を求めているのはこのためです。
さらに技術的な背景として、FortiOS 7.2.11・7.4.8・7.6.1以降ではパスワードハッシュの保存方式がSHA-256からPBKDF2(Password-Based Key Derivation Function 2)に変更されています。PBKDF2は計算コストを意図的に高くすることでオフラインクラッキングへの耐性を持ちますが、旧バージョンからアップグレードしても管理者が再ログインするまで旧来のSHA-256ハッシュが残存します。Fortinetの推奨対応でバージョン7.4・7.6・8.0への更新が明示されているのも、このPBKDF2対応を確実に有効化するためです。
Fortinetが開示した不審アカウント名のIoC
Fortinetは今回の声明で、設定検証時に特に注意すべき不審なアカウント名のパターンを具体的に示しました。ファイアウォールおよびVPNの設定を確認する際は、以下の名称を含む認識できないアカウントが存在しないかを重点的に確認してください。
- forticloud
- fortiuser
- fortinet-support
- fortinet-tech-support
これらはFortinetの正規サービスや技術サポートを装った名称で、攻撃者が設定変更後のバックドアとして設置するものです。一見して正規のシステムアカウントに見えるため、手動での確認では見落とされやすく、前後のログの変化と合わせて確認することが重要です。AD・LDAPとの連携設定がある場合は、これらのアカウントが内部ネットワーク上でも使用されていないか確認してください。
情報システム部門が今すぐ実施すべきFortinetの6段階ガイダンス
Fortinetが推奨する対応を、PSIRTブログの原文に基づいて整理します。
第1段階として、すべての管理者・VPNセッションを終了し認証情報をリセットします。アクティブなすべての管理セッションを終了させ、インターネットに露出したシステムを優先してFortinetのVPNおよび管理者パスワードをすべてリセットします。強固なパスワードポリシーの適用も必須です。
第2段階として、すべての管理者アカウントおよびVPNユーザーアカウントにMFAを実装します。認証情報が漏洩した場合でも、MFAが有効であれば不正ログインを防ぐことができます。フィッシング耐性を持つMFAが推奨されますが、まず何らかのMFAを即座に有効化することが先決です。
第3段階として、FortiOS 7.4・7.6・8.0の最新バージョンにアップグレードします。これらのバージョンは管理者認証情報のPBKDF2ハッシュをサポートしており、SHA-256ハッシュによるオフラインクラッキングへの耐性が大幅に向上します。アップグレード後は set login-lockout-upon-weaker-encryption のガイダンスに従い、旧来のレガシーパスワード設定を削除してください。
第4段階として、設定を検証します。ファイアウォールとVPNのユーザーやその他の設定について、不正な変更がないかを確認します。既知の正常な設定と比較することが望ましく、前述の不審アカウント名(forticloud、fortiuser、fortinet-support、fortinet-tech-support など)の追加がないかに特に注意してください。
第5段階として、ログを確認します。不明なIPアドレスやドメインからの予期しない管理者アクセス、ドメインコントローラーのログにおける横展開の痕跡・不審なアクセス・不明なアカウント・不正な設定変更がないかを確認します。
第6段階として、攻撃面を縮小し管理アクセスをロックダウンします。Fortinetは信頼できるホストからのみ外部管理アクセスを許可する設定(良)、ローカルインポリシーによる制限(より良)、インターネット経由の管理を完全に削除する設定(最良)の3段階を示しています。可能な限り上位の設定を採用することが推奨されます。
なお、設定の不正変更やその他のIoCが確認された場合は、デバイスを侵害済みとして扱い、Fortinetが公開するリカバリガイダンスに従って復旧してください。AD・LDAPとの連携がある場合は、当該アカウントを侵害済みとして扱い、他の場所での認証に使用されていないか、また新たなアカウントが作成されていないかをAD全体で監視してください。
FAQ
Q. FortiBleedに新しいCVEは割り当てられていますか?
A. Fortinetは今回の公式声明で「FortiBleedは新たなFortinetの脆弱性とは無関係」と明言しており、本件固有のCVEは割り当てられていません。起点となったのはすでにパッチが提供されている過去3件のCVE(CVE-2026-24858・CVE-2025-59718・CVE-2025-59719)であり、パッチ適用と認証情報ローテーションが済んでいる環境では新たなCVE対応は不要です。
Q. パッチを当てていれば安全ですか?
A. パッチ適用だけでは不十分です。過去3件のCVEのパッチを適用していても、その前後に認証情報をリセットしていなければ、漏洩した認証情報を使ったアクセスは継続します。パッチ適用・認証情報のリセット・MFAの有効化・PBKDF2対応バージョンへのアップグレードの4点を揃えて初めて本件への対応が完了します。
Q. Fortinetから侵害の通知が届いていない場合は安全と考えてよいですか?
A. Fortinetは影響機器を特定し能動的に通知するとしていますが、通知が届いていないことが必ずしも安全を意味するものではありません。通知の有無にかかわらず、インターネットに露出したFortiGateデバイスを運用しているすべての組織が、本記事で示した6段階の対応を実施することを推奨します。
Q. 管理インターフェースへのインターネット公開を止めた場合、運用上の問題はありますか?
A. 管理インターフェースのインターネット公開を停止することが最も効果的な対策ですが、外部からの管理が必要な場合は信頼できるホストのIPへのアクセス制限やローカルインポリシーによる制限との組み合わせが現実的な選択肢です。Fortinetはこれを「より良い(better)」対応として位置付けており、完全な停止ができない場合の代替として有効です。
出典
当サイト関連記事
- FortiBleed ─ 86,644台のFortiGateファイアウォール認証情報が流出、インターネット公開機器の約半数に影響。CISAが緊急アラート発出
- Fortinet、FortiCloud SSOの管理者ログインに認証バイパス脆弱性、サイバー攻撃による実害も(CVE-2026-24858)
- FortinetのSSO 脆弱性、公開直後から悪用を確認(CVE-2025-59718、CVE-2025-59719)
- 生成AIを悪用した脅威アクターがFortiGateへ不正アクセス ─ 脆弱性悪用なしでも600台超
- FortiGateのデバイス認証情報漏洩で被害者のメールアドレスが公開 ─ JPドメインも確認








