FortiBleed、86,644台のFortiGateの認証情報が流出-インターネット公開機器の約半数に影響|セキュリティニュースのセキュリティ対策Lab

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

2026年6月中旬、セキュリティ研究者によってFortinet FortiGateファイアウォールおよびSSL VPNを標的とした大規模な認証情報窃取キャンペーンが発覚しました。「FortiBleed」と命名されたこの活動では、194か国にまたがる86,644台分の有効な管理者・VPN認証情報が攻撃者によって収集・検証済みのデータベースとして保持されており、インターネットに公開されているFortiGate機器の約半数に相当するとされています。CISAは2026年6月18日に緊急アラートを発出し、Fortinet製品を利用するすべての組織に対して即時の対応を求めています。

サマリー

キャンペーン名：FortiBleed（SOCRadarが命名）
発覚日：2026年6月中旬（Bob Diachenko氏がLinkedInで最初に報告）
影響台数：86,644台分の有効認証情報（194か国）
影響範囲：インターネット公開FortiGateデバイスの約50%（Shodanデータより）
攻撃者：ロシア語話者の脅威アクター（SOCRadar・Diachenko氏の分析）
手口：過去の流出認証情報の再利用＋SSL VPNハッシュ傍受＋45GPU規模のオフラインクラッキング（Hashtopolis管理）→ Active Directory横展開
規模：FortiGateへ約11.6億回の認証試行（32万台超対象）、MSSQLサーバーへ約21億回のブルートフォース（16万台超対象）
確認済み完全侵害：少なくとも4組織（Huntress：845のパートナー組織が特定）
CISAアラート：2026年6月18日付で緊急アラートを発出
FortiBleed自体に固有のCVEは現時点で割り当てられておらず、新規ゼロデイ脆弱性ではなく認証情報管理の構造的問題が背景にある

1 何が起きたか
2 概要
3 原因
4 過去のFortiGate認証情報流出との連続性
5 情報システム部門が今すぐ取るべき対応
- 5.1 FAQ

何が起きたか

2026年6月、セキュリティ研究者Volodymyr「Bob」Diachenko氏がインターネット上に誤って公開状態になっていた攻撃者のサーバーを発見しました。そのサーバーには、FortiGateファイアウォールおよびSSL VPNゲートウェイから収集された認証情報のデータベース、攻撃に使用したツール群、自動化スクリプト、被害組織のリスト、そして攻撃者の正体に迫る情報が含まれていました。

Diachenko氏の報告を受け、脅威インテリジェンス企業SOCRadarが同キャンペーンの詳細を独自調査のうえ公開しました。その後、Hudson Rock、セキュリティ研究者Kevin Beaumont氏、サイバーセキュリティ企業Huntress、Arctic Wolf、Bitsightらが相次いで分析結果を公表し、被害の深刻さが次第に明らかになりました。

SOCRadarによると、このキャンペーンは2026年6月の時点で、インターネットに公開されたFortinet FortiGateファイアウォールおよびSSL VPNから86,644件を超える有効な認証情報（ユーザー名とパスワード）を収集・検証済みの状態としており、対象は194か国に及びます。Beaumont氏はShodanのデータをもとに「これはインターネット公開Fortinet機器の約50%に相当する」と指摘しています。

CISAは2026年6月18日付でFortiBleedに関する緊急アラートを発出し、Fortinet製品を利用するすべての組織に対してアクティブセッションの終了・認証情報リセット・MFA有効化・管理アクセスの制限といった即時対応を求めました。Huntressは自社の顧客データと照合した結果、845のパートナー組織が具体的な影響を受けていると確認しています。

概要

FortiBleedは新種の脆弱性を悪用したものではなく、組織的・大規模・自動化された認証情報収集キャンペーンです。攻撃者はまずShodanなどを使ってインターネット公開されているFortiGateファイアウォールおよびSSL VPNゲートウェイを網羅的にスキャンしました。

攻撃は大きく2つの方式で実行されています。第1の方式は認証情報の再利用です。過去のFortinet関連インシデントで流出した認証情報リストや、インフォスティーラーマルウェアがブラウザやVPNクライアントから窃取して蓄積したパスワードデータベースを活用し、自動スクリプトで各FortiGateへのログインを試みています。FortiGateへの認証試行は総計約11.6億回に上り、対象は32万台超のデバイスに達したとされています。

第2の方式はSSL VPNハッシュの傍受とオフラインクラッキングです。FortiGateがSSL VPNのログインハンドシェイク中に送受信する認証ハッシュを傍受し、それをHashtopolisで管理する45台のGPUで構成されたオフラインクラッキング環境に流し込んで平文パスワードを復元する手法が使われました。

いったんFortiGateへのアクセスを確立した攻撃者は、パケットスニッフィングにより通過するネットワークトラフィックを監視し、追加の認証情報を収集します。回収された新たなパスワードは再びスキャナーに投入されて被害機器をさらに拡大させる、自己増殖型の構造になっています。また、Diachenko氏の調査によれば、少なくとも4組織ではActive Directoryへの横展開も確認されており、NTLMおよびKerberosハッシュを収集することでドメイン全体のアカウントが危険にさらされた可能性があります。

注目すべきは、FortiGate以外の標的も並行して攻撃されている点で、MSSQLサーバーへも約21億回のブルートフォースが16万台超に対して実行されています。これは単なるFortinet専用のキャンペーンではなく、VPN機器を主要な侵入口としながら複数の標的を組み合わせた幅広い初期アクセス獲得作戦とみるべきです。

原因

FortiBleedが大規模なクラッキングに成功した背景には、FortiOSにおけるパスワードハッシュの管理方式に構造的な問題があります。

Fortinetは新しいバージョン（FortiOS 7.2.11、7.4.8、7.6.1以降）でパスワードハッシュの保存方式をSHA-256ベースからより堅牢なPBKDF2（Password-Based Key Derivation Function 2）ベースに変更しています。PBKDF2は意図的に計算コストを高くすることでオフラインクラッキングの実効性を著しく低下させる設計です。

ところが、旧バージョンからアップグレードした際、既存の管理者アカウントのパスワードハッシュはアップグレード後に当該管理者が一度ログインするまでSHA-256のまま維持されます。つまり、多くの組織でFortiOSを最新バージョンに更新していながら、実際には管理者が再ログインをしていなかったため、SHA-256ハッシュが残存し続けていた可能性が高いのです。SHA-256ハッシュは45台のGPUを使ったオフラインクラッキング環境の前では数時間〜数日以内に解析されてしまいます。

また、インフォスティーラーマルウェアによる認証情報収集が再利用攻撃を加速させている点も重要です。25文字以上の複雑なパスワードでも、インフォスティーラーによって平文で窃取されていれば、攻撃者のデータベースに平文のまま存在しています。つまりパスワードの複雑さ自体はインフォスティーラー経由の盗取に対してはほぼ意味をなさないということになります。Beaumont氏はこの点を明確に指摘しており、「複雑なパスワードが平文でデータセットに含まれていた。クラッキングされたのではなく、すでにインフォスティーラーのログに存在していた」と述べています。

過去のFortiGate認証情報流出との連続性

FortiBleedは突発的な事件ではなく、FortiGateを繰り返し標的とする攻撃パターンの延長線上にあります。

2020年、CVE-2018-13379を悪用した攻撃により約5万台のFortinet機器のVPN認証情報が流出しました。今回のFortiBleedではその当時の認証情報を変更していない機器が再び被害に遭っている可能性が指摘されています。Fortinet製品はCVE-2022-42475、CVE-2023-27997（XORtigate）、CVE-2024-55591、CVE-2025-24472など、毎年深刻な脆弱性が発見・悪用されており、日本の組織への攻撃も国内でたびたび報告されてきました。

ネットワークエンジニアとして現場に関わってきた立場からすると、この種の認証情報流出において一貫して見えてくるのは「パッチを当てても認証情報を変えない」という運用上の抜け穴です。ファームウェアの更新と認証情報のローテーションはセットで実施しなければならないはずですが、現実には後者が後回しになりがちです。FortiBleedはその習慣の隙を組織的かつ大規模に突いたキャンペーンです。

また今回、攻撃者のインフラ上には各組織の業種・年商・従業員数などの情報が整理されており、単なる無差別攻撃ではなく標的の選別も行われていた形跡があります。Hudson Rockは被害組織に政府機関や重要インフラプロバイダーが含まれていると指摘しています。攻撃ツールとして確認されたChiselおよびNeo-reGeorgは過去にVolt Typhoonキャンペーンでも観測されているもので、国家関与の可能性を含む高度な脅威アクターも同一のデータセットを活用している可能性が示唆されています。

情報システム部門が今すぐ取るべき対応

CISAが発出した緊急アラートおよび複数の研究機関の勧告をもとに、今すぐ実施すべき対応をまとめます。

まず最優先で実施すべきは、すべてのFortiGate管理者アカウントおよびSSL VPNユーザーのパスワードを一斉変更することです。

データセットに自組織のIPが含まれているかどうかに関わらず、現時点でパスワードが変更されていない機器はすべて侵害済みとして扱うのが適切な対応です。Hudson Rockはinfostealers.comにFortiBleedの無料確認ツールを公開しており、自組織のドメインがデータセットに含まれているか確認できます。ただしこれはあくまで補助的な確認であり、ツールでヒットしなかったからといって安全とは断言できません。

次に、FortiOSを最新バージョンにアップグレードしたうえで、すべての管理者が一度ログインしなおすことを徹底してください。

これにより古いSHA-256ハッシュがPBKDF2形式に更新されます。アップグレード後に管理者の再ログインが困難な場合は、super_adminアカウントを使って管理者パスワードを手動で更新する方法でも同様の効果が得られます。

管理インターフェースのインターネット公開を直ちに制限してください。FortiGateの管理画面（HTTPS・SSH）がインターネットに直接露出している状態は最大のリスクです。管理アクセスは社内ネットワーク・VPN経由・帯域外管理網などの信頼できる経路に限定し、SSL VPNポータルも業務上必要がない場合はインターネットへの公開を停止することを検討してください。

MFA（多要素認証）をすべての管理者アカウントおよびVPNリモートアクセスに適用してください。フィッシング耐性のあるMFAが推奨されますが、まずは何らかのMFAを即座に有効化することが先決です。認証情報が流出していた場合でも、MFAが有効であれば侵害を防ぐ最後の防壁になります。

ログの確認も重要です。不審な管理者アカウントの作成、予期しない地理からのSSL VPNログイン、管理インターフェースへの不審なアクセス、Active Directoryに対するDCSync相当のレプリケーション動作（Event ID 4662）などが侵害の兆候として挙げられます。侵害後の横展開はVPNアドレスプールからの不自然な内部接続としても観測されることがあります。

FAQ

Q. FortiBleedにはCVEが割り当てられていますか？

A. 現時点でFortiBleed自体にはCVEは割り当てられていません。これは特定の脆弱性を悪用したものではなく、認証情報の再利用・ハッシュクラッキング・過去の流出データの活用を組み合わせた認証情報管理の構造的問題に起因するキャンペーンです。パッチを当てれば解決するという性質ではなく、認証情報のローテーションと管理インターフェースの保護が根本対策になります。

Q. 最新のFortiOSを使っていれば安全ですか？

A. 最新バージョンへのアップグレードは必要条件ですが十分条件ではありません。アップグレード後に各管理者が一度ログインしなければ、パスワードハッシュは旧来のSHA-256形式のまま残存します。また、インフォスティーラーによって過去に窃取された認証情報がそのまま使い続けられている場合、パスワード強度に関わらず被害に遭う可能性があります。

Q. 自組織のFortiGateが影響を受けているか確認できますか？

A. Hudson Rockがinfostealers.comに無料の確認ツールを公開しています。ただし、そのツールに自組織のドメインが含まれていないからといって安全を保証するものではありません。公開されているデータセットは全体の一部である可能性があるため、ツールでの確認とは別に認証情報の全面変更を実施することを強く推奨します。

Q. Active Directoryが侵害された場合、何から対応すればよいですか？

A. FortiGateデバイスからActive Directory環境への横展開が確認または疑われる場合は、すべてのActive Directoryユーザーアカウントのパスワードをリセットしてください。特にKerberos・NTLMハッシュがパケットスニッフィングで窃取された可能性があるため、認証情報の変更だけでなく、パス・ザ・ハッシュ攻撃の痕跡確認とともにインシデントレスポンスの体制を整えて対応する必要があります。

出典

当サイト関連記事