N-able 證實 N-central 攻擊者已觸及受管理端點

2026年7月31日，N-able 的 Adlumin 託管偵測與回應服務在客戶環境中發現異常活動，並發現有威脅行為者利用 N-central 中一個廠商尚未公開的漏洞。N-central 是託管服務供應商賴以管理客戶系統的遠端監控與管理平台，因此入侵者所掌握的不是單一機器，而是掌控眾多機器的控制台。該漏洞後來被編為 CVE-2026-18577，可讓攻擊者在未經身分驗證的情況下取得遠端系統管理存取權；攻擊者隨後利用 N-central 自身的 Take Control 功能，向受管理的端點開啟工作階段，並在這些裝置上註冊 Cloudflare 通道服務，以便即使失去 N-central 帳號，存取仍能維持。N-able 表示「已確認有數量有限的客戶受到影響」，但未說明具體數量，也未說明攻擊者深入到什麼程度。本文根據the Orca AI Incident Archive中的單一記錄撰寫，該記錄將其與其追蹤的其他已記錄 RMM 及 MSP 供應鏈事件並列歸檔。

在描述此事的各家來源之間，這則記述鮮有爭議。N-able 自家的安全性更新、兩個 CVE 識別碼的 NVD 紀錄、於偵測後數日內發布的 Huntress 調查，以及 The Register 於 8 月 7 日、The Hacker News 於 8 月 8 日的報導，都描述了相同的序列：未經身分驗證進入 N-central、以 Take Control 作為跳板、在端點上註冊 Cloudflare 通道以維持持久性。該存檔將事件日期定為 2026 年 7 月 31 日，精確度為日，意即那是單一日期——Adlumin 提出偵測的那一天——而非一個時間範圍。有一個來源細節值得說明：N-able 的整合貼文日期為 2026 年 8 月 10 日，而該存檔引用的 URL（結尾為「august-2-2026」）現在會導向該後續更新，因此最初發布的 8 月 2 日文本已無法從該連結取回。

缺陷在於第二次繞過，而非第一次。

N-central 在那年夏天已經被繞過一次。CVE-2026-18556 被歸類為「使用替代路徑或通道的驗證繞過」，影響 N-central 至 2026.1 版，並在 2026.2 版中修復。CVE-2026-18577 的 NVD 記錄以一句話描述它為「CVE-2026-18556 的不完整修補」，且「允許在 N-central 至 2026.3.1 版中進行驗證繞過與帳號接管」。換句話說，已經套用 2026.2 修復的組織仍然暴露於風險中，這就是為什麼在第一個漏洞出現後一週內，又接連出現第二個漏洞與第二個熱修復。

兩筆記錄都具有相同的弱點類別，CWE-288。各評分者之間的分數並不一致，而這是評分本身的特性，並非矛盾：NVD 對 CVE-2026-18577 記錄的 CVSS 4.0 基本分數為 8.2，而 NIST 的 CVSS 3.1 評估則將其評為 8.1。就 CVE-2026-18556 而言，兩者分別為 8.2 與 7.4。2026-18577 的 4.0 向量為 AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N，子分數為 SC:L/SI:L/SA:L——機密性高，完整性與可用性皆為無。那是對繞過本身的一種描述，而非描述攻擊者跨越它之後會做什麼；而且它無法妥善指引受入侵的管理主控台可能造成多大損害。

CVE-2026-18577 的修復版本被列為所有早於 2026.3.1.7 的組建，此表述見於 Beazley Security 對該漏洞的公告；N-able 自己的貼文僅列出 hotfix 組建，並未公布受影響版本矩陣。

入侵者利用管理主控台做了什麼

Take Control 是 N-central 自家的遠端支援工具，推出目的是讓 MSP 技術人員能在終端使用者的桌面上開啟工作階段，而不必要求該使用者安裝任何東西。攻擊者使用它的方式就跟技術人員一樣。正如 The Register 報導，Huntress 將此存取權限描述為「通常保留給受信任網路營運與工程人員的同等 N-central 存取層級」——足以開啟遠端工作階段並將指令碼推送至客戶系統，而且，正如 CISO Intelligence 8 月 3 日摘要對這項能力的描述，還能開啟連往網域控制站的工作階段。沒有任何來源指出攻擊者實際使用了其中哪些能力。

持久化步驟是事件過後仍存活下來的部分。攻擊者若在端點上把 Cloudflare 通道註冊為 Windows 服務，就能取得一個僅對外的通道，既不需要輸入防火牆規則，重新開機後也會再次啟動，而且即使當初用來植入它的 N-central 帳號已被撤銷，仍會持續運作。N-able 的更新列出要尋找的服務名稱 Cloudflared，以及放在使用者 Documents 資料夾中的 svchost.exe 副本，還有產品自身日誌中異常的 Take Control 工作階段。Beazley Security 的公告則把內建帳號 mspsupport@n-able.com 列為要追查的跡象。N-able 也警告，攻擊者正在建立新帳號並重設現有帳號以維持存取，並直白說明後果：套用修補程式「不會移除可能已存在於您環境中的威脅行為者」。

影響所及：九個組織，以及一個不願納入計算的供應商

關於入侵深入程度，目前任何人唯一公開的數字來自 Huntress，而非 N-able。在單一遭入侵的合作夥伴環境中，Huntress 發現攻擊者觸及九個下游組織，各觸及其中一個端點，且大致僅限於處理程序列舉，隨後便斷開連線。這只是單一案例中觀測到的下限，並非總數：N-able 拒絕說明有多少客戶受影響、有多少下游系統遭觸及，或攻擊者一旦建立持續潛伏後做了什麼。The Register 明確報導了這項拒絕。CISO Intelligence 的 8 月 3 日摘要指出，截至該日，Huntress 合作夥伴可連線的雲端 N-central 伺服器中，仍有超過 55% 未修補。

AI 連線實際上究竟是什麼

檔案記錄顯示，AI 參與此次事件已獲確認，而該追查之處在於偵測，而非攻擊。N-able 將 Adlumin 宣傳為「AI 驅動、人工主導的 SecOps」，其「自適應 AI」能「持續學習你的環境」並標示行為異常；該公司於 3 月舉行的 RSAC 2026 上宣布 Adlumin MDR 內建三項 AI 驅動偵測——異常 PowerShell 偵測、ML 驅動的 DNS 中斷警示，以及會依據程序名稱、路徑與父系鏈對程序評分的單一事件程序執行模型。Adlumin 的 MDR 服務正是偵測到 7 月 31 日該起入侵的機制。

已確立的事實僅止於此。本文所查閱的任何來源，都未說明啟動這次應變的具體警示是由 AI 模型還是由人類分析師提出，而 N-able 也未將該偵測歸因於任何具名引擎。同樣清楚的是，另一側並沒有出現任何 AI 系統：無論是 N-able 的說法、如報導所述的 Huntress 調查結果，或是 The Register 與 The Hacker News 的報導，都未在入侵鏈的任何環節描述到模型、代理程式或 AI 工具。平實解讀，這筆紀錄會被歸入 AI 事件檔案，是因為 AI 輔助的安全平台是偵測工具，而非因為 AI 造成或執行了這起入侵。這項區別正是該檔案標籤在此能告訴讀者最有用的一件事。

有哪些改變，以及 N-able 仍不願說的事

N-able 於 8 月 2 日發布 Hotfix 1（組建 2026.3.1.7），並在其自家代管環境中集中完成了緩解；地端（on-premises）客戶則須自行安裝。8 月 6 日，持續監控發現了一條相關的攻擊路徑，該公司隨即發布 Hotfix 2（組建 2026.3.1.10），並表示其「附加了更多強化措施」、取代第一版，且即使是已套用 Hotfix 1 的客戶也必須安裝。CISA 於 8 月 3 日將 CVE-2026-18577 加入其「已知遭利用漏洞」目錄，聯邦機構修補期限為 8 月 6 日；並於 8 月 4 日將 CVE-2026-18556 加入，期限為 8 月 7 日——兩者皆為三天窗口，《The Register》稱這是專為急迫風險保留的不尋常短期限。隨修補程式發布的指引屬於作業面而非技術面：強制啟用 MFA、除非有工單需要否則停用產品內建的支援帳號、稽核帳號與權限的建立與重設情形，並執行廠商自家的指標掃描服務範本——同時要把掃描結果乾淨視為完全不能證明任何事。「掃描結果乾淨不應被解讀為保證你的環境未受影響，」N-able 寫道。

N-able 尚未公布的是根本原因。它表示，在行為者仍活躍期間，它刻意保留技術細節——「完整的根本原因分析即將出爐，一旦可以安全公布，我們就會分享」——並表示在確信之前「不會稱此事已結案」。這使得第二個繞過手法只能以其效果來描述，即它是繞過同一個身分驗證檢查的另一條路徑，而 2026.2 修復原本旨在封堵該檢查。

還有什麼仍然開放？

歸因不明，而廠商自身的指標也無法提供歸因。CISO Intelligence 報導，N-able 公布的數個 IP 位址中，有幾個是 Mullvad 與 NordVPN 的出口節點，之後又有兩個位址被加入清單——正如同一份摘要所指出的，這些是調查線索，而非歸因。N-able 在此處的信心程度並非該檔案庫的信心程度：該紀錄帶有信心等級 A，是因為主要來源彼此一致，而這是在說明文件記錄的狀況，並非表示有人已獨立地從頭到尾驗證了這起入侵事件。

紀錄所能支持的，其實比一則外洩頭條更狹窄，也更持久。MSP 用來管理整個客戶環境的平台中，第二個身分驗證繞過漏洞遭到實際利用，而且在 7 月 31 日首次偵測到、8 月 6 日第二次熱修補之間的那至少六天裡持續敞開。攻擊者在端點中建立了一條即使修補 N-central 也無法封閉的返回通道——這正是為什麼廠商自己對太晚修補者的建議是：把環境視為已遭入侵，並開始稽核帳號，而不是相信一次乾淨的掃描。