FortiBleed 台灣企業名單解析：FortiGate 憑證外洩與 IAB 攻擊鏈

更新日期：2026 年 7 月 25 日。一份名為「Taiwan Sample Access」的文字檔近日在 Telegram 被當成商品目錄兜售，台灣媒體報導名單涵蓋約 96 家企業，並把事件與 FortiBleed、FortiGate 登入憑證外洩及初始存取權限交易連結在一起。然而，名單出現公司名稱或網域，與攻擊者已經握有可登入的防火牆、VPN 或內網權限，是兩個完全不同的證據層級。

先講結論：截至本文截稿，公開資料不足以證明名單內 96 家企業均已遭入侵，也不足以把事件歸因於一個新的 Fortinet 漏洞。Fortinet 於 2026 年 6 月 19 日針對被稱為 FortiBleed 的活動表示，初步分析指向先前事件留下的憑證遭重用，以及針對弱密碼、未啟用 MFA 裝置的暴力破解；原廠更明確寫道，這「不是新的 Fortinet 漏洞」。企業仍應把被列名視為高優先級風險訊號，但正確做法是啟動驗證與獵捕，而不是直接宣布資料外洩。

60 秒看懂這起事件

• 發生什麼事：媒體報導一名 Telegram 使用者發布「Taiwan Sample Access.txt」，要求買家依編號挑選目標並私訊議價，呈現典型 Initial Access Broker（IAB，初始存取仲介）銷售話術。
• 名單代表什麼：我們取得的樣本有 96 行、96 個不重複網域，並附員工數與部分營收描述；它比較像目標清單或銷售型錄，而非「存取權限證明」。
• 樣本缺少什麼：沒有 IP、管理埠、帳號、密碼、雜湊、Cookie、Token、VPN 設定、裝置序號、成功登入畫面、驗證時間或目標 ID 對照。
• 能否確認 Fortinet：不能。單靠企業網域無法證明每家公司使用 FortiGate，也無法證明攻擊者利用特定 CVE。
• FortiBleed 是新 CVE 嗎：依 Fortinet 2026 年 6 月 19 日說法，不是。原廠認為這波活動涉及歷史事件憑證重用與暴力破解。
• 企業要不要處理：要，而且應立即處理。被列名雖不是入侵定論，仍可能表示企業被偵察、被納入憑證測試或被拿來包裝交易。

核心判讀：「遭列名」不等於「遭入侵」；「攻擊者聲稱有權限」也不等於「權限已被獨立驗證」。但對防守方而言，這已足以觸發管理介面、VPN、身分系統與設定異動的緊急稽核。

事件時間線：FortiBleed、舊漏洞與台灣企業名單如何交會

名單鑑識：96 個企業網域到底證明了什麼？

我們對取得的文字樣本做了離線結構檢查，不連線掃描名單內任何企業，也不嘗試登入或驗證服務。原始檔共有 96 行、96 個不重複網域；32 行帶有營收描述。員工規模欄位從 1–10 人到 5,000 人以上都有，其中 29 筆標示 10–50 人、27 筆標示 1–10 人，另有 6 筆缺少員工數。檔案的 SHA-256 是：

DE8189EB9DF5D419D33D7DD89553BD364F292F51C3D19A122D1C5073797BF900

這個雜湊只用來識別我們分析的樣本版本，不能證明內容真實。更重要的是，檔案沒有任何可直接支持「已取得權限」的技術材料：沒有裝置 IP、TCP 連接埠、FortiOS 版本、管理介面路徑、VPN realm、帳號、密碼、密碼雜湊、瀏覽器 Cookie、API Token、設定檔片段、成功登入時間、權限層級或買賣貼文所稱的目標編號。

因此，這份檔案目前最多能被稱為「被攻擊者拿來兜售的台灣企業目標清單」。把它稱為 96 家企業的「遭駭名單」、「外洩名單」或「已入侵清單」，都超過現有證據能支持的範圍。

哪些企業遭公開點名？為何本文不重貼完整名單

民視與後續新聞公開列舉的名稱包括友達、上銀、萬海、遊戲橘子、華新麗華、瑞昱、中磊、大同、中菲行、南茂、宏達電、緯創、台灣大、義隆、ETtoday 與 17LIVE 等。這些名稱在此只作為「新聞已公開報導其遭列名」的說明，不是本網站判定它們遭入侵、使用 Fortinet 產品或發生資料外洩。

其餘名單不逐筆轉載。從產業輪廓看，目標橫跨某半導體與電子零組件企業、某網通製造商、某大型製造業、某電信業者、某航運與物流企業、某遊戲及影音平台、某媒體、某資安或 IT 服務商，以及生技醫療、零售與旅宿等領域。這種跨產業分布更像以企業規模、品牌辨識度與可能的外部曝露面作為篩選條件，而不是能證明某一供應鏈或單一產品已被攻破。

不公開完整網域的理由也很直接：完整清單會替後續攻擊者降低偵察成本，可能造成二次傷害。事件研究的價值應該放在攻擊鏈、證據標準與可執行防禦，不是替銷售者放大商品目錄。

三種可能情境：目前證據無法直接選出唯一答案

情境 A：公開資料組成的目標或偵察清單

企業網域、員工數與營收多半可由公司網站、商業資料庫、求職平台或搜尋引擎整理。攻擊者可以先建立高價值目標清單，再以「可選購 Access」話術吸引買家；甚至可能等買家選定後才嘗試掃描、撞密碼或尋找外洩憑證。若是這種情境，清單是真實存在，但存取權限可能被誇大或尚未建立。

情境 B：歷史憑證資料與近期偵察結果的聚合

Fortinet 對 FortiBleed 的分析最接近這個方向：攻擊者重用 FG-IR-26-060、FG-IR-25-647 等先前事件相關憑證，搭配自動化暴力破解，測試仍使用弱密碼、重複密碼或未啟用 MFA 的裝置。攻擊者手上可能有大量舊資料，但只有其中一部分仍可使用；名單本身不會告訴我們成功率。

情境 C：已驗證的有效初始存取庫存

真正的 IAB 會先驗證登入，記錄權限類型、所在地區、企業規模與價格，再把 VPN、RDP、防火牆管理介面或其他邊界帳號賣給勒索軟體集團。若本案屬於此情境，賣方理應能向買家提供去識別化的登入證明、裝置資訊、權限層級與近期時間戳。但這些材料並未出現在目前取得的樣本內，外界也無法逐筆獨立驗證。

三種情境甚至可能同時存在：一部分只是偵察目標，一部分來自過期憑證，少部分則可能已驗證可登入。這正是防守團隊不能把整份名單視為同一證據等級的原因。

FortiBleed 的技術核心：不是「一個新洞」，而是憑證生命週期失守

FortiBleed 是第三方替這波 Fortinet 裝置憑證蒐集與存取活動使用的名稱，不是 Fortinet 新發布的 CVE 名稱。依原廠說明，較合理的技術鏈如下：

先前漏洞或事件取得設定檔／帳號材料
        ↓
抽取管理員或 VPN 身分資訊、舊式密碼表示
        ↓
離線破解、密碼字典、規則變形或憑證重用
        ↓
對網際網路暴露的管理介面／VPN 做自動化驗證
        ↓
弱密碼且未啟用 MFA 的設備被成功登入
        ↓
下載設定、建立新管理員／VPN 使用者、維持權限
        ↓
初始存取仲介依企業價值包裝並出售
        ↓
買家橫向移動、竊取資料或部署勒索軟體

為什麼設定檔會變成長期風險？

防火牆設定檔不只是規則清單。視版本與配置而定，它可能揭露管理員名稱、VPN 使用者或群組、LDAP／RADIUS／SAML 整合、內外網介面、位址物件、路由、憑證、站台命名、管理來源與密碼的受保護表示。即使不能直接還原所有秘密，這些資訊仍能大幅縮小攻擊者的猜測空間，讓密碼破解、社交工程與後續滲透更有效率。

尤其當管理員在事件後只升級韌體，卻沒有輪替管理員、VPN、LDAP bind、RADIUS shared secret、API Token 與其他可能受影響的祕密，舊設定檔就可能在數月後再次被利用。修補漏洞只能阻止同一入口再次被利用，不能自動讓已經被拿走的憑證失效。

為何 PBKDF2 很重要？

密碼雜湊的安全性不只看「有沒有加密」，還看每次猜測的成本。PBKDF2 透過 Salt 與大量重複運算，提高離線字典攻擊與 GPU 大規模猜測的成本。Fortinet 建議升級至最新 FortiOS 7.4、7.6 或 8.0，因為這些分支支援管理員憑證的 PBKDF2 雜湊，並依官方指引移除較弱的舊式密碼設定。這不是替弱密碼開免死金牌；高成本雜湊、獨特長密碼與 MFA 必須同時存在。

FG-IR-26-060 與 FG-IR-25-647 在攻擊鏈中的位置

FG-IR-25-647涵蓋 CVE-2025-59718 與 CVE-2025-59719，根因是 FortiCloud SSO 登入流程對密碼簽章驗證不當。當該功能啟用時，未驗證攻擊者可能以製作的 SAML 訊息繞過驗證。Fortinet 標示此問題曾遭利用，並要求升級到各分支的修正版；暫時緩解方式是關閉 FortiCloud SSO 管理登入。

FG-IR-26-060／CVE-2026-24858則是另一條 FortiCloud SSO 替代路徑驗證繞過。官方說明，觀察到的攻擊者會下載客戶設定檔並新增管理員帳號取得持久性。這類事件的重要後果，不只在當下設備有沒有被修補，也在設定與憑證材料是否已被複製到攻擊者手上。

因此，Fortinet 說「FortiBleed 不是新的漏洞」並不等於「沒有風險」，而是說目前活動不需要假設一個未知零時差漏洞：歷史漏洞取得的資料、未撤銷的憑證、弱密碼、無 MFA 與外露管理面，已足以形成完整攻擊鏈。

如何區分 CVE 利用、撞密碼與真正的入侵？

「可能利用 Forti 漏洞」可以是待驗證假設，但不能直接當作報導結論。正確的歸因必須把產品版本、功能設定、漏洞時間線與裝置日誌串起來。若只有網域清單，最嚴謹的說法是：攻擊者聲稱出售與台灣企業有關的存取權限，其取得方式與真實有效性尚未獲得公開、逐筆驗證。

FortiGate 緊急處置：先做這 10 件事

1. 確認資產：盤點所有 FortiGate、FortiManager、FortiAnalyzer、FortiProxy、FortiWeb 與 FortiSwitchManager，記錄序號、FortiOS 版本、管理介面、VPN、VDOM 與 HA 節點。不要只查主要資料中心。
2. 終止工作階段：依官方建議，終止所有管理員與 VPN 工作階段，再重設相關憑證，避免攻擊者的既有 Session 在改密碼後仍存活。
3. 輪替秘密：更換 Fortinet 管理員、VPN、API、LDAP bind、RADIUS shared secret、站台對站台 VPN PSK 與任何可能出現在外洩設定檔內的祕密；若同一密碼曾在其他系統使用，也要同步撤銷。
4. 全面啟用 MFA：管理員與 VPN 使用者都要啟用 MFA。只對一般使用者啟用、卻保留單因子 super_admin，是常見缺口。
5. 升級 FortiOS：依 Fortinet Upgrade Path Tool 與設備型號選擇受支援版本。FortiBleed 官方建議使用最新 7.4、7.6 或 8.0 以採用 PBKDF2；同時必須核對 FG-IR-26-060、FG-IR-25-647 及所有適用 PSIRT 通告。
6. 移除網際網路管理介面：最佳選擇是完全取消外網管理；若業務上無法做到，至少經獨立管理 VPN／跳板機存取，再用 trusted hosts 與 local-in policy 限制來源。
7. 比對已知良好設定：比較目前設定與事件前的可信版本，找出新增管理員、VPN 使用者、位址物件、VIP、policy、automation stitch、webhook、DNS、路由、Fabric connector 與日誌目的地異動。
8. 檢查可疑帳號：Fortinet 特別提醒留意非預期的 forticloud、fortiuser、fortinet-support、fortinet-tech-support 等名稱；也要檢查看似正常的 support、backup、audit、secadmin 類服務帳號是否由授權人建立。
9. 獵捕身分與橫向移動：查 FortiGate、FortiAnalyzer、SIEM、VPN、AD／Entra ID、LDAP、EDR、DNS 與 Proxy 日誌，將邊界登入與內網 Kerberos、SMB、RDP、WinRM、遠端服務建立事件做時間關聯。
10. 發現異動就當成已失陷：如果看到未授權設定修改、新管理員／VPN 使用者、異常密碼重設或不明地區登入，不要只刪帳號。隔離管理面、保全證據、撤銷所有相關憑證，並依事件應變程序調查內網。

FortiGate 稽核指令：先收集，不要直接在事故中盲改

以下是偏向唯讀盤點的 CLI 起點；FortiOS 版本、VDOM 與集中管理架構不同，輸出與可用語法會有差異。執行前應依官方文件與變更流程確認，敏感輸出不得貼到公開工單或聊天群。

# 版本、序號、HA 與系統狀態
get system status
get system ha status

# 檢視管理員與介面管理服務設定
show system admin
show system interface

# 檢視本機流量限制與 SSL-VPN 設定
show firewall local-in-policy
show vpn ssl settings

# 最近一次管理員登入失敗摘要（支援版本）
diagnose debug admin error-log

# 管理介面 HTTP 驗證工作階段（支援版本）
diagnose http_authd session list

show system admin 與完整設定檔可能含敏感資訊，收集後要加密保存、限制存取。比對時不要只搜尋 Fortinet 公開的幾個可疑名稱，也要建立「授權管理員基準」，逐一確認建立時間、建立者、權限 profile、VDOM、trusted hosts、MFA 與最後使用時間。

local-in policy 的作用與常見誤解

一般 firewall policy 控制「穿越」FortiGate 的流量；local-in policy 控制「目的地就是 FortiGate 本身」的流量，例如 HTTPS、SSH、PING 與部分 VPN／管理服務。只改內外網轉送規則，不一定能限制管理介面。Fortinet 的建議優先順序是 trusted hosts（好）、local-in policy（更好）、完全移除網際網路管理（最好）。

config firewall local-in-policy
    edit <policy_id>
        set intf "<management_interface>"
        set srcaddr "<approved_admin_source>"
        set dstaddr "all"
        set action accept
        set service "HTTPS" "SSH"
        set schedule "always"
    next
end

這只是結構示例，不可直接複製到生產環境。管理者還需規劃明確的 deny 規則、IPv6、HA 管理介面、FortiManager、VPN、FortiGuard／FortiCloud 所需流量與緊急維運來源，並先確保不會把自己鎖在設備外。

把 local-in 流量送進日誌

FortiOS 7.6 起可依 local-in policy 開啟更細緻的本機流量日誌。官方文件示例為：

config log setting
    set local-in-policy-log enable
end

config firewall local-in-policy
    edit <policy_id>
        set logtraffic enable
    next
end

舊版本的日誌能力與語法可能不同。企業應把管理登入、登入失敗、設定異動、VPN 驗證與 local traffic 集中送至 FortiAnalyzer 或 SIEM，並保留足以回溯歷史漏洞期間的資料；只留設備本機幾天日誌，會讓「有沒有被登入」變成無法回答的問題。

偵測邏輯：從「大量失敗」一路追到「成功後異動」

1. 暴力破解與密碼噴灑

• 同一來源 IP 在短時間對多個管理員或 VPN 帳號登入失敗。
• 同一帳號從大量來源、ASN 或國家嘗試登入。
• 固定節奏、低頻但持續數小時或數天的 password spraying。
• 大量失敗後緊接著一次成功，而且成功來源過去從未出現。
• 登入失敗理由為無效密碼，帳號名稱卻精準命中內部真實帳號。

FortiGate 的系統事件常含 logdesc="Admin login failed"、status="failed"、reason="passwd_invalid"、user 與 srcip 等欄位。SIEM 不應只對單一失敗事件告警，而要對帳號、來源、國別、設備與時間窗聚合，再關聯成功登入。

2. 管理員登入與設定修改

• 非維護時段的 super_admin 登入，或從首次出現的 IP／國家登入。
• 同一管理員在不可能的時間內從相距甚遠地點登入。
• 登入後立即下載設定、建立管理員、修改 trusted hosts 或關閉 MFA。
• 新增 VPN 使用者、修改 portal／group mapping、變更 LDAP/RADIUS/SAML。
• 新增 VIP、允許規則、automation stitch、webhook、API administrator 或外部日誌目的地。
• 停用日誌、變更 NTP／時區、清除事件，或在 HA 節點間出現不一致設定。

3. 從邊界設備追到內網

一旦 VPN 或防火牆管理權限被取得，攻擊者通常會尋找 AD、虛擬化平台、備份系統、檔案伺服器與遠端管理工具。應以可疑登入時間為中心，前後擴展至少數小時至數天，追查新 Kerberos TGT/TGS、LDAP 查詢激增、SMB/RDP/WinRM、遠端服務、排程工作、EDR 防護停用、備份刪除與大流量外傳。若 FortiGate 連接 AD/LDAP，Fortinet 建議把整合帳號也視為可能受影響並輪替。

事件應變決策樹：被列名後如何判斷嚴重度

管理層應問的不是「我們在不在名單」，而是這 8 題

1. 所有網際網路邊界設備是否都有唯一負責人、版本、序號與曝露面紀錄？
2. 管理介面是否真的只從管理網段／跳板機進入，還是掃描器仍能從外網看到？
3. 所有管理員與 VPN 帳號是否強制 MFA，包含緊急帳號、API 與外包商？
4. FG-IR-26-060、FG-IR-25-647 公布後，除了升級外是否輪替所有相關秘密？
5. 設定檔是否曾被未授權下載；目前能否與可信基準做差異比較？
6. 日誌保存多久，能否回溯 2025 年底至今，而非只看最近七天？
7. FortiGate 的成功登入能否與 AD、EDR、VPN 和網路流量在 SIEM 內關聯？
8. 若今晚確認失陷，誰能決定隔離、輪替、通知、法證與復原？

常見問題 FAQ

FortiBleed 有 CVE 編號嗎？

FortiBleed 本身是第三方替憑證蒐集／重用活動取的名稱，不是一個新 CVE。它可能利用歷史漏洞衍生的設定與憑證資料；Fortinet 點名的背景事件包括 FG-IR-26-060／CVE-2026-24858，以及 FG-IR-25-647／CVE-2025-59718、CVE-2025-59719。

公司出現在名單就代表已經被駭嗎？

不代表。樣本只含企業識別與公開型商業資料，缺少可驗證的存取證據。遭列名不等於遭入侵，但它代表公司可能已被偵察或被用於憑證測試，應立即稽核。

沒有使用 Fortinet，還需要處理嗎？

需要確認名稱與網域後，檢查其他外部邊界設備、VPN、SSO 與外洩憑證。Fortinet 也表示，相關攻擊者被報導會以暴力破解方式針對其他供應商設備；問題的共通點是外露管理面、弱密碼、密碼重用與沒有 MFA。

升級 FortiOS 就結束了嗎？

不夠。升級可修正已知漏洞與改善密碼雜湊，但不會撤銷先前外洩的密碼、Token、VPN PSK 或 LDAP bind secret，也不會移除攻擊者建立的帳號。必須同時終止 Session、輪替憑證、啟用 MFA、比對設定與獵捕橫向移動。

要不要主動聯絡名單內企業？

若是企業內部 CSIRT、供應鏈資安團隊或合法受託單位，可以透過已驗證的正式資安窗口進行負責任通知，內容只陳述「遭公開列名」與可核實事實，不附完整名單、不要求對方點開未知檔案，也不宣稱已入侵。若發現具體入侵證據，應依組織流程通報主管機關與執法單位。

結論：把名單當成觸發器，不要把它當判決書

這起事件最值得注意的不是「96」這個數字，而是邊界設備憑證可以在漏洞修補後很久，繼續在地下市場流通、被破解、被重用，再被 IAB 包裝成勒索軟體的入場券。公開名單無法證明 96 家企業已遭入侵，但也不能因為證據不完整就忽略它。

成熟的處理方式是建立清楚的證據階梯：先確認資產與曝露面，再核對版本與功能，接著查成功／失敗登入、設定異動、可疑帳號與內網活動。沒有技術證據時，不替攻擊者放大未證實的戰果；一旦出現未授權修改，就立刻按照已失陷設備處理。這比追逐一個聳動名單，更能真正降低下一次勒索軟體事件的機率。

參考資料

• Fortinet：Analysis of Reported Credential Compromise of FortiGate Devices
• Fortinet PSIRT FG-IR-26-060／CVE-2026-24858
• Fortinet PSIRT FG-IR-25-647／CVE-2025-59718、CVE-2025-59719
• Fortinet FortiOS Administration Guide：Local-in policy
• 中央社：美商 Fortinet 登入憑證疑似外洩，資安署發布警訊
• TechCrunch：Fortinet firewall credential campaign report
• 民視新聞：台灣企業遭 Telegram 名單點名事件
• Yahoo 新聞／民視：96 家企業名單與資安署應變報導

研究倫理聲明：本文只分析使用者提供的離線文字樣本與公開來源，未掃描、探測或嘗試登入名單內任何企業系統；未公開完整企業網域、私訊帳號或其他可能促成二次攻擊的資訊。