前阵子圈子里传得最凶的一个词是“AI打PLC”。一开始我以为是标题党直到自己参与的几个制造业客户在流量里截到了自动化扫描和异常协议报文才意识到这不是科幻片——黑客利用AI把工业设施当靶子西门子PLC成了被点名最多的目标。这篇文章聊聊我看到的东西以及防守方应该怎么接招。如果你在工厂管PLC、做自动化项目或者正好负责生产网的安全这篇文章都值得看完。它不讲空泛的大道理只讲三件事为什么工业设施会成靶子、AI在攻击链里具体干了什么、我们现在能做什么防护。1. 为什么工业设施成了AI攻击的新靶子1.1 设备联网把“信息孤岛”变成了“暴露面”以前PLC是真正的孤岛它与上位机之间用串口或现场总线物理上谁也别想远程碰。但近几年数字化改造很多工厂把PLC、HMI、变频器、传感器都接进了一个以太网再通过网关把数据推到MES、SCADA甚至云平台。联网带来效率也带来一个老生常谈但总被忽略的事实设备之间的信任关系被直接映射成了网络可达性。任何能从办公网摸到网关的人都有机会继续往里走。我见过不少现场PLC网段和办公网只用一台普通的交换机隔开甚至干脆共用一个VLAN。安全工程师去看项目文档发现网络拓扑图上面画着一道“防火墙”实际到现场一看那道防火墙是千兆家用路由器规则里有一条“允许所有”。这不是段子是我在真实调研里经常遇到的情况。举一个具体例子一套冷库监控系统跑在西门子S7-200 SMART上通过一个边缘网关把温度、压力、压缩机状态上传到云端管理平台。运维觉得这个网关很重要于是放在办公网内而网关又同时连着PLC网和云。结果就是只要有人攻破办公网里任意一台电脑就有机会顺着网关摸到PLC。类似的结构在食品、冷藏、市政等领域非常常见。1.2 西门子PLC为什么被反复点名几年前做工控安全宣讲我还会被问“黑客为什么不去偷银行数据要来打工厂”。现在没人问了因为答案太明显生产网的入口比很多人想象的更容易摸到而西门子PLC正好站在那个入口的正中央。西门子被点名有四个现实原因。市场份额太大。汽车、化工、食品饮料、制药、市政这些行业里西门子控制系统的占比非常高。攻击者只要研究一套手法就能覆盖大量工控现场这种“单点投入、多点复用”的性价比在AI加持后更加明显。协议历史包袱太重。S7家族最早的设计目标是可靠、实时并没有把安全考虑进去。S7comm基于102端口大量报文以明文传输Modbus TCP就更直接502端口、功能码一目了然几乎没有加密和认证机制。攻击者不需要破解什么东西只要网络能通所有控制指令都是“明文裸奔”。设备代差太大。S7-1500好歹有密码和访问级别但现场大量还在用的S7-200 SMART、S7-300几乎没有内置安全机制固件更新早就停了。这些老设备在5G、边缘计算改造中又被拉上以太网相当于把二十年前的门锁装在了今天的大街上。研究样板太多。公开安全大会上这些年展示过很多针对西门子协议的破解研究十几年前那次著名的工业控制系统攻击事件让S7系列第一次成为全球安全研究的焦点。攻击者不需要从零开始检索就能拿到思路和现成工具。提醒不要因为PLC有密码就觉得万事大吉。很多现场的项目交付文档里写着PLC密码“12345678”TIA Portal访问级别也保持默认。安全评估里最有效率的一项工作就是去试默认口令。1.3 AI让“破坏生产”而不是“偷数据”变成了主流目的工控攻击的目的和IT攻击不一样重点不在数据的机密性而在工艺过程的安全性。攻击者通过改变设定值、强制输出、触发停机可能让一套装置反复启停甚至让一台大型设备飞出指标范围。传统观点认为这种攻击需要深度工控知识但AI把门槛打下来了它能帮你读懂协议文档、生成报文、分析抓包结果、规划攻击步骤。换句话说过去这种攻击是少数专家才能干的事现在一个懂基本网络渗透的人加上AI工具也能拼出一条可行链路。一个例子十字路口红绿灯PLC程序平时看起来毫无价值但一旦被远程改写红绿相位错乱直接影响公共安全。攻击者不一定懂交通控制逻辑但AI能帮他分析程序块和寄存器映射把“绿灯一直亮”这种效果拼出来。这种物理后果比数据加密勒索更麻烦。2. AI在攻击链里到底扮演什么角色2.1 指纹识别和目标画像AI让测绘快到离谱攻击者进入网络后第一件事是搞清楚“网里有什么”。人工扫描需要逐段逐IP去试再靠抓包经验识别设备型号。AI辅助可以自动抓取多个IP的响应特征和公开指纹库比对自动给出设备类型、厂商、固件版本、开放端口、使用的协议。对S7系列来说ISO-on-TCP握手包里的TSAP信息能帮助区分S7-1200/1500/300/400AI还能根据响应时间、端口分布进一步归类。这不是说AI有某种超能力而是说它把重复劳动压缩了。原来一个人坐在电脑前敲命令、翻输出、整理清单几小时的活AI在几分钟内就能完成还能自动生成一份带优先级的备选目标列表。对防守方来说这意味着OT网络里的任何扫描行为都要当回事哪怕只是几个探测包。很多攻击者第二步就会去确认S7设备的102端口是否开放或者Modbus TCP的502端口是否有响应。下列端口经常出现在OT网段的设备指纹里协议常见端口典型用途S7comm102西门子PLC通信、程序上下载Modbus TCP502通用工业协议大量从站设备OPC UA4840数据采集、跨平台通信PROFINET34964/34962/34963实时IO通信、设备发现2.2 漏洞挖掘和协议分析从研究员专属到自动化流水线过去针对HMI、OPC UA服务器、S7协议栈的漏洞挖掘需要研究者写大量fuzz脚本分析崩溃样本手工逆向固件。AI把其中一部分流水线化了用模型自动生成畸形报文输入用覆盖率反馈选取下一次变异方向再用工具自动清洗崩溃日志。固件逆向方面AI辅助识别函数边界、字符串、危险调用链的能力越来越强。这一段的防御含义是你不应该假设自己买的设备“够老所以没人研究”。恰恰相反越老越成熟的协议栈越容易被自动化工具批量测试一旦某个公开的固件漏洞被找到并在网上放出分析攻击者用AI很快就能把概念验证变成可用的检测模块。另外请注意攻击面不只在PLC本体还包括与PLC联动的设备西门子200 SMART和变频器之间的通信、S7-1500与库卡机器人的交互、数控系统的调试存档、OPC UA服务器节点本身。AI把这些都当作“可编程接口”任何一层出问题都可能影响生产链路。2.3 载荷生成与代码编写攻击脚本进入“生成式”时代现在的大语言模型可以直接根据一段协议文档生成调用代码。例如让AI写一个连接Modbus TCP服务器、批量读取保持寄存器、然后写入指定数值的脚本几分钟就能得到可运行的结果。它甚至能帮攻击者生成看起来像正常操作的流量模式比如模仿上位机的轮询节奏降低被检测系统怀疑的概率。防守难点在于传统基于签名的检测面对AI生成的变体很吃力。同一个功能AI能生成几十种不同的报文组合和代码写法每种看上去都是合法协议操作。所以检测不能只看“这个包有没有攻击特征”而要学会看“这个通信行为是否偏离了这台设备的日常模式”。以OPC UA为例老一代安全设备看到的是“有没有人用匿名账号连入”AI思路则会进一步看“这个账号在什么时间点、访问了哪些节点、写了哪些值”。后者明显更接近真实威胁。2.4 社工情报和定向投递AI写钓鱼比人更勤快OT网络再封闭总有人要收邮件、看供应商通知。AI让钓鱼邮件的质量和成本都变了它可以模仿西门子技术支持的口吻生成补丁升级通知可以生成带宏的Excel清单可以针对具体项目名称做定制化内容。一次设计得好的社工可能比花几个月研究0day更有效。对防守方来说邮件网关要有但更重要的是告知运维人员“供应商不会通过邮件附件让你直接导入PLC程序”。我看到太多工厂把厂商官方论坛、QQ群分享的程序模板直接下载到工程师站这是一个非常现实的供应链入口。AI生成文件的能力越强这种“工程师主动引入风险”的场景就越值得重视。3. 一条典型攻击路径的防守视角还原我写这部分的目的很明确不是说怎么攻击而是告诉你该在哪个环节设卡。攻击者每一步都有特征关键是防守方有没有监控到。3.1 边界突破办公网到OT网的那道门典型第一击并不在PLC上而在办公网或远程接入侧。攻击者可能通过钓鱼获得一个办公账号然后横向移动寻找能通向生产网的通道。这个通道可能是运维工程师的双网卡电脑可能是远程维护平台也可能是某个边缘网关。防守重点办公网和生产网的边界策略要清楚尤其是远程维护通道。通道本身要开但必须是白名单式的只允许维护供应商的固定IP、固定时间段、固定账号接入每次接入都有会话审计记录。如果你看到某条维护通道在凌晨两点建立连接、并开始大量访问PLC网段这本身就是一个强信号。3.2 内网侦察AI如何快速定位PLC一旦进入OT网段攻击者会先做轻量扫描。除了ARP扫描找在线主机最重要的是探测102端口确认S7设备探测502端口确认Modbus从站。攻击者还可能通过Modbus功能码读取设备标识或者用S7协议的通话建立请求来拿到PLC类型。AI在这里能做的是把侦察结果自动整理成“攻击地图”哪个IP是PLC、哪个IP是HMI、哪个IP看起来不上不下像网关。防守侧建议在核心交换机上做镜像对OT网络里的扫描行为建立独立告警不要和生产业务的普通噪音混在一起。很多老工程师会说“业务正常运行怎么会有扫描”其实只要你把镜像流量抓下来跑一遍往往能发现意料之外的IP在到处探测。3.3 指令注入Modbus、S7comm与OPC UA三种常见手法这是攻击链里最关键的一环也是防守方必须看懂的环节。下面列出的功能码和操作本身并不可疑因为它们是自动化系统的日常工作。真正可疑的是“谁在做、从哪里做、做什么范围、是否符合基线”。协议常见端口常见危险操作防守要点Modbus TCP502写单个线圈、写单个寄存器、写多个线圈、写多个寄存器白名单功能码、限制寄存器地址范围S7comm102启动/停止PLC、上传/下载块、强制变量限制源IP、监控停止指令和强制指令OPC UA4840读取/写入标签尤其是匿名访问时禁止匿名账号、设置节点读写权限以Modbus TCP为例攻击者不需要知道任何密码只要网络可达、功能码正确就能向保持寄存器写入数值。如果我要监控重点就不是“写寄存器”这个动作而是某个从未见过的IP开始往原本只跟上位机通信的PLC持续写入。把“正常的轮询写值”和“异常的批量写值”分开是工业DPI最核心的能力。S7comm的停止指令更关键很多S7-1500厂房不允许外部随便STOP但攻击者通过合法会话就有机会做到。现场工程师最熟悉的“CPU在STOP和RUN之间反复切换”现象有可能不是硬件故障而是有人在利用协议控制指令。3.4 潜伏与后门比攻击更麻烦的残留风险攻击者一旦拿到PLC的控制权可能不只是做一次破坏而是会留下长期后门。比如在S7程序里插入一个条件触发的功能块或者通过OPC UA服务器创建新的隐藏节点甚至在HMI脚本里埋坑。这些后门平时不发作选在关键时刻动作。防守建议对高频变化点保持敏感。有条件的企业每次停产检修时做PLC程序比对计算程序块的哈希或比对源文件至少记录下组态软件的上传时间和操作者。很多攻击都怕“现场有人较真”哪怕只是每月做一次程序备份和比对都能大幅提高攻击成本。4. 防守方该做的四件实事4.1 资产盘点先知道自己家里有什么老话重提但真正做扎实的工厂不多。一个网段里哪些IP在线、哪些是PLC、哪些是HMI、哪些是历史数据库服务器必须先搞清楚。可以借助扫描工具也可以用更保守的方式翻开项目图纸对照交换机端口再结合上位机的组态信息逐台确认。最重要的是记录每台PLC的型号、固件版本、开放端口、程序修改时间。这是后续一切检测和响应的数据底座。建议输出一张资产台账至少包含设备名、厂家型号、IP、固件、使用协议、所属工段、上次程序备份时间、负责工程师。如果没有这份表后续白名单和异常检测都无从谈起。4.2 网络白名单把可通信范围锁到最小在OT网络里做严格的TCP/IP白名单非常有效但一定要设计成“最小必要”。具体做法确定上位机、HMI和PLC之间必须通信的IP、端口、协议方向在工业防火墙上按“源IP、目的IP、端口、协议功能码”组合放行其他全部拒绝。例如生产控制只允许工程师站通过102端口访问S7-1500不允许普通办公IP直连PLC。这里必须提个醒白名单规则一定要先在旁路镜像环境验证否则可能把合法的组态下载、HMI画面刷新、OPC UA连接全部挡掉。我见过不少项目因为上线第一周把自己锁死被迫“紧急开放全通”安全策略等于废纸。宁可花两周时间慢慢收敛规则也不要一天之内把所有端口全部封死。4.3 设备硬化密码、固件与访问级别针对S7-1500可以在TIA Portal的设备视图里设置“保护与安全”访问级别至少做到启用密码保护访问级别设为“仅允许使用密码访问”禁止未知设备访问。但必须清醒这不加密网络报文。攻击者通过网络层的指令注入依然可能绕开组态工具层面的认证。S7-200 SMART这类老设备没有内置加密机制唯一的有效手段就是网络隔离和流量白名单。如果业务必须让它上以太网一定要在它的前面加一道独立的隔离设备不要把它和办公网放在同一个网段。固件升级要单独说升级前一定要备份程序和组态并在试验台上验证与新固件的兼容性。生产环境不建议“有新固件就升”很多工厂就是在升级后出现了通讯延迟、模拟量漂移等问题反而把系统推到更危险的状态。4.4 检测响应从“看流量”到“看懂工艺”检测的核心不是抓恶意软件的指纹而是建立正常行为基线。具体可落地的几类通信基线哪些IP之间允许通信、频次多少、包大小多少。功能码基线某个PLC多久执行一次写操作写的寄存器范围是什么。工艺参数基线关键模拟量在正常运行区间的分布例如温度、压力、速度的合理范围。当一个人突然高频写PID设定值或者一个从未见过的IP开始枚举OPC UA节点检测系统应该给出高优先级告警。AI在这件事上的价值是降噪和关联前提是你先把业务基线喂给它。否则AI只会把运维人员淹没在上百条“疑似异常”的告警里最后变成“狼来了”的游戏。5. 我踩过的坑和几个实战经验5.1 白名单把自己锁在门外第一次给某化工客户做工业防火墙我按“最小权限”配置了允许访问S7-1500的源IP列表结果把组态下载的临时连接忘了放行导致TIA Portal连接失败工艺组态工程师差点提着笔记本到现场手动激活。后来加了独立调试通道和变更窗口规则才把这个坑填上。经验是白名单不是一次性配置要跟着组态变更、设备更换走每次变更都要重新审视规则。5.2 设了密码不等于安全继续说S7-1500。PLC密码可以防止组态软件随意上载程序、防止下载覆盖但它不保护通信链路本身。攻击者只要通过OPC UA匿名访问或者利用网络上的合法上位机会话仍有可能在PLC不知情的情况下读写数据。更现实的风险是很多业主为了方便售后把密码写在运维手册里或者干脆用“123456”。安全评估时密码问题总是最先被翻出来。5.3 被忽视的工艺异常PID波动案例有一次客户反馈“PLC温度PID波动温差大”现场的自动化工程师换了传感器、调了PID参数问题依旧。后来安全团队查OPC UA审计日志才发现有个外部维护账号以匿名方式连接OPC UA服务器每隔几十秒就把温度设定值来回改几个数造成温度曲线周期性震荡。这不是控制问题是通信层面的恶意注入。从这件事我学到一个习惯凡出现查不到原因的工艺波动先把网络侧的日志和报文拉出来看一遍特别是IO写操作的记录。5.4 AI使用的伦理边界作为安全从业者AI是很好的辅助但我给自己划了几条线不做未经授权的渗透测试不生成针对生产系统的攻击脚本不在没有测试床的情况下对真实PLC做安全验证。如果企业要引入AI安全产品建议把“OT系统未经授权禁止使用AI辅助渗透测试”写进制度。AI可以帮我们写检测规则、分析抓包、总结日志但它不应该成为攻击生产环境的理由。折腾了一圈我的体会就一句话AI确实把攻击成本打下来了但防守方最好的反制不是买更贵的AI产品而是把IP白名单、PLC密码、程序哈希、流量基线这四样基础动作练成肌肉记忆。安全没有银弹只有谁先把基本功做扎实谁就能在攻击者面前多撑几层。希望这篇东西能帮到正在做工控安全或准备启动这件事的朋友。