はじめに
2026 年 6 月、Fortinet 製 FortiGate を標的とした大規模な認証情報窃取キャンペーン「FortiBleed」が相次いで報じられ、6 月 23 日には JPCERT/CC が注意喚起を公開しました。注目すべきは、JPCERT/CC がこの漏えいデータに国内企業に関連するものが含まれていることを確認している点です。「自社の FortiGate は影響を受けているのか」「どう確認すればよいのか」を判断したい運用担当者は少なくないと思われます。
本記事は、FortiBleed の攻撃手法や恒久対処そのものではなく、影響有無の確認と、疑わしい場合の初動に焦点を当てます。攻撃チェーンの詳細や恒久・暫定対処の全体像は関連記事に譲り、ここでは確認作業の道筋を整理します。
- FortiBleed と国内の状況(JPCERT/CC が確認した影響範囲の要点)
- 公開チェックツール(Hudson Rock/SOCRadar)での照会方法と、その限界
- FortiGate のログから設定持ち出しの痕跡を確認する手順
- 見落としやすい IPsec 拠点間 VPN 経由の波及リスク
- 影響が疑われる場合の初動対応の進め方
結論を先に示すと、確認は 3 つの観点で進めるのが現実的です。第 1 に、公開チェックツールで自組織ドメインの該当有無を照会すること。ただし照合ロジックには限界があり、該当なしでも安全とは断定できません。第 2 に、FortiGate のログで設定エクスポートの痕跡と不審な管理者アクセスを確認すること。第 3 に、サイト間 IPsec VPN で接続する対向拠点が侵害された場合の波及も想定し、内部システムまで点検することです。
FortiBleed と国内の状況 — JPCERT 注意喚起の要点
FortiBleed は、インターネットに公開された Fortinet 製 FortiGate と SSL-VPN 機器を標的に、有効な認証情報を大規模に収集しているキャンペーンです。海外セキュリティベンダーの SOCRadar は、攻撃者が運用するデータベースに 194 か国・86,644 台以上の機器のログイン情報が含まれていることを確認したとしています(CISA は 6 月 18 日の注意喚起で約 74,000 台と言及しており、調査主体により台数の見方に幅があります)。
国内の運用担当者にとって重要なのは、これが対岸の火事ではない点です。JPCERT/CC は、漏えいデータに国内企業に関連するものが含まれていることを確認しています。
参考: JPCERT/CC(Fortinet 製品に関連する認証情報の漏えいに関する注意喚起)
当該情報に国内企業に関連するものが含まれていることを確認しています
https://www.jpcert.or.jp/at/2026/at260019.html
新規脆弱性ではないという見解と、研究者側の指摘
本キャンペーンで押さえておきたいのは、新たなゼロデイ脆弱性が悪用された形跡は確認されていない点です。Fortinet PSIRT は、本件が新規の脆弱性や直近のアドバイザリに関連するものではなく、過去のインシデントで取得された認証情報の再利用が主因との見解を示しています。
一方で、一部のセキュリティ研究者は、漏えいした認証情報に現在も有効なものが含まれている可能性を指摘しており、過去情報の再流通としてのみ扱うべきではないとしています。「パッチを適用済みだから安全」とは限らない点が、本件で確認作業を要する理由です。FortiGate の設定ファイルには管理者パスワードのハッシュが含まれるため、設定ファイルを取得されていた場合、機器への直接アクセスがなくてもオフライン解析でパスワードが解読され得ます。攻撃の具体的な仕組みは関連記事『FortiBleed の攻撃チェーンと検知』で解説しています。
確認すべき範囲は FortiGate 単体にとどまらない
JPCERT/CC は、被害が機器内にとどまらない可能性にも触れています。攻撃者は侵害した FortiGate を経由して内部ネットワークの認証トラフィックを傍受するツールを保有しており、Windows ドメイン認証(Kerberos・NTLM)の資格情報まで窃取・解読された事例が確認されています。このため、FortiGate 側の認証情報変更や MFA だけでは塞ぎきれない侵害経路が残ります。
したがって確認作業も、FortiGate の点検に加えて、Active Directory など内部システムの不審なアクティビティまで視野に入れる必要があります。恒久・暫定対処の全体像は関連記事『FortiBleed の影響と恒久・暫定対処』に整理しています。次章から、影響有無を確認する具体的な方法を見ていきます。
自社が影響を受けたかを確認する 3 つの方法
確認は「外部からの照会」と「自機のログ精査」を組み合わせるのが現実的です。まず公開チェックツールで該当の有無を素早く把握し、次に FortiGate のログで設定持ち出しと不審アクセスの痕跡を確認します。いずれか一方では判断材料が不足するため、両方を併用します。
公開チェックツールでドメインを照会する(Hudson Rock/SOCRadar)
最も手早い確認手段は、公開されている照会ツールです。Hudson Rock の FortiBleed ルックアップツールは、自組織のドメインを入力すると、FortiBleed のデータセットに該当があるかを返します。アカウント登録は不要で、結果はその場で表示されます。SOCRadar の FortiBleed Exposure Checker は、ドメインに加えて IP アドレスでも照会できます。
参考: SOCRadar(What Is FortiBleed?)
“queries the attacker’s operational database by IP address and domain”
(IP アドレスとドメインで攻撃者の運用データベースを照会する)
https://socradar.io/blog/what-is-fortibleed/
照会ツールの URL は次のとおりです。
- Hudson Rock: https://www.hudsonrock.com/fortinet
- SOCRadar FortiBleed Check: https://socradar.io/free-tools/fortibleed
ただし、ツールで「該当なし」でも安全とは断定できません。 JPCERT/CC は、照合に用いるデータベースが FortiGuard ライセンス登録時のメールアドレスのドメイン部分を基にしていると推定されるため、SIer や運用委託先による代行登録が行われていた場合、エンドユーザー自身のドメインでは結果に現れないケースがあると指摘しています。M&A で取得した子会社ドメインなど、照会対象に漏れが出やすい点も含め、複数ドメインをまとめて確認することをおすすめします。
設定エクスポート痕跡をログで確認する
本キャンペーンでは、侵害した FortiGate から設定情報をエクスポートして持ち出す手口が推定されています。FortiGate のログには、この設定エクスポートの痕跡が残る場合があります。JPCERT/CC は、GUI のシステムイベントログを「Config」で絞り込み、設定のエクスポート履歴を確認する方法を示しています。
確認時の留意点は次の 2 つです。
- 管理者アカウントの操作履歴だけでなく、REST API アカウントの操作履歴も併せて確認すること。設定取得が API 経由で行われた可能性があるためです。
- メンテナンス時間外の設定バックアップ実行や、見慣れない送信元 IP からの操作に注目すること。
GUI のメニュー名や階層は FortiOS のバージョンにより異なるため、稼働中のバージョンの公式ログリファレンスで、設定変更・設定エクスポートに対応するイベントを確認することをおすすめします。あわせて、CLI で管理者アカウントの一覧を棚卸しし、想定外のアカウントが追加されていないかを確認します。
show system admin参照: Fortinet Document Library(FortiOS Administration Guide)
https://docs.fortinet.com/document/fortigate/8.0.0/administration-guide
不審な管理者アカウントと設定変更を確認する
設定面では、意図しない管理者アカウントの追加や、ファイアウォールルール・ログ設定の変更がないかを点検します。JPCERT/CC は、forticloud、fortiuser、fortinet-support、fortinet-tech-support といった意図しないアカウントの追加に注意するよう示しています。正常時に取得した設定と現在の設定を比較し、差分から不審な変更を洗い出す方法も有効です。
加えて、AD/LDAP 連携用の AD アカウントが FortiGate に設定されている場合は、そのアカウントが組織内の AD 環境で不正に利用されていないかも確認します。アカウント棚卸しや設定変更確認の詳細な手順は、関連記事『FortiBleed の影響と恒久・暫定対処』に整理しています。
見落としやすい侵害経路 — IPsec 拠点間 VPN と対向拠点
確認作業で見落とされやすいのが、サイト間 IPsec VPN で接続する対向拠点経由の波及です。チェックツールで自組織の該当が無くても、安心はできません。 対向拠点を信頼ゾーンとして設定し、サイト間 IPsec VPN で常時接続している環境では、対向側の組織が侵害された機器を保有していた場合、その機器を起点に自組織側へ侵入が及ぶ可能性があります。
実際に、被害組織の一部では IPsec VPN トンネルへのログインが確認されています。FortiBleed の被害として、日本を含む複数国の組織が侵害され、ある NATO 関連の防衛請負業者からは機密文書が持ち出された事例も報告されています。被害が単一機器・単一組織にとどまらない前提で、対向拠点と接続する経路、およびその先の内部システムまで点検範囲に含めることが望まれます。
具体的には、IPsec VPN のログイン履歴、対向拠点側から到達する通信の宛先・認証イベント、ドメインコントローラーへの不審なアクセスを確認します。攻撃者が FortiGate を経由して内部の認証トラフィックを傍受する手口の詳細は、関連記事『FortiBleed の攻撃チェーンと検知』で解説しています。
参照: JPCERT/CC(Fortinet 製品に関連する認証情報の漏えいに関する注意喚起)
https://www.jpcert.or.jp/at/2026/at260019.html
影響が疑われる場合の初動対応
確認の結果、漏えいの可能性が高いと判断した場合は、Fortinet が公開している侵害時の推奨手順「Recommended steps to execute in case of a compromised host」に沿って対応を進めます。本記事では初動の道筋を示し、各作業の詳細手順は関連記事に譲ります。
初動で押さえたい順序は次のとおりです。
認証情報の変更や設定リストアの前に、ログ・設定バックアップなど調査に必要な情報を保全します。証跡を消す前に保存しておくことで、侵害範囲の特定が可能になります。
バックドアアカウントやインプラントなどの永続化を除去しないまま認証情報だけを変更すると、能動的なインプラントが残り、再侵入を許すおそれがあります。順序を逆にしないことが要点です。
管理アクセスの外部公開停止、不要な SSL-VPN の無効化など、攻撃者が使った入口を塞ぎます。
全管理者・VPN のパスワード、SSH 鍵、証明書を変更し、不明な管理者アカウントを削除します。あわせて WebAdmin・REST API アクセスと Automation Stitch に不審な設定がないかを点検します。
脅威がシステムに残存している可能性がある場合、設定バックアップのリストアは避け、初期化したうえで FortiOS を再インストールし、設定を構築し直す方法が安全側の選択肢になります。
認証情報ローテーションや MFA 有効化の具体的な手順は関連記事『FortiBleed の影響と恒久・暫定対処』に、永続化の確認や Active Directory への横展開チェックの観点は関連記事『FortiBleed の攻撃チェーンと検知』に整理しています。被害が確認された場合や判断に迷う場合は、Fortinet サポートへのケース起票(必要に応じて PSIRT の関与)も選択肢となります。
参照: Fortinet Community(Technical Tip: Recommended steps to execute in case of a compromised host)
https://community.fortinet.com/t5/FortiGate/Technical-Tip-Recommended-steps-to-execute-in-case-of-a/ta-p/230694
まとめ
FortiBleed は新規のゼロデイ脆弱性ではなく、認証情報の使い回しとレガシーなハッシュ保存方式を突いたキャンペーンです。JPCERT/CC は国内組織の関与を確認しており、影響有無の確認は「公開ツールでの照会」「ログでの痕跡確認」「内部システムまでの点検」を組み合わせて進めるのが現実的です。チェックツールで該当が無くても、IPsec 拠点間 VPN 経由の波及を前提に確認する姿勢が安全側の判断となります。
- JPCERT/CC が国内企業の関与を確認した認証情報漏えい
- 公開チェックツールでのドメイン照会が確認の第一歩
- ツールの「該当なし」は安全の確証にならない点に留意
- 設定エクスポート痕跡と REST API 操作履歴のログ確認
- forticloud 等の意図しない管理者アカウントの点検
- IPsec 拠点間 VPN の対向拠点経由での波及リスク
- 認証情報ローテーション前に永続化の有無を確認
以上、最後までお読みいただきありがとうございました。
