AI Agent 正將滲透測試、漏洞探索與橫向移動串成自動化攻擊鏈。當攻擊者開始以多個 AI Agent 同時執行任務，企業面對的已不只是更快的駭客，而是更具規模、更持續且更難以預測的攻擊模式。

人工智慧（AI）正在改變資安攻防的運作方式。過去需要資安人員逐步執行的網路探索、弱點分析、憑證蒐集、權限提升與攻擊路徑規劃，如今可以透過 AI Agent 自動完成部分工作，甚至由多個 Agent 分工合作，持續探索目標環境並調整攻擊策略。

近期受到關注的 ARTEX，正是這類 AI 驅動攻擊框架的代表。從臺灣 91APP 資安事件、韓國金融業攻擊，到美國資安研究機構揭露的 VAPOR PANDA 全球攻擊活動，以及印度 CERT-In 對金融業發布的 AI 自動化攻擊警示，都顯示 AI Agent 正逐步進入實際攻擊行動。

更值得注意的是，攻擊者不一定需要開發全新的零時差漏洞。透過 AI Agent 自動探索既有漏洞、分析系統設定、尋找暴露的憑證與錯誤的權限配置，就可能將原本分散的弱點串成完整攻擊鏈。

對企業而言，真正的風險不只是 AI 能否成功入侵，而是攻擊者能否以更低的人力成本、更快的速度，同時對更多目標展開攻擊。

一、ARTEX 是什麼？不是單一 AI，而是多 Agent 攻擊協作框架

ARTEX 並不是一個單純的聊天機器人，也不是只會產生滲透測試報告的 AI 工具，而是一套結合大型語言模型（LLM）、多 Agent 協作、攻擊工具整合與任務管理機制的自動化攻擊框架。

其核心概念，是讓 AI 不只回答問題，而是能夠根據任務目標，自行規劃步驟、呼叫工具、分析結果、產生下一步行動，並持續執行攻擊探索。

Google Cloud 威脅情報團隊 GTIG 在 2026 年 10 月 30 日發布的研究指出，ARTEX 已被不同威脅行為者用於自動化攻擊活動，其能力涵蓋網路探索、Active Directory 偵察、權限提升、雲端環境分析、Web Shell 部署及資料外洩準備等攻擊階段。

ARTEX 的核心架構：由 AI Agent 分工完成攻擊任務

ARTEX 的運作方式，可以理解為一個具備攻擊目標、任務規劃、工具執行與結果分析能力的 AI 攻擊工作平台。

其主要組成包括：

• Main Agent（主要 Agent）：負責整體任務管理、判斷目前進度及整合各 Agent 的結果，並與操作人員互動。
• Planner Agents（規劃 Agent）：將攻擊目標拆解成可執行的任務，規劃探索方向與後續步驟。
• Worker Agents（執行 Agent）：分別執行網路探索、服務辨識、弱點驗證、憑證分析及其他攻擊任務。
• Asset Graph（資產關聯圖）：整理已發現的主機、服務、帳號、憑證與其他資產關係，協助建立攻擊路徑。
• Exploration Graph（探索圖）：記錄已執行的探索、發現與待處理任務，避免重複工作並協助規劃下一步。
• 工具與整合介面：透過命令列工具、MCP、Skills 及其他整合機制，讓 Agent 能呼叫實際攻擊工具與外部服務。
• Memory（記憶機制）：保存任務過程中的重要資訊、發現與執行結果，讓後續 Agent 能延續先前工作。
• Human-in-the-loop（人工介入）：操作人員可以設定目標、提供指令、核准特定操作或調整任務方向。

這種架構的關鍵，在於 AI Agent 不再只負責單一任務，而是能將不同攻擊階段串接起來，並依據前一階段取得的資訊，持續調整後續探索策略。

例如，當 Agent 發現某台主機存在管理介面，可能進一步分析服務版本、尋找已知漏洞；如果取得帳號或憑證，則可能繼續探索其他系統的存取關係；當發現新的網路區段或資料庫，也可能將其納入後續攻擊規劃。

這代表攻擊者不必事先完全掌握目標環境，而是可以讓 AI Agent 在執行過程中逐步建立攻擊路徑。

AI Agent 不等於完全自主駭客

需要釐清的是，ARTEX 並不代表 AI 已經能完全自主完成所有入侵行動。

其執行能力仍受到模型推理品質、工具可用性、權限限制、網路環境及操作人員設定影響。AI Agent 可能產生錯誤判斷、執行失敗的操作，或需要人工介入才能繼續。

但這不會降低其威脅性。

真正的變化是：即使 AI Agent 無法完全自主完成攻擊，仍然可以大幅減少攻擊者在探索、分析、工具操作與任務規劃上的人力投入。

二、ARTEX 攻擊事件時間軸：從臺灣到全球，AI 攻擊框架逐步進入實戰

ARTEX 相關活動在 2026 年下半年陸續受到研究機構與企業資安團隊關注。以下整理目前較具代表性的事件與揭露時間。

日期	事件	主要觀察
2026/8/31 起	GreyNoise 揭露 AI 輔助攻擊活動	攻擊者利用大量 AI Agent、Codex 類工具及 DeepSeek，針對 PaperCut 已知漏洞展開自動化攻擊。
2026/10/7	韓國金融業 ARTEX 攻擊活動受到關注	CrowdStrike 揭露未知威脅行為者利用 ARTEX 對韓國金融機構進行攻擊。
2026/10/8	ARTEX 原始 GitHub 專案遭移除	原始公開專案被移除後，仍有其他分支、複製版本及相關映像持續流通。
2026/10/17 起	VAPOR PANDA 展開全球攻擊活動	CrowdStrike 追蹤到以 ARTEX 為核心的攻擊活動，涉及多國政府、半導體、電信與國防相關組織。
2026/10/19	日本 GMO 相關攻擊活動受到關注	日本企業攻擊活動中出現 ARTEX 相關操作痕跡，顯示該框架已被用於不同地區的攻擊行動。
2026/10/22	91APP 公布資安事件調查資訊	91APP 說明遭入侵原因與攻擊路徑，揭露未修補的內部應用程式及資料庫憑證暴露等問題。
2026/10/29	CrowdStrike 發布 VAPOR PANDA 全球攻擊研究	揭露超過 200 個組織受到攻擊活動影響或遭到攻擊者探索，至少 9 個組織確認出現後續入侵活動。
2026/10/30	Google Cloud GTIG 發布 ARTEX 研究	說明 ARTEX 已被不同威脅行為者用於多階段自動化攻擊。
2026/11/4	印度 CERT-In 發布 AI 攻擊金融業警示	警示 AI Agent、自動化攻擊框架與金融 API 濫用等攻擊趨勢。
2026/11/5	ARTEX 惡意 Docker 映像風險受到關注	研究人員通報疑似遭植入後門的 ARTEX Docker 映像，提醒使用者注意供應鏈與安裝來源風險。

上述事件並不代表所有攻擊都由同一組威脅行為者發動，也不代表每一個案例都能確認由 ARTEX 自主完成全部攻擊步驟。不同研究機構對活動的追蹤範圍、證據及歸因方式也有所差異。

但整體趨勢相當明確：AI Agent 正逐漸成為攻擊者整合既有工具、加速攻擊探索及擴大攻擊規模的重要手段。

三、VAPOR PANDA 全球攻擊：超過 200 個組織遭鎖定，AI Agent 大規模探索企業環境

2026 年 10 月 29 日，CrowdStrike 發布研究，揭露威脅行為者 VAPOR PANDA 利用 ARTEX 展開全球攻擊活動。研究指出，活動自 10 月 17 日起持續約 11 天，涉及至少 14 個國家、超過 200 個組織。

攻擊目標涵蓋：

• 外國政府與外交部門。
• 美國半導體產業相關組織。
• 國防相關企業與研究機構。
• 電信業者。
• 智庫及其他具有戰略價值的組織。

CrowdStrike 指出，這次活動中至少有 9 個組織確認出現後續入侵活動，攻擊者在部分環境部署 BLOODALCHEMY 後門，並執行網路探索、掃描及其他偵察活動。此外，至少還有 12 個組織遭到帳號密碼噴灑或網路掃描。

200 多個目標，不代表 200 多家企業都已遭入侵

這項數據必須正確解讀。

超過 200 個組織是研究所觀察到的攻擊目標或活動涉及範圍，並非所有組織都已確認遭成功入侵。CrowdStrike 明確指出，只有部分組織確認出現後續攻擊或入侵活動。

這也是企業閱讀 AI 攻擊事件時需要注意的重點：被掃描、被鎖定、遭帳號攻擊與確認遭入侵，是不同的事件階段，不能混為一談。

AI Agent 如何協助攻擊者擴大攻擊規模？

CrowdStrike 觀察到，VAPOR PANDA 使用 ARTEX 進行自動化探索，主要搭配 DeepSeek 模型及其他商用大型語言模型。攻擊過程中，Planner Agents 與 Worker Agents 分工執行任務，並透過主要 Agent 整合結果及接受操作人員指令。

研究也指出，單次入侵過程中，規劃 Agent 的輸入 Token 使用量曾達約 14 億。這顯示攻擊者可能透過大量模型推理，持續分析環境、規劃任務及協調多個 Agent。<Cite refs={[“turn415736search0″,”turn305408search13”]}/>

這種攻擊模式與傳統人工滲透測試最大的差異，不在於每個攻擊步驟都變得更高明，而是攻擊者可以：

1. 同時對多個目標展開探索。
2. 自動整理掃描與偵察結果。
3. 依據發現的資產與服務調整攻擊方向。
4. 將不同攻擊任務交由多個 Agent 平行執行。
5. 持續產生新的探索任務，降低人工介入需求。

為什麼攻擊者會檢查是否存在 Falcon？

CrowdStrike 研究指出，VAPOR PANDA 的操作過程中，出現檢查目標主機是否安裝 Falcon 的行為。

這顯示攻擊者可能會將端點偵測與應變（EDR）產品的存在與否，納入攻擊環境評估，並針對不同主機的防禦狀態調整後續行動。

對企業而言，這代表 EDR 的部署覆蓋率、偵測品質與伺服器防護能力，都可能直接影響攻擊者能否持續進行探索與入侵。

AI Agent 能自動化攻擊流程，但企業也可以透過自動化防禦、行為偵測與欺敵誘捕，讓攻擊者在探索過程中更容易被發現。

四、91APP 資安事件：AI 攻擊框架之外，更值得警惕的是企業內部的弱點串連

2026 年 10 月，臺灣電商服務業者 91APP 公布資安事件調查資訊，引發企業對 AI 輔助攻擊及內部系統安全的關注。

根據 91APP 公開調查內容，事件涉及未修補的 Appsmith 應用程式、內部網路存取及 GitLab 中保存的資料庫憑證等問題。攻擊者在取得初始存取後，進一步利用相關憑證存取資料庫，造成訂單相關資料遭到未授權存取。

91APP 事件的攻擊路徑

從公開調查資訊可整理出以下攻擊鏈：

第一階段：利用未修補的 Appsmith

攻擊者利用未修補的 Appsmith 應用程式取得初始存取機會，進入企業內部環境。

第二階段：進入內部網路並取得 GitLab 相關資訊

攻擊者進一步存取內部系統，並取得 GitLab 中保存的資料庫憑證或相關敏感資訊。

第三階段：利用資料庫憑證存取 Commerce Cloud 訂單資料

取得有效資料庫憑證後，攻擊者進一步存取 Commerce Cloud 相關資料，造成訂單資訊遭未授權存取。

這個事件的重要性，在於它呈現出一條典型的企業攻擊路徑：

未修補的應用程式 → 內部網路存取 → 敏感憑證暴露 → 資料庫存取 → 業務資料遭侵害

ARTEX 在 91APP 事件中扮演什麼角色？

91APP 事件與 ARTEX 的關聯受到關注，但分析時仍須區分公開調查所確認的入侵路徑，以及 ARTEX 相關工具或操作痕跡。

目前公開資料能支持的重點，是 91APP 事件涉及未修補應用程式、內部網路存取及資料庫憑證等問題；不能因此直接推論所有攻擊步驟都由 ARTEX 自動完成，也不能將每一項入侵行為都歸因於 AI Agent。

這個區分非常重要。

ARTEX 可能協助攻擊者進行探索、任務規劃、工具操作或攻擊路徑分析，但真正造成資料外洩的關鍵，仍是企業環境中存在可被利用的弱點與不當存取權限。

91APP 事件對臺灣企業的三項警示

第一，內部應用程式不等於安全。

企業經常優先修補對外服務，卻忽略內部管理工具、開發平台及測試系統。這些系統一旦遭入侵，可能成為進入核心網路的跳板。

第二，程式碼與開發平台可能成為憑證集中暴露的風險來源。

GitLab、CI/CD、程式碼 Repository 與設定檔，可能保存資料庫密碼、API Key、服務帳號及其他敏感資訊。即使攻擊者只取得有限的初始存取權，也可能藉此擴大攻擊範圍。

第三，企業不能只防止初始入侵，還必須限制入侵後的攻擊擴散。

如果應用程式、開發環境與正式資料庫之間缺乏存取限制，攻擊者一旦取得一組憑證，就可能沿著系統關聯持續擴大影響。

91APP 事件再次說明：企業真正需要防範的不是單一漏洞，而是漏洞、憑證、網路連線與權限配置所形成的完整攻擊鏈。

五、韓國、日本與其他 AI 攻擊活動：ARTEX 已不再只是研究工具

ARTEX 相關攻擊活動並非僅限臺灣。CrowdStrike、Google Cloud 及其他資安研究機構陸續觀察到不同地區的攻擊者使用 ARTEX 或類似 AI Agent 框架。

韓國金融業：AI Agent 協助攻擊者自動化探索

CrowdStrike 在 2026 年 10 月公布韓國金融業攻擊研究，指出未知威脅行為者利用 ARTEX 對金融機構進行攻擊，攻擊過程涉及自動化探索及後續入侵行動。

這顯示金融業不只是資料竊取與勒索攻擊的目標，也可能面臨 AI Agent 自動化探索所帶來的更高攻擊頻率。

日本企業：攻擊活動出現 ARTEX 相關操作痕跡

日本企業的相關攻擊活動也出現 ARTEX 操作痕跡，顯示 AI 攻擊框架正逐步被不同地區及不同產業的攻擊者採用。

不過，各事件之間是否存在相同攻擊者、相同模型或相同攻擊目的，仍須依個別調查證據判斷，不能僅因使用同一套工具就直接認定具有共同背景。

Microsoft 觀察：Storm-0940 也利用 ARTEX

Microsoft 在 2026 年 10 月公布 Storm-0940 相關研究，指出該威脅行為者利用 ARTEX 進行攻擊活動，並觀察到部分雲端權限取得及攻擊操作具有相當高的速度。

這代表 ARTEX 不只是單一攻擊者的工具，而可能被不同威脅行為者採用，並依各自的攻擊目標、基礎設施與操作方式進行調整。

企業應關注的重點，不是 ARTEX 是否成為某一個攻擊組織的專屬工具，而是這類框架已降低自動化攻擊的操作門檻，並可能被不同攻擊者快速複製與使用。

六、GreyNoise AI 攻擊活動：大量 Agent 不代表大量成功入侵

除了 ARTEX，GreyNoise 也揭露過利用大量 AI Agent 及 Codex 類工具進行自動化攻擊的活動。

該活動於 2026 年 8 月 31 日開始，攻擊者利用 AI Agent 搭配 DeepSeek 等模型，針對 PaperCut 相關已知漏洞展開攻擊，研究觀察到約 440 個實例、涉及 395 個可辨識組織及 48 個國家。部分目標確認遭取得網域管理員權限。

這個案例與 VAPOR PANDA 的 ARTEX 活動並非同一事件，不應將其數據混合計算。

但兩者呈現相同的趨勢：

• AI Agent 可協助攻擊者快速探索大量目標。
• 已知漏洞仍是自動化攻擊的重要入口。
• AI 可以協助攻擊者產生、調整及執行攻擊腳本。
• 攻擊規模增加，不代表每個目標都成功遭入侵。
• 取得高權限仍取決於漏洞、設定、憑證與環境條件。

AI 攻擊真正改變的，是攻擊者執行既有技術的速度、規模與成本，而不是所有攻擊都突然變得無法防禦。

七、CERT-In 警示：AI Agent 正將金融 API 與身分濫用風險推向新階段

2026 年 11 月 4 日，印度電腦緊急應變小組 CERT-In 發布 AI 輔助攻擊相關警示，提醒金融服務業關注 AI Agent、自動化攻擊框架及金融 API 濫用等威脅。<

警示提及的攻擊工具及框架包括 ARTEX、PentAGI、Cairn 與 CyberStrikeAI 等，攻擊目標涵蓋銀行、金融科技公司、非銀行金融機構（NBFC）、數位貸款業者、支付服務業者及加密貨幣相關服務。

AI Agent 如何改變金融業攻擊模式？

CERT-In 所描述的風險，不只是 AI 協助撰寫攻擊腳本，而是 AI Agent 可能將多個攻擊階段串接起來，包括：

• 自動化網路探索與弱點辨識。
• 產生、修改及測試攻擊腳本。
• 蒐集帳號、憑證與 API 存取資訊。
• 針對金融服務 API 進行異常操作。
• 利用非正式環境或測試環境的存取權限，嘗試進入正式環境。
• 透過大量自動化操作測試交易流程與授權機制。
• 在取得存取權後，嘗試隱藏操作痕跡或干擾安全監控。

其中，金融 API 的風險尤其值得關注。

如果攻擊者取得有效帳號、API Key 或服務憑證，可能利用原本合法的 API 呼叫方式執行未授權操作。這類活動不一定會呈現傳統惡意程式的特徵，也可能難以單靠 IP 封鎖或固定攻擊特徵辨識。

金融業應注意：合法 API 不代表合法交易

攻擊者可能利用已取得的憑證，透過看似正常的 API 請求執行異常交易、測試支付流程、濫用授權機制或存取敏感資料。

因此，金融業不能只檢查 API 是否具備身分驗證，更應確認：

• API 呼叫者是否具有執行該項操作的權限。
• 交易金額、頻率、對象與行為是否符合正常使用情境。
• 是否存在異常的小額測試交易或大量連續請求。
• 非正式環境的帳號與憑證是否能存取正式交易系統。
• 是否具備即時停止異常交易、撤銷憑證與阻斷存取的能力。
• API、身分驗證、交易與稽核紀錄是否能進行關聯分析。

對金融業而言，AI 攻擊最值得警惕的風險之一，是攻擊者不一定需要突破所有防禦，而可能利用已取得的合法身分與 API 權限，執行超出授權範圍的操作。

八、ARTEX 惡意 Docker 映像：AI 攻擊框架本身也可能成為供應鏈風險

2026 年 11 月 5 日，ARTEX 相關惡意 Docker 映像風險受到關注。

研究人員通報 Docker Hub 上出現疑似遭植入後門的 ARTEX 映像，涉及 tomicdd/artex。相關報告聲稱，映像中的程式碼可能透過未經驗證的登入流程執行命令，並以高權限操作主機。報導也提及，該映像可能已被下載數千次。

但目前仍需保留查證空間

這項後門指控並非所有研究者都已獨立重現或確認。

The Hum 的後續分析指出，相關研究證據仍存在限制，部分判斷依據為 AI 分析截圖或研究者描述，而非完整公開的程式碼逆向與可重現驗證，因此尚無法獨立確認所有後門細節。<Cite refs={[“turn305408search8”]}/>

因此，較適當的說法是：

研究人員已通報 ARTEX 相關 Docker 映像存在疑似後門風險，但其完整技術細節及實際影響仍需進一步驗證。

為什麼這件事值得企業重視？

ARTEX 本身是攻擊工具，但其安裝與部署環境同樣可能遭到供應鏈攻擊。

如果企業或研究人員直接下載不明來源的 Docker Image，並在具有高權限的主機或正式環境執行，即使原本只是要進行資安研究，也可能讓主機、憑證、網路與其他敏感資料暴露於風險中。

尤其當 Docker Container 以 Root 權限執行、管理介面暴露於網際網路，或容器能直接存取主機敏感目錄及其他內部服務時，疑似後門可能造成更嚴重的影響。

企業與研究人員應注意

• 僅使用可信任的原始專案、官方發布來源及經驗證的映像。
• 不應直接使用來路不明的 ARTEX Fork 或 Docker Image。
• 下載後應驗證映像 Digest、來源及版本，並檢查程式碼變更。
• 避免以 Root 權限執行不必要的容器。
• 不應將測試工具直接部署於正式環境或暴露於網際網路。
• 若曾執行疑似遭植入後門的映像，應將相關主機視為可能遭入侵，進行隔離、憑證輪替、網路與日誌調查，並從可信任來源重新建置環境。

這也提醒企業，AI 資安工具本身並不等於安全。工具來源、部署權限、容器設定與供應鏈完整性，同樣需要納入資安治理。

九、資安專家觀點：AI 攻擊時代，企業不能只靠傳統防禦

ARTEX 與近期 AI 攻擊活動所揭示的核心趨勢，是攻擊者正在將大型語言模型、多 Agent 協作、既有漏洞利用工具及自動化攻擊流程整合成可持續運作的攻擊架構。

這不代表 AI 已經完全取代駭客，也不代表每一次 AI 輔助滲透測試都能成功入侵企業。

但當攻擊者能以更低的人力成本，同時探索大量目標、分析攻擊路徑並持續調整策略，企業原本依賴人工調查、固定特徵碼及被動告警的防禦模式，就必須重新檢視。

AI Agent 帶來的三項結構性變化

第一，攻擊探索速度提高。

AI Agent 可以持續分析目標環境、整理掃描結果並規劃下一步，降低攻擊者在人工分析上的時間成本。

第二，攻擊規模擴大。

多 Agent 協作讓不同任務可以平行執行，攻擊者不再需要逐一對每個目標進行人工探索。

第三，攻擊行為更具變化性。

當攻擊者能使用不同模型、工具及任務規劃方式，攻擊流程可能持續改變，使單純依賴固定攻擊特徵或 IP 封鎖的防禦方式更容易出現盲點。

因此，企業不能只問「是否已經部署防火牆或 EDR」，而應進一步思考：

• 攻擊者取得初始存取後，能否快速發現其他系統？
• 企業是否能偵測帳號、憑證及服務之間的異常關聯？
• 如果攻擊者開始探索內部網路，是否能在真正接觸核心資產前發現？
• 是否能立即限制攻擊者的橫向移動？
• 是否具備阻斷異常 API 操作及撤銷遭濫用憑證的能力？
• 企業是否能掌握 AI Agent 或自動化工具在內部環境中的操作行為？

未來企業資安防禦的關鍵，不只是能否阻擋已知攻擊，而是能否在攻擊者持續探索、取得憑證與建立橫向移動路徑的過程中，及早發現、有效阻斷並快速應變。

十、企業如何因應 ARTEX 與 AI Agent 自動化攻擊？六大防禦策略

面對 AI 驅動的自動化攻擊，企業應從單點防護轉向結合攻擊面管理、身分治理、欺敵誘捕及行為偵測的整體防禦架構。

1. 優先修補漏洞，降低 AI Agent 可利用的攻擊面

AI Agent 並不一定需要全新的零時差漏洞才能取得突破。未修補的公開漏洞、過時的內部管理工具、暴露於網際網路的服務，以及設定不當的應用程式，仍可能成為攻擊者進入企業環境的入口。

企業應優先盤點：

• 對外暴露的 Web 應用程式、VPN、遠端管理介面及第三方服務。
• 開發、測試與內部管理平台，例如 Appsmith、GitLab 等。
• 未更新的軟體、過期套件與已知高風險漏洞。
• 存放於程式碼、設定檔、CI/CD 或容器映像中的敏感資訊。

重點不是只修補對外服務，而是確保內部系統不會因為被視為可信任環境，就成為 AI Agent 攻擊時容易突破的弱點。

2. 強化憑證治理與權限控管，避免單一帳號引發連鎖入侵

91APP 事件顯示，攻擊者一旦取得應用程式或 GitLab 中保存的資料庫憑證，就可能進一步存取其他系統及重要資料。

企業應落實：

• 禁止在程式碼、Git Repository 或設定檔中保存明碼密碼及 API Key。
• 定期掃描程式碼與歷史版本中的敏感資訊，並立即撤銷、輪替已暴露的憑證。
• 導入多因素驗證（MFA）及最小權限原則。
• 限制服務帳號、資料庫帳號及自動化帳號的存取範圍。
• 避免開發、測試環境憑證直接存取正式環境。
• 強化 API 身分驗證、伺服器端授權及異常交易監控。

尤其當攻擊者透過 AI Agent 自動探索帳號、憑證與服務關係時，一組有效憑證可能比單一漏洞更具攻擊價值。

3. 導入 Deception Technology 欺敵誘捕，提早發現 AI Agent 的探索與橫向移動

面對 AI Agent 能持續自動探索網路、辨識資產、分析服務與嘗試取得權限的攻擊模式，企業可導入欺敵誘捕技術（Deception Technology），在正式環境中部署具高度辨識性的誘捕資產，建立攻擊者容易觸及、但不屬於正常營運流程的監測節點。

例如：

• 誘捕伺服器與服務：部署偽裝成內部重要系統、管理介面或資料庫的誘捕資產。
• 誘捕帳號與憑證：配置不具正式系統存取權限的誘捕帳號、偽造憑證及誘捕 API Key。
• 誘捕資料與內部資產：建立看似具商業價值的文件、資料庫資料及網路資源，觀察是否遭到未授權存取。
• 誘捕橫向移動路徑：在適當的網路區段部署誘捕節點，監測異常服務連線、帳號使用及權限探索行為。

當 ARTEX 或其他自動化攻擊工具進行內網探索、服務辨識、憑證蒐集或橫向移動時，一旦接觸誘捕資產，即可觸發高可信度告警，協助資安團隊及早掌握攻擊行為，並進一步分析攻擊路徑、使用帳號及相關工具。

相較於傳統仰賴已知攻擊特徵碼或 IP 位址的偵測方式，欺敵誘捕能從攻擊者與誘捕資產的實際互動中取得偵測訊號，降低對既有攻擊特徵的依賴。

AI Agent 的自動化探索速度越快，企業越需要利用欺敵誘捕建立高辨識度的偵測機制，避免攻擊者在真正接觸核心資產前，仍未被察覺。

4. 建立網路分區，限制 AI Agent 的橫向移動與攻擊擴散

企業不能假設攻擊者取得一台主機或一組帳號後，就能立即存取整個內部網路。

建議透過網路分區、零信任架構及細緻化存取控制，限制不同系統之間的連線關係：

• 隔離開發、測試與正式環境。
• 限制 CI/CD 平台對正式資料庫的直接存取。
• 將重要資料庫、身分管理系統及核心服務設置獨立存取控制。
• 針對管理介面與高權限帳號設定額外驗證。
• 持續監控非預期的內部連線與跨區存取。

即使攻擊者透過 AI Agent 自動發現新的攻擊路徑，也應確保每一次跨系統存取都受到驗證與授權。

5. 強化行為偵測與事件應變，避免只依賴攻擊 IP 或特徵碼

AI Agent 可以改變探索順序、重新產生攻擊腳本、切換模型，甚至透過不同代理節點分散操作，因此單純依靠固定攻擊特徵或封鎖 IP，可能無法有效阻止攻擊。

企業應結合 EDR、NDR、SIEM 與威脅情資，關注：

• 短時間內大量服務探索、目錄列舉及異常登入。
• 不符合正常使用情境的帳號、憑證及 API 使用行為。
• 非預期的資料庫存取、資料匯出及跨系統連線。
• 管理工具遭異常執行、權限提升及安全機制遭停用。
• 連續出現弱點驗證、憑證使用及橫向移動等攻擊行為。

透過行為關聯分析及自動化應變，企業可更早發現攻擊者正在建立攻擊鏈，而不是等到資料外洩或勒索事件發生後才開始調查。

6. 建立 AI Agent 使用治理，防止攻擊工具與企業內部 AI 成為風險來源

AI Agent 不只被攻擊者用於滲透測試與入侵，也可能被企業內部導入自動化維運、資安分析及系統管理工作。

當 Agent 可以自行呼叫工具、執行程式、讀取資料或操作 API，企業就必須將其視為具有實際操作能力的身分，而不是單純的聊天機器人。

建議建立：

• AI Agent 專屬身分與操作紀錄。
• 明確的任務目標、工具使用範圍及存取權限。
• 高風險操作的人工核准機制。
• 對 Agent 使用的 API、憑證及資料來源進行限制。
• 可立即中止 Agent 執行、撤銷憑證及停止相關工作流程的機制。
• 對 Agent 操作結果、工具呼叫與資料存取建立稽核紀錄。

企業應避免讓 AI Agent 以過高權限直接操作正式環境，並確保自動化能力受到可驗證、可追蹤及可中止的治理機制約束。

結語：AI 攻擊可以自動化，企業防禦也必須具備主動性

從 ARTEX、VAPOR PANDA、91APP 資安事件，到金融業 AI 攻擊警示與惡意 Docker 映像風險，可以看出 AI 正逐步改變資安攻防的運作方式。

攻擊者開始利用 AI Agent 將網路探索、弱點分析、憑證蒐集、攻擊腳本生成及後續任務規劃串接起來，降低人工操作成本並提高攻擊規模。

但這並不意味著企業已經失去防禦能力。

真正需要改變的是企業對資安防禦的思考方式：從單純阻擋已知攻擊，轉向持續掌握資產、身分、權限與行為之間的關聯，並在攻擊者建立完整攻擊鏈之前，及早發現與阻斷威脅。

未來企業資安防禦應結合：

• 攻擊面管理與漏洞修補：降低攻擊者可利用的入口。
• 身分與權限治理：避免憑證遭濫用及攻擊擴散。
• 零信任與網路分區：限制攻擊者橫向移動。
• EDR、NDR 與行為偵測：掌握異常操作與攻擊鏈。
• Deception Technology 欺敵誘捕：利用誘捕資產與誘捕憑證，提早發現自動化探索及未授權存取。
• AI Agent 治理：確保企業內部自動化工具具備明確權限、稽核與中止機制。

其中，欺敵誘捕能補足傳統偵測機制對未知攻擊行為的不足，透過誘捕資產與誘捕憑證，讓攻擊者在探索與移動過程中留下可辨識的行為訊號，協助資安團隊提早發現威脅。

當攻擊者開始利用 AI Agent 擴大攻擊速度與探索範圍，企業防禦也必須從被動等待告警，轉向結合行為偵測、欺敵誘捕與主動威脅辨識的防禦架構。

AI 不會自動讓每一次攻擊都成功，但它正在讓攻擊者更有效率地尋找企業防禦中的缺口。

企業真正需要準備的，不是單純追逐最新 AI 攻擊工具，而是建立一套能持續辨識威脅、限制攻擊擴散、保護重要資料並快速應變的資安防禦能力。

_________________________________________________________________________________________________________________________________________

ARTEX 相關 C2 網域與 IP 情資

竣盟科技已彙整 ARTEX 相關命令與控制（C2）網域及 IP 情資。如有索取需求，歡迎來信 [email protected] 洽詢。

_________________________________________________________________________________________________________________________________________

參考資料

1. CrowdStrike — VAPOR PANDA 利用 ARTEX 展開全球攻擊活動
   https://www.crowdstrike.com/en-us/blog/vapor-panda-uses-artex-to-scale-global-campaign/
2. CrowdStrike — ARTEX 攻擊韓國金融業研究
   https://www.crowdstrike.com/en-us/blog/unknown-threat-actor-uses-artex-to-target-south-korean-finance/
3. Google Cloud GTIG — ARTEX and Friends: Agentic Offensive Frameworks
   https://cloud.google.com/blog/topics/threat-intelligence/artex-and-friends-enter-agentic-offensive-frameworks
4. Microsoft — Storm-0940 利用 ARTEX 進行攻擊活動
   https://www.microsoft.com/en-us/security/blog/2026/10/21/storm-0940-uses-artex-agentic-ai-connectwise-supply-chain-compromise/
5. 91APP — 資安事件調查與說明
   https://91app.com/91app-202610-security-incident/
6. 91APP — 資安事件後續調查報告
   https://91app.com/blog/91app-202610-security-incident-2/
7. iThome — 91APP 資安事件相關報導
   https://www.ithome.com.tw/news/179923
8. CERT-In — AI 輔助攻擊及金融業資安警示
   https://www.cert-in.org.in/s2cMainServlet?VLCODE=CIAD-2026-0058&pageid=PUBVLNOTES02
9. The Hacker News — ARTEX 疑似惡意 Docker 映像風險
   https://thehackernews.com/2026/11/backdoored-docker-image-for-artex-ai.html
10. The Hum — ARTEX Docker 後門指控的獨立查證限制
    https://hum.vibes.dev/s/researcher-says-one-artex-docker-image-is-backdoored/
11. Zscaler ThreatLabz — AI 輔助全球攻擊活動研究
    https://www.zscaler.com/blogs/security-research/inside-global-ai-assisted-hacking-campaign

NAS 不只是企業存放檔案的設備，更可能保存客戶資料、營運文件、系統備份及重要業務紀錄。一旦遭到駭客入侵，影響可能不只是檔案無法開啟，還可能造成營運中斷、資料外洩及勒索損失。

群暉科技（Synology）於 10 月 29 日發布安全警告，指出已發現攻擊者利用一項早在 2024 年 12 月就已修補的 DSM 安全漏洞，鎖定仍使用過時 DSM 版本的 NAS 設備，透過加密資料進行勒索。

這起事件最值得企業警惕的是：漏洞早已修補，攻擊者卻仍能利用尚未更新的設備發動攻擊。對長期存放重要資料的 NAS 而言，系統更新不只是例行維護，更是防止資料遭竊、遭加密的重要防線。

一、舊漏洞再遭利用！NAS 成為勒索攻擊目標

根據 Synology 官方公告，本次攻擊利用的漏洞與 2024 年 Pwn2Own 資安競賽揭露的 DSM 安全弱點有關，後續列入官方安全公告 Synology-SA-24:20。

該公告涉及三項安全漏洞，包含：

• CVE-2024-10441： 遠端程式碼執行漏洞，攻擊者可能利用弱點在受影響設備上執行程式碼，CVSS 3.1 風險評分為 9.8（Critical）。
• CVE-2024-50629： 檔案讀取漏洞，可能讓攻擊者讀取特定檔案，CVSS 3.1 風險評分為 5.3（Moderate）。
• CVE-2024-10445： 憑證驗證漏洞，可能遭相鄰網路中的中間人攻擊者利用，寫入特定檔案，CVSS 3.1 風險評分為 4.3（Moderate）。

Synology 已針對上述漏洞發布修補版本，並將該安全公告標示為已修復（Resolved）。然而，這次攻擊顯示，仍有部分設備持續運行未修補的舊版 DSM，讓已知漏洞再次成為駭客入侵的機會。

換句話說，不是漏洞沒有修好，而是設備沒有完成更新。

二、為什麼 NAS 遭入侵，可能造成更大的損失？

許多企業將 NAS 當作集中儲存與備份設備，平時存放部門共享檔案、客戶資料、財務文件、專案紀錄，甚至其他伺服器的備份。

一旦攻擊者取得 NAS 的控制權，可能進一步加密儲存資料，使企業無法正常存取檔案，並藉此要求支付贖金。

更需要注意的是，如果企業將 NAS 同時作為正式資料儲存及備份設備，卻沒有做好權限隔離，攻擊者可能連備份資料一併破壞，讓企業在系統遭到加密後，失去原本用來復原的資料。

因此，NAS 遭勒索攻擊的風險不只是單一設備故障，而是可能直接影響企業的資料可用性、營運持續及災害復原能力。

三、PHP2Shell 漏洞也需留意，但與本次勒索攻擊不同

除了舊版 DSM 漏洞遭利用，Synology 近期也針對 PHP2Shell（CVE-2026-109618、CVE-2026-109619）發布安全更新。

這兩起事件屬於不同的安全議題，目前不能據此認定 NAS 勒索攻擊是由 PHP2Shell 引起。

PHP2Shell 主要影響使用特定 PHP 相依套件的系統，例如 WordPress、Joomla、phpMyAdmin、Web Station 等。Synology 已針對相關套件提供安全更新，並指出 Synology Drive 不受此漏洞影響。

使用相關套件的用戶，應透過 DSM「套件中心」檢查 PHP 及相關套件版本，依官方公告完成更新。也提醒企業，除了作業系統本身，應同步檢查 NAS 上安裝的應用程式及相依元件，避免遺漏潛在風險。

四、企業與 NAS 使用者應立即檢查的五件事

面對已知漏洞持續遭利用的情況，建議企業及 NAS 使用者優先完成以下檢查：

1. 確認 DSM 版本並完成安全更新

檢查 NAS 目前使用的 DSM 版本，立即更新至官方已修補版本。Synology-SA-24:20 列出的最低修補版本如下：

• DSM 7.2.2：7.2.2-72806-1 或以上
• DSM 7.2.1：7.2.1-69057-6 或以上
• DSM 7.2：7.2-64570-4 或以上
• DSM 7.1：7.1.1-42962-7 或以上
• DSM 6.2：6.2.4-25556-8 或以上

2. 檢查已安裝的套件

除了 DSM 本身，也要透過套件中心檢查 PHP 及相關應用程式是否已更新。未使用的套件應評估停用或移除，減少不必要的攻擊面。

3. 避免 NAS 管理介面直接暴露於網際網路

檢查 NAS 是否開放不必要的外部連線，並透過防火牆、VPN 及存取控制限制管理介面的連線來源，避免讓攻擊者輕易接觸內部設備。

4. 啟用自動更新及多重身分驗證

依照設備支援情況啟用自動更新，並為管理帳號設定多重身分驗證（MFA），避免單一帳號遭竊就讓攻擊者取得設備管理權限。

5. 確保備份不會跟著一起被加密

重要資料應保留獨立備份，並採取離線或不可變更備份（Immutable Backup）等方式，避免 NAS 遭入侵時，連備份資料也一併遭到破壞。同時應定期測試資料還原，確認備份真正能在事故發生時發揮作用。

五、資安觀點：漏洞修補不能等到發生事故才做

台灣許多企業使用 NAS 作為檔案共享、資料集中管理及備份設備，部分中小企業因缺乏專責 IT 或資安人員，容易因為設備長期運作正常，就忽略 DSM 版本更新及套件安全檢查。

從企業資安管理的角度來看，NAS 不應只是一般儲存設備，而應納入正式的資訊資產盤點與漏洞管理範圍。已知漏洞一旦公開，攻擊者就可能持續尋找尚未完成修補的設備。尤其 NAS 通常存放大量重要資料，一旦遭到入侵或加密，影響可能擴大到整個企業的營運與備份環境。

企業應定期檢查系統版本、套件更新、外部連線及帳號權限，並確保備份資料具有獨立的防護機制，避免發生攻擊時連備份也無法使用。

這次 Synology 安全警告再次提醒企業，資安防護不能只依賴設備本身的安全設計，更重要的是持續更新、定期檢查，以及確保資料能夠在事故發生後順利復原。不要等到資料遭到加密，才發現系統早已存在可以修補的漏洞。

---

官方參考資料

• Synology-SA-24:20：DSM 安全漏洞公告
• Synology 安全公告

駭客不必竊取資料，也能利用遭入侵的設備賺錢；更值得警惕的是，當攻擊流量透過一般住宅 IP 傳送，企業熟悉的登入地點與 IP 信譽判斷，也可能成為資安防線的盲點。

資安威脅情資公司 GreyNoise 揭露，一波代理流量劫持（Proxyjacking）攻擊已波及全球 34 個國家，至少 143 台設備遭到入侵。攻擊者利用 D-Link 網路儲存設備、Ubiquiti 網路錄影系統及其他設備的已知漏洞，未經所有人同意，偷偷安裝合法的頻寬共享應用程式 Pawns.app，將受害設備納入商業住宅代理網路，藉此轉送網路流量並獲利。

但這起事件真正值得企業注意的，不只是網路頻寬遭到劫持。

GreyNoise 在調查企業身分驗證紀錄時，發現部分與惡意活動相關的 IP 位址來自看似正常的住宅網路，地理位置也沒有立即呈現明顯異常。進一步調查還發現，多名使用者透過同一個住宅 IP 位址進行驗證，成為研判企業遭到入侵的重要線索。

這揭示了住宅代理網路帶來的另一層風險：當攻擊者借用一般住宅 IP 傳送流量，企業若只依賴 IP 信譽與地理位置判斷登入安全，就可能錯失異常訊號。

一、駭客劫持你的網路，讓 IP 成為攻擊跳板

代理流量劫持（Proxyjacking），是指攻擊者未經設備所有人同意，入侵網路設備並利用其網路連線轉送其他人的流量，藉此從商業代理服務獲利。

這次事件涉及的 Pawns.app，本身是合法的頻寬共享應用程式。使用者可以自願分享網路連線，並依服務規則取得報酬。然而，攻擊者利用設備漏洞，將應用程式偷偷安裝到其他人的設備上，讓原本合法的服務成為未經授權的獲利工具。

整個攻擊流程可以分為四個階段：

1. 尋找漏洞設備： 掃描暴露於網際網路的 NAS、網路錄影設備及企業系統。
2. 入侵並安裝程式： 利用已知漏洞取得設備存取權限，部署頻寬共享應用程式。
3. 劫持網路連線： 將受害設備納入住宅代理網路，透過受害者的 IP 位址轉送流量。
4. 利用設備獲利： 攻擊者取得收益，設備所有人卻可能承受 IP 被封鎖及網路活動遭調查的風險。

對受害者而言，問題不只是頻寬被占用。當其他人透過遭劫持的 IP 位址對外連線，外部服務看到的可能是受害者的網路來源，而非實際操作的人。

如果相關流量涉及可疑活動，受害者的 IP 可能被列入封鎖名單，甚至需要進一步釐清設備是否遭到入侵，以及相關網路活動是否與自己有關。

二、D-Link、Ubiquiti、SAP 成為攻擊目標：已知漏洞仍是入侵入口

GreyNoise 研究人員辨識出多項與這波攻擊相關的已知漏洞，涉及網路儲存設備、網路錄影系統及企業應用系統。

這份清單反映出一個容易被忽略的問題：企業的資安風險不只存在於核心伺服器，也可能藏在長期沒有更新的周邊設備。

NAS 可能存放重要檔案與備份；網路錄影設備可能連接監控系統；企業應用系統則可能與內部業務流程相連。只要設備存在可被利用的漏洞，又缺乏適當的網路存取控管，就可能成為攻擊者入侵的入口。

需要注意的是，這不代表所有相關品牌或型號都已遭到入侵。企業應依實際設備型號、軟體版本及廠商公告確認是否受影響。

真正的風險在於，設備即使仍能正常運作，也可能已被安裝未經授權的程式，甚至被用來執行與原本用途完全無關的工作。

三、住宅 IP 為什麼會讓企業更難發現異常登入？

企業常利用 IP 信譽、地理位置、登入時間及裝置資訊，判斷使用者是否可能遭到冒用。

例如，員工平常在台灣登入企業系統，卻突然出現來自另一個國家的登入活動，系統可能觸發異常登入警示。

但當攻擊者透過住宅代理網路轉送流量時，登入請求可能呈現一般住宅網路的特徵，來源地理位置也可能看似合理。這會增加只靠 IP 位址與地理位置判斷風險的難度。

GreyNoise 的研究便凸顯這項盲點：研究人員在調查企業身分驗證活動時，發現部分可疑 IP 具有看似合理的住宅網路來源及地理位置。後續觀察到多名使用者透過同一個住宅 IP 進行驗證，成為進一步調查的線索。

該報告並未公開完整的入侵經過，因此不能據此推定攻擊者的所有入侵步驟，但這些發現足以提醒企業，必須重新檢視單靠來源 IP 判斷登入安全的做法。

企業應特別留意三個問題：

• IP 看起來正常，不代表登入者就是本人。 住宅代理可能讓攻擊流量呈現一般使用者的網路來源特徵。
• 地理位置合理，不代表存取行為合理。 即使登入地點沒有明顯異常，帳號、裝置及登入模式仍可能存在風險。
• 合法服務也可能被濫用。 單靠惡意程式黑名單或已知惡意 IP，未必能辨識所有未經授權的活動。

因此，企業應從單純判斷「連線來自哪裡」，進一步確認「誰在登入、使用什麼裝置，以及登入行為是否符合正常模式」。

四、企業如何發現住宅代理掩護下的異常登入？

企業應將 IP 信譽、登入行為與裝置資訊交叉分析，而不是只依賴單一指標。

1. 觀察多個帳號是否共用同一個住宅 IP

如果多個不同的企業帳號在短時間內，透過同一個住宅代理 IP 進行驗證，應進一步確認原因。

不過，公司共用網路、網路位址轉換（NAT）及其他合法網路架構，也可能讓多名使用者共用同一個 IP。因此，這項特徵應視為調查線索，而非直接判定遭到入侵的依據。

2. 比對裝置識別資訊

確認使用者登入時的裝置是否符合既有紀錄，包括系統能夠提供的裝置識別碼、作業系統及瀏覽器資訊。若同一帳號突然出現不熟悉的裝置特徵，應結合其他訊號判斷是否需要額外驗證。

3. 分析工作階段與用戶端資訊

工作階段相關資訊及 User-Agent 可協助辨識登入環境的變化。若同一帳號在短時間內出現無法合理解釋的裝置或用戶端特徵變化，應進一步檢查。

但這些資訊也可能因瀏覽器更新、網路環境變動或合法共用設備而改變，不能單獨作為入侵證據。

4. 將登入紀錄與網路活動交叉比對

若身分驗證系統出現可疑登入，應進一步檢查相關時間的網路連線、端點活動及設備設定。若同時發現不明程式、未授權的 SSH 金鑰或異常對外流量，就應提高調查優先級。

這類交叉分析有助於避免因為單一指標看似正常，就忽略其他可能的入侵跡象。

五、台灣企業應優先做好哪些防護？

對台灣企業而言，這起事件帶來的警示不只是及時修補漏洞，更要將邊界設備安全、網路行為監控與身分驗證納入整體防禦策略。

第一，盤點所有對外連線設備。

清查 NAS、NVR、DVR、路由器及企業應用系統，確認設備型號、軟體版本、管理介面與外部存取需求。對不再需要的服務應予以關閉，避免管理介面直接暴露於網際網路。

第二，儘速修補已知漏洞。

依廠商公告確認受影響版本並執行更新。對已停止支援、無法修補的設備，應評估隔離、限制連線或汰換。

第三，檢查是否存在持續存取管道。

若設備出現異常，除了修補漏洞，也應檢查未授權的帳號、SSH 公開金鑰、常駐程序及其他設定變更，避免攻擊者在原始漏洞修補後仍可重新進入。

第四，強化身分驗證與異常登入監控。

將 IP 信譽、登入頻率、地理位置、裝置資訊及工作階段特徵交叉分析，並依風險採取多因素驗證、額外身分確認或限制存取等措施。

第五，建立完整的事件調查流程。

發現設備遭入侵時，應保留相關紀錄與證據，確認攻擊時間、影響範圍、持續存取方式，以及是否波及其他系統。不能只因為設備恢復正常，就認定事件已經結束。

GreyNoise 也提供需註冊帳號的 IP 查詢服務，可協助使用者檢查 IP 是否與已知代理服務相關聯。不過，查詢結果只能作為調查線索，不能單憑是否命中，就認定設備遭到劫持或完全沒有風險。

結語：別讓「看起來正常」成為企業資安的盲點

這波代理流量劫持攻擊表面上是駭客劫持網路設備、利用住宅代理網路獲利，背後卻凸顯兩個企業不能忽視的問題：一是長期未更新的邊界設備可能遭到濫用；二是攻擊者利用住宅 IP 轉送流量，可能讓部分異常活動不容易透過傳統登入規則辨識。

對台灣企業而言，防禦策略不能只依賴已知惡意 IP、登入地理位置或惡意程式告警。更重要的是持續掌握設備實際行為，確認帳號、裝置及網路連線是否符合正常使用情境。

當駭客能借用一般住宅 IP 隱藏網路活動，企業就不能再把「IP 看起來正常」當成「登入安全」的證明。

設備安全、網路監控與身分驗證必須相互配合，才能更早發現設備遭到劫持及帳號遭到濫用的跡象，避免企業在系統仍能正常運作的情況下，錯失處理資安事件的時機。

資料來源：GreyNoise，Proxyjacking Edge Devices Into Residential Proxies。

台灣網路設備成為 Linux 後門攻擊鏈的一環。

資安業者 Rapid7 最新揭露一批針對電信與網路邊緣環境的 Linux 惡意程式活動，其中包括此前未公開的 AVERAT 後門。研究人員在台灣設備環境發現 6 個 AVERAT 樣本，並分析出一套疑似專為眾至資訊 (ShareTech)設備環境打造的惡意安裝程式。

更值得台灣企業注意的是，Rapid7 從 AVERAT 的設定資料中進一步發現 3 台位於台灣的設備已遭攻擊者入侵，並被拿來當作 AVERAT 的中繼基礎設施。這些設備分別位於台南、板橋與桃園，皆位於中華電信 HiNet 網路環境。

這代表這起事件不能只理解成「某一款 Linux 後門出現」。

從資安角度來看，更值得警覺的是：攻擊者正在把台灣企業與網路環境中的設備，轉變成自己的隱蔽通訊節點，進一步掩護後續攻擊活動。

AVERAT 最危險的地方，不只是「後門」，而是藏得像正常郵件流量

Rapid7 將這批活動的核心特徵歸納為「區域化偽裝」。

攻擊者會根據目標環境中實際使用的軟體與設備，調整惡意程式的程序名稱、檔案名稱及通訊方式，讓它看起來更像系統原本就存在的正常元件。

AVERAT 就是一個典型案例。

這個後門會透過 TCP/25，也就是 SMTP 常見的郵件通訊埠對外連線，甚至會先進行 EHLO、要求 STARTTLS，再建立自己的加密通訊。對郵件安全設備而言，對外建立 SMTP 連線本來就是正常工作，因此單純從網路流量來看，惡意通訊很可能與正常郵件服務混在一起。

更重要的是，AVERAT 的回連時間也不是固定值，而是在約 600 至 699 秒之間，並且可由攻擊者修改。

也就是說，如果企業只依靠「異常連接埠」或固定週期的網路特徵來抓後門，很可能會漏掉這類藏在正常服務流量裡的攻擊。

台灣部分最值得注意：疑似針對Sharetech環境打造

Rapid7 發現一個 ELF 格式的 Dropper，極可能是針對眾至資訊設備環境所設計。

其中一個非常特殊的細節是，Dropper 的加密金鑰衍生方式直接使用 「ShareTech」 字串。惡意程式進一步從設備的 /addpkg/sbin/ 目錄取得檔案，將惡意元件複製到 /sbin/，並偽裝成 ntpdate、udevds 等看似正常的 Linux 程序。

執行後，惡意檔案會在約 10 秒內從磁碟刪除，但程序仍持續運作，導致系統管理者即使事後檢查 /sbin/，也可能找不到原本的惡意檔案。

Rapid7 更指出，這種做法讓檔案型偵測變得困難，應改從 /proc/<pid>/exe 是否出現 (deleted)、記憶體中的可執行頁面，以及程序啟動鏈等方向調查。

但目前不能直接說「ShareTech 有漏洞」

這一點必須特別釐清。

Rapid7 的研究證明的是：有一個 Dropper 的技術特徵高度指向眾至資訊設備環境，包括使用「ShareTech」作為金鑰衍生來源，以及從設備特定目錄取得惡意元件。

但 Rapid7 並沒有確認攻擊者最初是透過哪一個漏洞取得設備存取權限，也沒有證實這起事件是由眾至資訊特定產品漏洞造成。

眾至資訊在事件說明中也強調，目前公開研究尚未說明初始入侵方式，亦未確認事件是由特定產品漏洞造成；公司表示現行 ShareTech 郵件伺服器具備異常檔案及可疑執行行為偵測機制，若發現問題將提供必要更新。

因此，目前最精確的說法應該是：

Rapid7 發現疑似針對 ShareTech 設備環境設計的惡意安裝程式，但初始入侵途徑與是否涉及產品漏洞，仍待進一步確認。

這個區分對台灣企業非常重要，避免把「攻擊者針對某設備開發惡意程式」直接等同於「該產品存在已確認漏洞」。

更令人擔心的是：台灣設備被拿來當「跳板」

Rapid7 的調查還揭露另一個台灣企業更容易忽略的風險。

研究人員從 AVERAT 的設定資料中找到 3 個中繼節點，進一步分析後發現，這些都是位於台灣的第三方設備，包括一台台灣燃料零售業者使用的 Synology NAS、一台嵌入式網路設備，以及一台 大華(Dahua) 影像錄影設備。

這些設備並不是攻擊者自己的伺服器，而是先遭到入侵，再被拿來隱藏真正的攻擊來源。

Rapid7 認為，這些設備具有共同特徵：可從網際網路連線、未修補、缺乏監控，而且不容易被定期稽核。攻擊者因此可以利用它們建立中繼層，讓真正的 C2 通訊更難追蹤。

這對台灣企業的警示非常直接：

你的設備即使不是攻擊者真正想攻擊的目標，也可能被拿來當成攻擊別人的跳板。

為什麼「邊界設備」特別危險？

Rapid7 發現的 AVERAT 並不是單純竊取資料的工具。

它具備檔案上傳、下載、目錄探索、程序列舉、程序終止、互動式 Shell，以及 Proxy／Port Forward 等功能。

其中 Proxy 與 Port Forward 尤其值得注意。

一旦攻擊者控制位於網路邊界的設備，就可能利用該設備作為內外網路之間的通道，進一步進行內部偵察、建立隱蔽連線，甚至掩護其他攻擊活動。

這也是為什麼資安團隊不能只監控 Windows 工作站或一般伺服器。

郵件安全設備、NAS、DVR、路由器、閘道器及其他 Linux 型網路設備，同樣需要被納入企業的偵測與事件調查範圍。

台灣企業現在應該檢查什麼？

Rapid7 建議，企業應優先從幾個方向檢查 Linux 與網路邊界設備：

一、檢查異常的 Raw Socket 與 BPF 行為

如果設備本身沒有封包擷取或分析需求，卻出現異常 Raw Packet Socket 或 BPF Filter，應進一步調查。

二、檢查非郵件程序對外連 TCP/25

不能只看到 TCP/25 就認定是正常郵件流量，而要追查「到底是哪一個程序建立連線」。

如果來源是本來不應該發送郵件的網路設備或系統程序，就值得高度注意。

三、檢查程序是否冒用正常名稱

例如惡意程序可能偽裝成 ntpdate、udevds 或其他看似正常的系統服務。

因此應進一步比對程序實際執行路徑、檔案雜湊、父子程序關係，以及 /proc 中的執行檔狀態，而不是只看程序名稱。

四、重新盤點所有直接暴露在網際網路上的設備

尤其是 NAS、DVR、路由器、郵件閘道器及其他嵌入式 Linux 設備。

如果設備已經停止原廠支援、長期沒有更新、管理介面直接暴露在網際網路，風險會更高。

給台灣企業的一個重要提醒

這起 AVERAT 事件最值得台灣企業注意的，並不是又出現一個新的 Linux 後門，而是攻擊者正在把台灣的網路設備環境納入完整的攻擊基礎設施。

一端是疑似針對特定設備環境設計的惡意程式；另一端則是已遭入侵的台灣 NAS、網路設備與影像設備，被進一步拿來當成中繼節點。

這代表攻擊者的目標不一定只是「偷資料」。

控制一台不起眼的網路設備，本身就可能具有攻擊價值。

對台灣企業而言，真正需要重新思考的是：企業現在的資安監控，是否只看「有沒有惡意檔案」，卻沒有看「這台設備現在正在做什麼」。

因為在 AVERAT 這類攻擊中，惡意程式可以刪除自己的檔案、偽裝成正常程序，甚至把 C2 通訊藏進設備原本就應該使用的 SMTP 流量。

當攻擊者開始偽裝成正常服務，防禦的重點就必須從「檔案有沒有異常」，進一步提升到「程序、網路連線與設備行為是否符合正常工作」。

這才是這起台灣 AVERAT 事件對企業最重要的資安警訊。

過去企業談資安，多半聚焦在「怎麼把駭客擋在門外」。但現在的攻擊環境已經不同，攻擊者可能透過釣魚、漏洞、被竊帳密或供應鏈風險取得初步存取權，再利用合法帳號與系統內建工具進行偵察、橫向移動，甚至尋找重要資料。

這也讓「如何在攻擊者進入環境後更早發現他」成為企業資安防禦的重要課題。

美國網路安全暨基礎設施安全局（CISA）近期發布 Cyber Decoy 指南，將 Cyber Decoy 納入偵測與事件回應思維。核心概念很簡單：既然不能假設駭客永遠進不來，就要設計一套機制，讓駭客進來之後更容易暴露。

Zero Trust 之後，還要思考「駭客進來了怎麼辦」

Zero Trust 的核心精神，是不因為使用者「已經在內網」就直接信任他。

但實務上，即使企業已經導入身分驗證、MFA、EDR、Firewall、SIEM 等防護措施，攻擊者一旦取得合法帳號，仍可能利用正常工具進行系統探索。

例如探索內部網路與伺服器、嘗試存取其他帳號、搜尋重要檔案與資料夾、進行橫向移動，或尋找備份與其他可利用的系統。

這些行為不一定會立即觸發傳統安全設備的高風險告警。

因此，Cyber Decoy 的思維不是再增加大量告警，而是刻意放置一些「正常使用者不應該碰到」的資產，讓攻擊者一旦碰觸，就成為高度可疑的訊號。

不只是 Honeypot，而是完整的欺敵防禦

Cyber Decoy 並不只是傳統的 Honeypot。

企業可以運用不同形式的誘餌，包括 Decoy 系統、帳號、憑證、檔案、URL、網路服務，以及 Honeytoken、Tripwire 等技術。

例如，在企業研發環境中，可以建立看起來像真的「R&D」資料夾，放入沒有實際敏感內容、但具有監控能力的誘餌檔案。

也可以建立一組看似具有管理權限的帳號或憑證。

如果一般員工根本不應該存取這些資源，一旦出現登入、讀取、複製或嘗試使用的行為，SOC 就可以立即收到告警。

這種做法最大的價值，就是降低「到底是不是攻擊」的判斷成本。

一般的登入行為可能是正常的；但一個從未被使用、且不應該被碰觸的 Decoy 帳號突然遭到嘗試登入，安全團隊就有更明確的調查方向。

CISA 提出的三種目的：Expose、Affect、Elicit

CISA 將欺敵防禦的目標概括為三個方向。

Expose：讓攻擊者現形

透過高可信度的誘餌與觸發條件，快速發現攻擊者。例如放置假的管理員憑證、誘餌資料夾或網路服務，只要攻擊者碰觸，就產生告警。

Affect：增加攻擊成本

讓攻擊者花時間在沒有實際價值的目標上，延緩其攻擊進程。例如提供看似重要、實際上沒有敏感資訊的資料，讓攻擊者在錯誤方向上花費更多時間。

Elicit：觀察並蒐集攻擊情報

透過高度擬真的受控環境觀察攻擊者的行為，進一步了解攻擊手法與工具。

不過這種方式對監控、紀錄與事件分析能力要求較高，因此企業通常可以先從 Expose 與 Affect 開始。

真正重要的不是「放了多少誘餌」，而是能不能形成偵測閉環

欺敵防禦最容易犯的錯，就是把它當成「多放幾台假的伺服器」。

實際上，Decoy 只有與既有的監控與事件回應流程整合，才能真正產生價值。

一個完整的流程應該包括：

部署 → 觸發 → 告警 → 分析 → 調查 → 回應 → 持續調整

例如，攻擊者碰觸一個誘餌帳號後，SOC 不只是收到一則告警，而是進一步確認：

這個帳號從哪裡被使用？來源 IP 是什麼？之前是否已經出現其他偵察行為？同一台設備是否還存取其他系統？是否有後續的橫向移動？

透過這些關聯，原本一個孤立的事件，就可能變成完整的攻擊行為軌跡。

對企業而言，最值得注意的是「合法帳號＋正常工具」

現在許多攻擊並不是一登入就執行明顯的惡意程式。

攻擊者可能使用已取得的合法帳號，再搭配 PowerShell、遠端管理工具或其他系統原生功能進行操作。

這也是企業為什麼越來越難單純依靠傳統特徵式偵測來判斷攻擊。

從資安實務來看，「攻擊者不應該做的事情」往往比「惡意程式長什麼樣子」更值得監控。

如果一名一般員工突然嘗試存取不存在於正常工作流程中的管理服務，或者某個從未使用過的高權限 Decoy 帳號突然出現登入行為，這類事件本身就具有很高的調查價值。

從 CISA 指南到企業實戰：欺敵防禦如何落地？

這也是 Acalvio ShadowPlex 所對應的企業應用場景。

企業可以在既有 IT、OT、雲端或混合環境中部署不同形式的 Decoy，包括虛擬主機、網路服務、帳號、憑證、檔案與其他誘餌，讓攻擊者在進行網路偵察、帳號嘗試、橫向移動或尋找敏感資料時，一旦碰觸這些 Decoy，就能產生高可信度的安全事件。

與其從大量正常使用者行為中尋找「哪一個可能是攻擊」，欺敵防禦採取的是另一種思維：

不是預測駭客下一步會做什麼，而是預先布置不應該被碰觸的帳號、系統或資料。一旦有人嘗試存取，就能產生高可信度的偵測訊號。

因此，ShadowPlex 並不是要取代 EDR、SIEM 或 SOC，而是補上傳統偵測機制較難處理的一個環節——當攻擊者已經進入環境，甚至使用合法帳號與正常工具進行偵察時，企業如何讓他自己暴露？

這也正是 Cyber Decoy 最值得企業關注的地方。

資安防禦不應只思考「怎麼阻止攻擊者進來」，也要開始思考：

如果駭客真的進來了，我們能不能讓他更早被發現、讓他的行為留下足夠證據，並在造成重大損害之前啟動事件回應？

對已經建立 EDR、SIEM、SOC 等資安防護能力的企業而言，欺敵防禦可以成為下一層的偵測補強，讓企業從「等待告警發生」，進一步走向「主動設計讓攻擊者暴露的環境」。

竣盟科技：從產品導入到長期在地支援

對企業而言，導入欺敵防禦平台不只是購買產品，更重要的是後續的部署、維運、調校與技術支援。

竣盟科技自 2020 年起代理 Acalvio ShadowPlex，持續深耕台灣市場，建立在地技術支援與客戶服務體系。

除了產品導入，我們同步培訓並建立具原廠認證的技術工程團隊，並定期為關鍵客戶與經銷夥伴提供 ShadowPlex 系統操作及維運訓練，協助客戶真正將平台能力融入既有資安環境。

我們也特別重視產品導入後的持續支援，避免企業在導入解決方案後，因缺乏技術資源而形成「孤兒產品」。從系統操作、維運到實際使用需求，提供持續且專業的技術協助。

對於過去曾使用類似欺敵解決方案，但因原廠停止支援而需要轉換平台的企業，竣盟科技也可提供 POC 測試、場地勘查與需求規劃，協助企業評估環境與需求，逐步銜接新一代欺敵誘捕與主動式防禦架構。

想了解 Acalvio ShadowPlex？

如果企業正在評估 Cyber Decoy、欺敵防禦，或希望強化現有 EDR、SIEM、SOC 的偵測能力，歡迎與竣盟科技團隊聯繫。

竣盟科技 Billows Technology
網站：www.billows.tech
Email：[email protected]
電話：02-2562-3952

9月中旬，Cisco 與 Check Point 接連釋出重大安全更新，其中 Cisco Identity Services Engine（ISE）更出現 CVSS 10.0 的最高嚴重度漏洞，Cisco 已確認漏洞遭到實際利用；Check Point 的 Security Management Server 與 Log Server 則發現 CVSS 9.8 的遠端程式碼執行漏洞。

這一波漏洞有一個共同特徵：出問題的不是一般使用者電腦，而是企業用來管理網路、身分、防火牆與安全政策的核心系統。

對企業而言，這些平台本身就是高權限、高價值的管理入口。一旦遭到攻擊，影響可能不只是一台設備，而可能進一步牽動整個企業網路。

Cisco ISE 爆 CVSS 10.0，漏洞已遭實際利用

目前最需要優先處理的是 Cisco ISE 的 CVE-2026-76460。

Cisco ISE 是企業常用的網路存取控制平台，負責管理使用者與設備身分、網路存取權限，以及相關安全政策。

這次漏洞出現在 ISE 的 API 驗證機制。攻擊者可以從遠端送出特製請求，在不需要帳號、密碼，也不需要使用者操作的情況下繞過身分驗證。

更重要的是，Cisco 已確認這個漏洞正在遭到實際利用，且目前沒有可用的 workaround，受影響企業必須升級到修補版本。

Cisco 目前提供的修補版本包括：

• ISE 3.1：Patch 12
• ISE 3.2：Patch 11
• ISE 3.3：Patch 12
• ISE 3.4：Patch 7
• ISE 3.5：Patch 4

ISE 3.0 已進入終止維護階段，則建議移轉至仍受支援的版本。

為什麼 ISE 漏洞特別值得注意？

因為 ISE 本身就是企業網路的存取控制中心。

如果一般辦公室電腦遭到入侵，攻擊者通常還需要尋找其他帳號、系統或權限；但如果攻擊目標直接是管理網路存取的平台，攻擊者取得的可能是更有價值的資訊與權限。

例如企業有哪些使用者、哪些設備、網路如何分區，以及不同設備可以存取哪些資源。

這些資訊對攻擊者而言，就像一張企業網路的架構圖。

因此，CVE-2026-76460 真正值得注意的地方，不只是 CVSS 10.0，而是它提供了一條從遠端直接進入高權限管理平台的攻擊路徑。

Cisco 不只 ISE，Firewall Management Center 也出現重大漏洞

近期 Cisco 也針對 ISE 發布多項安全更新，涵蓋遠端程式碼執行、SQL Injection、XXE 及命令注入等問題，其中部分漏洞的 CVSS 評分同樣達到 10.0。

此外，企業用來集中管理防火牆政策與相關設備的 Cisco Secure Firewall Management Center 也出現多項重大漏洞。

不過，這些漏洞與 ISE 的情況仍有差異。Cisco 目前並未表示 Secure Firewall Management Center 相關漏洞已遭到實際利用，因此企業不應把所有漏洞都視為已發生攻擊。

但從資安管理角度來看，這類系統仍應列為高優先級資產。

原因很簡單：它管理的不是一台設備，而是一整套網路安全設定。

Check Point 也中招：CVSS 9.8，可取得 Root 權限

同樣值得注意的還有 Check Point。

Check Point Security Management Server 與 Log Server 被發現 CVE-2026-91843，CVSS 評分達 9.8。

該漏洞存在於登入處理流程，遠端攻擊者可能在不需要登入的情況下觸發漏洞，進而執行任意程式碼並取得 Root 權限。

Check Point 目前表示，尚未發現該漏洞遭到實際利用，並已透過 LivePatch 提供修補方式；啟用自動更新的客戶也可能已受到保護。

企業除了確認修補狀態，也應檢查 Trusted Clients 設定及管理伺服器的網路暴露情況，尤其不應讓不必要的管理介面直接暴露在 Internet。

Cisco、Check Point 的共同問題：管理平台成為高價值攻擊面

把 Cisco 與 Check Point 的事件放在一起看，可以看到一個值得企業注意的現象：

攻擊者盯上的，開始不只是防火牆、Server 或 PC，而是「負責管理這些設備的系統」。

這類管理平台通常具有三個特性。

第一是權限高。

ISE、Firewall Management Center、Security Management Server 都具備管理其他設備或安全政策的能力。

第二是掌握大量資訊。

這些平台通常可以看到使用者、設備、網路架構、存取政策及管理活動。

第三是影響範圍大。

一台 PC 被入侵，影響可能集中在單一使用者；但管理平台遭到控制，可能進一步影響一批網路設備或安全設定。

因此，企業不能只把這些系統視為「IT 管理工具」，而應該把它們視為企業最重要的安全控制點之一。

修補之後，還要回頭確認「有沒有被打過」

企業面對這類重大漏洞，不能只確認「現在已經 Patch」。

尤其 Cisco ISE 的 CVE-2026-76460 已經確認遭到實際利用，如果企業過去曾使用受影響版本，就應該進一步確認在修補之前是否曾出現異常活動。

包括異常登入、可疑 API 請求、帳號新增、權限變更、設定修改，以及不尋常的管理操作等。

「Patch 是把漏洞關起來，但不代表攻擊者過去沒有進來過。」

因此，企業處理這類漏洞應該分成兩個階段：先修補，再查證。

對已確認遭到利用的漏洞，更不能因為系統目前已經更新，就直接認定事件已經結束。

企業資安盤點，別忘了「管理資安的系統」

這次 Cisco 與 Check Point 接連出現重大漏洞，對企業最大的提醒可能不是「又多了幾個 CVE」，而是企業需要重新檢視自己的攻擊面。

過去做資安盤點時，企業通常會優先關注 Server、PC、Firewall、VPN 或端點設備；但現在，網路管理平台、身分管理平台、資安管理伺服器，同樣應該被列入高風險資產。

因為這些系統一旦被攻擊，攻擊者取得的可能不只是單一主機權限，而是企業整個網路環境的管理資訊與控制能力。

Cisco ISE 已經出現實際利用案例，Check Point 的漏洞目前則尚未發現遭到利用，兩者的風險狀態並不相同。

但兩起事件共同說明了一件事：

企業真正需要保護的，不只是防火牆和 Server，也包括那些「負責管理防火牆和 Server」的系統。

當攻擊者開始把企業的管理後台當成攻擊入口，資安團隊的漏洞管理策略，也必須從「哪些設備需要更新」，進一步擴大到「哪些系統一旦失守，可能影響整個企業網路」。

微軟才剛發布 9 月例行安全更新，Microsoft Defender 卻又被公開一個新的零時差漏洞。

9 月 9 日，資安研究員 Nightmare Eclipse 公開名為 ShieldCrash 的 Proof-of-Concept（PoC），聲稱可繞過微軟日前針對 Defender 漏洞 ShieldBreak（CVE-2026-69414） 所推出的修補機制。更值得注意的是，研究員宣稱，即使 Windows 10、Windows 11 與 Windows Server 已經安裝 9 月安全更新，仍可能透過 ShieldCrash 讓攻擊者以 SYSTEM 權限讀取任意檔案。

目前 Microsoft 尚未針對 ShieldCrash 公布正式 CVE 或完整修補方案，因此企業不應直接把研究員公開的 PoC 視為已經被 Microsoft 官方確認的漏洞。不過，從防禦角度來看，這起事件已經值得企業立即關注。

最值得注意的不是「又一個零時差」，而是「修補竟然可以被繞過」

ShieldCrash 的特殊之處，在於它並不是突然冒出來、完全獨立的一個漏洞。

它其實延續了一條非常值得企業注意的攻擊鏈：

RoguePlanet → ShieldBreak → ShieldCrash

今年 6 月，研究員先揭露 Microsoft Defender 的 RoguePlanet 漏洞；微軟在 7 月進行修補。之後研究員又發現 ShieldBreak（CVE-2026-69414），指出可以繞過先前的修補。微軟再於 9 月初針對 ShieldBreak 推出修正，但不到一週，ShieldCrash 又被公開，研究員宣稱可以再次繞過這次修補。

這代表一個非常重要的資安問題：

企業以為「漏洞已修好」，不代表原本的攻擊面真的已經消失。

如果修補只封住研究人員已經找到的攻擊路徑，而沒有把底層的權限控管或程式處理邏輯一起修正，攻擊者仍可能從另一條路進入。

這也是為什麼資安團隊不能只看「Patch Tuesday 有沒有更新完成」，還必須持續確認漏洞是否真的被有效緩解。

SYSTEM 權限到底有多嚴重？

很多人看到「SYSTEM」可能沒有概念。

在 Windows 環境中，SYSTEM 是非常高權限的本機安全性帳戶。一般使用者即使已經登入電腦，也不代表可以任意存取所有系統檔案；但如果攻擊者成功取得 SYSTEM 層級的操作能力，權限就會大幅提升。

目前公開的 ShieldCrash PoC，研究員聲稱主要展示的是：

以 SYSTEM 權限讀取任意檔案。

這點需要精確理解。

目前並不是「只要 ShieldCrash 成功，就可以立刻完全控制整台電腦」。研究員自己也表示，目前 PoC 主要展示任意檔案讀取，尚未提供完整的 SYSTEM shell 或任意寫入能力。

但從防禦角度來看，SYSTEM 層級的任意讀檔仍然不能輕忽。

因為企業電腦裡可能包含：

• 系統設定與安全性設定
• 應用程式設定檔
• API 金鑰與服務帳號資訊
• 憑證或其他敏感資訊
• 企業內部文件
• 應用程式所留下的機敏資料
• 部分 Windows 安全性資料

因此，「只能讀、不能寫」不代表風險很低。

如果攻擊者已經能在端點上執行低權限程式，再利用 Defender 本身的高權限元件取得 SYSTEM 層級讀檔能力，下一步就可能是尋找認證資訊、敏感設定或其他可以協助橫向移動的資料。

換句話說，ShieldCrash 真正值得企業關注的，是它可能成為攻擊鏈中的「權限提升與資訊蒐集工具」。

為什麼 Defender 反而成為攻擊者研究的目標？

這也是這次事件最值得資安主管思考的地方。

過去企業常把 EDR、AV、Endpoint Security 視為「保護電腦的東西」，因此容易產生一個直覺：

安全軟體本身應該比一般應用程式更安全。

但實際上，安全軟體往往擁有非常高的權限，而且需要深入 Windows 核心、檔案系統、程序、服務與其他系統元件。

也因此，一旦安全產品本身出現權限控管問題，影響反而可能比一般應用程式漏洞更值得注意。

這不是只有 Microsoft Defender 的問題。

近期 Nightmare Eclipse 也陸續公開針對其他資安產品的漏洞，包括 Kaspersky Endpoint Security、Avast，以及 CrowdStrike Falcon 等。這反映出一個越來越明顯的趨勢：

攻擊者開始把「企業用來防禦攻擊的工具」本身，也當成攻擊面。

「已經更新」不等於「可以放心」

對企業 IT 與資安團隊來說，目前最實際的問題不是要不要更新。

答案當然是：

該更新還是要更新。

ShieldBreak 的官方漏洞資料顯示，Microsoft Malware Protection Engine 的受影響版本低於 1.1.26080.3；Microsoft 已針對 ShieldBreak 提供修正。

因此企業首先仍應確認 Defender Malware Protection Engine、病毒碼與相關安全元件是否維持自動更新，以及實際版本是否已經達到 Microsoft 公布的修補版本。

但現在真正需要多做一步。

如果企業已經安裝 9 月更新，不要因此直接把 Defender 相關風險標示為「已解決」。

因為目前 ShieldCrash 的公開說法正是在挑戰這個假設：研究員宣稱，即使套用最新更新，特定條件下仍然存在相同類型的高權限操作路徑。

資安團隊現在應該做什麼？

在 Microsoft 尚未針對 ShieldCrash 發布正式修補前，企業可以先從「降低攻擊成功後的影響」著手。

第一，確認 Defender 與 Malware Protection Engine 的實際版本，不要只確認 Windows Update 顯示「已完成」。

第二，持續監控端點上的異常權限提升行為。 特別是低權限使用者程序突然出現高權限操作、異常存取敏感系統檔案，或安全軟體程序出現不符合正常行為的檔案存取活動。

第三，確認 EDR、SIEM 或 SOC 是否真的能看到這類異常。

這一點非常重要。

如果安全產品本身成為攻擊面，企業不能只依賴「該產品自己告訴我它沒有問題」。還需要透過其他層級的監控機制，觀察端點、帳號、程序與檔案存取行為。

第四，針對高價值端點降低橫向移動風險。

例如網域管理員工作站、財務系統管理主機、伺服器管理端點等，不應與一般辦公環境採取完全相同的權限與網路存取策略。

這次事件真正提醒企業的是「安全工具也不是信任邊界」

從資安專家的角度來看，ShieldCrash 最值得注意的地方，其實不是又出現一個新的漏洞名稱。

而是它再次提醒企業：

不要把「有安裝資安產品」直接等同於「這台主機就是安全的」。

Defender、EDR、AV、SIEM、NDR 都是防禦工具，但這些工具同樣存在程式碼、權限、服務與介面，也因此可能成為攻擊面。

更值得注意的是，這次漏洞揭露還呈現出另一個趨勢：漏洞修補與漏洞繞過之間的時間正在縮短。

從 RoguePlanet 到 ShieldBreak，再到 ShieldCrash，攻擊者不是每次都從零開始，而是會研究上一個修補到底改了什麼，再尋找下一個可以利用的缺口。

因此，企業的漏洞管理不應只停留在：

「這個 CVE 有沒有 Patch？」

更成熟的做法應該是：

「Patch 完成之後，這個攻擊路徑真的被關掉了嗎？」

這也是 ShieldCrash 對企業最大的警示。

目前 ShieldCrash 尚未有 Microsoft 正式 CVE 與官方修補資訊，企業應持續追蹤 Microsoft Security Response Center 的後續公告。在正式修補推出前，最重要的不是恐慌停用 Defender，而是確認版本、強化端點監控、降低高權限帳號暴露，並提高對異常 SYSTEM 層級活動的偵測能力。

因為真正危險的，從來不是「有漏洞」這件事本身，而是企業不知道漏洞已經被繞過，卻仍以為自己已經修好了。

中國背景的網路間諜組織 Fire Ant 再度擴大攻擊範圍。資安事件公司 Sygnia 最新調查發現，Fire Ant 不只入侵 VMware 虛擬化環境，更進一步將目標鎖定 Cisco IOS XR 路由器、TACACS 驗證伺服器與 Linux 管理主機，企圖掌握企業核心網路與管理權限。

這次攻擊最值得注意的地方，不只是「駭客進入了網路」，而是他們開始利用遭入侵的網路設備監看流量、竊取管理員憑證，同時刪除或隱藏自己的活動紀錄。

換句話說，駭客不只想進門，還想把監視器關掉。

從一條不明 GRE Tunnel 發現入侵

Sygnia 在調查一台 Cisco IOS XR 路由器時，發現設備出現一條沒有正常設定紀錄的 GRE Tunnel。沿著這條異常通道追查後，研究人員發現攻擊者已利用一台 Linux 主機，持續對其他網路進行連線與 Port 探測，包含 SSH、HTTP、SMB 與 RDP 等服務。

更進一步調查發現，Fire Ant 已將遭入侵的 Cisco 路由器當成「觀察站」，從多台 Cisco 設備擷取網路封包（PCAP），再將資料傳送到外部 FTP 伺服器。

這意味著，攻擊者取得路由器控制權後，可以從企業網路的核心位置觀察哪些系統正在互相通訊，以及哪些網路路徑值得進一步探索。

駭客盯上的不是一般帳號，而是網路管理員

Fire Ant 同時入侵企業使用的 TACACS/TACACS+ 驗證伺服器。

TACACS 是企業用來集中管理網路設備管理員登入權限的重要機制。一旦這類系統遭到攻擊，駭客取得的可能不是單一員工帳號，而是具有高度權限的網路管理憑證。

Sygnia 發現名為 TacTap 的工具，會將惡意程式碼注入 tac_plus 驗證程序，攔截登入連線並蒐集驗證資訊。

這種手法尤其危險，因為後續駭客可能使用竊取到的合法管理員帳號操作網路設備，讓攻擊行為更難與正常管理活動區分。

最危險的一招：讓企業看不到駭客

Fire Ant 的另一項行動更值得企業警戒。

研究人員發現，攻擊者修改 Cisco 路由器上的系統元件，讓部分 Log 訊息遭到過濾，甚至修改管理員查看設備設定時的指令輸出，藉此隱藏攻擊者建立的 Tunnel。

在 Linux 主機上，攻擊者也嘗試關閉 SELinux、修改登入紀錄，以及移除高權限操作相關的系統 Log。

這代表攻擊者已經不只是「躲避偵測」，而是直接破壞企業用來判斷是否遭到攻擊的證據。

因此，這起事件也帶來一個很重要的資安問題：

如果產生 Log 的設備本身已經被駭客控制，我們還能相信 Log 嗎？

Fire Ant 疑似與 UNC3886 高度相關

Sygnia 評估 Fire Ant 的活動與公開揭露的中國背景間諜組織 UNC3886 有高度重疊。

UNC3886 過去就曾被發現鎖定 VMware、網路設備與 TACACS 基礎設施，並利用工具竊取網路管理員憑證。不過 Sygnia 並未對 Fire Ant 與 UNC3886 做出確定性的歸屬，因此目前仍應視為高度重疊，而非確認為同一組織。

值得注意的是，Sygnia 也發現 Fire Ant 曾對與關鍵基礎設施相關的網路進行掃描與連線嘗試，但目前沒有證據證明這些目標已遭成功入侵。

台灣企業不能只盯著 EDR

這起事件對台灣企業最大的警訊，是資安防禦不能只放在 PC、Server 與 EDR。

路由器、TACACS、Jump Server、Hypervisor 等設備，同樣可能是高價值的攻擊目標。

尤其金融、電信、半導體、製造與政府供應鏈，網路設備往往連接大量內部與外部系統。一旦其中一個核心節點被控制，駭客取得的可能不只是單一設備，而是一張通往其他系統的「網路地圖」。

企業因此應重新檢查三件事：

第一，核心網路設備是否有獨立且持續的監控？

第二，TACACS、RADIUS、AD 等高權限驗證系統是否被視為 Tier-0 資產？

第三，重要 Log 是否已即時送往攻擊者無法修改的獨立平台？

尤其最後一點非常關鍵。

Router 說「沒有異常」、TACACS 說「沒有異常」，不代表真的沒有發生攻擊。企業應將 Router、Firewall、TACACS、AD、EDR、NetFlow 等不同來源的資訊交叉比對。

因為在 Fire Ant 這類攻擊中，「沒有留下紀錄」本身，就可能是一個警訊。

對企業而言，真正需要防守的已不只是「端點有沒有被駭」，而是整條網路、身分驗證與管理信任鏈是否仍然可信。