FortiBleed｜Fortinet機器7.4万台の認証情報流出とCISA警戒、SOCがいま実施すべき該当確認・認証ローテーション・ログ監査を攻撃者視点で

「うちのファイアウォールは設定も済んでいるし、ベンダーのサポートも受けている。だから大丈夫」。Fortinet製のFortiGateを使っている現場で、そう考えていた方ほど、今回の話は一度立ち止まって読んでほしい内容です。問題はパッチを当てれば終わる類の脆弱性ではなく、すでに外へ漏れてしまった「正規の認証情報そのもの」だからです。

2026年6月18日、米国のサイバーセキュリティ・社会基盤安全保障庁（CISA）が、Fortinet製機器に関連する認証情報の大量流出が確認されたとして注意喚起を出しました。報道で「FortiBleed」と通称されるこの事案では、世界で約74,000台のFortinet製ファイアウォール・VPNゲートウェイに紐づく認証情報が攻撃者の手に渡ったとされています。新たな脆弱性が見つかったわけではない、という点がこの事案の不気味さを際立たせています。

この記事では、FortiBleedで何が起きたのかを一次情報から整理し、流出した認証情報が攻撃者の手でどう侵入に悪用されるのかを攻撃者視点で解き明かします。そのうえで、SOC（セキュリティ監視を担うチームや組織）・情シス・ネットワーク運用者が、いま実施すべき該当確認・認証情報のローテーション・ログ監査の手順を、現場で使えるレベルで整理します。攻撃の手口を取り上げるのは、あくまで防御のためです。敵がどこを狙うかを知らなければ、守るべき場所も見えてきません。不安を煽るためではなく、落ち着いて優先順位をつけて守りを固めるために、順を追って読み解いていきましょう。

FortiBleedとは何が起きた事案なのか

まず事実関係を一次情報ベースで整理します。FortiBleedは、Fortinet製のファイアウォール・VPNゲートウェイ（主にFortiGate）の設定情報に含まれていた認証情報が、攻撃者によって大量に収集・流出した事案です。CISAが現地時間2026年6月18日に注意喚起を出したことで、広く知られるようになりました。影響を受けるとされる機器は世界で約74,000台。これはインターネットに接続されているFortinet製ファイアウォールの相当な割合に及ぶと指摘されており、影響範囲は2万を超えるドメイン、194カ国にまたがると報じられています。

重要なのは、この事案が「新しい脆弱性の発見」ではない点です。CISAの注意喚起の時点でも、あらたなゼロデイ脆弱性が確認されたわけではないとされています。では認証情報はどこから漏れたのか。Fortinetの見解として報じられているのは、過去に悪用された脆弱性の名残、ブルートフォース攻撃（パスワードの総当たり）、そして過去のインシデントで収集されたデータが今回まとめて表面化した、という複合的な経路です。つまり「昨日まで安全だった機器が今日突然破られた」という話ではなく、「これまでの侵害や設定の隙が、いま一括して攻撃者の武器庫に積み上がった」と捉えるのが実態に近いでしょう。

この流出は、セキュリティ研究者が攻撃者側のサーバーに露出していたデータを発見したことで明るみに出ました。攻撃者が自らのツールや収集物を置いていたサーバーが外から見える状態になっており、そこに大量のFortinet機器の認証情報が含まれていた、という経緯です。皮肉な話ですが、攻撃者の不注意がなければ、この流出は水面下で静かに悪用され続けていた可能性が高いと言えます。

ここで押さえておきたい用語が「設定情報からの認証情報流出」です。FortiGateのようなファイアウォールは、VPN接続のためのユーザー認証情報や管理者アカウント、各種の連携設定を内部に保持しています。設定ファイルが何らかの形で外部に渡ると、そこに含まれるパスワードのハッシュ値や、場合によっては平文に近い情報まで攻撃者の手に渡ります。攻撃者はそれをオフライン（自分の環境）でじっくり解析し、使える認証情報を選り分けていくわけです。

攻撃者は流出した認証情報をこう悪用する

では、手に入れた約74,000台分の認証情報を、攻撃者は具体的にどう使うのか。防御を組み立てるための材料として、攻撃者の視点で順に見ていきます。いずれも特別なexploitコードを必要とせず、「正規の認証情報を正規の入り口で使うだけ」で成立してしまう点が、この事案のやっかいなところです。

1. VPNの正面玄関を正規の鍵で開ける

もっとも直接的な悪用が、流出したVPN認証情報を使ったリモートアクセスです。FortiGateのSSL VPNは、社外から社内ネットワークへ入るための正面玄関です。攻撃者が正規のユーザーIDとパスワードを持っていれば、その玄関を「正しい鍵」で開けられます。総当たり攻撃のように何度もログインを試みて痕跡を残すこともなく、一発で正規利用者になりすませてしまう。検知の観点から見ると、これは厄介です。失敗ログインの急増といった分かりやすい兆候が出ないまま、攻撃者が社内側に足場を作れてしまうからです。

攻撃者の立場で考えると、VPNゲートウェイは極めて価値の高い標的です。インターネットに常時面して待ち受けており、突破できれば社内ネットワークへ一気に入り込めます。しかも今回は「鍵そのもの」が手元にある。攻撃者から見れば、わざわざ鍵を壊す必要すらない状態です。

2. 管理インタフェースを乗っ取って機器を支配する

流出情報には、一般ユーザーのVPN認証情報だけでなく、機器の管理者アカウントが含まれている可能性があります。管理インタフェースをインターネットに公開している機器であれば、攻撃者は管理者として直接ログインを試みます。管理権限を奪われると、ファイアウォールのルール変更、新たな不正アカウントの作成、ログ機能の無効化まで自在にできてしまいます。守りの要であるはずのファイアウォールが、そのまま攻撃者の拠点に変わるわけです。

3. パスワードを使い回す横展開とハッシュ解析

流出した認証情報の価値は、その機器だけにとどまりません。多くの組織では、同じパスワードや似たパスワードが複数のシステムで使い回されています。攻撃者はVPNで侵入した後、手に入れた認証情報を社内の他のシステム（Active Directory、業務サーバー、クラウドサービスなど）に対しても試します。これがいわゆる横展開（ラテラルムーブメント）です。さらに、流出データにパスワードのハッシュ値が含まれていれば、攻撃者は自分の環境でオフラインで時間をかけて解析し、元のパスワードを割り出そうとします。インターネット越しのログイン試行と違い、オフライン解析は防御側からは見えません。

4. 侵入の足場をランサムウェアへつなげる

VPN経由の侵入は、それ自体がゴールではなく、より深刻な攻撃の入り口になります。近年のランサムウェア攻撃は、VPNやファイアウォールの認証突破を起点に、社内で権限を昇格させ、データを窃取し、最終的に暗号化と二重脅迫へ進むという定型的な流れをたどります。流出した認証情報は、その攻撃チェーンの最初の一歩を攻撃者に無償で提供してしまうのです。「認証情報が漏れた」という一文の背後には、こうした連鎖の起点になり得るという重みがあります。

まず確認すべき「自社が該当するか」の切り分け

攻撃者の手口を踏まえたうえで、防御側が最初にやるべきは「自社が影響対象か」の冷静な切り分けです。慌てて全社のパスワードを一斉変更する前に、状況を正しく把握する一手が効きます。次の観点で棚卸しをしてください。

・Fortinet製機器の利用有無: FortiGateをはじめとするFortinet製ファイアウォール・VPNゲートウェイを使っているか。リースや保守委託先任せで実機を把握できていない場合は、まず構成台帳と現物を突き合わせます。
・インターネットへの露出: SSL VPNや管理インタフェースをインターネットに公開しているか。公開している機器ほど、流出認証情報を使った直接ログインのリスクが高くなります。
・認証情報の鮮度: VPNユーザー・管理者アカウントのパスワードを、過去のどの時点から変更していないか。流出データは過去のインシデント由来を含むため、長く変えていない認証情報ほど危険度が上がります。
・多要素認証（MFA）の有無: VPNログインにMFAをかけているか。パスワード単体で入れる構成は、流出した認証情報がそのまま侵入の鍵になります。

この切り分けで「Fortinet機器を使っており、VPNを公開しており、パスワードを長く変えていない」に当てはまる組織ほど、後述する対応を優先度高く進める必要があります。逆に、Fortinet機器を使っていない組織でも、「認証情報の使い回し」という普遍的なリスクの点では学ぶところがあります。

SOC・情シスがいま実施すべき防御の手順

ここからは、CISAが2026年6月18日付の注意喚起で示した推奨対応をベースに、SOC・情シスが順を追って実施すべき手順を整理します。流出事案への対応は、大きく「セッションと認証情報の即時無効化」「ログによる侵害有無の確認」「再発しにくい構成への作り直し」の3段階で考えると進めやすくなります。

1. セッションを切り、全認証情報をリセットする

最初の一手は、いま生きている接続を断ち切ることです。CISAは、すべてのSSL VPNセッションと管理セッションを終了させたうえで、VPNと管理者のパスワードをすべてリセットするよう求めています。すでに攻撃者が正規の認証情報でログイン中であっても、セッションを切ってパスワードを変えれば、その鍵は使えなくなります。ここで中途半端に一部のアカウントだけ変えると、変えていないアカウントが侵入経路として残ります。VPNユーザー・管理者を問わず、対象機器に関わる認証情報は漏れなくローテーション（一斉更新）するのが原則です。

パスワードの保存方式そのものも見直しましょう。CISAは、管理者の認証情報をPBKDF2（パスワードから鍵を導出する現代的なハッシュ方式で、総当たり解析に強い）で保存するよう推奨しています。古い方式でハッシュ化された認証情報は、流出した際にオフライン解析で破られやすくなります。

2. ログを精査して侵害の痕跡を探す

認証情報を無効化したら、次は「すでに悪用されていなかったか」をログで確認します。CISAも、不正アクセスや横展開の兆候がないかログを精査するよう求めています。攻撃者は正規の認証情報を使うため、失敗ログインのような分かりやすい痕跡が出にくい点に注意してください。見るべきは「成功したログインの中の不自然さ」です。

・見慣れない接続元IP: ふだん業務で使わない国・地域・データセンターからのVPNログイン成功がないか。
・時間帯の異常: 深夜や休日など、本来そのアカウントが使われない時間帯のログインがないか。
・同時・連続ログイン: 同一アカウントが地理的に離れた場所からほぼ同時にログインしていないか（正規利用者と攻撃者の併存を示唆します）。
・管理操作の痕跡: 設定変更、アカウント追加、ログ設定の変更など、攻撃者が支配を固める際に残りやすい操作がないか。

VPNの認証ログだけでなく、侵入後の横展開を捉えるために、Active Directoryの認証ログや主要サーバーのアクセスログも併せて確認します。「VPNで入られた後、社内のどこへ動いたか」を追える状態にしておくことが、被害の全容把握につながります。

3. 多要素認証と管理インタフェースの露出制限

パスワードのリセットだけでは、また同じことが起きます。CISAが強調しているのが、フィッシング耐性のある多要素認証（MFA）の有効化です。MFAをかけておけば、たとえパスワードが再び漏れても、第二の要素がなければログインできません。とくにフィッシング耐性のある方式（ハードウェアキーなど）は、攻撃者がワンタイムコードを盗み取る手口にも強く、流出事案への根本的な防御策になります。

あわせて、ファイアウォールの管理インタフェースをインターネットから到達できないよう制限します。管理画面を公開IPで開けている構成は、流出認証情報を使った直接ログインの標的になります。管理アクセスは社内ネットワークや専用の踏み台経由に限定し、不要な公開を畳むことが、攻撃面そのものを小さくする確実な一手です。最後に、ログ精査で見つかった不正アカウントは速やかに削除し、攻撃者が仕込んだかもしれない裏口を塞ぎます。

流出事案への対応を「対策の型」として整理する

今回のFortiBleedは、特定ベンダーの問題に見えて、実は「認証情報が外に出たとき、組織はどう動くべきか」という普遍的な問いを突きつけています。下の表に、攻撃者の悪用シナリオと、それに対する防御策を対応づけて整理しました。自社の状況と照らし合わせ、抜けている対策がないか点検してください。

攻撃者の悪用シナリオ	防御策	着手の優先度
流出VPN認証情報での正規ログイン	全VPNパスワードの一斉リセット＋セッション終了	高（最優先・即時）
管理者アカウントの乗っ取り	管理パスワードのリセット＋管理画面の公開制限	高（即時）
パスワード単体での侵入	フィッシング耐性MFAの有効化	高（数日以内）
すでに侵入済みの横展開	VPN・AD・サーバーログの精査と不正アカウント削除	中～高（並行実施）
流出ハッシュのオフライン解析	PBKDF2など現代的方式での認証情報保存	中（構成見直し）
パスワード使い回しによる連鎖被害	使い回しの棚卸しと個別化・パスワード管理の徹底	中（恒久対策）

表を見ると、最優先は「いま生きている鍵を無効にすること」、次が「すでに使われていないかの確認」、そして「同じことが起きにくい構成への作り直し」という順序が浮かび上がります。慌てて手当たり次第に動くのではなく、この優先順位に沿って進めるのが、限られた人手で守りを固めるコツです。

Linuxサーバー側のログ監視やファイル権限の固め方については、姉妹サイトLinuxMaster.JPでも実践的に解説しています。VPNの先にある社内サーバーの守りまで含めて見直す際の参考にしてください。

よくある疑問（FAQ）

Q1. FortiBleedは新しい脆弱性（ゼロデイ）なのですか？

いいえ。CISAの注意喚起時点で、あらたな脆弱性が確認されたわけではありません。今回問題になっているのは、過去の脆弱性悪用やブルートフォース、過去インシデントで収集されたデータなどを通じて、すでに攻撃者の手に渡っていた認証情報の大量流出です。パッチを当てて塞ぐ性質の話ではなく、認証情報のローテーションと構成見直しが対応の中心になります。

Q2. Fortinet製機器を使っていなければ無関係ですか？

直接の影響対象ではありませんが、教訓は共通します。VPNやファイアウォールの認証情報が漏れたとき、攻撃者は正規の鍵としてそれを使い、さらにパスワードの使い回しを突いて横展開します。これはどのベンダー製品でも起こり得ます。MFAの有効化、管理画面の公開制限、認証情報の使い回し排除は、製品を問わず有効な備えです。

Q3. パスワードを変えれば、それで対応は完了ですか？

完了とは言い切れません。パスワードのリセットは「いま生きている鍵」を無効化する重要な一手ですが、すでに侵入されていた場合、攻撃者が別の裏口（不正アカウントや設定変更）を仕込んでいる可能性があります。ログを精査して侵害の痕跡を確認し、不正アカウントを削除するところまでをワンセットで進めてください。

Q4. 約74,000台という数字は、自社の機器も含まれているという意味ですか？

その数字だけで自社が含まれるかは判断できません。重要なのは「含まれているかどうか不明な以上、含まれている前提で動く」ことです。Fortinet機器をインターネットに公開して運用しているなら、影響対象である可能性を排除せず、認証情報のリセットとログ精査を優先度高く実施するのが安全側の判断です。

Q5. 中小企業で専任のセキュリティ担当がいなくても、何から手をつければよいですか？

まず「VPNと管理者のパスワードを変える」「管理画面をインターネットに公開していないか確認する」「MFAをかける」の3点から着手してください。この3つは専門知識が浅くても着手でき、効果が大きい対策です。ログ精査が難しい場合は、保守委託先やセキュリティ事業者に「FortiBleedの影響確認」として相談するのも現実的な選択肢です。

本記事のまとめ

FortiBleedは、新しい脆弱性ではなく「正規の認証情報が大量に外へ出てしまった」事案です。だからこそ、パッチを待つのではなく、自分たちの手で鍵を取り替え、すでに使われていないかを確かめ、同じことが起きにくい構成へ作り直すという、能動的な対応が求められます。攻撃者から見れば、流出した認証情報は「壊す必要のない、正規の鍵」です。その鍵が使えなくなる状態を、防御側が先回りして作ることが本質的な対策になります。

やるべきことの軸はシンプルです。セッションを切って全認証情報をリセットし、ログで侵害の有無を確認し、MFAと管理画面の露出制限で再発を防ぐ。この3段階を、今回示した優先順位に沿って淡々と進めてください。正しく知れば、過度に恐れる必要はありません。落ち着いて、しかし確実に、守りを固めていきましょう。