六百栋楼停暖两天，攻击者只发了几条“合法”指令

六百多栋居民楼在零下的天气里停暖近两天。事后查明，没有一台设备被物理破坏，没有一根管道被炸断。攻击者所做的，只是用工业设备之间通行了四十多年的标准语言，向控制器发出了几条格式完全正确的指令。

工控安全公司 Dragos 在 2024 年 7 月的报告中，把这个样本命名为 FrostyGoop。这是人类已知的第九款专用于工业控制系统的恶意软件，也是第一款直接通过 Modbus 协议造成物理后果的样本。

暖气片凉了

2024年1月22日，乌克兰西部城市利沃夫，气温在零下徘徊。

那天傍晚，城北一批苏联时期建成的板楼里，住户陆续发现暖气不热了。集中供暖的楼有一种常年不断的背景音——水流过管道的低鸣，暖气片受热时金属的爆响。住得久的人早已听不见，只有它停止的时候才会被注意到。

先是拧阀门，再是拍管道，然后打电话给供热公司，占线。当晚室温降到十度上下。当地媒体后来的报道提到，有居民整夜穿着外套睡觉，有人打开烤箱取暖。

利沃夫地处后方，2024年初仍然安置着大量从东部撤离的人口。冬季供暖在这里不是舒适度指标。

供热恢复正常，用了将近两天。

“一切正常”

同一时段，供热企业调度室的屏幕上没有出现任何异常。

要理解这一点，需要先弄清楚城市集中供暖是怎么运转的。

热源把水加热，通过泵送进覆盖全城的管网；各小区的换热站把热量交给楼内的循环水，冷却后的水再送回热源。中间的调节由换热站里的控制器完成——一个装在配电柜里的工业设备，接着温度传感器和电动阀门。室外冷了就多送，回水温度偏高说明送多了就关小一些。

图1  城市集中供暖的调节回路，以及攻击发生的位置

控制器判断的全部依据，是它读到的数值：回水温度、压力、阀门开度。它不具备怀疑这些数值的能力，正如家用温控器不会怀疑自己的探头。

Dragos 的分析显示，攻击者向换热站的控制器写入了错误的数值，导致设备的测量失真，进而做出错误的调节动作。整个过程中控制器没有报警，也没有停机——从它的逻辑看，它一直在正确工作。调度屏幕读取的是同一批数据，因此也显示正常。

没有爆炸，没有烧毁的设备，没有黑屏。系统按错误的前提认真运行，六百栋楼同时变凉。

一门1979年的语言

攻击者使用的协议叫 Modbus。

它诞生于1979年，比互联网普及早了一代人，最初的用途是让可编程控制器与现场设备在一根串行线上完成通信。这门“语言”的常用词汇极少：读取某个编号的寄存器，或者向某个编号的寄存器写入数值。

寄存器可以理解为设备内部一排编了号的格子，每个格子存一个数——可能是回水温度，可能是阀门开度，也可能是某个状态位。

图2  寄存器里的数被改写之后，控制器看到的世界

Modbus 不设身份验证，不加密，也不询问对方是谁。收到一条格式正确的写入指令，它就执行。

这个设计在1979年是合理的。当时那根线是封闭的，两端都在同一个机柜里，能接线的人本身就是有权限的人。此后工业界把 Modbus 封装进 TCP/IP，使其可以在以太网上传输，默认端口 502。一门只在院内使用的方言，就此接上了公共网络。

第九个

FrostyGoop 的技术构造并不复杂。

据 Dragos 披露，它由 Go 语言编写，是运行在 Windows 上的可执行程序，通过命令行参数和配置文件工作：指定目标地址、端口以及需要读写的寄存器，随后与控制器建立连接。

它没有利用 Modbus 的任何漏洞。

没有缓冲区溢出，没有认证绕过，没有零日。它调用的是协议规范中的标准功能，执行的是现场工程师调试设备时每天重复数十次的操作。它之所以能造成后果，唯一的原因是它被允许接入。

这一点使它区别于此前的同类样本。2010年被发现的 Stuxnet 需要作者掌握离心机的转速特性、变频器型号与控制逻辑，才能让设备在自检正常的状态下损坏自身。FrostyGoop 不需要这些。它需要的只是知道对面是什么设备、哪个寄存器对应什么参数。

Dragos 同时指出，该程序不必部署在目标网络内部运行。只要网络可达，它可以从外部直接与控制器通信。

在 Dragos 维护的清单上，FrostyGoop 是第九款专门针对工业控制系统的恶意软件，前八款依次为 Stuxnet、Havex、BlackEnergy2、Industroyer、Trisis、Industroyer2、Pipedream 和 COSMICENERGY。

九个月

入侵发生在停暖之前九个月。

图3  从入侵到披露的时间线

Dragos 的调查显示，2023年4月，攻击者利用一台暴露在公网上的路由器的已知漏洞进入企业网络，随后部署 web shell、获取账户、建立隧道。报告提到，相关连接来自莫斯科的 IP 地址。此次攻击的具体归属，目前没有公开的官方结论。

此后是长达九个月的驻留。

这段时间的工作内容，事后复盘看相当平淡：熟悉网络结构，清点资产，确认哪台控制器负责哪一段管网，以及各个寄存器分别对应什么参数。

这恰恰是工控攻击中最耗时的部分。取得寄存器的读写权限并不等于具备破坏能力——一个不了解现场工艺的入侵者，即便能写入任意数值，也无法预判某次修改会带来什么后果。要把权限转化为效果，必须先看懂这套系统。攻击者有九个月。

使这九个月得以顺利进行的，还有另一个因素：该企业的网络没有做分段。

分段是工控安全的基础要求，即在办公网与生产网之间建立实质性的隔离，仅开放必要的通道。Dragos 的报告指出，这家企业的网络不具备这样的隔离，攻击者从边界路由器一路抵达可与控制器通信的位置，中途没有需要突破的屏障。

在工控领域，这并非孤例。许多生产网络是在二十年间逐段扩建而成：先满足生产，后来为远程查看数据接入网络，再后来为设备商远程诊断开放通道。每一步单独看都有合理理由。

没有回滚键

抢修过程缓慢。

被破坏的不是数据，而是一座城市中水与热的物理状态，不存在一键恢复的选项。管网需要重新平衡，换热站须逐个到现场核实，被改写的参数要人工比对后逐台恢复。工程师在地下配电室里，把控制器屏幕上显示的数值与手持仪表的读数一一对照。

这个动作的实质，是用人的眼睛替系统重新建立一次可信的测量。

将近两天后，管道里的低鸣恢复了。

四万六千台

Dragos 在同一份报告中给出了一个数字：全球可从互联网直接访问、使用该协议通信的工业控制设备，超过四万六千台。

它们分布在自来水厂、污水处理设施、楼宇空调系统、粮库通风、小型电站和化工装置中。将它们接入网络的理由普遍成立——远程运维成本更低，工程师无须深夜驱车前往现场，设备供应商也需要远程诊断通道。

利沃夫的这起事件中，没有任何设备被摧毁。攻击者进入了一间未上锁的房间，用房间内通用的语言，按照标准发出了几条指令。

随后，六百多栋居民楼在零下的天气里，冷了将近两天。

本文事实依据为 Dragos 于 2024 年 7 月公开的事件分析报告及相关公开报道。文中未使用任何虚构的人物、对话或引语；居民反应部分为公开报道中的概括描述。文中三张示意图为原创制图，可自由使用。