FortiBleed の攻撃チェーンと検知｜暫定回避と恒久対処の手順

はじめに

2026 年 6 月、脅威インテリジェンス企業 SOCRadar が FortiBleed の詳細な調査レポートを公開し、これまで「認証情報の使い回しと総当たり」と報告されていた本キャンペーンの実像が明らかになりました。判明したのは、FortiBleed が単一の脆弱性ではなく、偵察から認証情報の収集・解読・横展開・持ち出しまでを含む 5 段階の攻撃チェーンであり、その中核で FortiGate が正規の診断コマンドを悪用した「盗聴装置」に変えられている という点です。

本記事は、影響範囲と基本的な対処を扱った関連記事『FortiBleed の影響と恒久・暫定対処の全体像』の続編として、攻撃手法の解明と検知・緩和に踏み込みます。

結論を先に示します。FortiBleed の初期侵入は、FortiGate の SSH 管理アクセスに対する総当たりです。侵入後、攻撃者は FortiOS のdiagnose sniffer packetという正規の診断コマンドを使い、ファイアウォールを通過する 24 種類のプロトコルの認証情報を受動的に収集し、解読して Active Directory などへ横展開します。マルウェアを設置しないため痕跡が残りにくい一方、初期侵入は管理アクセスの総当たりに依存するため、防御の要点は、管理アクセスの外部公開を断つこと、推測されやすい管理者名・パスワードを見直して MFA を有効化すること、そして盗聴の痕跡を検知することです。

新レポートで判明したこと — 規模と攻撃チェーンの全体像

SOCRadar のレポートは、FortiBleed を金銭目的のイニシャルアクセスブローカー（IAB）による大規模な認証情報窃取作戦と位置づけています。ツール内のコメントにキリル文字が含まれることから、ロシア語話者による活動と評価されています。

参考: The Hacker News（FortiBleed 報道）
“credential-harvesting operation known as FortiBleed that has targeted over 430,000 FortiGate firewalls”
（43 万台を超える FortiGate ファイアウォールを標的とした、FortiBleed と呼ばれる認証情報窃取作戦）
https://thehackernews.com/2026/06/fortibleed-targeted-fortigate-firewalls.html

430,000 台規模・110 万件の認証情報・5 段階の攻撃チェーン

レポートによれば、本キャンペーンは少なくとも 2026 年 2 月から継続しており、43 万台を超える FortiGate を標的に、659 を超える認証情報収集パイプラインを通じて 1 億 1,000 万件以上の認証情報が特定されています。その内訳には、RADIUS 約 1,480 万件、NTLM ハッシュ約 92 万件、Kerberos ハッシュ約 13 万件、MySQL 認証トークン約 8,900 万件が含まれます。レポート執筆時点では、被害は 80,553 台の FortiGate と 23,406 のドメインに及ぶとされています。

標的は従業員 200 人未満の中小企業（SMB）に偏り、とくに米国とインドが多く、IT サービス業が中心です。これは、サービス提供事業者を起点に顧客環境へ侵入経路を広げる狙いとみられています。日本も対象に含まれ、約 165 ドメインが影響を受けたと報告されており、対岸の火事ではありません。

攻撃は次の 5 段階で構成されます。

• 第 1 段階（偵察）: MasscanやShodanでインターネット上の FortiGate を特定し、国別に分類する。
• 第 2 段階（初期侵入）: 管理パネルと SSL-VPN ポータルへのクレデンシャルスタッフィングと、SSH 管理アクセスへの辞書攻撃で侵入する。
• 第 3 段階（盗聴・収集）: 侵入した FortiGate に FortigateSniffer を展開し、diagnose sniffer packetで 24 プロトコルの認証情報を受動収集する。
• 第 4 段階（悪用）: 収集したハッシュを GPU クラスターで解読し、Active Directory を列挙して横展開する。
• 第 5 段階（収集・持ち出し）: ファイル共有から機密データを持ち出し、窃取したセッションクッキーで認証済みアクセスを維持する。

なお、本キャンペーンは FortiGate のみを狙うものではなく、Synology NAS、Sophos ファイアウォール、RDWeb、Citrix SSL-VPN、MSSQL サーバーなど複数製品を横断的に標的とする、より広範な作戦の一部とされています。

ゼロデイではなく「正規の診断コマンド悪用」という核心

本キャンペーンで重要なのは、新たなゼロデイ脆弱性が悪用された形跡が確認されていない点です。SOCRadar は Fortinet 製品の脆弱性が悪用された証拠は見つからなかったとしています。攻撃者は、総当たりで得た管理アクセスを使い、FortiOS に標準搭載されたdiagnose sniffer packetという正規の診断コマンドを実行することで、マルウェアを設置せずに認証トラフィックを盗聴します。

この「正規機能の悪用」という性質が、検知と防御の両面で重要になります。脆弱性パッチだけでは塞げず、管理アクセスの保護と挙動の検知が防御の中心になるためです。次のセクションでは、この FortigateSniffer の仕組みを具体的に見ていきます。

FortiGate が盗聴装置に変えられる仕組み — FortigateSniffer

このキャンペーンの中核は、侵入した FortiGate を、それ自体を通過する認証トラフィックの「盗聴装置」に変える点にあります。攻撃者は専用マルウェアを設置せず、FortiOS に標準搭載された診断コマンドを悪用します。ここでは、初期侵入から盗聴、解読・横展開までの流れを順に見ていきます。

初期侵入: SSH 管理アクセスへの総当たり（製品特化の辞書攻撃）

攻撃者はまずMasscanやShodanでインターネット上の FortiGate を特定し、FortiProbe-fastで「FortiGate か否か」を選別して総当たりの対象を絞り込みます。そのうえで 2 つの経路から認証を試行します。1 つは Web 管理パネル（/logincheck）と SSL-VPN ポータル（/remote/logincheck）を狙う認証チェッカーforticheck（最大 25,000 スレッドが観測）、もう 1 つは SSH 管理アクセスへの辞書攻撃を行うmpbrute2です。

注目すべきは、mpbrute2が汎用辞書ではなく、FortiGate の管理者アカウント命名規則に特化した 16 種類の辞書（fortiAdmin、system、Support_fortinetなど）を使う点です。レポートで最も狙われたユーザー名として挙がっているのは、adminin、admin、fortiAdmin、fgtsecure、forticloud-syncです。この SSH 経由で得られた管理者認証情報が、次の盗聴フェーズの起点になります。

受動盗聴: diagnose sniffer packet による 24 プロトコルの認証情報収集

SSH 管理アクセスを得た攻撃者は、FortigateSnifferを使って各 FortiGate にログインし、FortiOS の正規診断コマンドdiagnose sniffer packetを実行します。これにより、ファイアウォールを通過する認証トラフィックを受動的に捕捉します。

参考: SOCRadar「Dismantling FortiBleed」
“abuses the FortiOS built-in diagnostic command -diagnose sniffer packet to passively capture authentication traffic”
（FortiOS 標準の診断コマンド diagnose sniffer packet を悪用し、認証トラフィックを受動的に捕捉する）
https://socradar.io/wp-content/uploads/2026/06/Dismantling-FortiBleed.pdf

レポートに記録された、攻撃者が実行したコマンドは次のとおりです（24 のポートを対象とするフィルタ）。

diagnose sniffer packet any 'port 49 or port 88 or port 445 or port 389 or port 135 or port 139 or port 143 or port 110 or port 25 or port 21 or port 23 or port 3389 or port 5985 or port 5986 or port 636 or port 3268 or port 1433 or port 3306 or port 5432 or port 6162 or port 1812 or port 1813 or port 1645 or port 1646' 6 0 a

末尾の引数の意味は、公式リファレンスに照らすと次のとおりです。

• any: すべてのインターフェースを対象とする。
• フィルタ（24 ポート）: 認証に関わるプロトコルのみを捕捉する。
• 6: 詳細レベル 6。パケットの中身（ペイロード）まで 16 進数で出力するため、平文の認証情報やハッシュを抽出できる。
• 0: パケット数 0、すなわち無制限（停止操作まで継続）
• a: 絶対時刻のタイムスタンプ。

参照: Performing a sniffer trace or packet capture（Fortinet Document Library） https://docs.fortinet.com/document/fortigate/8.0.0/administration-guide/680228/performing-a-sniffer-trace-or-packet-capture

対象となる 24 のプロトコルとポートは次のとおりです。

FortiGate はネットワークのゲートウェイに位置するため、そこを通過する認証トラフィックが網羅的に収集対象になります。捕捉された SSH 上の 16 進ダンプは、攻撃者のツールで.pcapngに変換され、解析スクリプトが平文認証情報（RADIUS、MySQL、SMTP、IMAP、POP3 など）とハッシュ（NTLM、Kerberos など）を自動抽出します。

検知の観点で重要なのが、この盗聴に組み込まれた 2 つの回避策です。第 1 に、特定の IP レンジに限定するジオフェンス（ipgeo.csv）。第 2 に、稼働時間をモスクワ時間の 07:00〜18:00 に制限するスケジューリングで、通常業務時間帯のログインに紛れ込み、業務時間外の異常検知を避ける狙いがあります。この運用特性は、後述する検知の手がかりになります。

ハッシュ解読と横展開: Active Directory 列挙とセッション再利用

収集したハッシュは、Hashtopolisで管理された分散 GPU クラスター上のHashcatで解読されます。GPU はクラウドのvast.aiで調達され、解読ジョブは Telegram のボットから制御されていたとされます。解読対象は NetNTLMv2、Kerberos、FortiGate VPN、MSSQL、RAKP など、盗聴したプロトコルに対応しています。

得られた認証情報は横展開に使われます。SMB のスプレーや、共有内のスクリプト・設定ファイルからパスワードを探索するツール（spider.py）、Kerberos によるパスワードスプレー（Spray_da.py）、そして BloodHound 風に AD の弱点（AS-REP ロースティング、Kerberoasting、委任設定、LAPS、gMSA など）を一括列挙するツール（ad_full_audit.py）が用いられます。

最終段階では、SMB から SSH へストリーム転送してローカルに痕跡を残さず持ち出すツール（backup_dfs.py）や、盗聴で得たセッションクッキーを再生して、解読を経ずに社内 Web アプリへ即座に認証済みアクセスする 2,000 以上のスクリプト（curl_replay.sh）が確認されています。実際に、NATO 関連の防衛請負業者から DFS バックアップデータが持ち出された事例が報告されており、被害は機器内にとどまりません。

自社の FortiGate が悪用されていないか検知する

この攻撃はマルウェアを設置しないため、専用シグネチャだけでの検知は困難です。検知は、(1) 不正な管理アクセスの痕跡、(2) 攻撃者の運用特性、(3) IoC（攻撃の痕跡情報）、の 3 つを組み合わせるのが現実的です。

不審な SSH 管理ログインと診断コマンドの実行痕跡

初期侵入は SSH 管理アクセスへの総当たりに依存するため、まず管理者ログインの痕跡を確認します。GUI ではダッシュボードの Administrators ウィジェットで「Show active administrator sessions」を開くと、ログイン種別（https／ssh／jsconsole）と送信元 IP を確認でき、不審なセッションは Disconnect で切断できます。REST API では/api/v2/monitor/system/current-adminsからも取得可能です。

ログ面では、Log & Report のシステムイベント（General System Events）で管理者ログインの成功・失敗を確認します。総当たりの痕跡として、短時間の多数の失敗ログイン、見慣れない送信元 IP、業務時間外のログインに注目します。

検知の限界も正直に押さえておきます。diagnose sniffer packetの実行自体は、既定では専用ログに残りにくいため、コマンド名だけを狙った検知は期待できません。そのため、(1) 不正な管理アクセスの検出、(2) 詳細レベル 6 の盗聴は CPU を消費するためget system performance statusでの負荷確認、(3) 後述の攻撃インフラ宛て通信、を組み合わせて判断します。

参照: List and disconnect administrators logged in to a FortiGate（Fortinet Community） https://community.fortinet.com/t5/FortiGate/Technical-Tip-Multiple-ways-to-list-and-disconnect/ta-p/192340

攻撃者の運用特性（業務時間帯のみ稼働・ジオフェンス）を逆手に取る

第 2 回で触れた 2 つの回避策は、そのまま検知の手がかりになります。盗聴はモスクワ時間（UTC+3）の 07:00〜18:00 のみ稼働するため、日本時間（UTC+9）では 13:00〜24:00 に集中する不審な管理アクセスや外部通信を相関分析する着眼点になります。また、ジオフェンスにより特定 IP レンジに限定して動作するため、自社の公開 IP が攻撃対象に含まれるかを、IoC や公開チェッカーで確認する価値があります（第三者ツールの利用可否は各組織の判断によります）。

IoC の活用（攻撃インフラ IP レンジ・ファイルハッシュ・アカウント名）

SOCRadar レポートには、攻撃インフラの IP やツールのハッシュなど多数の IoC が掲載されています。実務で優先度が高いものを整理します。

ネットワーク IoC としては、攻撃インフラの主要な 4 つの /24 が挙げられます。

FortiGate からこれらの IP レンジへの送信は、盗聴データの送出を示唆します。アカウント IoC としては、不審な管理者アカウント（forticloud-syncなど）や、辞書が狙う管理者名（fortiAdmin、system、Support_fortinet、admin）を棚卸しします。ファイルハッシュ IoC としては、FortigateSniffer や関連ツールの SHA-256 がレポートに掲載されており、内部ホストの EDR で照合できます。完全な IoC リストはレポートを参照することをおすすめします。

参照: SOCRadar「Dismantling FortiBleed」
https://socradar.io/wp-content/uploads/2026/06/Dismantling-FortiBleed.pdf

今すぐできる暫定回避・緩和策

初期侵入が管理アクセスの総当たりに依存するため、管理アクセスを断つことが最も即効性の高い緩和策です。以下はいずれも恒久対処と並行して適用する位置づけです。

管理アクセスの遮断（外部 SSH／HTTPS の無効化、trusthost、local-in-policy）

まず、インターネットに面したインターフェースのallowaccessからsshとhttpsを外し、管理アクセスを外部公開しない構成にします。これが初期侵入経路の直接的な遮断になります。

config system interface
    edit "wan1"
        set allowaccess ping
    next
end

あわせて、各管理者アカウントへtrusthostを設定し、接続元を信頼できる IP やサブネットに限定します。

config system admin
    edit "admin1"
        set trusthost1 203.0.113.0 255.255.255.0
    next
end

より細かい受信制御にはlocal-in-policyを用います。具体的な設定例は関連記事『FortiBleed の影響と恒久・暫定対処の全体像』に整理しているため、本記事では重複を避け、そちらを参照する形にします。

推測されやすい管理者名・パスワードの見直しと MFA

本攻撃の辞書は、fortiAdmin、system、Support_fortinet、adminといった FortiGate 特有の管理者名を狙います。そのため、既定的で推測されやすい管理者名の改称、不要な管理者アカウントの無効化、強固でユニークなパスワードへの変更が有効な緩和策になります。あわせて、外部ゲートウェイと管理インターフェースでのフィッシング耐性を備えた MFA の有効化をおすすめします（FortiToken による設定手順は前回記事を参照）。

攻撃インフラ IP のブロックと SSL-VPN の最小化

検知で挙げた攻撃インフラの 4 つの /24 は、遮断対象にもなります。ここで注意したいのは、遮断の向きによって使う機能が異なる点です。FortiGate 自身への受信（管理アクセス）は前述のallowaccess／trusthost／local-in-policyで制限します。一方、盗聴データの送出や持ち出しといった攻撃インフラ宛ての送信は、通常のアウトバウンドの拒否ポリシーや外部ブロックリスト／脅威フィードで遮断します。

config firewall policy
    edit 0
        set name "deny-fortibleed-infra"
        set srcintf "any"
        set dstintf "wan1"
        set srcaddr "all"
        set dstaddr "fortibleed-infra"
        set action deny
        set schedule "always"
        set service "ALL"
    next
end

fortibleed-infraは、上記 4 つの IP レンジをまとめたアドレスグループとして事前に作成します。さらに、初期侵入面の 1 つである SSL-VPN ポータルについては、運用上不要であれば無効化または web-mode の無効化により攻撃面を縮小できます（具体的な手順は前回記事を参照）

参照: Local-in policy（Fortinet Document Library） https://docs.fortinet.com/document/fortigate/7.6.6/administration-guide/363127/local-in-policy

恒久対処 — PBKDF2 移行・MFA・運用の見直し

暫定回避で時間を稼ぎつつ、恒久的には認証情報の保護、多要素化、管理面の分離、監視体制の整備を進める方針となります。本攻撃が FortiGate を通過する認証情報そのものを狙う以上、FortiGate 単体だけでなく、認証基盤全体の堅牢化まで視野に入れることが望まれます。

PBKDF2 への移行と認証基盤の堅牢化

FortiGate の管理者パスワードは、PBKDF2 に対応した FortiOS（7.2.11／7.4.8／7.6.1 以上）へアップグレードし、全管理者が再ログインすることで再ハッシュされます。さらに残留する旧ハッシュの除去が必要です。これらの詳細な手順は関連記事『FortiBleed の影響と恒久・暫定対処の全体像』に集約しているため、本記事ではそちらを参照する形にします。

加えて本攻撃では、FortiGate を通過する Active Directory の認証情報（NTLM、Kerberos など）が盗聴・解読されます。そのため、GPU 解読に耐える強固なパスワードポリシー、RC4 を避けた Kerberos の AES 暗号化、不要な平文・レガシー認証プロトコルの削減といった、認証基盤側の堅牢化もあわせて検討する価値があります。

参照: Enhanced administrator password security（Fortinet Document Library） https://docs.fortinet.com/document/fortigate/8.0.0/administration-guide/548023/enhanced-administrator-password-security

アウトオブバンド管理と監視・検知ルールの整備

恒久的な管理面の対策として、管理アクセスをインターネットから到達できない専用の管理ネットワーク（アウトオブバンド管理）に分離する構成が有効です。これにより、初期侵入の前提となる「インターネット経由の管理アクセス」そのものを断てます。

監視面では、FortiGate のログを SIEM へ転送し、想定外の送信元・業務時間外の管理者ログイン、CPU の急上昇、攻撃インフラ宛ての通信を検知ルール化します。検知ルール設計の起点として、SOCRadar レポートの MITRE ATT&CK マッピングから、本攻撃の主要な技術を抜粋します。

これらを SIEM のユースケースに落とし込むことで、単一の痕跡では見えにくい本攻撃を、複数の弱いシグナルの相関として検知しやすくなります。

まとめ

FortiBleed の新レポートにより、FortiGate が正規の診断コマンドで「盗聴装置」に変えられる攻撃チェーンの実像が明らかになりました。初期侵入は SSH 管理アクセスへの総当たりに依存するため、管理アクセスの遮断・推測されやすい管理者名の見直し・MFA が即効性のある緩和策となります。検知は不正な管理アクセス・運用特性・IoC の組み合わせで行い、恒久的には PBKDF2 移行とアウトオブバンド管理、監視体制の整備が望まれます。

• FortiBleed は正規の診断コマンドを悪用した盗聴型の攻撃チェーン
• 初期侵入は SSH 管理アクセスへの総当たりに依存
• FortiGate を通過する 24 プロトコルの認証情報が収集対象
• 即効策は外部 SSH／HTTPS の遮断と管理者名の見直し
• 検知は不正な管理アクセス・業務時間帯の偏り・IoC の組み合わせ
• 攻撃インフラ 4 レンジの監視とアウトバウンド遮断
• 恒久対処は PBKDF2 移行・MFA・アウトオブバンド管理

以上、最後までお読みいただきありがとうございました。