真实环境中的 CyberStrikeAI：一个 LLM 编排器在拉丁美洲和非洲的教育目标中取得了域管理员权限

2026年11月2日，Kaspersky 发布了一份 Securelist 报告和一份新闻稿，描述了拉丁美洲和非洲多个国家教育行业组织遭受的入侵，其中后渗透工作由一个大语言模型指挥。该工具是 CyberStrikeAI，一个基于 Go 的开源渗透测试框架，其命令与控制服务器托管着一个大语言模型，由它选择工具并编写命令，而普通植入程序则在受害主机上执行这些命令。在 Kaspersky 详细还原的一起案例中，一名人工操作员通过一台遭入侵的 Microsoft SQL Server 进入，停顿了两周，随后让智能体开始运行：域管理员账户在三四天内被攻陷，而最后阶段——横向移动、大规模凭据转储和数据库导出——在一小时内完成。Kaspersky 未点名任何机构或国家，未给出受害者数量，并表示其在 2026 年 9 月至 10 月期间观察到该活动。该活动的完整记录，包括其严重性等级、置信度评级和完整来源列表，归档于Orca AI Incident Archive，与关于 AI 辅助入侵的其他条目并列。

卡巴斯基实际发布了什么

主要文档是《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 日之间发表了报道，而每一篇都源自卡巴斯基的发布内容，而非其自身调查；这家肯尼亚媒体的文章围绕卡巴斯基威胁探索负责人尼基塔·纳扎罗夫（Nikita Nazarov）在新闻稿中的同一段引述展开。截至 2026 年 11 月 9 日，尚无受影响大学、教育部或国家计算机应急响应团队公开证实这些入侵，卡巴斯基也未公布受害者身份。这种缺失本身就是记录的一部分：得到详细记录的是攻击手法，而不是对任何具名机构造成的损害。

卡巴斯基对影响范围的说明刻意写得很窄。用他们的话说，已确认的受害者是“非洲和拉丁美洲多个国家教育领域的组织”。声明没有说明有多少个、涉及哪些国家，也没有交代这场攻击活动最初是如何被发现的——只提到团队是在“主动威胁监控过程中”发现了它。

这里有一个区分很重要，因为它很容易被模糊。独立组织如今已在真实入侵中报告了 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，正如卡巴斯基所描述的那样，是“一个用 Go 编写的开源模块化平台，用于自动化渗透测试”。其标志性的设计选择是：整个智能层都位于攻击者的控制服务器上，而不是受害者的机器上。侦察与利用工具、webshell 管理、向代理分配任务以及读取结果，全都作为 MCP 工具在单个服务器进程内暴露给模型，而由模型决定下一步调用其中哪些工具。

植入体是另一半，而且它被刻意设计得很笨。卡巴斯基写道，它是“一个经典的 C2 代理，不具备 AI 功能——没有 API 密钥，不调用 AI 服务 API，也没有自主逻辑”。它通过 HTTP/S、TCP 或 WebSocket 轮询监听器，执行 shell 命令，并访问文件系统。它不是运行在受害者网络中的模型，也从不联系 AI 提供商。卡巴斯基用这句话解释整个方案的分工：“决策分布在两个层级：操作员以概括性方式定义任务，而模型决定如何执行它。”

人类控制得以保留，而非被移除。Kaspersky 指出了一种人在回路机制，在该机制下，“操作员保留对流程的完全控制”，并且模型生成的命令“在执行前可能需要人工批准或纠正”。AI 编写步骤；人仍然可以拒绝它们。

一次重建的入侵事件，按 Kaspersky 标注的日期顺序

该报告记述了该攻击活动中的一起单一事件，其第一阶段看起来像是普通的人工键盘操作。受害者系统上的命令来自 sqlservr.exe 进程，指向“一台遭入侵的 SQL Server（版本 16.0.1000）”可能是入侵途径。随后，操作者收集了基本的主机信息，部署了工具，并手动绘制了网络拓扑。这个过程花了“将近一天”，之后攻击者沉寂了约两周。

第二阶段是节奏发生变化的地方。在部署 CyberStrikeAI 代理后，持久化和本地侦察在“2 分钟内”完成——一个名为 SystemUpdate、指向该植入体的计划任务，并以 HKCU\Software\Microsoft\Windows\CurrentVersion\Run 下的注册表 Run 键作为该框架在 Windows 上的替代方案，以及 crontab @reboot 条目或 ~/.bashrc 中的 nohup 行作为其在 Linux 上的替代方案。域侦察在“接下来的 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，将反向 shell 脚本 p1.ps1 推送到远程主机并回连到 185.186.245[.]144:5501。有效载荷被拆分成诸如 d3.b64 的片段，并用 certutil 重新组装，其中一个信标伪装成 svchosts.exe。

收集阶段排在最后。该代理生成了针对任务定制的 SQL 查询，但在运行这些查询之前检查了数据库账户的权限，在拉取文件之前递归扫描了网络共享，并通过同一个加密 C2 通道返回所有内容，数据以 Base64 编码嵌入 JSON 中。Windows 和 Linux 上的截图均可获取，但在 Kaspersky 的描述中，只有在编排器发出命令时才进行截图。报告指出，数据收集“是攻击的最后阶段：攻击链在此结束，我们未观察到进一步活动”。

被拿走的是什么，以及记录没有说出的又是什么

卡巴斯基记录称，该代理程序从教育机构的 SQL 服务器导出了数据库记录，并从网络资源收集了文件，还详细描述了其机制。它没有说明有多少记录或文件外泄、导出是否完成，也没有说明这些表中是谁的数据。二手摘要在这方面比报告走得更远：SecurityOnline 的文章称，该代理程序“生成了有针对性的 SQL 查询，以从数据库表中窃取学生和教职员工记录”，而卡巴斯基自己的文本只是描述了针对教育 SQL 服务器的查询，并未说明这些表中包含什么。读者应将“学生和教职员工记录”这一描述视为二手转述，而非卡巴斯基的发现。

同样未出现在记录中的还有：是否有任何受害者检测到入侵本身、各机构事后做了什么、受影响国家的监管机构或数据保护机构是否收到通知，以及该攻击活动是否仍在进行。卡巴斯基仅表示，在其审查的事件中，数据收集是最后观察到的步骤。新闻稿未包含针对受影响组织的修复指导——其建议面向一般防御者。

归因：证据支持什么，以及不支持什么

卡巴斯基明确表示，它无法指认攻击者。“现有数据无法让我们将该活动关联到任何已知攻击者组织，也无法确定同一操作者是否主导了这两次行动。”它所依赖的工件是植入程序中的 Go 构建元数据，其中包含版本控制哈希、提交时间以及一个表示工作副本有未提交更改的标志——“特定构建的唯一指纹”。据此，样本分为两组，而每组内 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 给客户的指导是常规做法——端点检测与响应、网络检测、威胁情报，以及在非工作时间或通过托管服务进行监控。

纳扎罗夫在新闻稿中的声明用一句话表达了同样的论点：攻击者“使用基于 CyberStrikeAI 的 AI 代理来执行完整的攻击链，并在受入侵的网络内调整其后续步骤”，但“该框架仍然依赖于熟悉的技术和程序，包括发现、凭据转储、横向移动以及收集和外泄”。

哪些是已确立的，哪些不是

直白地说：该机制被记录得足够详尽，足以让防御者明天就能据此展开追踪——来自 sqlservr.exe 的进程血缘、名为 SystemUpdate 的计划任务、通过 comsvcs.dll 访问 LSASS、从非域控制器发起 DCSync、X-Implant-Token HTTP 标头，以及 Kaspersky 列出的 C2 地址。但围绕该机制的攻击活动却并非如此。Kaspersky 未公布受害者名单、国家分布、数据量估计，也未指明攻击者。读者可能想知道的关于谁受到侵害以及侵害程度如何的一切信息，都止步于行业和地区层面。

有两点值得提醒那些前往报告、期望获得更多信息的人。第一，卡巴斯基将该攻击描述为“首批公开描述的涉及真实环境中 LLM 的入侵事件之一”，而非“首例”——这种措辞上的审慎使该说法仅限于团队在公开报道中能够找到的内容。第二，报告指出，植入体的版本并不跟随服务器版本变化；监听器配置与密钥在操作者更新后依然保留；样本的构建日期只能给出最早可能的部署日期，而无法说明入侵持续了多长时间。3–4 天这一数字是对一起已还原事件的测量结果，而非对这些入侵在有人察觉之前持续多久的上限。