APT45 用 AI 批量验证漏洞：零日攻击门槛正在下降

Sun, 17 May 2026 19:52:39 +0800

Google Threat Intelligence Group 在 2026 年 5 月 11 日发布了新的 AI Threat Tracker。报告里最值得注意的不是“攻击者开始用 AI”这件事本身，而是使用方式正在从辅助写作、翻译、侦察，进入漏洞研究、PoC 验证、恶意代码混淆和自动化攻击编排。

这里有两个容易被混在一起的点，需要先拆开：

第一，Google 说他们首次发现了一个高度疑似由 AI 辅助开发的零日漏洞利用。这个案例来自未点名的网络犯罪团伙，目标是一个流行的开源 Web 系统管理工具，漏洞可在已有账号凭据的前提下绕过 2FA。Google 表示已与受影响厂商协作披露，并可能阻止了一次大规模利用。

第二，APT45 不是这起零日案例的归因对象。GTIG 另行提到，和朝鲜相关的 APT45 被观察到向 AI 模型发送大量重复提示，用于递归分析不同 CVE，并验证 PoC exploit。这说明 APT45 正在把 AI 当成漏洞研究和武器库整理工具，而不是只把 AI 用来写钓鱼邮件。

AI 零日案例说明了什么

这起零日并不是传统意义上最常见的内存破坏、输入过滤缺陷或简单配置错误。GTIG 把它描述为一个高层语义逻辑问题：开发者在认证流程里硬编码了某种信任假设，导致 2FA enforcement 逻辑和例外条件之间出现矛盾。

这类漏洞对传统扫描器不友好。静态分析和 fuzzing 更擅长找崩溃、危险函数、输入输出路径和已知模式。它们不一定能理解“开发者本来想保证什么，却在哪个例外里破坏了这个保证”。

大模型的风险就在这里。它不一定比专业安全研究员更强，但它擅长读上下文、解释意图、比较相似代码路径，并指出“这里的业务逻辑前后不一致”。当这种能力被攻击者接入自动化流程后，原本需要资深研究员长时间阅读的逻辑漏洞，可能更容易被批量筛出来。

GTIG 还提到，这段 exploit 代码里有不少 AI 生成痕迹，例如教育式 docstring、虚构的 CVSS 分数，以及接近教材风格的 Python 结构。Google 同时说明，他们不认为 Gemini 被用于该 exploit，但对攻击者使用某个 AI 模型辅助发现和武器化漏洞有较高信心。

APT45 的变化更值得长期关注

APT45 长期被视为朝鲜相关威胁组织，活动目标覆盖间谍、金融收益和战略情报。GTIG 这次强调的是它使用 AI 的方式：大量、重复、递归地分析 CVE，验证 PoC exploit，并把结果沉淀成更可靠的攻击能力。

这和“让 AI 写一段脚本”不是一个量级。

如果一个组织能把 AI 接入漏洞筛选、PoC 验证、payload 调整和测试环境，那么它的人力瓶颈会改变。过去，一个团队能同时研究多少漏洞，取决于研究员数量、经验和时间。现在，AI 可以承担一部分重复阅读、归纳、变体测试和初步判断，让人的精力更多放在挑选目标、验证可用性和实战投递上。

对防守方来说，这意味着已知漏洞的窗口期会更短。

一个 CVE 披露后，攻击者不需要从零读公告、找补丁 diff、搭环境、改 PoC。AI 可以帮助它更快理解影响范围、生成测试思路、排查失败原因，并把不同目标版本里的细节差异整理出来。即使 AI 生成的结果需要人工修正，它也足以提高整体吞吐量。

这不是“AI 自动黑掉一切”

也没必要把这件事理解成 AI 已经可以独立完成完整入侵。

GTIG 的报告更像是在说：攻击链里的多个环节正在被 AI 加速。漏洞研究、恶意代码混淆、侦察、社会工程、信息操作、移动端 UI 自动化、供应链投毒，都已经出现了 AI 参与的迹象。

但 AI 仍然会犯错。它可能幻觉漏洞、误判可利用性、生成不可运行代码，也可能在复杂企业权限逻辑里迷路。真正危险的地方不是 AI 完美无缺，而是攻击者可以低成本试错。只要大规模尝试足够便宜，一部分错误输出就会被过滤掉，剩下的可用结果会进入攻击流程。

这也是 APT45 这类案例值得关注的原因：国家级或准国家级组织不缺目标和耐心。如果 AI 能把重复劳动压缩掉，它们就能把更多资源投向真正高价值的目标。

防守重点要从“有没有零日”扩展到“窗口期多短”

很多企业过去会把风险分成两类：已知漏洞靠补丁管理，零日漏洞靠纵深防御。但 AI 进入漏洞研究后，这条边界会变得更模糊。

更现实的问题是：

新 CVE 披露后，外部攻击者多久能形成可用 exploit？
企业资产清单能否在同一天告诉你哪些系统受影响？
WAF、EDR、日志和身份系统能否发现异常尝试？
高风险系统是否默认启用 MFA、最小权限和网络隔离？
开源组件、AI agent 插件、第三方连接器是否进入供应链审查范围？

AI 零日不会让基础安全失效。相反，它会惩罚那些基础安全长期欠账的环境。

如果补丁周期很慢，资产清单不清楚，互联网暴露面没人负责，日志不可检索，账号权限长期过大，那么攻击者是否使用 AI 只是效率差异。问题迟早会被撞上。

AI 供应链也成了攻击面

GTIG 报告还提到，攻击者开始关注 AI 软件生态本身，包括 agent 技能包、第三方数据连接器、开源包装库和自动化框架。风险不一定来自模型被“攻破”，而是来自模型周围的工具链被投毒。

这点对使用 AI 编程、AI Agent、自动化插件的人很重要。

一个恶意 skill、一个带后门的依赖、一个过度授权的连接器，都可能让 AI 系统从“帮你做事”变成“替攻击者做事”。当 agent 拥有文件系统、浏览器、终端、云账号或企业数据权限时，供应链审查就不能停留在传统应用层。

至少应该做到：

不随便安装来源不明的 agent skill 和插件。
对能执行命令、读取文件、访问密钥的工具做权限隔离。
生产环境不要直接运行未经审查的 AI 生成脚本。
对 AI 项目的依赖、GitHub Actions、PyPI / npm 包做扫描。
对模型 API Key、云密钥、GitHub Token 做最小权限和泄露监控。

对安全团队的实际建议

第一，把漏洞响应节奏前移。高危 CVE 不能只等月度补丁窗口，尤其是 VPN、网关、系统管理面板、身份系统、CI/CD、远程管理工具这类边界资产。

第二，建立可查询的资产清单。AI 加速攻击的前提是攻击者能快速定位目标；防守方也必须能快速回答“我有没有这类系统、哪个版本、暴露在哪里”。

第三，用行为检测补足签名检测。AI 生成 exploit 或恶意代码可能会改写表面特征，但认证绕过、异常登录、批量探测、失败请求模式、权限提升路径仍然会留下行为痕迹。

第四，把 AI 工具纳入安全治理。内部使用的 coding agent、浏览器 agent、文档 agent、自动化脚本和插件市场，都应该有准入、审查、日志和回滚流程。

第五，不要把 AI 防守只理解成“买一个安全大模型”。真正有用的是把 AI 放进漏洞优先级排序、日志分析、补丁影响评估、代码审查和配置基线检查里，让防守效率也跟上攻击效率。

小结

GTIG 这次报告的信号很清楚：AI 正在把攻防节奏推快。

AI 辅助零日说明，逻辑漏洞和认证绕过这类问题可能更容易被模型发现。APT45 的案例说明，成熟威胁组织已经在用 AI 批量分析 CVE 和验证 PoC。PROMPTSPY、AI 生成混淆代码、agent 供应链攻击则说明，AI 不只是攻击者的聊天工具，而是正在进入攻击工具链。

这不是末日，但也不是普通新闻。

对企业来说，最实际的应对不是恐慌，而是把补丁、资产、日志、身份、供应链和 AI 工具权限这些基础工作做得更快、更清楚、更可验证。AI 会提高攻击者的试错速度，防守方也必须提高发现、判断和修复速度。

威胁情报 on KnightLi的博客