Hudson Rock 旗下的 Infostealers 日前發表 FortiBleed 2.0 調查，公布從 1,703 份 FortiGate 設定報告中整理出的 101,419 筆帳號與憑證紀錄，其中 40,573 筆是可直接使用的明文機密，並統計出 975 個未出現在第一波資料中的網域。Hudson Rock 同時開放免費查詢入口，讓受影響單位以網域查詢並申請「ethical disclosure」。
CyberQ 對照 Fortinet 官方公告、6 月的回應與 FBI 10 月的聯合通告，再以一台 FortiGate 60F（FortiOS 7.6.8）做額外實測，依原文與 Fortinet 建議逐項體檢、檢查設定檔中的機密如何保存、從境外雲端主機複測管理面曝露，並實際操作 Hudson Rock 的查詢入口。體檢全程只讀取設定，體檢後再依結果嘗試啟用兩項建議設定，並記錄實際結果。
事件摘要
FortiBleed 第一波於 2026 年 6 月公布，Hudson Rock 查詢入口目前標示為 73,932 個以上的防火牆網址、194 個國家、21,632 個以上的網域。Fortinet 當時在 PSIRT 部落格回應，認為這是攻擊者重用先前事件取得的憑證，並對密碼管理不良、未啟用 MFA 的設備進行暴力破解，不是新的漏洞。
美國 FBI 與特勤局則於 10 月 6 日發布聯合通告 JCSA-20261006-01，指出 FortiBleed 仍在進行，引用 SOCRadar 驗證的 86,644 台以上受害設備，並點出攻擊者利用重用或外洩的憑證，以及舊式的 SHA-256 密碼雜湊，以 GPU 叢集大規模破解，部分受害者的原有管理帳號被刪除或改密碼，被鎖在自家防火牆之外，存取權也被轉賣給 INC/Lynx 與 Payload 勒索軟體的附屬組織（CyberQ 已在 10 月 9 日的產業精選報導）。
而這次資安界更重視的原因，是第二波的資料型態不同。FortiBleed 2.0 是完整的設定報告，而不只是登入憑證：
- 1,703 份設定報告，1,689 個非空的主機識別碼
- 其中 1,672 份的報告時間戳為 2026 年 2 月 20 日，另 31 份沒有日期
- 原文強調這是「報告日期」，不是確認的入侵或設定擷取日期
- 歸因於代號 k0t 的攻擊者，並引用 NyxLab 與 Group-IB 的研究；與 Qilin、The Gentlemen 勒索集團有受害者重疊，但原文說明直接關聯未經證實
40,573 筆明文究竟是什麼 ?
原文把 101,419 筆紀錄分成明文、雜湊、未解密與空值四類：
| 類別 | 筆數 |
|---|---|
| 本機使用者（含 SSL-VPN） | 37,076 |
| 已驗證的管理員登入 | 1,672 |
| Active Directory LDAP 綁定帳號 | 1,576 |
| HA 叢集密碼 | 144 |
| SMTP 郵件伺服器 | 105 |
| 明文小計 | 40,573 |
| 雜湊（SH2、PB2、AK1 等） | 13,999 |
| 未解密的 FortiOS ENC 值 | 10,743 |
| 空白密碼欄位 | 36,104 |
| 合計 | 101,419 |
閱讀這些數字時，有幾點原文自己也提醒過：
紀錄數不是人數，也不代表憑證目前仍有效，本機使用者紀錄中有 7,437 筆已標示為停用。
975 個網域不是 975 家受害企業， 網域取自三個欄位（主要受害網域、FortiGuard 或 MSSP 註冊信箱、使用者名稱中的信箱），去重後共 1,453 個網域標籤，其中 975 個（67.1%）不在第一波的 22,003 個標籤中。比對時沒有排除免費信箱、沒有合併上層網域，也沒有做 DNS 驗證，註冊信箱也可能屬於 MSSP、電信商或 IT 承包商。
另外，Hudson Rock 公布資料的口徑不一致，Hudson Rock 查詢入口頁面寫的是「Decrypted AD LDAP Binds 1,937」與「Net-New Organizations 75.5%」，與文章表格的 1,576 與 67.1% 不同，入口查詢結果的提示文字稱這些是「confirmed working logins」，與文章「不代表目前可用」的說法也有落差。
CVE-2026-24858 與 Fortinet 的官方立場
原文把 FortiCloud SSO 驗證繞過漏洞 CVE-2026-24858（FG-IR-26-060）列為攻擊活動的背景。這個漏洞於 2026 年 1 月 27 日公告，CVSS 9.8，已確認遭到利用，持有 FortiCloud 帳號與已註冊設備的攻擊者，可登入其他帳號名下、有啟用 FortiCloud SSO 管理員登入的設備。FortiOS 的受影響與修正版本如下：
| 分支 | 受影響版本 | 修正版本 |
|---|---|---|
| FortiOS 7.6 | 7.6.0 到 7.6.5 | 7.6.6 以上 |
| FortiOS 7.4 | 7.4.0 到 7.4.10 | 7.4.11 以上 |
| FortiOS 7.2 | 7.2.0 到 7.2.12 | 7.2.13 以上 |
| FortiOS 7.0 | 7.0.0 到 7.0.18 | 7.0.19 以上 |
FortiOS 8.0 與 6.4 不受影響，FortiProxy、FortiManager、FortiAnalyzer、FortiWeb 等產品的版本則可看官方公告。
需要注意的是，原文也明確表示這些紀錄無法確立每台主機的初始入侵方式。Fortinet 6 月的回應則把重點放在重用憑證與暴力破解。老實說這兩者並不衝突，因為你的設定檔一旦外流，不論當初從哪個入口進來，裡面的機密都必須視為外洩。
為什麼設定檔外流等於機密外流
FortiOS 設定檔裡的密碼有兩種保存方式：
1、雜湊
管理員密碼、API 金鑰等只需要比對的值，以 ENC SH2（加鹽 SHA-256）、ENC PB2（PBKDF2）或更舊的 AK1 開頭。攻擊者只能離線暴力破解，難度取決於演算法與密碼強度。
2、可逆加密
LDAP 綁定密碼、PPPoE 撥接密碼、Wi-Fi 預共用金鑰、VPN 預共用金鑰、憑證私鑰密碼等，設備自己要用到明文，所以必須能還原。未啟用 private-data-encryption 時，加密金鑰寫在韌體裡，同一代韌體的所有設備共用。
2019 年的 CVE-2019-6693（FG-IR-19-007）公開了舊版的內建金鑰，Fortinet 當時就表示這類資料應視為容易解密，並建議啟用 private-data-encryption。n0p 於 2026 年 8 月發表的研究指出，7.4 build 2731 起改用 AES-256-CBC 與一把新的內建金鑰，並在密文後加上 8 位元組標記，但金鑰仍然寫死在韌體中。
下圖以自造的假密碼示範 2019 年公開的舊格式：用公開金鑰加密成設定檔中的 ENC 字串，再原樣還原。示範只為說明原理，長度也比實際設定短，沒有使用任何真實設定值。
接著檢查 60F 從 7.6.4 到 7.6.8 五個版本的自動備份。所有 ENC 欄位解碼後都是 156 位元組，結尾都是 7.4 起的新格式標記，符合 n0p 描述的結構（4 位元組 IV、144 位元組密文、8 位元組標記）。本次測試沒有另外取得新版金鑰，也沒有嘗試解密實機的值，但依該研究，7.6 的設定檔外流時，這些欄位同樣應視為明文外洩。Infostealers 文章中「未解密的 ENC 值」有 10,743 筆，這倒是沒有說明未解的原因。
實測一：依報告與官方建議逐項體檢 60F
這次測試，除了讀取設定與日誌，也並離線分析設備在每次升級時自動產生的設定修訂版。
| 檢查項 | Infostealers 文章或官方建議 | 60F 現況 | 確認 |
|---|---|---|---|
| 韌體版本 | 升到修正版本 | 7.6.8 build 3744 | 已含 CVE-2026-24858 修正 |
| FortiCloud SSO 管理員登入 | 不用就關閉 | disable，2025-08 起五個修訂版都未啟用 | 該攻擊路徑不適用 |
| 可疑帳號名稱 | 比對原文、FG-IR-26-060 與 FBI 通告名單 | 40 個名稱，管理員、API、本機使用者皆 0 筆 | 未發現 |
| 管理員密碼雜湊 | 使用 PBKDF2 | 目前密碼為 PB2 | 符合 |
| 管理員舊密碼雜湊 | FBI 建議移除舊雜湊 | old-password 仍為 SH2 | 可改善，見下方說明 |
| API 金鑰 | FBI 建議檢視並更新 | 兩組，皆為 SH2 | 外洩時可離線破解 |
login-lockout-upon-weaker-encryption | Fortinet 建議啟用 | disable（預設） | 可改善，舊雜湊因此仍在 |
private-data-encryption | 原文建議啟用 | disable（預設） | 影響最大，但本機無法啟用，見下方說明 |
| LDAP、RADIUS 綁定帳號 | 輪替外洩值 | 0 個伺服器 | 不適用 |
| 本機使用者 | 重設、停用閒置帳號 | 1 個，已停用 | 符合 |
| HA、SMTP 機密 | 協調更換 | 單機、SMTP 不驗證 | 不適用 |
| WAN 管理存取 | 限制或移除 | allowaccess 為空、local-in 擋 10443 | 符合 |
| IoC IP | 比對日誌 | 33 個 IP，0 筆命中 | 見下方限制 |
測試中有幾個值得分享的心得：
修補時程
依自動備份的時間，這台 60F 在 2026 年 1 月 7 日到 1 月 31 日之間執行 7.6.5，正好在 CVE-2026-24858 的受影響範圍內，並在修正版釋出後 4 天升到 7.6.6。由於 FortiCloud SSO 從未啟用，幸好這段期間不受該漏洞影響。這也說明，同樣的受影響版本，實際風險取決於功能是否開啟。
設定檔裡以內建金鑰加密的機敏資料有 25 個
其中 14 個是本機憑證的私鑰密碼、8 個是 SSH CA 與金鑰的密碼，另外各 1 個是 PPPoE 撥接密碼、Wi-Fi 預共用金鑰與一個已停用本機使用者的密碼。換句話說，這台家用等級設備的備份一旦外流，就等於交出寬頻帳號、無線網路金鑰與設備憑證的私鑰。大型環境再加上 LDAP 綁定、VPN 預共用金鑰與 RADIUS shared secret，影響就是 Infostealers 提出的統計規模。
60F 無法啟用 private-data-encryption
體檢後實際嘗試啟用這一台的private-data-encryption，很不幸地，在 CLI 的 config system global 下輸入 set private-data-encryption enable，回應是 command parse error（return code -61），也就是 CLI 不認得這個屬性。
diagnose hardware deviceinfo tpm 同樣不存在，get system status 顯示 Private Encryption: Disable。上網重新看了 Fortinet 技術文件，確實有提到 7.6.3 起這個功能只支援具備 TPM 的設備。換句話說，60F 這類沒有 TPM 的機型只要執行 7.6.3 以後的韌體，就用不了原文建議的這項防護，設定檔中的 secret 只能繼續以韌體內建金鑰加密。
舊密碼仍以 SH2 保存
管理員目前的密碼是 PB2，但設定中的 old-password 欄位仍是 SH2 格式。依 Fortinet 技術文件，FortiOS 7.2.11、7.4.8、7.6.1 起管理員密碼改用 PBKDF2，但更新密碼後，舊的 SHA-256 雜湊預設會保留在隱藏的 old-password 欄位，super_admin 權限可匯出的備份看得到。這點要特別注意，這正是美國 FBI 通告點名、被拿去用 GPU 破解的格式。若這組雜湊對應的密碼曾在其他系統重複使用，外洩後就多了一個較容易破解的目標。兩組 API 金鑰也都是 SH2，FBI 通告建議檢視所有 API 金鑰並全部更新。
login-lockout-upon-weaker-encryption 的作用
這個設定就是用來移除舊雜湊的。依 Fortinet 技術文件，啟用後才會清掉 old-password 中的 SHA-256 雜湊（7.2 與 7.4 的設定名稱是 login-lockout-upon-downgrade）。代價寫在 7.6.8 設定 schema 的說明裡，日後若把韌體換成不支援較安全密碼格式的版本，管理員會被鎖定。這台 60F 維持預設的關閉，所以舊雜湊仍在。
日誌比對的限制
集中日誌伺服器保存了 10 月 6 日到 10 月 28 日共約 588 萬行，與 FG-IR-26-060 的 13 個及 FBI 通告的 20 個 IoC IP 比對，結果都是 0 筆。FBI 表列 IP 的觀察期間是 6 月到 7 月，早於這份日誌的保存範圍，所以這部分的比對只能作為參考。
實測二：從境外雲端主機複測管理面曝露
從境外雲端主機對 60F 的公網位址測試 10443、443、80、22、23、541、8443、8080 共 8 個埠，全部無法連線，與 10 月 23 日升級 7.6.8 當天的結果一致。管理介面只允許內網來源，WAN 介面沒有開放任何管理協定，SSL-VPN 服務另以 local-in 政策擋在 WAN 之外。
Fortinet 6 月的建議把管理面限制分成三級，trusted hosts（基本）、local-in policy（較佳）、完全不從網際網路管理（最佳）。FortiBleed 兩波資料都以登入憑證為核心，因此，假設你的管理面不對外開放，外洩的憑證就少了直接可用的入口。
實測三：Hudson Rock 查詢入口怎麼用
查詢入口在 hudsonrock.com/fortinet，輸入網域即可查詢，不需要登入。從網頁前端程式可以看到，查詢實際呼叫的是兩支公開 API：
GET /api/json/v2/stats/website-results/fortinet-domains/<網域>：查單一網域，沒有資料時回傳 404GET /api/json/v2/stats/website-results/fortinet-domains/search?q=<關鍵字>：搜尋
筆者查詢指定的網域，均回傳「No Fortinet data for this domain」。解讀時要注意三點：
- 入口只能用網域查詢，不能用設備 IP 或序號。資安報告提到的網域取自設定中的信箱與受害網域欄位，沒有在設定中留下自家網域的設備，即使在資料集中也查不到。
- 查不到只代表這兩波公布的資料中沒有對應紀錄，不代表設備從未被存取。
有資料的網域可以申請 ethical disclosure。依前端程式，申請表要填姓名、職稱、公司、電話、詢問類型、資訊來源等欄位，並可勾選預約產品展示。信箱必須屬於所查詢的網域（或其上層、子網域），Hudson Rock 會寄信到該信箱驗證。原文寫明查詢免費，但沒有說明揭露內容是否收費、審核需要多久。依原文，揭露內容包含對應的設備 IP 與主機名稱、管理員與本機使用者帳號、LDAP 服務帳號與已還原的明文密碼，以及內部網路的中繼資料。另一方面，Hudson Rock 的付費客戶可在其 Cavalier 平台取得 FortiBleed 1.0、2.0 的原始資料集。填寫申請表前，可自行斟酌要提供哪些個人資訊。
建議檢查清單
以下是 CyberQ 依這次資安議題、FG-IR-26-060、Fortinet 官方建議與 FBI 通告整理，並加上本次實測的發現。執行前請先備份設定。
- 版本：
get system status，確認已高於 CVE-2026-24858 的修正版本。 - FortiCloud SSO：
show full-configuration system global | grep forticloud-sso。不使用就關閉：
config system global
set admin-forticloud-sso-login disable
end - 管理員與 API 帳號：
show system admin、show system api-user，與核准清單比對。其中，FG-IR-26-060 與 FBI 通告列出的名稱（例如 fgtsecure、forticloud-sync、fortinet-support、backupadmin、adminsslvpn、roadmin）只是調查線索，不是入侵的證據。不明的 API 金鑰要刪除，其餘的全部重新產生。 - 雜湊格式：檢查
password與old-password是否仍有SH2或AK1。本次實測顯示，即使目前密碼已是 PB2，舊密碼的雜湊仍可能是舊格式。尚未轉換的管理員要登入一次或重設密碼，才會改存成 PB2。 - 移除舊雜湊：確認每個管理員都已有 PB2 雜湊後再啟用，否則可能被鎖在外面，啟用後就不能再降版到不支援 PBKDF2 的韌體：
config system password-policy
set login-lockout-upon-weaker-encryption enable
end
7.2 與 7.4 的設定名稱是login-lockout-upon-downgrade。CyberQ 在 60F 啟用後重新匯出備份，old-password的 SH2 雜湊已經消失，但兩組 API 金鑰仍是 SH2，這個設定並未處理 API 金鑰。 - 設定檔中的機密：先以
get system status與diagnose hardware deviceinfo tpm確認設備是否具備 TPM。7.6.3 起只有具備 TPM 的設備能啟用private-data-encryption，沒有 TPM 的機型只能把備份檔本身當成機密保管（存放與傳輸都另外加密、限制取得權限），並定期輪替設定中的機密。具備 TPM 的設備可以啟用：
config system global
set private-data-encryption enable
end
7.6.1 起不再要求輸入 32 位十六進位金鑰，而是由設備產生隨機金鑰，管理員無從得知。啟用前系統會警告，以系統預設金鑰加密的舊設定檔，之後將無法還原。依 Fortinet 文件，設備若重置或因硬體故障更換，還原備份後除了管理員密碼以外的加密密碼都會遺失，所以 PPPoE、Wi-Fi、VPN 預共用金鑰等要另外留存。 - 外洩或無法排除外洩時：視同明文外洩，輪替 LDAP 與 RADIUS 綁定密碼、VPN 預共用金鑰、本機使用者密碼、HA 密碼、SMTP 帳號、PPPoE 帳號與 Wi-Fi 金鑰，並重新簽發設備憑證；同時終止所有管理與 VPN 工作階段。
- 管理面：WAN 介面移除
https、ssh等管理協定，設定 trusthost，用 local-in policy 擋住管理與 VPN 埠，並為管理員與 VPN 使用者啟用 MFA。 - 日誌：查詢管理員登入事件（logid 0100032001 成功、0100032002 失敗）中的陌生來源 IP，並比對 IoC。另外要確認被 local-in 擋掉的流量有沒有送到集中日誌。
資安建議
CyberQ 認為，FortiBleed 2.0 的數字需要謹慎解讀，101,419 筆紀錄、975 個網域，其實並不能直接換算成受害企業或可用帳密的數量，原文本身也寫得很清楚。但它提醒的核心問題很具體，FortiGate 設定檔中的機密，預設是用韌體內建的金鑰加密，設定檔外流就等於機密外流。
本次實測的 60F 已修補、管理面不對外、FortiCloud SSO 從未啟用，原文列出的多數檢查項都符合。但 private-data-encryption 仍是預設的關閉，設定檔中有 25 個機密使用內建金鑰，舊密碼與 API 金鑰也仍以 FBI 點名的 SH2 格式保存。這些都是預設值，也代表大多數設備很可能處在同樣的狀態。
實測後，舊密碼的 SH2 雜湊已透過啟用 login-lockout-upon-weaker-encryption 清除，private-data-encryption 則因為 60F 沒有 TPM，在 7.6.8 上無法啟用。對大量部署在分支據點與小型辦公室的這類入門機型來說，這代表 Infostealers 文章中最重要的一項建議可能根本做不到，備份檔的保管就更加關鍵。與其只查自己的網域在不在名單裡，不如假設設定檔終究可能外流，先把設定檔裡的機密保護好。
