CISA 警告:VMware vCenter Server 關鍵 RCE 漏洞已遭實際利用,聯邦機構限期三週完成修補

美國網路安全暨基礎設施安全局(CISA)近日正式警告,一項影響 VMware vCenter Server 的關鍵遠端程式碼執行(RCE)漏洞 CVE-2024-37079 已在實際攻擊中遭到利用,並要求美國聯邦政府機構必須在 三週內完成修補,否則將違反強制性營運指令(BOD)。

該漏洞已於 2024 年 6 月由 Broadcom 修補,成因為 vCenter Server 在 DCERPC 協定實作中的 Heap Overflow(堆積溢位)弱點。vCenter Server 為 VMware vSphere 的核心管理平台,廣泛用於管理 ESXi 主機與虛擬機,一旦遭入侵,等同掌控整個虛擬化環境。

低門檻、高衝擊的 RCE 風險

根據技術分析,攻擊者僅需具備網路連線存取權限,即可透過傳送特製封包觸發漏洞,直接在目標 vCenter Server 上執行任意程式碼。

此攻擊不需帳號權限、不需使用者互動,攻擊複雜度極低,對企業與政府機構而言風險極高。

Broadcom 亦明確指出,CVE-2024-37079 並無任何替代性緩解措施或暫時性防護方式,唯一可行的處理方式即為立即升級至最新版本的 vCenter Server 或 Cloud Foundation。

CISA 列入「已遭實際利用漏洞清單」

CISA 已於上週五將 CVE-2024-37079 納入其「已在野外遭利用漏洞清單(Known Exploited Vulnerabilities, KEV)」,並依據 BOD 22-01 要求所有聯邦民用行政機構(FCEB)最晚須於 2 月 13 日前完成修補。

FCEB 機構包含美國國務院、司法部、能源部與國土安全部等非軍事行政單位。

CISA 強調:

「此類漏洞是惡意行為者最常利用的攻擊途徑之一,對整體政府體系構成重大風險。請依照供應商指引完成修補,遵循 BOD 22-01 對雲端服務的相關要求,若無可行緩解措施,應立即停止使用該產品。」

Broadcom 證實漏洞已遭攻擊者利用

同日,Broadcom 更新原始公告並證實,已掌握 CVE-2024-37079 在實際環境中遭濫用的情資,進一步印證該漏洞的即時威脅性。

VMware 產品成為高價值攻擊目標的趨勢

值得注意的是,這並非個案。

2024 年 10 月,CISA 亦曾要求美國政府機構緊急修補 VMware Aria Operations 與 VMware Tools 中的高風險漏洞 CVE-2025-41244,該漏洞自 2024 年 10 月起即遭中國駭客以零時差攻擊方式利用。

此外,Broadcom 在去年亦陸續修補多項由 美國國安局(NSA) 與 Microsoft 回報、且已被實際利用的 VMware 零時差漏洞,涵蓋 NSX 與多項核心元件。

資安觀點

從近期趨勢來看,VMware 核心管理元件已明確成為國家級與進階威脅行為者的重點攻擊目標。

對企業與關鍵基礎設施而言,vCenter Server 不再只是 IT 管理工具,而是高風險、必須被納入關鍵資產防護與弱點即時修補流程的核心系統。

延遲修補,等同將整個虛擬化環境暴露在可被遠端全面接管的風險之中。

當「已修補」不再安全:FortiGate 防火牆正在被悄悄打開後門

對許多企業來說,「漏洞已修補」往往意味著風險已解除。
但近期多起 Fortinet FortiGate 防火牆遭入侵的實際案例,正在動搖這個資安世界裡最基本、也最危險的假設。

修補後仍遭攻擊,CVE-2025-59718 並未真正落幕

自 2025 年底 Fortinet 修補關鍵驗證繞過漏洞 CVE-2025-59718 以來,原本預期風暴已過。然而,來自全球多位 Fortinet 管理員的回報卻顯示,即便已升級至 FortiOS 7.4.9、甚至 7.4.10,攻擊仍在發生

多名受害管理員指出,他們在完全更新的 FortiGate 裝置上,偵測到異常的 SSO 登入行為,並且在數秒內就被建立新的本地系統管理員帳號,典型帳號名稱包含 helpdesk 等,看起來像是自動化腳本所為。

其中一名管理員表示:

「我們的 FortiGate(FGT-60F)已在 2024 年 12 月 30 日升級至 7.4.9,但 SIEM 仍偵測到透過 SSO 登入後,新管理員帳號被建立。行為模式與 CVE-2025-59718 完全一致。」

熟悉的帳號、熟悉的 IP——攻擊手法高度重疊

多起事件的日誌顯示,攻擊行為具有高度一致性:

  • SSO 登入帳號:cloud-init@mail.io
  • 來源 IP:104.28.244.114
  • 登入後立即建立本地系統管理員
  • 隨即匯出防火牆設定檔(Firewall Config)

這些 入侵指標(IoCs),與資安公司 Arctic Wolf 在 2025 年 12 月揭露的 CVE-2025-59718 實際攻擊行為完全吻合。
差別只在於——這次發生在「已修補」的設備上

Arctic Wolf 也在最新通告中坦言:

「目前尚無法確認,這一波攻擊是否完全被既有修補涵蓋,或是否仍存在未修補的攻擊路徑。」

Fortinet 內部確認:7.4.10 仍未完全修補

更令人警惕的是,多名客戶在與 Fortinet 技術支援單位交涉後,獲得一致回饋:

FortiOS 7.4.10 並未完全修補該驗證繞過問題。

根據目前流出的資訊,Fortinet 正計畫於短期內釋出以下版本,嘗試「完整修補」該漏洞:

  • FortiOS 7.4.11
  • FortiOS 7.6.6
  • FortiOS 8.0.0

截至目前,Fortinet 尚未對外發布正式公開說明,也未回應媒體的多次詢問。

這不只是 FortiGate 的問題,而是「修補信任」的問題

從技術角度來看,CVE-2025-59718 的核心風險在於:

  • 攻擊者可透過惡意構造的 SAML 訊息
  • FortiCloud SSO 啟用的情況下
  • 繞過身分驗證,直接取得管理權限

一旦成功,攻擊者能做的事情遠不只新增帳號——
匯出防火牆設定、建立 VPN 帳號、橫向移動、長期潛伏,都是合理推論。

暫時性防護建議:關閉 FortiCloud SSO

在 Fortinet 提供「可驗證的完整修補」前,現階段最實際、也最有效的風險緩解措施只有一個:

立即停用 FortiCloud SSO(若已啟用)

GUI 操作路徑:
System → Settings →
關閉「Allow administrative login using FortiCloud SSO」

CLI 指令:

config system global
set admin-forticloud-sso-login disable
end

Fortinet 也曾在原始公告中指出:
若設備未註冊 FortiCare,FortiCloud SSO 預設並不啟用。

然而,事實並不樂觀。

仍有上萬台設備暴露在網際網路上

根據 Shadowserver 監測數據:

  • 2025 年 12 月中旬:超過 25,000 台 Fortinet 設備啟用 FortiCloud SSO 並暴露於網際網路
  • 目前仍有 約 11,000 台 可被直接存取

同時,美國 CISA 已正式將 CVE-2025-59718 列入「已被積極利用漏洞清單(KEV)」,並要求聯邦機構在一週內完成修補。

結語:這是一個「假修補」時代的真實案例

FortiGate 事件再次提醒我們:

修補 ≠ 安全
版本號 ≠ 風險解除
官方公告 ≠ 攻擊結束

對企業與資安團隊而言,現在最重要的不是「是否已更新」,
而是——是否真正理解修補範圍、實際攻擊路徑,以及風險仍存在的現實。

這起事件,值得所有依賴邊界設備與 SSO 架構的組織,重新審視自己的「信任模型」。

問題從來不只是某一家產品安不安全,
而是在攻防節奏上,攻擊者往往比修補流程更快完成布局。

24 小時內,6 家台灣企業被勒索軟體點名——這不是資安事件,而是警訊

在資安圈裡,有些數字本身就足以構成警訊。

不是因為它們驚人,而是因為它們「不該出現」。
台灣時間1月20日,24 小時內,6 家台灣企業,被4 個不同勒索軟體組織公開列為受害者。

這不是單一攻擊行動,也不是某個企業「資安做得不夠好」。
從威脅情資角度來看,這是一個高度一致的訊號
台灣,正在被多個勒索生態系同時鎖定。

同一天,多個名字被放上洩密網站

根據竣盟科技B-Lab的情資,在短短一天內,以下台灣企業先後出現在不同勒索集團的洩密頁面上:

OO貿易有限公司,出現在 Gentlemen 勒索軟體名單中;


OO電子(上市)、OO工程顧問、OO鋼鐵,則同時被 Everest 勒索軟體公開點名;


OO企業,遭麒麟(Qilin)勒索軟體宣稱入侵;


WorldLeaks 則揭露了OO電子的內部資料。

產業不同、規模不一、使用的系統與供應鏈各異,唯一的共通點只有一個:
他們都在同一個時間點,被不同勒索組織選中。

Everest:對台灣最「熟門熟路」的那一群人

如果要從中挑出最值得警惕的名字,答案會是 Everest

Everest 並不是新出現的勒索組織。它自 2020 年底 開始活躍,最早鎖定法律服務業,透過雙重勒索模式迅速累積談判經驗與地下聲量。與其他勒索集團不同的是,Everest 很早就不只滿足於「加密換錢」,而是進一步扮演 Access Broker,將已入侵企業的網路存取權轉售給其他犯罪集團。

也正因如此,Everest 對企業內部環境、談判節奏與心理壓力的掌握,向來相當精準。

對台灣而言,Everest 的出現並非突如其來。
2025 年 12 ,Everest 曾高調宣稱入侵華碩(ASUS),並竊取近 1TB 資料。即便華碩後續澄清,實際受影響的是供應鏈夥伴,而非核心系統,但這恰恰點出了勒索集團近年的核心戰略——

不必打進品牌本體,只要控制供應鏈節點,就能產生等量衝擊。

到了 2026 年 1 月 20 ,Everest 不再只點名單一企業,而是在 24 小時內,同步公開三家台灣企業的外洩資訊。
這代表的,不是「運氣不好」,而是它已經完成對台灣目標輪廓的描繪。

其他勒索組織,正在同一時間進場

值得注意的是,這一天並不只有 Everest 在行動。

Gentlemen 勒索軟體 屬於新興但攻擊節奏明確的勒索集團,對OO貿易的攻擊,延續其一貫鎖定中小型企業的策略,特點是談判時間短、公開壓力高。

麒麟勒索軟體為近年快速成長的勒索品牌,鎖定製造與供應鏈相關企業,擅長結合資料外洩與營運中斷,對企業實質衝擊極大。


WorldLeaks 以「資料公開」為核心威脅手段,未必強調全面加密,而是直接以外洩資料作為談判籌碼,對品牌信任與客戶關係傷害極深。

這些勒索集團彼此沒有合作,也沒有共享工具,但卻在同一時間點,把目光投向台灣。
從情資分析角度來看,這幾乎可以被視為一種「市場共識」。

為什麼是台灣?這是一個冷靜但現實的答案

從勒索集團的角度來看,台灣具備極高的「攻擊性價比」:

這裡有全球關鍵的電子製造與供應鏈節點;
有大量 IT 與 OT 混合的老舊環境;
有資料價值極高、卻資安成熟度不一的企業結構;
也有一旦外洩,就會對上下游造成連鎖壓力的產業特性。

對攻擊者而言,這不是地緣政治,而是投資報酬率。

24 小時,真正該被記住的是什麼?

不是哪一家企業被點名,
也不是哪個勒索組織最兇狠。

而是這個事實本身——
多個勒索生態系,正在同時對台灣測試、施壓,並驗證成功率。

對台灣企業來說,現在真正該問的,已經不是:
「我們會不會成為目標?」

而是:
「當我們被選中時,是否真的準備好了?」

因為從這 24 小時開始,答案已經不再是理論問題,而是時間問題。

“轉貼、分享或引用文章內容,請註明出處為竣盟科技 https://www.billows.tech , 以免觸法”

GlobalProtect 高風險漏洞修補:PoC 已曝光,防火牆安全告急

近期,資安公司Palo Alto Networks 修補了影響 GlobalProtect Gateway 與 Portal 的高風險漏洞(CVE-2026-0227,CVSS 7.7),該漏洞已有公開 PoC(Proof-of-Concept 可利用。GlobalProtect 是 Palo Alto Networks 提供的 VPN 與安全遠端存取解決方案,可透過 Palo Alto 防火牆將使用者流量導入企業網路,並套用與內部網路相同的安全控管。

漏洞概述

此次漏洞影響 PAN-OS 系統,允許攻擊者在 無需認證 的情況下對防火牆發動拒絕服務(DoS)攻擊。官方公告指出:

「PAN-OS 軟體存在漏洞,可能讓未經授權的攻擊者造成防火牆拒絕服務。重複觸發此漏洞可能導致防火牆進入維護模式。」

攻擊者若重複利用此漏洞,可將防火牆強制置入維護模式,使網路流量中斷,並暫時喪失防火牆保護,直至管理員手動干預。

受影響版本

資安廠商強調,此漏洞僅影響已啟用 GlobalProtect Gateway 或 Portal 的 PAN-OS 或 Prisma Access 環境;Cloud NGFW 不受影響。截至目前,Palo Alto Networks 尚未發現該漏洞在實際攻擊中被濫用的案例。

專家觀點與建議

  1. 立即檢查與升級:受影響的企業應立即檢查防火牆版本,並盡快升級至官方修補版本,以降低被 PoC 攻擊利用的風險。
  2. 監控異常行為:加強對防火牆進入維護模式、異常重啟或網路流量中斷的監控,避免未授權中斷服務影響營運。
  3. 強化遠端存取安全:除了更新防火牆,建議檢視 VPN 登入策略、限制無用的遠端訪問,以及定期審查使用者權限。
  4. 追蹤威脅情資:考量近期針對 GlobalProtect 登入的攻擊活動(自 2025年12月初起,駭客鎖定 GlobalProtect 登入與 SonicWall API 掃描),企業應整合威脅情資,以快速辨識可疑行為。

總結來說,這次漏洞雖未有大規模攻擊報告,但 PoC 已公開,對企業網路安全仍構成實質威脅。建議企業管理層與資安團隊立即採取行動,確保防火牆與 VPN 安全不受威脅。

Everest 勒索組織再出手:自稱竊取 Nissan 900GB 內部資料,倒數五天公開

Photo Credit: HackRead

國際知名的跨國汽車製造商日產汽車Nissan 再度成為全球資安焦點。
根據HackReadCybernews以及TechNadu等多家資安新聞網站的報導與俄羅斯具關聯的勒索組織 Everest2026 年 1 月 10 在暗網公開聲稱,已成功入侵日本汽車製造巨頭日產汽車Nissan並竊取高達 900GB 的內部資料。

攻擊者同時發出 五天倒數 威脅,若 Nissan 不回應要求,相關資料將於暗網全面外洩。
這種「倒數公開」策略已成全球勒索組織施壓談判的標準手法。

Everest 公開的截圖顯示:內部文件、經銷商資料、營運報表疑遭掌握

Everest 在其暗網洩漏網站上傳多張資料樣本,根據Cybernews 研究團隊對這些樣本進行初步比對。

Photo Credit: Cybernews

從資料樣本內容可見:

  • 包含 經銷商名稱、地址、城市/州別、經銷計畫文件
  • 內部文件目錄截圖:ZIP、TXT、CSV、XLS、PGP 等格式
  • 涉及 經銷據點資料、認證流程文件、財務報告、營運系統輸出
  • 甚至包含 遺失與尋獲鑰匙報告(lost & found car key reports)
  • 其他與 Nissan 合作經銷商往來的作業文件

研究團隊指出,雖截圖未直接曝光個資,但有高度可能含有員工或客戶聯絡資訊,並表示:

「主要風險目前仍是聲譽,但若包含員工或客戶 PII,則會大幅提高法規責任與風險。」

換言之,目前外界最擔憂的不是截圖顯示了什麼,而是未公開的 900GB 裡還有什麼。

Nissan 過往資安事件頻傳:客戶資料、員工資料、原始碼都曾遭波及

Everest 這次的威脅並非 Nissan 首度面臨重大資安風險。
回顧近年紀錄,Nissan 的全球資安防線多次出現破口,從客戶個資、員工資料到原始碼,都曾受到不同程度的入侵與外洩影響:

2025 年 12 月:21,000 名客戶資料遭入侵

攻擊者透過 Nissan 使用的客戶管理系統 Red Hat 取得存取權限,成功入侵並竊取約 21,000 名客戶的個人資訊。事件引發官方調查並迫使 Nissan 進行系統補強與通報。


2024 年:Akira 勒索攻擊波及澳洲與紐西蘭,至少 10 萬人受影響

Akira 勒索集團成功入侵 Nissan 澳洲與紐西蘭的本地伺服器。
外洩內容包括客戶資料、員工資訊、內部文件,受影響規模超過 100,000 名個案,迫使 Nissan ANZ 停止部分線上服務並通知主管機關。


2024 年:北美子公司資料外洩,涉及 53,000 名員工

Nissan北美通報遭遇資料外洩事件,超過 53,000 名現任與前任員工的敏感資料遭駭,包括社會安全號碼、薪酬紀錄與人事文件。事件同時波及部分營運相關資料與內部流程文件。


2021 年:原始碼因錯誤設定外流

Nissan 的 Git 伺服器被發現使用「admin/admin」的預設帳密,導致多個專案原始碼遭公開外流。該事件凸顯基礎架構與身分存取管理(IAM)控管的嚴重疏漏。

綜合來看,Nissan 的資安防線在存取管理、基礎建設配置與全球性資料治理上明顯承受長期壓力。

Everest 的攻擊清單,足以讓任何企業感到壓力

Everest 在 2025 年是全球最活躍的勒索組織之一,其聲稱攻擊對象包含:

近期高調攻擊案例包括:

  • ASUS — 聲稱竊取 1TB 相機原始碼與企業機密
  • SIAD Group(義大利氣體大廠) — 影響生產但未中斷營運
  • Petrobras(巴西油氣巨頭) — 攻擊者宣稱取得地震與探勘數據
  • Air Miles España(西班牙最大忠誠計畫) — 攻擊者宣稱外洩 131GB 含上百萬筆顧客資料
  • Iberia Airlines(伊比利亞航空) — 聲稱可「長期、無限制訪問」訂位系統並可篡改預訂

這些受害者涵蓋科技、製造、航空、能源、電信、交通等關鍵產業。
Everest 的行動特性通常包括:

  1. 長期潛伏
  2. 系統橫向移動
  3. 大規模資料整併與打包
  4. 多重勒索(加密 + 外洩威脅)
  5. 外洩倒數壓力,迫使企業談判

這意味著一旦遭入侵,往往不是「單點事件」,而是完整的攻擊鏈已被完整走過。

合規風險更值得企業高層關注

若 Everest 的宣稱屬實,Nissan 可能面臨多國同步監管壓力:

  • GDPR(歐盟):延遲通報或跨境傳輸不當可能面臨巨額罰款
  • 日本 APPI:需依法通報主管機關與受影響者
  • 美國多州資料法:涉及經銷商與金融資料時,將加重法律責任
  • 供應鏈管理壓力:合作夥伴將要求提供資安稽核與風險緩解措施
  • 投資人關係(IR)與公司治理:是否構成重大訊息需對外揭露?

全球化企業的問題在此完全浮現:

資料可能在多國流動,使外洩同時在所有地方引發法律風險。

結語:這不是一則勒索新聞,而是一堂企業治理的示範課

目前 Nissan 尚未正式回應 Everest 的聲稱。
但無論事件後續發展為何,有三點已經非常明確:

  1. 攻擊者的能耐正在提升
  2. 跨國企業的防線正面臨更高壓力
  3. 資料治理不再只是 IT 的工作,它已成為董事會必須親自把關的風險管理議題ˇ

Everest 展現出的攻擊模式與規模,再次提醒大型企業:

資料外洩並不會隨事件結束而結束,它只是換了一種形式持續存在。

【資安警示】比 VMware 公開還早!中國駭客秘密操作 ESXi 漏洞超一年

近期 Huntress 資安團隊揭露一件驚人的攻擊事件:中國駭客利用被入侵的 SonicWall VPN,成功在企業內部署針對 VMware ESXi 的零日攻擊工具,而這套工具可能在漏洞公開前一年就已存在。換句話說,駭客比 VMware 官方還早一步掌握漏洞,並且秘密利用,凸顯虛擬化環境已成駭客新戰場。

攻擊流程速覽

Huntress 2025 年 12 月的分析指出,駭客行動具備高度組織性:

  1. 入侵 SonicWall VPN → 取得初始存取權
  2. 橫向移動 → 使用 Domain Admin 資格滲透企業網域
  3. 部署 ESXi VM Escape 工具鏈 → 逃出虛擬機,進入 Hypervisor
  4. 安裝隱蔽後門 → 持久控制 ESXi 主機
  5. 資料蒐集與潛在外洩 → 雖然事件最終被阻止,但顯示駭客能力驚人

這是一個典型的多階段、高度自動化攻擊鏈,從 Guest VM 直接跳到 ESXi Hypervisor 層級,幾乎達到「完全控制」的等級。

目標漏洞:三個 ESXi 零日漏洞

攻擊者很可能利用 VMware 在 2025 年 3 月才公開的三個零日漏洞:

  • CVE-2025-22226 (CVSS 7.1):HGFS Out-of-Bounds Read → 洩漏 VMX 記憶體
  • CVE-2025-22224 (CVSS 9.3):VMCI TOCTOU → 任意程式碼執行
  • CVE-2025-22225 (CVSS 8.2):任意寫入 → VMX Sandbox Escape 到 Kernel

三個漏洞串在一起,就形成完整的「虛擬機逃逸」能力,攻擊者可直接突破隔離,掌握底層 Hypervisor。

Photo Credit: Huntress虛擬機器逃逸利用流程

工具鏈證據:開發早於公開一年以上

Huntress 在惡意程式的 PDB 開發路徑中發現:

C:\Users\test\Desktop\2024_02_19\全版本逃逸–交付\report\ESXI_8.0u3\

  • 開發日期:2024 年 2
  • 目標版本:ESXi 8.0 Update 3
  • 代表這是打包交付版,早於 VMware 官方漏洞公告超過一年

另一段路徑:

C:\Users\test\Desktop\2023_11_02\vmci_vm_escape\getshell\

顯示部分工具組件甚至在 2023 年底就已存在。

工具鏈組成說明

整體攻擊工具鏈模組化設計,包含:

  1. MAESTRO(協調程式):控制攻擊流程、載入驅動、監控逃逸結果、恢復環境
  2. MyDriver.sys(核心漏洞利用程式):檢測 ESXi 版本、洩漏 VMX 記憶體、跳脫 Sandbox、部署後門
  3. VSOCKpuppet(Hypervisor 後門):透過 VSOCK 通訊管道隱蔽控制 ESXi,不走網路監控
  4. GetShell 客戶端:從 Guest VM 操控 VSOCKpuppet,達到互動式控制

模組化意味著駭客可以快速替換漏洞利用部分,但保留後滲透架構,靈活且易商品化

威脅來源推測

Huntress 觀察到:

  • 程式路徑使用簡體中文
  • README 用英文
  • 技術成熟度高,且工具可跨語系使用

推測:

中文系、資源充足、技術成熟的駭客團隊

很可能具備長期維護 exploit chain 的能力
甚至可能販售或出租這套工具鏈

企業防護建議

  1. 立即更新 SonicWall VPN 與 ESXi
  2. 啟用 ESXi 驗證模式 → 阻擋未簽署驅動
  3. 監控 VSOCK 異常流量 → 後門核心通道
  4. 部署 YARA 與 Sigma 規則 → 及早偵測攻擊活動
  5. 檢查 VMCI / HGFS 異常行為 → 可及早發現沙箱逃逸企圖

結語

這次事件提醒我們:

  1. ESXi 與虛擬化平台已是駭客新目標
  2. 威脅行為者可能在漏洞公開前就已掌握 exploit
  3. VM Escape 攻擊可直接控制 Hypervisor,風險極高

對企業來說,防護不只是漏洞修補,更要監控異常行為與潛在後門,否則可能在不知情的情況下遭到完全控制。

D-Link 老舊 DSL 路由器爆出零日漏洞:已遭鎖定攻擊、無修補可用

Photo Credit: BleepingComputer

據資安媒體BleepingComputer報道資安社群近日揭露一項正在被實際利用的新漏洞,目標直指 多款 D-Link 已退役(EoL)的 DSL 家用閘道器。由於這些設備早在數年前停止維護,無法取得安全更新,對使用者構成極高風險。

這項漏洞已被編列為 CVE-2026-0625,核心問題源於 dnscfg.cgi 端點在處理輸入時缺乏嚴謹的檢查,導致攻擊者能透過 DNS 設定參數,注入惡意指令並遠端執行系統命令(RCE。更糟糕的是,攻擊不需認證,任何人皆可直接觸發。

漏洞來源與攻擊跡象

漏洞最初由 The Shadowserver Foundation 於蜜網環境中偵測到攻擊行為,並由漏洞情報單位 VulnCheck 進一步確認後於 12 月 15 日通報 D-Link。

VulnCheck 指出,Shadowserver 捕捉到的攻擊技巧過去未曾公開,而 D-LinkVulnCheck 也確認攻擊成功後會導致完整的系統指令控制權限外泄

VulnCheck 報告強調:「未經認證者即可注入並執行任意 Shell 指令,最終導致遠端代碼執行。」

受影響機種(皆已 EoL,無法再獲更新)

D-Link 已確認下列型號與版本受到 CVE-2026-0625 的影響:

型號受影響版本
DSL-526B≤ 2.01
DSL-2640B≤ 1.07
DSL-2740R< 1.17
DSL-2780B≤ 1.01.14

上述產品皆在 2020 年前後停止維護(EoL,不再提供安全更新。
換句話說,官方不會修補這個漏洞

D-Link 目前仍在釐清更舊或區域型號是否也受影響,但坦言產品世代與固件版本繁多,使得識別困難度上升。

攻擊條件與風險評估

多數家用 DSL 路由器的 CGI 管理介面(如 dnscfg.cgi)預設僅能在區域網路(LAN)存取,因此攻擊者有兩種可能方式:

瀏覽器為入口的攻擊鏈(browser-based attack

利用惡意網站或 XSS 結合:

  • 使用者瀏覽惡意頁面
  • 攻擊者透過瀏覽器向路由器管理端點發送惡意請求
  • 遠端取得裝置控制權

裝置開啟遠端管理(WAN administration

若使用者啟用 WAN 端管理介面,設備將可被外部直接掃描、攻擊,風險更高。

資安專家建議:立即汰換、停止暴露於網際網路

對已經 EoL 的網通設備,資安風險並不只是「缺乏新功能」,而是:

無安全補丁

無維護、無監控

已知漏洞將持續被攻擊者利用

因此建議:

(1)立即更換為仍受支援的設備

使用可持續更新固件的產品,包含安全修補與漏洞防護。

(2)若暫時無法汰換,至少進行以下設定

  • 關閉遠端管理(Remote Management / WAN Access)
  • 將設備部署在非關鍵網路(如隔離區段)
  • 使用最新可得的舊版固件
  • 建置網路層 ACL、阻擋外部管理連線
  • 啟用網段隔離(LAN segmentation)

結語:老舊設備是攻擊者最容易得手的入口

本次事件再次提醒所有企業與家庭用戶:
網路設備的安全生命週期(Security Lifecycle)與其功能壽命不同。

即使設備仍能運作,只要進入 EoL:

  • 風險便會隨時間與漏洞累積而急劇上升
  • 成為攻擊者最容易利用的入侵點之一

在威脅環境快速演變的 2025–2026 年,持續使用停更設備已不再只是「不建議」,而是明確的 高風險行為

Everest 勒索事件解析:第三方風險、資料治理與合規責任的交會點

Photo Credit: Hackread

不是 24 小時,而是企業治理的倒數計時。

Everest 外洩華碩資料,揭露勒索攻擊的真正戰場當倒數計時歸零,流出的不只是資料,而是企業治理的壓力測試結果。

2025 年 12 月 2 日,勒索軟體組織 Everest 聲稱成功入侵華碩(ASUS),並竊取高達 1TB 的內部機密資料,12 月底Everest 將一整批、總量高達 1TB 的華碩內部資料公開於暗網。這並非突發事件,而是一場「早已寫好結局」的勒索流程——
24 小時期限未獲回應後,Everest 先公開佐證截圖,並最終外洩全部資料

這個節奏,Everest 已經演練過無數次。


表面是勒索,實際是治理缺口被放大

外洩資料據稱涵蓋 AI 模型資訊、系統記憶體傾印、硬體校正檔案,華碩隨後也證實事件確實發生,並指出入侵源頭為其供應商。

這個關鍵說法,對資安人與法遵人員而言,比「被勒索」本身更值得警惕。

因為這代表問題並不在單一弱點,而在於:

  • 第三方是否被納入同等資安與合規標準
  • 關鍵資料是否被正確分級與隔離
  • 供應鏈環境是否成為攻擊者的「合法後門」

當資料經由供應商外洩,責任卻仍由品牌承擔,這正是現代企業最難防、也最常被低估的風險。


暗網不是終點,而是第二戰場的起點

根據 Hackread的報導,資料公開後,外洩檔案迅速在多個俄語系地下論壇流通,包括 ExploitDamageLib

Photo Credit: Hackread

駭客聲稱資料集中包含 9 個主要檔案組,部分疑似來自 ArcSoft 與 Qualcomm 相關內容。

HackRead稱循負責任揭露原則,選擇不下載、不分析資料,然而風險仍已不可逆轉——
一旦進入地下生態系,資料的再利用、轉賣與二次攻擊,將不再受企業掌控。


這不是第一家,也不會是最後一家

回顧 Everest 近月行動軌跡,可以發現一個清楚的趨勢:

  • 聖誕節期間,宣稱入侵美國汽車大廠 Chrysler,竊取 1TB 完整內部資料庫,外加 105GB Salesforce 資料
  • 2025 年 11 Under Armour 遭竊 343GB 資料並遭全數外洩,隨即引爆法律與合規風暴

這些事件顯示,Everest 鎖定的從來不是「能不能收贖金」,
而是 誰的治理與通報能力承受不起公開壓力


真正被拷問的,不是 IT,而是董事會

在這類事件中,最關鍵的問題往往不是:
「我們有沒有被駭?」

而是:

  • 我們是否知道哪些資料外洩、影響多大、觸及哪些法規?
  • 第三方是否被納入可稽核、可問責的治理框架?
  • 事件回應、對外揭露與主管機關通報,是否經得起事後檢視?

當勒索攻擊演變為 法遵、訴訟、品牌與營運連鎖風險
事件所揭示的風險,早已超出資訊安全範疇,成為董事會必須關注的治理與合規挑戰。


資安專家觀點:勒索軟體,正在淘汰治理不成熟的企業

Everest 不斷重複同一套劇本,原因只有一個——
它依然有效。

在 AI、供應鏈高度外包、資料高速流動的時代,
企業若仍將資安視為「技術防線」,而非「合規與治理能力」,
下一次暗網倒數的,可能不只是資料,而是企業的信任資本。

真正的防線,不在於能不能擋住一次攻擊,
而在於——
當攻擊發生時,你是否具備承擔、說明與合規面對的能力。

漏洞愈來愈多,風險卻更難控:2025 年 CVE 現象背後的合規真相

Photo Credit:VulneCheck

2025 年,全球 漏洞揭露(Common Vulnerabilities and Exposures, CVE數量再度刷新歷史紀錄,正式宣告資安產業進入「漏洞爆量常態化」的新階段。從資安治理與法遵(GRC)角度觀察,2025 年並非只是 CVE 數量再創新高的一年,而是企業漏洞管理模式正式失效的一年。根據 Cisco Threat Detection & Response 首席工程師 Jerry Gamblin 的統計,截至目前為止,2025 年已通報 45,777 筆 CVE,平均每日新增 130.4 個漏洞,年成長率達 19%。依其推估,2025 年底 CVE 總數將達 46,407 ,較 2024 年成長 16.2%,再度刷新歷史紀錄。

然而,對資安長與風險、合規單位來說,真正需要警覺的並非「漏洞數量」本身,而是漏洞治理模型是否仍具可行性


高危漏洞比例下降,並不代表整體風險降低

—— CVSS v4.0 對合規判讀的結構性影響

VulnCheck 漏洞研究員 Patrick Garrity 指出,儘管 2025 年 CVE 數量暴增,但 Critical 與 High Severity 漏洞的通報比例,反而較 2024 年下降

若從合規角度解讀,這是一個 極易被誤判的訊號

此現象高度可能與 CVSS v4.0 評分模型導入有關。新版 CVSS 在:

  • 環境影響權重
  • 攻擊前置條件
  • 利用成熟度判定

等層面進行調整,使部分「實際可被快速武器化」的漏洞,未必再被標示為 Critical。

對合規與內控而言,這意味著:
僅依賴 CVSS 分數作為修補優先順序,已不再符合合理風險管理原則。


從治理角度重新定義漏洞風險

「被利用事實」>「理論嚴重度」

2025 年的多起重大事件已清楚證明:

漏洞是否被列為 Critical,已不等於是否構成重大營運、法遵與供應鏈風險。

多個影響全球的關鍵事件,均具備以下共同特徵:

  • 漏洞迅速被納入攻擊工具鏈
  • 遭國家級 APT 或大型勒索集團武器化
  • 影響範圍橫跨供應鏈、雲端與 CI/CD
  • 引發實質資料外洩、營運中斷或監管風險

這正是 現代合規制度(如 ISO 27001、NIST CSF、金融資安指引)所強調的「實際風險導向(Risk-based Approach)」


2025 年五大漏洞利用事件

從合規與治理視角的關鍵警示

以下事件不僅是技術漏洞,更是資安治理與內控失效的具體案例

一、React2Shell:React.js 關鍵 RCE 漏洞,遭多國國家級駭客武器化

2025 年 11 月 29 日,資安研究員 Lachlan Davidson 向 Meta 負責揭露一項影響 React.js關鍵遠端程式碼執行(RCE)漏洞,正式編號為 CVE-2025-55182,並被命名為 React2Shell,名稱明顯致敬 2021 年震撼全球的 Log4Shell。

該漏洞存在於 React Server Components 19.x 多個版本,屬於 未經驗證即可觸發的 RCE 漏洞。一旦成功利用,攻擊者可直接在伺服器上執行任意程式碼,全面掌控系統,進而存取敏感資料。

由於 React 與 Next.js 幾乎是現代 Web 應用的核心基礎建設,該漏洞一經揭露即引發高度警戒。

短短數日內:

  • AWS 證實 Earth Lamia、Jackpot Panda(與中國國家利益相關)已發動實際攻擊
  • Shadowserver 掃描發現 超過 77,000 個暴露在網際網路上的潛在受害系統
  • 多個犯罪集團開始植入 XMRig 礦工、竊取 AWS 環境變數與金鑰

更值得注意的是,Sysdig 研究團隊在遭入侵的 Next.js 應用中發現 EtherRAT 惡意植入程式,其工具與 北韓 APT「Contagious Interview」行動高度重疊,顯示國家級駭客之間可能已出現 工具共享或戰術借用的現象。

CISA 已於 12 月 17 日將相關 CVE 納入 KEV(Known Exploited Vulnerabilities)清單


二、Shai Hulud 2.0:NPM 生態系被全面下毒的供應鏈蠕蟲攻擊

11 月下旬,資安圈震撼揭露 Shai Hulud 2.0 行動——這不是單一漏洞,而是 一場針對開源供應鏈的系統性滲透行動

攻擊者透過 竊取 npm 套件維護者帳號,在短時間內發布 數百個被植入惡意程式碼的合法套件版本,並濫用 preinstall 腳本,在依賴安裝瞬間即執行惡意行為,成功繞過多數 SCA 與測試機制。

其影響範圍驚人:

  • 約 700 個 npm 套件
  • 超過 25,000 個 GitHub Repo
  • 橫跨 500 多個組織

更危險的是第二階段攻擊:
駭客利用竊得的 GitHub Token,劫持 GitHub Actions 與自架 Runner,建立長期後門,甚至能 一次性外洩整個 Secrets 儲存庫

這起事件被多家研究機構評為 2025 年規模最大、最具破壞力的供應鏈攻擊之一


三、Oracle E-Business Suite 零時差漏洞:Clop 勒索集團再度出手

2025 年 10 月,Oracle 緊急警告客戶,其 E-Business Suite(EBS 可能已遭零時差漏洞攻擊。

該漏洞 CVE-2025-61882(CVSS 9.8 可直接導致 RCE,並被 Clop 勒索集團 實際用於資料竊取與勒索。

受害名單橫跨:

  • 英國 NHS 醫療體系
  • Canon、Mazda、羅技
  • 多家跨國製造與科技企業

這再度證實:大型企業 ERP 系統,依然是勒索集團的高價值目標


四、ToolShell:SharePoint 本地部署成 APT 兵家必爭之地

2025 年 7 月,Microsoft 警告 SharePoint On-Premises 遭到鏈式漏洞攻擊(CVE-2025-53770 / 53771),被命名為 ToolShell

短時間內, 400 台 SharePoint 系統遭入侵,且多數屬於政府、醫療等關鍵產業。

已確認涉入的攻擊者包含:

  • Linen Typhoon(APT27)
  • Violet Typhoon(APT31)
  • Storm-2603(具勒索背景的中國相關團隊)

這起事件也讓企業重新正視:內部部署系統並不等於安全


五、CitrixBleed 2:熟悉的漏洞型態,再次重演

2025 年 6 月,Citrix NetScaler 再度爆出 類似 2023 CitrixBleed 的高危漏洞(CVE-2025-5777,可繞過 MFA、劫持使用者工作階段。

與前代不同的是,CitrixBleed 2 直接鎖定 Session Token,風險更高、偵測更困難。

CISA 已將其列入 KEV,並要求政府單位 隔日完成修補,顯示其威脅等級。


合規總結建議

2025 年對企業的核心啟示只有一個:

合規不是「是否修補漏洞」,而是「是否有能力即時回應被利用的風險」。

建議治理方向包含:

  • KEV、實際攻擊跡象(In-the-wild)納入正式風險評分
  • 對開源與 CI/CD 建立 持續監控責任制
  • 漏洞管理需與 營運衝擊分析(BIA 連動
  • 修補延遲必須具備 風險接受與管理層簽核紀錄

Fortinet警告: FortiOS SSL VPN 驗證繞過漏洞(CVE-2020-12812)再度遭實際攻擊利用

五年前的老漏洞,今天仍在被武器化:

Fortinet 近期證實,一個早在 2020 年即已揭露並修補的 FortiOS SSL VPN 漏洞,至今仍在特定環境設定下遭到駭客實際濫用(in-the-wild exploitation
這起漏洞編號為 CVE-2020-12812(CVSS 5.2,本質並非傳統的程式錯誤,而是驗證邏輯與身分系統設計不一致所導致的安全繞過問題

漏洞本質:大小寫差異,竟能繞過雙因素驗證(2FA

CVE-2020-12812 屬於 不當驗證(Improper Authentication)漏洞,影響 FortiOS 的 SSL VPN 驗證流程
在特定條件下,攻擊者只要變更使用者名稱的大小寫(例如 jsmith 改成 JSmith),就可能完全跳過第二道驗證FortiToken / 2FA,成功登入系統。

Photo Credit: Fortinet

問題核心在於:

  • FortiGate 預設將使用者名稱視為「大小寫敏感」
  • LDAP 目錄服務則是「大小寫不敏感」
  • 當兩者混用時,驗證邏輯出現落差

什麼情況下會中招?(關鍵設定條件)

根據 Fortinet 最新(2025/12/24)公告,必須同時滿足以下設定條件,漏洞才會被觸發

  1. FortiGate 上存在啟用 2FA 的本機使用者(Local User
  2. 該本機使用者是透過 LDAP 進行遠端驗證
  3. 同一帳號同時也是 LDAP 群組成員
  4. 該 LDAP 群組被設定於 FortiGate,並用於:
    • 管理者登入
    • SSL VPN
    • IPsec VPN 等驗證政策

攻擊流程如何發生?

當使用者以「非完全一致大小寫」的帳號登入時:

  1. FortiGate 無法比對到本機的 2FA 使用者
  2. 系統轉而嘗試其他驗證政策
  3. 發現符合條件的 LDAP 群組
  4. 只要 LDAP 帳密正確,即可直接通過驗證
  5. 2FA、帳號停用等本機安全設定完全被繞過

結果是:

管理者或 VPN 帳號在未經 2FA 的情況下成功登入

為何這麼危險?

這類漏洞特別容易被忽略,因為:

  • 不需要漏洞利用程式(Exploit)
  • 不會留下明顯錯誤紀錄
  • 登入行為「看起來完全正常」

一旦被濫用,企業可能必須:

  • 全面重置管理者與 VPN 帳密
  • 重新檢視 AD / LDAP 架構
  • 進行入侵調查(IR)

多個 APT 與勒索組織早已實戰利用

事實上,CVE-2020-12812 並非理論漏洞,早已被多個威脅行為者武器化:

  • 2021 :FBI 與 CISA 聯合警告 APT 利用該漏洞攻擊 FortiOS
  • 伊朗相關 APT(含 APT35 / Charming Kitten)
    利用 CVE-2018-13379、CVE-2019-5591、CVE-2020-12812 進行橫向入侵
  • COBALT MIRAGE APT(2022)
    被 Secureworks 證實實際利用此漏洞
  • Hive 勒索軟體組織
    亦曾在攻擊行動中使用該漏洞

該漏洞也被列入美國政府「周邊設備(Perimeter Device)被大量武器化的關鍵弱點清單」。

修補與緩解建議(務必檢查)

已修補版本(2020 年即已釋出)

  • FortiOS 6.0.10
  • FortiOS 6.2.4
  • FortiOS 6.4.1

強制建議設定(關鍵)

舊版本(未升級者)

set username-case-sensitivity disable

較新版本(6.0.13 / 6.2.10 / 6.4.7 / 7.0.1 以上)

set username-sensitivity disable

關閉後,FortiGate 將把jsmith / JSmith / JSMITH 視為同一帳號,避免驗證流程錯位

進階防護建議(資安實務)

  • 若非必要,移除次要 LDAP 群組驗證
  • 定期檢視「本機帳號 + LDAP」混合設計
  • 若曾發現未經 2FA 的管理或 VPN 登入紀錄
    • 立即重置所有相關帳密
    • 聯繫 Fortinet Support 進行調查

資安觀點總結

這不是「舊漏洞沒修」的問題,而是「驗證設計被誤用」的風險。
在零信任與多因素驗證已成基本要求的今天,
任何一個「看似只是設定問題」的裂縫,都可能成為實際入侵的入口。