CyberStrikeAI 在野現蹤：LLM 協調器在拉丁美洲與非洲的教育機構目標中取得網域管理員權限

2026 年 11 月 2 日，Kaspersky 發布了一份 Securelist 報告與一份新聞稿，描述拉丁美洲與非洲多個國家教育領域組織遭到的入侵；在這些入侵中，後滲透作業由大型語言模型指揮。該工具是 CyberStrikeAI，一套開源、以 Go 為基礎的滲透測試框架，其命令與控制伺服器託管一個 LLM，由它選擇工具並撰寫命令，而由一般植入程式在受害主機上執行這些命令。在 Kaspersky 詳細重建的一起案例中，一名人類操作員透過遭入侵的 Microsoft SQL Server 進入，潛伏兩週，然後讓代理程式執行：網域管理員帳戶在三到四天內淪陷，而最後階段——橫向移動、大規模憑證傾印與資料庫匯出——在一小時內完成。Kaspersky 未指名任何機構與國家，未提供受害者數量，並表示其觀察到該活動發生於 2026 年 9 月至 10 月間。此活動的完整記錄，包含其嚴重性等級、信心評級與完整來源清單，歸檔於 Orca AI Incident Archive，與其他關於 AI 輔助入侵的條目並列。

Kaspersky 實際發布了什麼

主要文件是《CyberStrikeAI 在野：AI 在真實世界攻擊組織中的運用》，於 2026 年 11 月 2 日發表在 Securelist 上，署名為 Kaspersky 威脅研究團隊的 Kirill Antonov、Vladislav Vlasov 與 Dmitry Chizhmak。隨附的還有 Kaspersky 同日發布的新聞稿，摘要說明相同的發現。該檔案庫的 A 級信心評分說明了這兩份文件彼此相符的程度，以及技術細節的具體程度；這並不表示已有第二個機構獨立驗證了該入侵事件。

這份報告的次級報導並未提供那第二個組織的資訊。Cybersecuritynews.com、Cyberpress、SecurityOnline 以及位於奈洛比的 TechTrends Kenya 都在 2026 年 11 月 2 日至 3 日之間發表了報導，而每一篇都源自 Kaspersky 的新聞稿，而非自身的調查；這家肯亞媒體的報導，也是圍繞 Kaspersky 威脅探索部門主管 Nikita Nazarov 在同一份新聞稿中的引述所建構。截至 2026 年 11 月 9 日，尚無任何受影響的大學、教育部或國家電腦緊急應變團隊公開確認這些入侵事件，Kaspersky 也未公布受害者的身分。這種缺席本身就是紀錄的一部分：詳細記錄下來的是作案手法，而非對任何具名機構造成的損害。

Kaspersky 的範圍聲明刻意寫得狹窄。用它的話說，已確認的受害者是「非洲和拉丁美洲多個國家的教育部門組織」。它沒有說明有多少個、是哪些國家，或這場行動最初是如何被偵測到的——只說團隊是在「作為主動威脅監控的一部分」發現了它。

這裡有一個區別很重要，因為它很容易被混淆。獨立機構現在已通報 CyberStrikeAI 出現在真實入侵事件中——但不是這些入侵事件。Team Cymru 將運行該工具的基礎設施與 2026 年 1 月至 2 月針對逾 600 台 FortiGate 裝置的活動聯繫起來，並觀察到在 2026 年 1 月 20 日至 2 月 26 日期間，有 21 個不重複的 IP 位址在提供該工具。Trend Micro 的 TrendAI 部門在 2026 年 10 月 23 日發表的研究中描述，一名操作者運行 44 個協同運作的 CyberStrikeAI 代理，在同年 10 月的一個短暫時間窗口內，使至少 19 個可識別組織（其中至少 16 個位於日本）遭受驗證活動。Cloud Security Alliance 於 2026 年 10 月 28 日的研究筆記彙整了這兩者，並得出結論：尚無已發表來源將這些各自獨立的 CyberStrikeAI 活動連結到單一行為者。這些研究成果佐證了這個前提——亦即該框架正被用於攻擊真實網路——但對 Kaspersky 報告中的拉丁美洲與非洲教育受害者隻字未提。

工具，以及 AI 實際所在的位置

CyberStrikeAI，如 Kaspersky 所描述，是「一個以 Go 語言撰寫的開源模組化平台，用於自動化滲透測試」。其關鍵設計選擇在於：整個智慧層位於攻擊者的控制伺服器上，而非受害者的機器上。偵察與漏洞利用工具、webshell 管理、將任務指派給代理以及讀取結果，全都以 MCP 工具的形式暴露給模型，並置於單一伺服器程序內，而由模型決定接下來要呼叫其中哪些工具。

植入程式則是另一半，而且它刻意設計得很笨。Kaspersky 寫道，它是「一個典型的 C2 代理程式，完全沒有 AI 功能——沒有 API 金鑰、不會呼叫 AI 服務 API，也沒有自主邏輯。」它透過 HTTP/S、TCP 或 WebSocket 輪詢監聽器，執行 shell 命令，並存取檔案系統。它不是執行於受害者網路中的模型，也從不聯絡 AI 供應商。這種分工正是 Kaspersky 用來說明整個方案的那句話：「決策分散在兩個層級：操作員以概括方式定義任務，而模型決定如何執行。」

人類控制得以保留，而非被移除。Kaspersky 指出一種人在迴路機制，其中「操作員保留對流程的完全控制」，且模型生成的命令「在執行前可能需要人工核准或修正」。AI 負責撰寫步驟；人仍然可以拒絕這些步驟。

一次經重建的入侵事件，依 Kaspersky 對其標定的日期順序

這份報告追蹤該活動中的單一事件，而其第一階段看起來像是尋常的手動鍵盤操作。受害者系統上的命令來自 sqlservr.exe 程序，指向「一個遭入侵的 SQL Server（version 16.0.1000）」是可能的入侵途徑。操作人員接著收集基本主機資訊、部署工具並手動繪製網路。這花了「將近一天」，之後攻擊者沉寂了約兩週。

第二階段是節奏改變的地方。在部署 CyberStrikeAI 代理程式後，持久化與本機偵察在「2 分鐘內」完成——一個名為 SystemUpdate 的排程工作指向該植入程式，並以 HKCU\Software\Microsoft\Windows\CurrentVersion\Run 下的登錄 Run 機碼作為該框架在 Windows 上的替代方案，而在 Linux 上則以 crontab 的 @reboot 項目或 ~/.bashrc 中的 nohup 行作為替代方案。網域偵察「在接下來 5 小時內」進行，使用模型生成的 PowerShell 指令碼以及對 Active Directory 的 LDAP 查詢，包括準備 Kerberoasting 與 AS-REP Roasting 所需的查詢，以及對 LAPS、Azure 和 .azcopy 目錄的檢查。在「短暫暫停數天」後，最終階段——透過 SMB 和 WMI 進行橫向移動、大規模憑證傾印，以及資料庫匯出——花費「不超過一小時」。

卡巴斯基的摘要總結最值得保留：整場攻擊「從代理程式部署到網域管理員遭入侵——都在 3 至 4 天內完成」。

憑證竊取工作是一系列眾所周知的 Windows 技術的彙整，而非任何新技術：使用 reg.exe 複製出的登錄區、透過 comsvcs.dll 的 MiniDump 函式傾印 lsass.exe（使用處理程序 ID 而非其名稱以規避命令列比對），以及——一旦內建的網域系統管理員帳戶遭入侵——透過重新命名的 Mimikatz 二進位檔 wdiag2.exe 執行 DCSync 與 Golden Ticket 攻擊。橫向移動使用了 Impacket 的 WMIExec、共用的系統管理資料夾與 WMI，將反向外殼指令碼 p1.ps1 推送至遠端主機並回連至 185.186.245[.]144:5501。酬載被分割成如 d3.b64 等片段，並使用 certutil 重新組合，且有一個信標偽裝成 svchosts.exe。

資料收集是最後階段。代理程式會產生針對該任務量身打造的 SQL 查詢，但在執行前先檢查資料庫帳戶的權限；在提取檔案前，先遞迴掃描網路共享；並透過同一個加密 C2 通道回傳所有內容，資料以 Base64 編碼內嵌於 JSON 中。Windows 與 Linux 上的螢幕截圖都可取得，但根據卡巴斯基的說法，只有在編排器發出命令時才會擷取。報告指出，資料收集「是攻擊的最後階段：攻擊鏈在那裡結束，我們未觀察到進一步活動。」

被奪走的是什麼，以及紀錄未曾言明的事

卡巴斯基記錄了該代理從該教育機構的 SQL 伺服器匯出資料庫記錄，並從網路資源收集檔案，且詳細描述了其機制。報告並未說明有多少記錄或檔案外流、匯出是否完成，或資料表中是誰的資料。次級摘要在此點上比報告走得更遠：SecurityOnline 的報導稱該代理「產生針對性的 SQL 查詢，從資料庫資料表中竊取學生與教職員記錄」，而卡巴斯基本身的文字僅描述針對教育 SQL 伺服器的查詢，並未指明資料表中存放了什麼。讀者應將「學生與教職員記錄」的描述視為次級轉述，而非卡巴斯基的調查發現。

記錄中同樣沒有提及：是否有任何受害者偵測到入侵本身、各機構事後做了什麼、受影響國家的監管機關或資料保護主管機關是否已獲通知，以及該攻擊行動是否仍在進行。Kaspersky 僅表示，在它所檢視的事件中，資料收集是最後一個被觀察到的步驟。該新聞稿未提供針對受影響組織的補救指引——其建議是普遍針對防禦者提出的。

歸因：證據支持什麼，以及不支持什麼

Kaspersky 明確表示，它無法指名任何行為者。「現有資料不允許我們將該活動連結到任何已知的攻擊者團體，也無法確切指出這兩個行動背後是同一個操作者。」它所依賴的證據是植入程式內的 Go 建置中繼資料，其中包含版本控制雜湊、提交時間，以及工作副本有未提交變更（dirty）的旗標——「特定建置的唯一指紋」。在此基礎上，這些樣本分成兩組，而每組內的 Windows 與 Linux 載荷都共享完全相同的中繼資料，意味著它們來自同一份工作副本。

這些團體並未串連起來。它們「不共用共同的 C2 基礎設施」，而且兩套控制伺服器上執行的是不同版本的 CyberStrikeAI。卡巴斯基提出兩個理由，說明為何在此難以歸因：該框架公開可用，因此不同操作者可能在類似條件下獨立建構酬載；此外，指令本身由模型生成，這增加了指令的多樣性，同時去除了行為歸因所依賴的個人習慣。

目前掌握的線索僅屬暗示，而非決定性結論。部分腳本帶有中文註解，攻擊者使用中國的服務 dnslog[.]cn 來確認能否從受害主機連上網際網路，而多數控制伺服器的重啟——之所以能夠還原，是因為自簽 TLS 憑證會在每次啟動時於記憶體中重新產生，因此其 not_before 欄位記錄了重啟時間——都落在 UTC+8 的上班時間內。CyberStrikeAI 本身即是在中國網路安全社群中開發而成。卡巴斯基的新聞稿則明確劃出界線：這些痕跡「無法確立攻擊者的身分或所在地」，該公司「無法將此活動歸因於已知的威脅組織，也無法確認所有已識別的基礎設施皆由同一名操作者控制」。推論出操作者說中文，只是一種推測，並非已證實的發現。

為什麼 Kaspersky 說這不是偵測緊急事件

報告的結論反駁了「攻擊鏈中出現 LLM 就需要全新類別防禦」的觀點。由於模型位於攻擊者的伺服器上，它「未在基礎設施中留下任何存在痕跡（例如對本機 LLM 的特定 API 請求，或主機資源消耗的異常模式）」。防禦者反而看到的是具有人類操作特徵的入侵：相同的工具、相同的順序、相同的事件記錄項目。卡巴斯基的判斷是，「將 AI 引入攻擊鏈尚未對偵測帶來根本性的新挑戰」，「經典且經過良好調校的關聯與行為分析規則就已足夠」，而其新穎之處「不在於方法本身，而在於執行這些方法的速度與容易程度」。

已發布的偵測遵循這套邏輯，而非另行發明新的邏輯。Kaspersky Anti Targeted Attack 會針對植入程式的流量提出 Backdoor.CyberStrikeAI.HTTP.C&C 的網路判定；名為「Scanning domain records via LDAP queries」的網路異常偵測規則可捕捉網域偵察活動；Kaspersky SIEM 內建超過 100 條規則，涵蓋報告中的手法，包括 DCSync、Golden Ticket、Kerberoasting 與 Impacket WMIExec；而植入程式則被分類為 HEUR:HackTool.Win64.CyberStrike.gen 和 HEUR:HackTool.Linux.CyberStrike.gen。Kaspersky 給客戶的指引相當常規——端點偵測與回應、網路偵測、威脅情報，以及在非工作時間或透過託管服務進行監控。

Nazarov 在新聞稿中的聲明，用一句話來說就是同一個論點：攻擊者「使用以 CyberStrikeAI 為基礎的 AI 代理來執行完整的攻擊鏈，並在受駭網路內調整其下一步行動」，但「該框架仍依賴熟悉的手法與程序，包括探索、憑證傾印、橫向移動，以及蒐集與外洩」。

哪些是已經確立的，哪些則尚未

直白地說：該機制的記錄詳盡到足以讓防禦者明天就能追獵它——從 sqlservr.exe 的處理程序父系關係、名為 SystemUpdate 的排程工作、透過 comsvcs.dll 存取 LSASS、從非網域控制站發動 DCSync，到 X-Implant-Token HTTP 標頭，以及 Kaspersky 列出的 C2 位址。但圍繞該機制的行動則未被記錄到這種程度。Kaspersky 未公布受害者名單、國家/地區分布、資料量估計，也未指明行為者。讀者可能想知道誰受害、受害程度多嚴重的所有資訊，都止於產業與地區。

有兩個細節值得提醒任何去看報告、期待更多內容的人。第一，Kaspersky 將這起攻擊描述為「首批公開描述之一，涉及在野環境中 LLM 的入侵事件」，而非第一起——這種保留說法讓該主張僅限於團隊在公開報導中能找到的內容。第二，報告指出，該植入程式的版本不會跟著伺服器版本走，監聽器設定與金鑰會在操作者更新後留存，而某個樣本的建置日期只能給出最早可能的部署日期，不能代表入侵持續了多久。「3–4 天」這個數字是對一起已重建事件的測量，並不是對這些入侵在有人注意到之前持續多久的上限。