PLC 安全

AI 降低了 PLC 攻击门槛：AA26-231A 之后的防御清单

不是新漏洞，是曝光面 + 脚本成本变了。AA26-231A 与水务 MicroLogix 事件：AI 把"会说工业协议"的稀缺技能打平了，防御要做结构性控制。

一句话结论：2026 年最值得工业工程师读的两份安全材料，讲的都不是"新漏洞"。7 月，FBI 与 EPA 联合公告警告针对水务系统 MicroLogix 1100/1400 的攻击活动，攻击者改变了密码、IP 和梯形图，造成真实的水压下降与溢流；8 月，NSA、CISA、FBI、能源部、EPA 五部门联合公告 AA26-231A 首次明确：威胁行为者正在使用 AI 生成的脚本攻击西门子 S7 系列 PLC。西门子确认这不是产品新漏洞，公告指向的是配置弱点与暴露面。要记住的结论只有两句：攻击成本在下降，防御必须转向结构性的"可达性控制"；以及公告里最容易被忽略的一句——给 AI 或自动化工具任何权限时，要有人工审批与完整审计日志。

本文完整编译自三份来源（见文末），数字与引述以来源为准。

一、AA26-231A：一份"不是补丁公告"的联合公告

2026-08-19，NSA、CISA、FBI、能源部（DOE）与 EPA 联合发布网络安全公告 AA26-231A，警告针对西门子 S7 系列 PLC 的侦察活动。让新闻上头条的是"AI 生成的利用脚本"；对防御者更重要的事实是：公告没有披露任何新漏洞。

公告描述的链路并不复杂：

发现：行为者使用 Censys、ZoomEye 等互联网扫描服务，寻找暴露在公网、或防护不足且运行过时软件的 PLC；
生成：把目标数据喂给 AI 工具，生成可工作的 Python 脚本——使用开源的 snap7 / python-snap7 库；
伪装：脚本冒充合法的监控软件，混入正常的工程流量；
访问：通过 S7comm 协议（通常是 TCP 102 端口）获得对 PLC 内存、配置数据和梯形图的读写能力。

公告点名的受影响产品范围很宽：S7-200、S7-300（含 314、315、317）、S7-400、S7-1200（CPU 1211C、1212C、1214C、1215C、1217C）与 S7-1500 系列，包括 F 系列安全控制器。机构评估这是一次持续性侦察——用于发展能力、为潜在的运营影响做准备。被列为重点目标行业的包括：关键制造业、能源、水务与污水处理、化工、食品与农业、商业设施。

SIEMENS 的回应值得完整读一遍：公告不描述 S7 系列的新漏洞，指出的是配置错误与暴露面；S7comm 在很多设备上历史性地缺乏认证；公司请客户参考 ProductCERT 公告 SSB-104599，落实软件更新、受保护网络、强密码与型号相关的加固文档。

这段回应直接改变防御姿势：不存在一个"一装就好"的补丁。公告引用的是"已知漏洞、配置错误与其他弱点"，而不是生产线上的共同缺陷。去找缺失的固件版本，不如去减少可达性——时间花在前者，就是没花在后者。

二、水务系统事件：当攻击后果是物理的

另一条线与 AA26-231A 相互印证。2026-07-30，FBI 与 EPA 发布联合产品安全公告 I-073026-PSA，针对水务与污水处理系统的攻击活动；事件自 7 月 27 日起被上报，至少覆盖 7 个州（不同来源的统计口径不一）。公告直接点名目标类别：Rockwell Automation / Allen-Bradley 的 MicroLogix 1100 与 1400 系列 PLC。

这类紧凑型控制器用于泵站控制、阀门调度和维持管网平衡的本地逻辑，装在泵房、提升泵站和远程站点——这也正是它们挂在蜂窝链路上、或待在小型远程机房、而不是放在加固数据中心里的原因。
公告的核心发现与"精妙的漏洞"无关，而是"位置"：暴露在互联网上的控制器，其原生工业协议可直接被访问，攻击活动进行的是规模化扫描。
已上报的运营后果是物理的：水压下降，部分案例的逻辑被篡改后发生溢流。供水系统失压的后果超出不便——压力损失为污染物进入配水系统创造了条件，公用事业公司因此发布"煮沸饮用水"（boil-water）通知。
后续报道描述的手法混合了机会性扫描与蓄意操纵：识别暴露控制器后，修改设备密码与 IP 地址、切断监控（SCADA）系统、部分案例中修改了梯形图——也就是决定设备行为的那段程序。扫描使用了多个协议，包括与 Modbus 相关的端口以及 502、102、44818 等工业协议端口。
还有一个容易被忽略的身份线索：报道描述攻击者通过 SSH 到达蜂窝调制解调器。也就是说，入侵点落在承载控制流量的通信基础设施上，而不只是控制器本身。拿到调制解调器的人，可以观察并塑造 SCADA 层看到的一切。

配套的资金数字也值得一提：EPA 宣布通过饮用水基础设施韧性专项，向 6 个州、10 个项目投入 1175 万美元。水务运营商是资源最紧张的关键基础设施群体之一，很多小水厂只有个位数的 IT/OT 人员。协调攻击能尝试的事情，与小水厂能防住的事情之间的差距，不是技术差距，而是资金与人力差距——补助是慢慢弥合它的机制。

三、为什么"AI 生成脚本"改变了成本结构

这一节来自对 AA26-231A 的专门解读。公告把 AI 定位为行为者能力的一次演进，而不是一个自主攻击者：目标识别、意图确认、下达物理过程指令，仍然是人的决策。真正变的是造工具的成本与速度。

历史上，要开发一个可靠的 PLC 交互工具，需要三种重叠技能：工业协议知识、漏洞开发能力、对特定过程环境的熟悉。这个组合很稀缺，开发周期以周计。而现在，一个行为者只需要把设备型号、固件版本、开放端口交给语言模型，就能拿到一份基于 snap7 的、可工作的 Python 脚本——时间线被大幅压缩，三种技能里直接去掉了一种。

更麻烦的是伪装：当攻击工具说的是同一种协议、用的是同一个库、发出的是和授权监控程序一样的读操作时，基于签名的检测就失效了。公告给出的一个具体信号是"在未经批准的系统上使用 snap7.dll"：一家不用 snap7 的 SCADA 工厂，如果在 102 端口观察到 snap7 流量，就应当按失陷指标（IOC）处理。更一般地说：行为基线比签名更重要。

同样值得注意的是公告没有给的东西：没有 CVE 编号、没有 IOC 列表。这意味着检测不能依赖"比对一份已公布的 IOC 清单"，而要靠对异常 S7comm 活动的监控——不寻常的读取模式、意料之外的对梯形图的写操作、来自陌生来源的连接。

四、暴露面数据：这些数字该怎么读

AA26-231A 的解读文章引用了一组 ZoomEye（网络空间测绘）计数，抓取自 2026-09-16：

查询	结果
`app="Siemens S7"`	173
`app="Siemens SIMATIC"`	10,160
`port="102"`	161,764
`device="plc"`	95,395

这些数字必须小心阅读：102 端口的计数描述的是"在 S7comm 相关端口上可达的服务"，不是"确认的西门子控制器"，更不是"确认存在漏洞的设备"；device="plc" 覆盖所有厂商；产品指纹计数描述的是被索引到的产品资产，不是可被利用的实例。它们真正说明的事情只有一件：相关的协议暴露面足够大，"降低可达性"是一项有意义的控制，而不是纸上谈兵。

同一批来源还提供了另一组对照：Ignition 网关（制造业、公用事业和楼宇系统常用的 SCADA 平台）在 2026-10-07 的测绘结果为 app="Ignition" 5,037 条、title="Ignition Gateway" 3,146 条。同样地，这些计数只表示"互联网上可匹配到指纹的服务"，不保证控制着真实过程、也不表示接口没有认证；其中会混有测试系统、演示实例和厂商文档。但网关的定位决定了风险量级：它从控制设备读数据、也向控制设备写数据，持有描述物理过程的标签、每个控制器的连接信息，往往还有到达它们的凭据，而远程支持访问常常被开启。为可靠运行而设计的系统，不一定为暴露在公网而设计。

五、工程侧要做的六件事

防御响应是"降低暴露、控制访问"，而不是等一个可能不会来的补丁。把三份来源的建议合并起来，是这六条：

把 PLC 从公网直接暴露中拿掉。 102 端口永远不应该从公网可达；远程维护走经过认证、被监控的通道。控制器到不了公网，扫描服务就扫不到它。
分割 OT 与 IT。 按照 IEC 62443 的原则隔离生产网络与企业、云环境。
盘点并分类控制器，包括遗留型号。没有清点过的设备无法保护——这在水务场景尤其重要，因为泵房和远程站点常年在"网络地图之外"。
强制认证、更换默认口令。 大量设备出厂就是弱认证甚至无认证，这些口令会让暴露的代价进一步降低。
监控异常的工业协议活动。 先给正常的工程流量建立基线，再对偏差告警——尤其是来自意外主机的连接、异常的读取模式、对梯形图的写操作。在没有 IOC 的公告里，行为基线就是检测本身。
为无法打补丁的硬件规划退役。 S7-300 和 S7-400 无法靠补丁解决；隔离或替换是唯一持久的答案。

补充：IEC 62443 的"分区与通道"到底在说什么

第 2 条里的 IEC 62443 经常被当成一句口号，其实它说的是很具体的结构：把系统按安全等级和功能划成若干分区（zone）（比如现场控制层、监控层、企业层），分区之间只保留必要的通道（conduit），并在通道上做访问控制与监控。一个控制器能发起的通信越少，被横向移动利用的面就越小。

对 PLC 现场而言，落地方式通常是：控制层只与它真正需要的设备通信；远程维护不直连控制器，而经过跳板/网关与审批；企业网与生产网之间的通道做白名单与日志。听起来笨，但这类结构性工作没有"发布日期"，也就没有"过期"一说。

接下来的 30 天，值得做这三件最不舒适也最有用的事：

画出哪些控制器有任何一条通往外部的路由——包括通过蜂窝调制解调器、远程访问网关和厂商支持链路的间接路径。这场演习之所以重要，是因为攻击活动依赖的是可达性，而不是某个特定漏洞。
更换每一台有口令的控制器的凭据，并停止把控制器所在的网络当作"隐含可信"。
隔离不了的地方，在前面放一个监控点，对配置变更、口令变更和逻辑下载告警——这些是物理后果发生之前的事件。

六、为什么 OT 世界很难靠补丁解决

把前五节压成一句工程现实：OT 的补丁节奏天生比 IT 慢。

生产线不能随时停；补丁窗口要和检修、排产、验收一起排；
大量 PLC 的固件更新需要停机与重新验证，不是"重启一下"；
老设备（S7-300/400 这一代）没有可用的修复补丁；
而公告本身也说了：根因不是某个产品缺陷。

这带来一个反直觉的结论：在 OT 里，"等官方修复"往往不是一个可行的安全策略。可行的策略永远是"减少可达性 + 收紧权限 + 可观测"。这也解释了为什么第 5 节的六条建议里，有五条与补丁无关。

七、把六件事落到角色上

角色	先做什么	交付物
资产管理	清点所有控制器与网关（含遗留、含远程站点）	资产清单：型号、固件、网络位置、负责人
网络	画可达性路径，分区与通道落地	网络分区图 + 外连路径清单（含蜂窝/远程支持）
工程	更换默认凭据；评估无法升级设备的替代/隔离	加固记录；退役/替换计划
监控	为正常工业协议流量建基线，配置告警	基线报告；对配置/口令/逻辑下载的告警规则
管理	把资金与人力缺口摆上台面（参考 EPA 补助思路）	有优先级的整改预算与时间表

八、公告里最容易被忽略的一段：AI 智能体进工程环境

CISA 在这轮建议中加入了一条 OT 专属的内容，值得单独拎出来：

当 AI 智能体或自动化工具获得对工业系统的任何权限时，要要求人工审批与完整的审计日志——因为对过程控制的自主更改，恰恰是操作员不能"事后才发现"的那类动作。

这条建议可以反过来用在工程侧。AI 进入 PLC 工程，有两种完全不同的定位：

只读理解：解析工程、建立交叉引用、回答"谁调用了这个块""改这个变量会影响什么"。这类查询不改变工程，风险面小得多——TIA-CONTEXT 就是按这个定位做的：程序图谱通过 MCP 提供给智能体，AI 拿到的是可核对的查询结果，配合人工复核使用。
写入操作：创建块、改硬件组态、批量迁移。要让 AI 碰工程，就必须有预演（dry-run）、编译检查、仿真验证与出错回滚——改动的每一步在博途中执行、由人决定是否保存。这正是 TiaLink（博途 MCP 网关）把"预演—验证—回滚"作为设计前提的原因，也是把攻击面（以及误操作面）压到最小的工程做法。

一句话：给 AI 的权限，应该和给人的权限一样受控——范围、审批、留痕，一个都不能少。这和我们在《九起真实事故，六项控制》里复盘过的 Agent 安全控制是同一套逻辑，只是这次对象换成了 PLC。

九、怎么读一份"不是补丁公告"的公告

最后是一条方法论，比任何单条控制都耐用：

看它有没有 CVE 和 IOC。 都没有，说明根因是暴露面与配置，响应就是架构与配置工作——这些工作没有"发布日期"。
看厂商怎么回应。 西门子说"不是新漏洞、看加固指南"，那就别去找根本不存在的固件。
看攻击成本是否被技术压缩。 AI 生成脚本的意义不是"机器人自己攻击"，而是把一项稀缺技能变成可复制的脚本。防御要针对的是技能门槛下降后的"更多人"。
看物理后果。 水压下降、溢流、煮沸通知——OT 安全最终要落到"过程有没有被改变"上，而不是"有没有告警"。
看建议里有没有"人"的部分。 这轮公告把"人工审批 + 审计日志"写进了 OT 建议，说明自动化工具在工业环境里的权限治理，已经进入主流安全框架。

十、Q&A

Q：我的 PLC 不在公网上，是不是就没事？ 不一定。水务事件里的入口包括蜂窝调制解调器和远程支持链路——"不在公网"要看的是完整路径。第三节说的 30 天动作，第一件就是把间接路径画出来。

Q：Siemens 说不是新漏洞，那我该装什么补丁？ 没有"针对性补丁"。按公告指引做加固与分段、保持受支持版本与安全更新（ProductCERT/SSB-104599 方向），重点在曝光面与配置，而不是等一个不存在的修复。

Q：用开源库（snap7）做正常的工程集成有问题吗？ 库本身是合法的开源工具，公告针对的是未经批准的用途。工程上要做的是：只允许批准的系统使用它，并可观测、可审计；如果现场观察到不该出现的 snap7 流量，按 IOC 处理。

Q：AI 完全不能用来做 PLC 工程吗？ 可以，但要把权限分清楚：只读查询风险低；写操作必须有预演、验证与回滚，且最终保存由人决定。这与"给人类工程师的权限要分级"是同一个原则。

十一、小结

两份公告、一个月的时间差，说的是同一件事：攻击的入口不是漏洞，而是暴露面；让局势变化的是脚本成本，而不是某个新缺陷。工程侧能做的，是把 PLC 从公网上拿下来、把 OT 与 IT 分开、把资产盘点清楚、把认证和默认口令管起来、把异常协议流量看出来、把补不上的硬件安排好退役；并在这两条线之外，给 AI 工具划定和人类工程师一样清楚的权限与审批边界。

真要说一句话给管理层：我们不需要一个新的安全产品，我们需要一张可达性清单、一套分段与权限规则、和一份能记录"谁在什么时候改了什么"的审计日志。

参考来源与口径

@onaeiuspkz《The Advisory That Was Not a Patch: Reading AA26-231A and the AI-Assisted Reconnaissance of Siemens S7 PLCs》，dev.to，2026-09-16（含 ZoomEye 计数，抓取于 2026-09-16）。
@bianliang《When AI Lowers the Bar for Industrial Attacks: Defending OT in the Age of Generated Exploits》，dev.to，2026-09-19（含对 AA26-231A 与 Siemens ProductCERT SSB-104599 的解读）。
@onaeiuspkz《The FBI and EPA Warning on Water-Sector PLCs: What the MicroLogix Campaign Exposed》，dev.to，2026-10-03（含 FBI/EPA 公告 I-073026-PSA、事件时间与 EPA 资金信息）。
@jeffreyciend《Ignition gateways: 5,037 application matches and 3,146 titles on an industrial control platform》，dev.to，2026-10-13（含 ZoomEye 计数，抓取于 2026-10-07）。
本文为上述来源的完整编译与中文整理；公告编号、机构、时间与测绘数字均以来源文章为准，本文未做独立复测，也不构成任何攻击方法的教学。防御建议已合并去重并保留出处；IEC 62443 分区说明、角色分工表与 Q&A 为在来源基础上的整理。