> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# AI 降低了 PLC 攻击门槛：AA26-231A 之后的防御清单
- URL: https://www.hubwiz.com/blog/ai-generated-plc-attacks-aa26-231a-ot-defense/
- Published: 2026-10-16T04:09:47.000Z
- Updated: 2026-10-16T04:22:16.000Z
- Description: 不是新漏洞，是曝光面 + 脚本成本变了。AA26-231A 与水务 MicroLogix 事件：AI 把"会说工业协议"的稀缺技能打平了，防御要做结构性控制。
- Author: admin
- Tags: PLC 安全, OT 安全, 工业控制, Siemens S7, 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 生成的利用脚本"；对防御者更重要的事实是：**公告没有披露任何新漏洞**。

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

1. **发现**：行为者使用 Censys、ZoomEye 等互联网扫描服务，寻找**暴露在公网、或防护不足且运行过时软件**的 PLC；
2. **生成**：把目标数据喂给 AI 工具，生成可工作的 Python 脚本——使用开源的 **snap7 / python-snap7** 库；
3. **伪装**：脚本**冒充合法的监控软件**，混入正常的工程流量；
4. **访问**：通过 **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 条**。同样地，这些计数只表示"互联网上可匹配到指纹的服务"，不保证控制着真实过程、也不表示接口没有认证；其中会混有测试系统、演示实例和厂商文档。但网关的定位决定了风险量级：**它从控制设备读数据、也向控制设备写数据，持有描述物理过程的标签、每个控制器的连接信息，往往还有到达它们的凭据**，而远程支持访问常常被开启。**为可靠运行而设计的系统，不一定为暴露在公网而设计。**

## 五、工程侧要做的六件事

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

1. **把 PLC 从公网直接暴露中拿掉。** 102 端口永远不应该从公网可达；远程维护走**经过认证、被监控的通道**。控制器到不了公网，扫描服务就扫不到它。
2. **分割 OT 与 IT。** 按照 **IEC 62443** 的原则隔离生产网络与企业、云环境。
3. **盘点并分类控制器**，**包括遗留型号**。没有清点过的设备无法保护——这在水务场景尤其重要，因为泵房和远程站点常年在"网络地图之外"。
4. **强制认证、更换默认口令。** 大量设备出厂就是弱认证甚至无认证，这些口令会让暴露的代价进一步降低。
5. **监控异常的工业协议活动。** 先给正常的工程流量建立基线，再对偏差告警——尤其是来自意外主机的连接、异常的读取模式、对梯形图的写操作。**在没有 IOC 的公告里，行为基线就是检测本身。**
6. **为无法打补丁的硬件规划退役。** 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](https://tia.hubwiz.com/tia-context?utm%5Fsource=blog&utm%5Fmedium=article&utm%5Fcampaign=ai-generated-plc-attacks-aa26-231a-ot-defense) 就是按这个定位做的：程序图谱通过 MCP 提供给智能体，AI 拿到的是**可核对的查询结果**，配合人工复核使用。
- **写入操作**：创建块、改硬件组态、批量迁移。要让 AI 碰工程，就必须有**预演（dry-run）、编译检查、仿真验证与出错回滚**——改动的每一步在博途中执行、由人决定是否保存。这正是 [TiaLink](https://tia.hubwiz.com/tia-link?utm%5Fsource=blog&utm%5Fmedium=article&utm%5Fcampaign=ai-generated-plc-attacks-aa26-231a-ot-defense)（博途 MCP 网关）把"预演—验证—回滚"作为设计前提的原因，也是把攻击面（以及误操作面）压到最小的工程做法。

一句话：**给 AI 的权限，应该和给人的权限一样受控**——范围、审批、留痕，一个都不能少。这和我们在[《九起真实事故，六项控制》](https://www.hubwiz.com/blog/agent-security-nine-incidents-six-controls/)里复盘过的 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 为在来源基础上的整理。

## 延伸阅读（本站）

- [AI × 工业 / PLC 完全指南](https://www.hubwiz.com/blog/ai-industrial-stack/)
- [九起真实事故，六项控制：AI Agent 的凭据、身份与供应链](https://www.hubwiz.com/blog/agent-security-nine-incidents-six-controls/)
- [接手别人的 PLC 程序：动第一行代码前的 4 步取证](https://www.hubwiz.com/blog/taking-over-legacy-plc-program-4-steps/)
- [没有硬件也能练 PLC：Factory I/O + OpenPLC + Modbus TCP 虚拟实验台](https://www.hubwiz.com/blog/virtual-plc-lab-factory-io-openplc-modbus-tcp/)
- [AI 正在改变 PLC 编程：哪些真能用，哪些还是噱头](https://www.hubwiz.com/blog/ai-transforming-plc-programming-what-works/)

工具入口：[TIA-CONTEXT](https://tia.hubwiz.com/tia-context?utm%5Fsource=blog&utm%5Fmedium=article&utm%5Fcampaign=ai-generated-plc-attacks-aa26-231a-ot-defense) ｜ [TiaLink](https://tia.hubwiz.com/tia-link?utm%5Fsource=blog&utm%5Fmedium=article&utm%5Fcampaign=ai-generated-plc-attacks-aa26-231a-ot-defense) ｜ [TIA Forge 总入口](https://tia.hubwiz.com/tia-forge?utm%5Fsource=blog&utm%5Fmedium=article&utm%5Fcampaign=ai-generated-plc-attacks-aa26-231a-ot-defense)

> **这是「AI × 工业 / PLC」专题的一部分。**完整地图见：[AI × 工业 / PLC 完全指南](https://www.hubwiz.com/blog/ai-industrial-stack/)