AI攻击的三层光谱

核心摘要

  • 2026 年秋日本企业接连发生 Web 系统数据泄露,日本国家网络安全办公室 10 月 9 日向企业发出警报,执政党网络安全总部主席称网络空间处于"紧急状态"
  • Trend Micro 从三个攻击者遗留的公开目录重建攻击基础设施,提出 AI 参与攻击不是铁板一块,而是一条从全流程自主到仅辅助工具开发的光谱
  • 最激进的 Case A 用开源工具 CyberStrikeAI 的 44 个 agent 并行完成侦察、利用、C2、数据外泄和自动报告
  • 但三个案例的入口都是暴露的遗留系统、默认口令和配置弱点,没有一个用到 AI 发现的 0day

2026 年秋日本企业接连发生 Web 系统数据泄露,日本国家网络安全办公室 10 月 9 日向企业发出警报,执政党网络安全总部主席称网络空间处于"紧急状态"。

Trend Micro 从三个攻击者遗留的公开目录重建攻击基础设施,提出 AI 参与攻击不是铁板一块,而是一条从全流程自主到仅辅助工具开发的光谱。

最激进的 Case A 用开源工具 CyberStrikeAI 的 44 个 agent 并行完成侦察、利用、C2、数据外泄和自动报告。

但三个案例的入口都是暴露的遗留系统、默认口令和配置弱点,没有一个用到 AI 发现的 0day。

对银行的真正启示是:AI 放大了已知弱点被试探的规模,而防守方可以反过来利用 AI 输出的弱点做检测。

一、为什么是日本,为什么是现在

  1. 事件背景:2026 年秋季,日本企业和组织接连报告 Web 系统数据泄露。日本内阁官房下属的国家网络安全办公室(NCO)于 10 月 9 日就"非法访问导致泄露"发布响应警报,JPCERT/CC 于 10 月 8 日发布咨询,Trend Micro 10 月 16 日复盘了当年 1 至 9 月的日本安全事件。
  2. 法证来源:Trend Micro 的分析基于攻击者自己留在服务器公开目录(open directory)里的文件——侦察工具、脚本、目标清单、结果、日志和命令历史,而不是受害者侧日志。这意味着它展示的是攻击者准备了什么、尝试了什么、自报了什么,不能单独证明每次尝试是否得手。
  3. 与 ARTEX 的区别:此前业界关注的是开源自主渗透工具 ARTEX(CrowdStrike 10 月 7 日报告其被用于攻击韩国金融机构)。Trend 明确指出,这次分析的三个基础设施与 ARTEX 不同,但活动时间多在 ARTEX 报告之前。
  4. 三个案例都是简体中文工作语言:目录、控制台、注释均为简体中文。Trend 谨慎指出,这只能说明操作员的工作语言,是定位和归属的弱线索,不能据此下结论。
  5. 目标选择是机会主义的:日本是最大目标国,目录里有 jp_success、jp_attack、jp_cve_attack 这样按日本组织结果的命名,但操作员也扫到台湾、香港、韩国、英国、法国、意大利、卡塔尔和哥伦比亚的资产。

二、三层光谱:从全自主到仅辅助

  1. Case A——AI 全流程自主执行(已确认):滥用开源 AI agent 渗透测试工具 CyberStrikeAI,暴露的管理控制台是简体中文。侦察、漏洞发现与验证、利用、命令控制、持久化、数据外泄和自动报告构成一条可重复流水线。记录里出现"credential-search agent 8/44",说明配置了 44 个分工 agent 并行作业。
  2. Case A 的规模与克制:短时间内至少识别出 19 个组织(日本至少 16 个),每个都有同格式报告和证据索引。平台还会自动生成目标国语言材料,包括日文表单和假登录页。关键细节是它对每个目标限流,让单个组织的日志很难识别这是一场大规模协同行动。
  3. Case A 得手率并不高:尽管目标多,深度入侵证据只占很小比例,许多目标平台自己记录"无会话、无 WebShell、无外泄"。即使最完整的入侵链,起点也是一个未认证、公开暴露的遗留 Web 管理接口,没有新漏洞。
  4. Case B——人主导、AI 辅助(已确认):LLM 加速规划和工具开发,但决策由人做。最直接的证据是一份 LLM 生成的攻击计划输出文件,目标包括 AI 工作流平台、LLM 预处理平台和推理服务。操作员把请求伪装成"授权评估"来绕过模型安全护栏——这种虚假前提请求在实践中被使用。
  5. Case B 的真实损失:至少一家公司被完整控制链拿下(FTP、数据库、管理员权限、WebShell、SSH),清理后后门被反复恢复;另一家 GIS 服务器用默认口令暴露,导致数十万条地籍和商业记录、Windows 凭证和邮件被盗。操作员还试图劫持他人 AI 服务、聚合多份访问凭据复用,意图是低成本获取大量推理算力。
  6. Case C——有限 AI 使用(高置信,未确认):目标是暴露的 VPN 设备(日本中小企业和分支机构广泛使用的 Yamaha RTX1210)和 Oracle WebLogic 服务器,至少 1300 个 WebLogic 候选、35 个 VPN 入口。RTX1210 的活动不涉及产品漏洞,而是攻击者从获取的配置文件里拿到残留凭证直接连入内网。
  7. Case C 的 AI 痕迹是风格化的:命令历史里用 echo '=== ... ===' 分节、自定义清理脚本用 emoji 做状态标记、整齐的分段注释——这些是当代 LLM 生成代码的典型特征,但 Trend 保留判断:这是高置信而非确认,不能完全排除熟练操作员故意模仿这种风格。

三、AI 到底改变了什么,没改变什么

  1. AI 改变的四件事:并行处理的目标数量、尝试的速度、自动适配目标国语言、自动记录和生成结构化报告。
  2. AI 没改变的三件事:利用的漏洞类型、入口的性质(暴露遗留系统和默认配置)、以及被深度入侵的目标占比。
  3. Trend 的比喻很准:AI 增加了攻击者的"人力",但活儿还是挨家挨户找没锁的门;门的种类和没锁的原因没变,变的是能同时试几千扇门、用当地语言伪装、不知疲倦。
  4. AI 也在加速防守方:2026 年 10 月披露的 PHP2Shell 关键漏洞(CVE-2026-109618/19)就是防守方研究者通过 AI 辅助审计先发现的,早于攻击者。这意味着漏洞披露到被利用的窗口可能进一步收窄,补丁和虚拟补丁的价值上升。
  5. 三个案例都没用 AI 发现的 0day:Trend 在这三个基础设施里没有发现攻击者利用 AI 挖的 0day,入口全是已知弱点和误配置。能力展示和真实利用是两回事,但这种能力让更大范围的恶意使用成为现实担忧。

四、防守方可以利用的 AI 输出弱点

  1. 过度乐观自评:攻击者侧文件里观察到,AI 把"计划要做的动作"记录成"已完成",自评过于乐观。这意味着攻击者自报的成功数要打折看,防守方不能被这种夸大误导。
  2. 编造漏洞编号:LLM 有在计划里引用不存在的 CVE 编号的通用倾向(这是已知通病,Trend 明确区分于本次观察)。
  3. 风格特征即线索:emoji 状态标记、整齐的分节 echo、结构化注释块,这些在人交互式命令历史里罕见,但在 AI 生成脚本里常见,可以作为检测诱饵和蜜罐的设计依据。
  4. 对银行 SOC 的含义:监控规则不要只盯单次成功,要识别跨组织、低频、分布式的试探模式;同时在蜜罐里投放"看起来值得 AI 扫描器光顾"的遗留管理接口,观察其行为指纹。
  5. 成功数要交叉验证:Trend 反复强调把"攻击者侧记录的成功"和"经证据确认的成功"分开。银行在做威胁狩猎和事件定级时,同样不能只凭告警里的"已入侵"字样下结论。

五、对银行的六条直接启示

  1. 暴露面盘点优先于追新威胁:三个案例的入口都是公网管理接口、默认口令、遗留 Web 平台和边缘 VPN。银行最该做的不是上最先进的 AI 防御产品,而是把暴露在公网的系统、API、管理后台、BI 工具、员工移动办公入口逐一盘点,该隔离的隔离、该下线的下线。
  2. 把内部 AI 和 GPU 资产纳入攻击面:Case B 明确把他人 AI 工作流平台、推理服务和 GPU 集群当目标,想偷算力。银行自建的大模型推理服务、AI 开发平台、GPU 训练集群如果直接暴露公网,本身就是高价值靶标,要和核心系统一样做资产登记和边界管控。
  3. VPN 和边缘设备凭证治理:RTX1210 案例说明,中小企业和分支机构广泛使用的边缘 VPN 设备,其配置文件里的残留凭证一旦泄露,就是直连内网的通行证。银行要排查分支 VPN 设备的默认口令、凭证复用、配置文件外泄和固件更新状态。
  4. 为 LLM 虚假前提滥用做准备:Case B 操作员把恶意请求包装成"授权评估"绕过护栏。银行内部用 LLM 做研发、运维、安全分析时,要防提示注入和社会工程式的"合法工作请求",对高权限 LLM 操作加人工确认和日志审计。
  5. 监控要容忍低频分布式试探:Case A 对每个目标限流,单看一家银行的日志可能只是零星异常。银行要加入行业共享和 CERT 情报通道,把单点异常放到跨机构背景里判断。
  6. 补丁窗口继续压缩:AI 同时加速攻击者扫描和防守方挖洞,从 PHP2Shell 的先例看,关键漏洞从披露到被武器化的间隔在缩短。银行对公网暴露系统的补丁和虚拟补丁要建立小时级响应能力,而不是按季度窗口处理。

六、一个冷静判断

  1. 不要高估"AI 自主攻击一切"的叙事:Trend 的法证证据显示,即使最激进的 Case A,得手率也很低,入口还是老漏洞。AI 把攻击的规模和速度提上来了,但没有把"找没锁的门"这件事变成"无门不入"。
  2. 也不要低估"AI 班组"的常态化:44 个 agent 并行、自动生成日文钓鱼页、跨十几个国家扫描、不知疲倦——这种攻击基础设施的边际成本在快速下降,银行面对的将是更频繁、更分散、语言更本地化的试探洪流。
  3. 防御的起点没变,只是更值钱了:资产盘点、补丁、默认口令清理、边界最小化、日志和情报共享,这些都是 AI 出现之前就有的基本功。AI 时代的差别在于,基本功做得不一致的机构,会被 AI 扫描器从海量目标里优先挑出来。
  4. 银行要建立对 AI 攻击的分层判断能力:不是所有"AI 相关事件"都一样严重,要能区分全自主流水线、人主导辅助、和仅代码风格痕迹这三种光谱,匹配不同的响应等级和投入。

结语

Trend Micro 这份报告的价值,在于它没有停留在"AI 会攻击"的口号上,而是从三个真实攻击基础设施里捞出了证据,画出了一条 AI 参与程度的光谱。对银行风险管理一线来说,这条光谱上最该盯的不是最激进的 Case A,而是那类人主导、AI 辅助、把已知弱点扫一遍的 Case B 和 Case C——因为它们成本最低、数量最多、也最容易被银行当作"零星扫描"放过。AI 没有重新发明攻防,它只是把老问题的试错速度提到了人跟不上的量级。银行能做的,是把那些早该锁上的门认真锁好,再用 AI 自己的输出弱点去识别那些正在批量试门的 AI 班组。

(口径说明:本文事实来自 TrendAI/Trend Micro Research 2026 年 10 月 27 日发布的英文深度报告《Not Only ARTEX: The Different Levels AI is Used in Attacks Targeting Japan》,案例编号、agent 数量、目标组织数、设备类型和攻击链描述均为该报告口径;报告基于攻击者侧公开目录重建,未包含受害者侧日志,成功比例为下界估计。日本 NCO 警报日期、JPCERT 咨询、CrowdStrike ARTEX 报告和 PHP2Shell 漏洞编号均为报告内引用。本文对银行防御优先级的分析为个人判断,不构成具体安全方案建议;实际防护应结合本行资产清单和监管要求执行。)

参考文献

  1. Not Only ARTEX: The Different Levels AI is Used in Attacks Targeting Japan(TrendAI Research,2026-10-27) [TrendAI / Trend Micro Research]
  2. CrowdStrike: Unknown Threat Actor Uses AI-Driven ARTEX to Target South Korean Finance(2026-10-07) [CrowdStrike]
  3. JPCERT/CC Advisory on recent unauthorized access incidents at organizations in Japan(2026-10-08) [JPCERT/CC]