はじめに
2026 年 6 月、インターネットに公開された FortiGate を標的とする大規模な認証情報窃取キャンペーン「FortiBleed」が報告され、米国 CISA をはじめ英国 NCSC やカナダのサイバーセキュリティ機関が相次いで注意喚起を出しました。攻撃者は既知のパスワードによる総当たりと、FortiGate の設定ファイルに保存されたパスワードハッシュのオフライン解読を組み合わせ、有効な管理者・VPN 認証情報のデータベースを構築しているとされています。
ここで注意したいのは、FortiBleed が新たなゼロデイ脆弱性ではなく、認証情報の使い回しとレガシーなハッシュ保存方式（SHA-256）という運用面の弱点を突いている点です。そのため「最新ファームウェアを適用しているから安全」とは限りません。
- FortiBleed の攻撃手口と影響範囲の概要
- ファームウェアを更新しても認証情報が危険なまま残り得る理由（SHA-256 ハッシュ移行の落とし穴）
- 自社の FortiGate が影響を受けるかを確認する手順
- アップグレード・再ログイン・認証情報ローテーションによる恒久対処
- すぐに取れる暫定回避（管理アクセスの制限と SSL-VPN の最小化）
- 侵害の有無を調べるインシデントレスポンスの観点
結論を先に示すと、対処の要点は 3 つです。第 1 に、PBKDF2 ハッシュをサポートする FortiOS へアップグレードしたうえで、全管理者が一度ログインし直し、古い SHA-256 ハッシュを再ハッシュさせること。第 2 に、管理者・VPN の認証情報をローテーションし、フィッシング耐性のある MFA を有効化すること。第 3 に、即時の暫定回避として管理インターフェースの外部公開を絞り、不要な SSL-VPN を無効化して攻撃面を縮小することです。
FortiBleed とは — キャンペーンの概要と影響範囲
FortiBleed は、インターネットに面した Fortinet FortiGate ファイアウォールと SSL-VPN ゲートウェイを標的に、有効な認証情報を大規模に収集している継続中のキャンペーンです。セキュリティ研究者の Volodymyr “Bob” Diachenko 氏が攻撃者の公開サーバーを発見し、SOCRadar が全体像を分析しました。ロシア語話者とみられる脅威アクターによる活動と報告されています。
攻撃の手口（クレデンシャルスタッフィングと設定ファイルからのハッシュ採取）
攻撃は自動化された自己増殖型の 2 段構えとされています。まずインターネットを広範にスキャンして Fortinet のリモートログインエンドポイントを特定し、漏えい済みの既知パスワードのリストでログインを試行します。次に、侵入に成功した機器を通過する通信を受動的に監視して追加の認証情報を収集し、それを使ってさらに別の機器を侵害します。収集した認証情報は 1 件ずつ有効性が検証され、確認済みの「使えるログイン」としてデータベースに蓄積されていきます。
英国 NCSC は本キャンペーンを、ブルートフォース・辞書攻撃・クレデンシャルスタッフィングを用いる世界規模のものと説明しています。設定ファイルの取得経路については、一部の報道で 2026 年 1 月公開の FortiCloud SSO 認証バイパス（CVE-2026-24858、CISA の KEV カタログ収録）との関連が指摘されていますが、取得手段は公式には確認されていません。
ゼロデイではない — 86,644 台が示す認証情報衛生の問題
本キャンペーンで注目すべきは、新たなゼロデイ脆弱性が悪用された形跡が確認されていない点です。SOCRadar は Fortinet 製品の脆弱性が悪用された証拠は見つからなかったとしており、Fortinet 自身も、関与するデータは過去のインシデントの再共有と認証情報の総当たりによるもので、現行のアドバイザリとは関係しないとの見解を示しています。
参考: The Hacker News（Fortinet 広報コメント）
“the data involved is likely a resharing of data from previous incidents”
（関与するデータは、過去のインシデントから再共有されたものである可能性が高い）
https://thehackernews.com/2026/06/cisa-warns-fortinet-customers-as.html
影響を受けた機器の台数は調査の進展とともに更新されており、SOCRadar は 2026 年 6 月 19 日時点で 86,644 台としています（CISA は約 74,000 台と言及）。対象は 194 か国に及び、影響の大きい業種は通信・政府・教育、露出の多い国はインド・米国・メキシコ・コロンビア・タイと報告されています。窃取された認証情報の内訳は、汎用的な管理者アカウントが 35%、Fortinet の組み込みシステムアカウントが 28.3%、組織固有のアカウントが 36.7% とされ、初期アカウント名の未改称や工場出荷時パスワードの未変更が広範に残っていることがうかがえます。
なぜパッチ適用だけでは不十分なのか — SHA-256 ハッシュ移行の落とし穴
FortiBleed が大規模化した背景には、FortiGate の管理者パスワードの保存方式が関係しています。要点は、ファームウェアをアップグレードしただけでは古いハッシュが残り続け、設定ファイルを入手されると解読の対象になり得るという点です。以下で仕組みと、見落とされやすい残留ハッシュの存在を整理します。
PBKDF2 への移行と「再ログインしないと再ハッシュされない」仕様
Fortinet は管理者認証情報のハッシュ方式を、解読が速い SHA-256 から計算コストの高い PBKDF2 へ変更し、FortiOS 7.2.11、7.4.8、7.6.1 で導入しました。PBKDF2 は反復計算により、GPU を使ったオフライン解読を大幅に困難にします。
ただし移行には注意点があります。これらのバージョンへアップグレードしても、既存の管理者パスワードは各管理者が一度ログインし直すまで SHA-256 ハッシュのまま保存されます。つまり、パッチを適用済みでも、管理者が再ログインしていない機器は依然として解読されやすい SHA-256 ハッシュを保持したままになります。FortiBleed はこの移行の隙を大規模に突いたとされています。
参考: Fortinet Document Library（Enhanced administrator password security）
“their password remains saved as the SHA256 hashed password”
（そのパスワードは SHA256 でハッシュ化されたまま保存される）
https://docs.fortinet.com/document/fortigate/8.0.0/administration-guide/548023/enhanced-administrator-password-security
設定に残留する old-password（隠し設定）の存在
さらに見落とされやすいのが、再ログインで PBKDF2 へ変換された後も、ダウングレード互換のために古い SHA-256 ハッシュがold-passwordという設定に既定で残る点です。この設定はファイアウォールにログインした管理者からは見えませんが、super_admin が取得した設定バックアップには現れます。つまり、再ログインだけではold-passwordに残った SHA-256 ハッシュを設定バックアップ経由で取得され得るということです。
残留ハッシュを除去するには、config system password-policyのlogin-lockout-upon-weaker-encryptionを有効化したうえで、各管理者がログインし直します。公式ドキュメントによれば、この設定が有効な場合、ログイン成功時に PBKDF2 へ変換されると同時に SHA-256 ハッシュがシステムから削除されます。
config system password-policy
set login-lockout-upon-weaker-encryption enable
end設定名にはバージョン差があります。7.6.1 の新機能ドキュメントでは関連する設定がlogin-lockout-upon-downgradeとして記載され、7.6.3 以降の CLI リファレンスではlogin-lockout-upon-weaker-encryptionが確認できます。稼働中のバージョンの公式 CLI リファレンスで設定名を確認することをおすすめします（参照: 7.6.3 CLI リファレンス https://docs.fortinet.com/document/fortigate/7.6.3/cli-reference/127236326/config-system-password-policy ）
なお、この設定を有効化するとダウングレードが制限される場合があり、アップグレード後にローカル管理者のログインが拒否される事象も公式トラブルシューティング記事で報告されています。本番適用前に検証環境での確認をおすすめします。
自社の FortiGate が影響を受けるか確認する手順
侵害の有無を判断する前に、まず自機が「解読されやすい状態」にあるかを確認します。確認の観点は、稼働バージョン、ハッシュの移行状況、インターネットへの露出の 3 つです。
PBKDF2（PB2）への移行状況を確認する
super_admin で設定バックアップを取得し、管理者アカウントのパスワード行を確認します。PBKDF2 でハッシュ化されたパスワードはPB2で始まる文字列として表示されます。PB2で始まらない、またはold-passwordの行が残っている場合は、レガシーな SHA-256 ハッシュが残存している可能性があります。
config system admin
edit "admin1"
set password ENC PB2xxxxxxxx... （PBKDF2 へ移行済み）
set old-password ENC xxxxxxxx... （残存する SHA-256 ハッシュ）
next
endあわせて、get system statusで稼働中の FortiOS バージョンが PBKDF2 をサポートする 7.2.11／7.4.8／7.6.1 以上かを確認します。
参考: Arctic Wolf（FortiBleed 分析）
“can be observed in a configuration backup taken by a super_admin”
（super_admin が取得した設定バックアップ上で確認できる）
https://arcticwolf.com/resources/blog/active-fortibleed-campaign-impacting-fortinet-devices-across-194-countries/
インターネット露出と管理インターフェースの確認
次に、管理アクセスと SSL-VPN がインターネットへ露出していないかを確認します。WAN 側インターフェースのallowaccessにhttpsやsshが含まれていないか、SSL-VPN が外部公開されていないかを点検します。
show system interface
config vpn ssl settings露出が確認された場合は、後述の暫定回避（管理アクセスの送信元制限と SSL-VPN の最小化）を先行して適用し、恒久対処と並行して攻撃面を縮小することを推奨します。
参照: FortiOS 7.6.3 CLI リファレンス（config system interface、config vpn ssl settings等） https://docs.fortinet.com/document/fortigate/7.6.3/cli-reference
恒久対処の手順
恒久対処の基本は、PBKDF2 に対応したバージョンへのアップグレード、全管理者の再ログイン、残留ハッシュの除去、認証情報のローテーション、MFA の有効化です。CISA もほぼ同内容の対応を推奨しています。漏えい済みの認証情報が悪用される前に、解読されやすい状態の解消と認証情報の入れ替えを進める方針となります。
参考: CISA 勧告（BleepingComputer 報道）
“malicious cyber actors have targeted internet-accessible Fortinet devices”
（悪意あるサイバー攻撃者が、インターネットからアクセス可能な Fortinet 機器を標的にしている）
https://www.bleepingcomputer.com/news/security/cisa-warns-fortinet-users-to-secure-devices-after-fortibleed-leak/
固定リリースへのアップグレードと全管理者の再ログイン
まず、PBKDF2 に対応した固定リリース（7.2.11／7.4.8／7.6.1 以上）へアップグレードします。アップグレードパスは Fortinet の Upgrade Path Tool で確認することをおすすめします。
アップグレード後は、前述のとおり、各管理者が一度ログインし直すことで SHA-256 ハッシュが PBKDF2 へ変換されます。さらに残留するold-passwordを除去するため、config system password-policyのlogin-lockout-upon-weaker-encryptionを有効化したうえで再ログインします（設定名はバージョンにより異なるため、稼働中のバージョンの公式 CLI リファレンスで確認することをおすすめします）
参照: Fortinet Upgrade Path Tool https://docs.fortinet.com/upgrade-tool
VPN／管理者パスワードのローテーションと MFA の有効化
アップグレードと並行して、すべての VPN・管理者パスワードをリセットします。とくにインターネットへ公開している機器を優先します。これにより、すでに漏えいしている認証情報を無効化できます。あわせて、強固なパスワードポリシーの適用と、外部ゲートウェイおよび管理インターフェースでのフィッシング耐性を備えた MFA の有効化をおすすめします。
管理者アカウントへ FortiToken による二要素認証を設定する例は次のとおりです。
config system admin
edit "admin1"
set two-factor fortitoken
set fortitoken <token-serial>
set email-to <admin-email>
next
end参照: Set up FortiToken multi-factor authentication（Fortinet Document Library） https://docs.fortinet.com/document/fortigate/6.2.0/cookbook/458581/set-up-fortitoken-multi-factor-authentication
なお、フィッシング耐性という観点では、ワンタイムコード型よりも FIDO2／ハードウェアキーの利用が望ましいとされています。利用可能な認証方式は環境や契約により異なるため、公式ドキュメントで対応状況を確認することをおすすめします。
すぐに取れる暫定回避
アップグレードや全台の認証情報ローテーションには時間を要します。その間に攻撃面を狭めるため、即時に取れる暫定回避を整理します。いずれも恒久対処と並行して適用する位置づけです。
管理アクセスの送信元制限（trusthost／local-in-policy）
まず、インターネットに面したインターフェースで管理アクセスを公開しない構成にします。WAN 側インターフェースのallowaccessからhttpsやsshを外し、必要な管理サービスのみを信頼できる経路に限定します。
config system interface
edit "wan1"
set allowaccess ping
next
end次に、各管理者アカウントへtrusthostを設定し、接続元を信頼できる IP やサブネットに限定します（1 アカウントあたり最大 10 件）。
config system admin
edit "admin1"
set trusthost1 203.0.113.0 255.255.255.0
next
endより細かい制御が必要な場合は、local-in-policyで送信元・宛先・サービスを指定して受信トラフィックを制限します。
config firewall local-in-policy
edit 1
set intf "wan1"
set srcaddr "trusted-admins"
set dstaddr "all"
set service "HTTPS" "SSH"
set action accept
set schedule "always"
next
endtrusthostとlocal-in-policyには適用範囲や上限などの制限があるため、適用前に公式の制限事項を確認することをおすすめします。
参照: Local-in policy（Fortinet Document Library） https://docs.fortinet.com/document/fortigate/7.6.6/administration-guide/363127/local-in-policy
SSL-VPN の無効化・最小化（CVE-2025-25250 を含む攻撃面の縮小）
SSL-VPN を運用上必要としない場合は、無効化または機能の最小化により攻撃面を縮小できます。ここで、参考までに別件の脆弱性にも触れます。CVE-2025-25250（FG-IR-24-257）は、SSL-VPN web-mode における認証済みユーザーによる情報漏えいで、深刻度は Low です。FortiBleed の原因ではありませんが、回避策が「SSL-VPN の無効化」であり、攻撃面の縮小という方向性は本記事の暫定回避と一致します。根本対処は固定リリース（7.6.1 以上／7.4.8 以上）への更新です。
参考: Fortinet PSIRT（FG-IR-24-257 / CVE-2025-25250）
“an authenticated user to access full SSL-VPN settings via crafted URL”
（認証済みのユーザーが、細工した URL を通じて SSL-VPN 設定の全体にアクセスし得る）
https://fortiguard.fortinet.com/psirt/FG-IR-24-257
SSL-VPN の web-mode は、現行バージョンではconfig system globalのsslvpn-web-modeで制御されます（既定で無効）。意図せず有効化されていないかを確認し、不要であれば無効化します。
config system global
set sslvpn-web-mode disable
endSSL-VPN 全体が不要な場合は、SSL-VPN のファイアウォールポリシーとsource-interfaceの設定を解除します。手順はバージョンによって異なるため、公式 KB「How to disable SSL VPN functionality on FortiGate」を参照することをおすすめします。
アクティブセッションの強制終了
CISA は、アクティブな SSL-VPN セッションと管理者セッションの終了を推奨しています。認証情報のリセットと SSL-VPN の無効化・制限を適用すると、既存セッションは再認証を求められます。あわせて、GUI の SSL-VPN モニター画面から接続中のユーザーを確認し、必要に応じて個別に切断できます。管理者セッションについても、パスワード変更後は再認証が必要となります。
侵害の有無を調べるインシデントレスポンス
漏えいデータセットは不完全な可能性があるため、リストに掲載されていなくても、インターネットに公開していた FortiGate は侵害の可能性を前提に確認することが推奨されています。確認は、機器上の痕跡（不審アカウント・設定変更・ログ）と、横展開先（Active Directory 等の内部システム）の両面で行います。
参考: Canadian Centre for Cyber Security（AL26-014）
“identify unauthorized or suspicious accounts (e.g., forticloud-sync, forticloud-tech)”
（不正または不審なアカウント（例: forticloud-sync、forticloud-tech）を特定する）
https://www.cyber.gc.ca/en/alerts-advisories/al26-014-fortibleed-leak-thousands-compromised-credentials-impacting-fortinet-devices
不審な管理者アカウントと設定変更の確認
まず、FortiGate 上の全アカウントを棚卸しし、不正または不審なアカウント（例: forticloud-sync、forticloud-tech）を特定して、不要・疑わしいものを無効化または削除します。show system adminの出力や設定バックアップを確認し、想定外のローカル管理者アカウントが追加されていないかを点検します。
設定面では、意図しないファイアウォールルールの変更、ログ設定の無効化、永続化につながる構成変更がないかを確認します。監査ログでは、メンテナンス時間外のshow full-configurationや設定バックアップの実行、見慣れない管理ログイン元といった、設定ファイル持ち出しの兆候に注目します。
なお、認証情報をローテーションする前に、永続化（バックドアアカウントやインプラント等）の有無を確認することが推奨されています。永続化を除去しないまま認証情報だけを変更すると、能動的なインプラントが残り、再侵入を許すおそれがあるためです。
ログ精査と Active Directory への横展開チェック
侵害された FortiGate は、通過する認証トラフィック（LDAP バインドや VPN ユーザー認証情報等）を受動的に収集していたとされます。このため、被害が機器内にとどまらない前提で内部システムまで確認します。
ファイアウォール・VPN・認証・ドメインコントローラーのログを精査し、異常なログイン時刻、想定外の IP アドレスや地域、業務時間外のアカウント活動を確認します。あわせて Active Directory を監査し、不正アカウント、新規サービスアカウント、権限昇格、横展開の痕跡を、キャンペーンの活動想定期間（少なくとも 90 日程度）にさかのぼって確認することが推奨されています。侵害の証拠が見つかった場合は、機器のリプレースも選択肢となります。
まとめ
FortiBleed は新たなゼロデイ脆弱性ではなく、認証情報の使い回しとレガシーな SHA-256 ハッシュ保存方式を突いたキャンペーンです。FortiGate を運用する組織は、パッチ適用だけで安心せず、再ハッシュ・残留ハッシュ除去・認証情報ローテーション・MFA・攻撃面の縮小を一連で進めることが望まれます。漏えいリストへの掲載有無にかかわらず、インターネット公開機器は侵害を前提に確認する姿勢が安全側の判断となります。
- FortiBleed はゼロデイではなく認証情報衛生の問題
- パッチ適用後も再ログインまで SHA-256 ハッシュが残存
- 残留する旧ハッシュの除去には専用の password-policy 設定が必要
- VPN・管理者パスワードのローテーションと MFA が有効
- 管理アクセスの送信元制限と SSL-VPN の最小化で攻撃面を縮小
- 不審アカウントと設定変更、AD への横展開を確認
- 漏えいリスト掲載の有無にかかわらず侵害を前提に調査
以上、最後までお読みいただきありがとうございました。
