CVE-2026-59310：VMware vCenter 攻擊擴至47個國家、361個IP

CVE-2026-59310 已經不只是「要盡快打補丁」的漏洞。Broadcom 於2026年7月29日披露並修正 VMware vCenter Syslog Server 的這個嚴重漏洞，但研究人員在8月3日已觀察到實際攻擊，前後只相隔5日。相關活動涉及47個國家、361個觀察到的IP，攻擊者更利用反向 SSH 維持存取；Shadowserver 因而指，出現這種持久化機制的系統應視為全面失陷。

CVE-2026-59310 可以做到甚麼？

Broadcom 及美國國家漏洞資料庫（NVD）將 CVE-2026-59310 描述為 vCenter Syslog Server 的目錄穿越漏洞。只要攻擊者能夠連接到 vCenter，便毋須登入或驗證，即可利用漏洞在受影響系統上執行任意程式碼。漏洞 CVSS 評分為9.8，屬於「嚴重」級別。

簡單講，暴露在網絡上的 vCenter 設備可能被變成進入虛擬化基礎設施的跳板，讓攻擊者建立持久化存取，甚至進一步接觸其他系統。部分入侵報告形容攻擊者可在設備的 root 權限環境執行程式碼；不過，供應商及漏洞資料庫最權威的描述，主要確認的是「任意程式碼執行」風險，未有完整交代每宗入侵所取得的實際權限。

Broadcom 已提供修正版本，但沒有替代方案。對受影響系統而言，按照供應商列出的版本更新，是官方唯一的修復方法。

修補程式推出後5日便遭利用

Broadcom 在7月29日公布 CVE-2026-59310 並推出修補程式。QUIRSO 則報告，攻擊跡象由8月3日開始出現，之後迅速擴大。

這個時間差對事故應變非常關鍵。即使管理員在8月3日之後成功完成更新，也不能因此認定系統沒有被入侵。修補漏洞和確認是否已經失陷，是兩件不同的事：先修補，再調查攻擊者是否早已留下存取方式。

攻擊規模有多大？

研究人員將活動與361個觀察到的受害IP及47個國家連繫起來。據報德國、美國、土耳其、伊朗及法國合計佔觀察數字超過一半。

不過，「361個IP」不等於361間不同公司或機構。一個IP可能代表共享網絡、雲端環境或同一組織的多個系統。因此，這個數字不應直接解讀為361名獨立受害者。現有報告可以支持的結論是：攻擊活動廣泛針對可從互聯網或其他網絡位置接觸到的 vCenter 系統。

為何研究人員懷疑與中國有關？

QUIRSO 以「中等信心」評估這次活動具中國關聯。研究人員提到的線索包括中文語言痕跡、相關工具及公開重用的研究資料、符合 UTC+08:00 工作時段的活動模式，以及看似排除中國內地的受害者分布。

這些線索可以支持地區或語言層面的判斷，但不能确认某個中國國家級組織的身份，也不能證明事件由政府指揮。基於惡意軟件特徵、活動時間及目標選擇作出的歸因，仍可能隨新證據出現而改變。現階段較穩妥的說法是「疑似具中國關聯的攻擊者」，而不是已確認的國家支持行動。

已知的入侵流程

根據現有報告，攻擊者似乎先利用 CVE-2026-59310 取得初始程式碼執行能力，再加入多重持久化及遠程存取手段：

1. 目錄穿越： 向 Syslog 服務發送特製請求，跳出原本指定的路徑，並寫入攻擊者控制的內容。
2. Cron 持久化： 據報攻擊者建立格式異常的 cron 項目，讓定時工作執行後續指令。
3. 投放後門： 透過 curl 或 wget 下載名為 linuxFile 的後門。報告指該後門採用 WebSocket 通訊，並以 XOR 混淆內容。
4. 反向 SSH： 安裝反向 SSH 工具，從受害系統向攻擊者控制的基礎設施建立外連通道。Shadowserver 在專題報告中表示，這種持久化機制出現在其報告涵蓋的所有受害系統。
5. 濫用帳戶及憑證： 調查人員發現未經授權的 vCenter 及 ESXi 管理員帳戶，並指攻擊者濫用 VMware Directory Service 憑證。
6. 部署勒索軟件： 至少有部分報告將活動與 Babuk 衍生的勒索軟件變種連繫起來，該變種會在檔案名稱後加入 .babyk。

反向 SSH 的發現尤其值得注意。Shadowserver 的實務結論是：如果系統被部署了這種機制，便應視為全面失陷。單純刪除一個執行檔或 cron 工作，並不足以恢復對設備及憑證的信任；管理員應考慮重建設備，並更換所有高權限憑證。

勒索軟件可能也是反取證手段

報告中的 .babyk 活動，未必是傳統以大規模加密及勒索為主要目的的勒索軟件攻擊。分析人員認為，選擇性加密 ESXi 日誌，可能是為了干擾調查及掩蓋入侵痕跡。

這仍然只是分析推論，並非已確認的攻擊者意圖。防守方仍應同時調查兩種可能性：虛擬機是否受到勒索軟件影響，以及日誌是否被刻意篡改以掩飾入侵。

GitHub 偽裝及工具重用

報告亦將這次行動與一個 GitHub 儲存庫連繫起來。該儲存庫把反向 SSH 二進制檔案包裝成 Linux 臨時檔案清理工具。將持久化工具偽裝成管理或清理程式，可能有助於降低分發及日常檢查時的可疑程度。

但現有證據未能獨立確認該儲存庫由誰操作，因此儲存庫本身不能被視為歸因證據。

對 Broadcom 及 VMware 業務有何影響？

8月14日，市場得悉 VMware vCenter 正遭積極利用漏洞攻擊後，Broadcom 股價下跌約5%至6%。其中一份報告指，股價由417.82美元跌至392.99美元。

不過，安全事件只是市場下跌的其中一個因素，不能將整個跌幅或某個精確的市值損失金額全數歸因於 CVE-2026-59310。同期報道亦提到包括人工智能相關債務風險在內的其他投資者憂慮。

現有報告也不足以證明事件已令 VMware 收入出現可量度的下跌。較有根據的短期業務影響包括客戶修復成本、營運中斷風險及聲譽壓力；至於長期收入影響，則需要公司披露或更多財務證據支持。

vCenter 管理員應如何應對？

打補丁是第一步，不是最後一步。企業應採取以下行動：

1. 立即套用 Broadcom 的修正版本： 為所有受影響的 vCenter 實例更新，優先處理面向互聯網、或可從廣泛內部網絡接觸到的設備。Broadcom 沒有提供替代方案。
2. 發現跡象便假設已失陷： 留意異常 cron 變更、反向 SSH 檔案或連線、linuxFile、不明的 curl 或 wget 下載、陌生的 vCenter 或 ESXi 管理員帳戶，以及 VMware Directory Service 的異常活動。
3. 隔離可疑設備： 在實際可行的情況下，重建前先保存磁碟映像、日誌及揮發性證據。
4. 更換所有高權限憑證： 包括 vCenter SSO、VMware Directory Service、ESXi 或 root、API、服務帳戶及相關管理員憑證；同時撤銷現有工作階段，並檢查聯邦認證路徑。
5. 確認持久化後應重建，而非只作清理： 將未經授權的帳戶、cron 工作、二進制檔案、SSH 金鑰及通道納入完整事故應變流程處理。單純刪除檔案並不足以恢復系統可信度。
6. 在整個虛擬化環境進行威脅搜尋： 檢查 .babyk 活動、異常外連 SSH 或 WebSocket 連線、可疑帳戶，以及 ESXi 日誌遭篡改的跡象。
7. 從可信備份恢復日誌及遙測資料： 如果日誌或設定已被修改，應使用已知正常且不可變更的備份恢復。
8. 減少日後暴露面： 將 vCenter 管理存取限制在分段的專用管理網絡，並監察 vCenter 及 ESXi 主機的外連，尤其是意外的 SSH 或 WebSocket 流量。

底線很清楚：所有受影響的 vCenter 都要立即更新，但「成功完成更新」不代表環境已經乾淨。快速利用、反向 SSH 持久化及疑似憑證濫用同時出現，意味著防守方應把曾暴露的設備當作可能全面失陷，展開完整調查及復原。