工业控制系统的取证一直是安全事件响应里比较特殊的一块它不像传统IT取证那样有现成的全家桶工具链很多情况下得靠分析人员自己对协议的理解去手工挖线索。而Modbus作为工控领域最老牌、部署最广的协议之一几乎贯穿了从PLC、RTU到上位机软件的所有环节。可以说凡是搞过工控安全或者ICS取证的人都绕不开Modbus。这篇笔记是我在学习Modbus协议及其取证应用时整理的一些心得重点关注协议本身的架构、报文结构以及在实际取证过程中如何利用这些知识做时间线重建、异常行为分析和证据固定希望能给正在入门OT取证的朋友一些参考。1. 取证视角下的Modbus为什么这个老协议值得死磕1.1 从RS-485到以太网Modbus的形态演变Modbus最早是1979年由Modicon现在的施耐德电气为PLC通信设计的最初的形态跑在串行链路上也就是后来大家都熟悉的Modbus RTU和Modbus ASCII。RTU模式用二进制编码数据紧凑、效率高至今仍广泛存在于车间现场的RS-232、RS-422和RS-485网络中。而Modbus ASCII模式则是用十六进制字符的ASCII码表示数据可读性稍好但效率低现在应用较少。随着工业以太网的普及Modbus被移植到了TCP/IP网络上形成了Modbus/TCP。它把原来的串行帧封装进TCP报文里端口号固定为502。这个形态对于取证人员来说其实是个好消息因为意味着大量的工控流量可以被标准的网络抓包工具捕获和分析而不需要像串行总线那样依赖专用的硬件探针。从取证的角度看Modbus/TCP带来的关键变化有两点。第一每个报文都带有了完整的IP层和TCP层信息源地址、目的地址、端口、时间戳一应俱全这为流量溯源和时间线重建提供了基础。第二TCP是有状态连接取证人员可以依据会话的建立、维护和拆除过程还原一次完整的人机交互或机机通信过程这在事件响应中价值巨大。不过也要注意现场环境里Modbus RTU仍然大量存在尤其是老旧产线改造不彻底的情况下RTU总线旁往往还挂了不少老旧仪表。如果事件涉及这些串行设备普通的交换机镜像口是抓不到数据的需要额外的串口采集设备或者协议网关配合。这是取证实操中很容易被忽略的一个点后面我会专门讲。1.2 从功能码看协议本质一台极其朴素的读写寄存器机器Modbus协议之所以能几十年不衰核心在于它足够简单。整个协议做的事情说白了就是两件读数据、写数据。所有的工业业务比如读温度、读压力、启动电机、切换阀门最终都归结为对PLC内部线圈Coil和寄存器Register的读写操作。协议的数据模型分为四个表线圈Coil位操作可读可写对应DO数字量输出离散输入Discrete Input位操作只读对应DI数字量输入保持寄存器Holding Register字操作可读可写对应AO模拟量输出或内部数据区输入寄存器Input Register字操作只读对应AI模拟量输入这四个表加上功能码构成了Modbus的应用层语义。取证分析时功能码就是判断攻击行为的最重要线索。比如正常的上位机逻辑通常是周期性地读取保持寄存器和输入寄存器偶尔写入少数几个控制字而一个恶意的自动化脚本可能会连续对线圈地址空间做遍历写操作或者以极高的频率读取大范围寄存器——这些行为特征在流量里会表现得非常明显。从证据链的角度理解Modbus PDU也有必要。Modbus的报文结构非常规整Modbus/TCP的报文由MBAP报文头7字节和PDU组成MBAP头包含事务处理标识符、协议标识符、长度和单元标识符PDU则包含功能码和数据。这个结构意味着只要掌握了字节布局就可以手写解析脚本而不依赖任何商业取证工具。这一点在应急响应现场尤其关键因为你不可能指望每个客户现场都有正版的工控协议分析软件。2. 抓包前的准备工作现场条件的判断与采集策略2.1 镜像口、TAP与串行总线的采集差异取证工作有个铁律先固定现场再分析。但在OT环境里这个铁律执行起来很麻烦因为很多工控网络是环形拓扑或者专用总线并不是标准的交换机星型结构。即便是以太网架构也经常遇到不支持端口镜像的老旧工业交换机这时候就需要在交换机前串一个TAP设备测试接入点物理分光出一路流量来采集。实际操作中我见过不少分析人员到了现场才发现根本没法接入网络。所以在出发之前最好先电话沟通确认现场的交换机型号、网络拓扑以及是否有可用的镜像口。如果没有镜像条件可以退而求其次在上位机HMI的网卡上做旁路抓包或者直接在服务器侧用tcpdump抓取经过的流量。虽然覆盖范围有限但对单个主机的行为取证通常够用了。串行总线的情况就更复杂。Modbus RTU是半双工的两线制总线RS-485传统的PC网卡根本没法直接监听必须通过USB转RS-485适配器配合专门的串口抓包软件比如Serial Port Monitor、Free Serial Port Monitor才能记录总线上的报文。需要注意的是RTU报文没有IP地址和端口的概念只有从站地址Slave ID也没有全局一致的时间戳所以现场要手动记录采集时间尽量让抓包电脑和上位机保持时间同步。2.2 时间同步是被严重低估的证据要素时间戳是整个取证链条里最重要的元信息之一。没有可靠的时间同步时间线重建就是空中楼阁。IT系统通常用NTP统一时间但OT环境里NTP的覆盖情况参差不齐很多老旧的PLC站控层甚至没有时间同步服务上位机时间也可能因为长期未维护而偏差几分钟甚至几小时。在做取证采集之前一定要先在抓包机上执行同步。简单一点的做法是临时开启NTP同步或者用手机GPS时间做人工校准。如果整个系统本来就没有NTP服务器那么抓包机上记录的时间就不能作为全局基准而是要与HMI的时钟、PLC内部的实时时钟逐个做偏差比对记录偏差值并在后续分析中做偏移修正。这个细节看似不起眼但在法庭举证阶段如果辩护律师质疑时间线的准确性一个明确的偏差修正记录可以省去很多麻烦。2.3 采集窗口与数据量控制工控系统的流量通常有很强的周期性。PLC的扫描周期可能几十毫秒一次上位机每秒钟会发出大量的读请求。如果盲目开启全流量抓包几分钟就能产生几个GB的数据事后分析时反而增加了噪音。经验做法是先做5到10分钟的抽样抓包观察流量基线判断通信的周期、主要功能码和常见连接对。然后再决定是进行长期镜像采集还是只针对可疑设备做定向抓包。定向抓包通常是基于IP或端口过滤比如只抓某个PLC的502端口流量或者只抓上位机与某个控制器之间的会话这样可以大幅降低数据量让后续分析更加聚焦。另外考虑到502端口的特殊性绝大多数Modbus/TCP流量都集中在单一的TCP端口上所以抓包时的过滤规则其实很简洁。比较典型的采集命令是tcpdump -i eth0 -s 0 -w modbus_trace.pcap tcp port 502如果现场环境里同时还存在DNP3、IEC 104等其他工控协议可以根据需要添加过滤条件。但我建议不要过度过滤制造、能源行业的现场经常是多种协议混跑保留一些上下文流量有助于还原完整攻击链。3. Modbus/TCP报文拆解用tshark和Python完成逐层分析3.1 MBAP头的字节布局与字段含义拿到pcap文件后第一步就是确认里面的报文确实是Modbus/TCP。Wireshark通常能自动识别502端口的Modbus协议但有时候现场流量经过了NAT或者端口映射源目的端口并不是标准的502这时Wireshark就无法自动识别需要手工设置解码规则或者用tshark的-d参数强制解码。Modbus/TCP的MBAP报文头一共7个字节各字段含义如下字段长度说明事务处理标识符2字节用于匹配请求和响应通常每次通信自增协议标识符2字节Modbus协议固定为0x0000长度2字节表示后续单元标识符加PDU的总字节数单元标识符1字节相当于RTU模式下的从站地址用于标识下游设备解析MBAP头最基础的作用是配对请求和响应。在同一个TCP连接里事务处理标识符通常是一一对应的上位机发出请求后PLC响应的报文中事务标识符与请求一致。通过匹配事务ID可以把一次读或写请求与结果对应起来从而在时间线上形成一个完整的操作记录。如果出现大量有请求无响应的事务则说明PLC可能处于异常状态、断线或者被拒绝服务攻击这些都需要在报告中单独标注。事务处理标识符还有一个有趣的取证的用途很多上位机组态软件在通信时会从0x0001开始递增事务ID而如果分析人员发现某个IP的事务ID杂乱无章、重复频繁甚至长时间保持不变那这个IP背后的程序就很可疑——很可能是没有遵循标准栈的自研脚本或者攻击工具。3.2 PDU功能码的分布统计功能码是MBAP头之后PDU的第一个字节也是最核心的取证信号。为了快速掌握一个pcap文件中Modbus流量的整体概貌可以用tshark直接统计功能码分布tshark -r modbus_trace.pcap -Y modbus -T fields -e modbus.func_code func_codes.txt然后配合sort和uniq做一次计数统计。正常情况下大范围的流量里0x03读保持寄存器、0x04读输入寄存器、0x01读线圈应该占绝对多数而0x05写单线圈、0x06写单寄存器、0x0F写多线圈、0x10写多寄存器这类写操作比例相对较低。如果统计结果里写操作占比异常高或者出现了0x08诊断功能码、0x2B封装接口等不常见的码就需要逐条展开核查。功能码不仅可以识别异常行为还能帮助恢复攻击意图。比如2017年著名的工控恶意软件事件中攻击者就是通过Modbus功能码0x05连续触发PLC的线圈输出导致物理设备动作异常。在流量中看到大批量对特定地址的0x05写入基本上可以判断是有人在远程操作物理设备属于严重危险信号。3.3 用Python解析寄存器地址与数值Wireshark虽然方便但日志要导出成报告或者做关联分析时用Python脚本解析会更灵活。这里分享一个很精简的解析函数基于Scapy的Raw负载读取MBAP和PDUimport struct def parse_modbus_tcp(payload): if len(payload) 7: return None trans_id, proto_id, length, unit_id struct.unpack(HHHB, payload[:7]) pdu payload[7:7length-1] if len(pdu) 0: return None func_code pdu[0] return { trans_id: trans_id, unit_id: unit_id, func_code: func_code, pdu: pdu }拿到功能码之后再针对不同的功能码做字段切分。比如对于0x03读保持寄存器请求PDU的字节结构是功能码1字节 起始地址2字节 寄存器数量2字节响应则是功能码1字节 字节数1字节 寄存器值若干字节。对于0x10写多寄存器请求PDU则是功能码1字节 起始地址2字节 寄存器数量2字节 字节数1字节 数据若干字节。这些字段全部是大端序网络字节序解析时千万别用错。我见过不少初学者在写脚本时把小端大端搞混解析出来的寄存器地址和数值完全是错的。工控协议普遍使用大端序这一点和x86主机上的本地字节序相反务必在代码中显式用前缀的struct格式来规避。解析寄存器数值后结合设备点表Tag表才能还原业务含义。比如某个保持寄存器的地址40001对应的是1号罐的温度值原始数值3280可能除以10就是328.0摄氏度。所以取证实操中拿到点表几乎是解析业务意义的必要条件。如果事件响应阶段无法获取点表那就只能做行为层面的异常判断无法深入到物理量层的还原这一点需要在报告里如实说明。4. 异常行为识别从正常基线中找出攻击痕迹4.1 建立协议基线是判断前提在讨论异常行为之前必须承认一个现实Modbus协议本身几乎没有安全性。它没有认证没有会话密钥也没有报文完整性校验MBAP里虽然有长度字段但没有校验和RTU模式下的CRC校验也不是完整性安全机制。也就是说任何人都能伪造请求去读写PLC前提是能接触到网络。攻击者一旦进入OT网络内部Modbus基本是裸奔状态。那么取证分析的目标就很清晰了在这样高危的前提下通过流量特征找出那些不应该发生的行为。而判断不应该发生的前提就是先建立基线也就是搞清楚在正常业务情况下网络里的通信模式长什么样。建立基线通常需要至少一个完整业务周期的流量理想情况下是24小时覆盖白班、夜班、换班、非生产时段。如果事件响应的时间紧迫那么至少也要覆盖半个小时以上的稳定运行窗口用来观察周期性的轮询请求。基线的观察维度包括每个PLC的寄存器轮询范围是否固定比如HMI是否始终只读40001到40050之间的寄存器两次读请求的间隔是否稳定通常是几百毫秒到几秒写请求的发起方是否固定是否只来自上位机或者工程师站会话连接的建立和断开是否有规律比如是否只在班次切换时断开有了这些基线之后分析可疑窗口时就有了参照系。4.2 典型异常一寄存器扫描与侦察行为攻击者在实施破坏之前往往先要做资产探测和寄存器扫描搞清楚PLC的地址空间里哪些寄存器是有效的、有哪些物理功能。反映到流量上就是大范围的连续读请求。比如正常的HMI只会读取40001到40010这十个保持寄存器而扫描行为可能会从40001一直遍历到49999每个地址读一次甚至对线圈地址也做同样的遍历。如果只看单条报文这些请求和正常请求没什么区别功能码同样是0x03。但是把流量按时间排列来看扫描行为的模式非常机械从低地址到高地址读取数量通常是1或者2相邻请求之间间隔均匀。人工翻报文很难发现规律但是用pandas做个简单的滚窗统计就能识别。import pandas as pd df pd.DataFrame(records) # 每行包含timestamp, src_ip, start_addr, quantity df[addr_gap] df[start_addr].diff() scan_candidates df[df[addr_gap] 1]如果同一个源IP在短时间内出现了大量地址连续递增的读请求基本可以判定为寄存器空间探测。这类行为的攻击意图多半是后续写入做准备因此在报告里应该被标记为侦察阶段。4.3 典型异常二写指令的爆发性出现相比侦察行为写指令的分析更直接但也更危险因为一旦攻击者发送了写指令物理设备可能已经受到影响了。取证人员面对的问题是这个写指令到底是谁发的什么时候发的写的是什么值写指令识别的主要依据是时间戳和源IP。正常的维护操作通常是在停机检修时段由工程师站发起操作员在HMI上确认整个流程有明确的人为节奏。而攻击性写入有几个共同特征爆发性短时间内连续写入多个地址、非工作时间凌晨两三点、源IP与正常的工程师站不一致、或者使用了高权限但平时不用的通信端口。在解析写多寄存器0x10或写单寄存器0x06报文时重点要记录三件事目标寄存器地址、写入值、时间戳。然后把写入时间与现场实际业务事件比如设备启停记录、报警记录做关联判断写入是否造成了实际物理影响。这一步需要与现场工程师密切配合不能只靠流量分析下结论。4.4 典型异常三重放攻击的识别难点重放攻击是OT环境里识别难度最高的攻击模式之一。攻击者不需要理解功能码的含义只需要把之前抓到的合法写指令原样回放一遍就可能重新触发一次设备动作比如打开阀门或者启动电机。从流量的角度重放攻击的报文和合法报文在格式上完全一致无法通过字段级别的规则去识别。唯一的突破口是利用事务处理标识符和时间戳。正常的请求-响应过程里事务ID是连续递增的而重放工具往往直接发送预设的报文内容事务ID会重复或者停滞在一个固定值上。如果出现了连续多个写请求的事务ID完全相同但时间间隔与正常操作节奏不符就值得怀疑。另外还可以对比同一源IP、同一目标地址、同一寄存器值的写指令是否在历史上已经出现过。如果在历史流量里找到了完全相同的写入操作而本次写入并没有对应的业务上下文比如没有经过HMI确认、没有伴随其他操作那么极有可能是一次重放。这时候建议把历史报文和当前报文的十六进制内容做比对保存为证据。5. 实战复盘一次PLC异常停机的流量调查过程5.1 事件背景与取证范围有一次参与某制造企业的应急响应核心问题是一条装配线的PLC在凌晨3点15分左右突然停机导致整个产线停产。现场工程师确认PLC没有硬件故障也没有本地报警记录怀疑是网络侧被人动了手脚。我们到达现场后先在核心交换机的镜像口抓到了过去两周的镜像流量但数据量非常大不可能全部人工分析所以采用了时间窗口聚焦 行为基线比对的策略。事件的关键时间窗口是停机前30分钟到停机后15分钟。通过tshark按时间过滤把这一窗口内所有源或目的端口为502的流量单独导出然后统计每一个会话的活跃度、功能码分布和写操作明细。5.2 定位肇事IP和异常写操作分析过程中我发现了一个会话非常可疑源IP 192.168.10.77目标IP是停机的PLC端口502窗口内这个连接发出了12次写操作其中8次是写单寄存器0x064次是写单线圈0x05。而对比基线正常状态下该PLC一天最多只有2到3次写操作且都集中在白天。进一步解析这12次写操作的内容发现0x06写寄存器的目标地址指向了控制器的命令字寄存器写入值均为0x0001而正常情况下该寄存器的启动命令值也是0x0001。也就是说攻击者通过重复发送相同值的写指令强制命令字一直保持启动状态但实际上又触发了某种逻辑冲突导致PLC保护性停机。随后我把192.168.10.77的整个通信时间线拉出来发现该IP在停机前大约2小时才开始出现在网络上之前没有任何流量记录。这说明很可能是临时接入的一台设备大概率是攻击者为了进行操控而带来的笔记本电脑或者临时工控终端。5.3 证据固定与报告输出为了固定证据我把可疑会话的所有原始报文导出为单独的pcap文件并计算了文件的SHA256哈希。同时用脚本把12次写指令的字段时间、事务ID、功能码、寄存器地址、值提取成表格作为报告的附件。需要注意的一个实操经验是pcap文件在提取过程中不要做任何改写包括不要用Wireshark另存为时勾选重写时间戳否则可能影响哈希一致性。如果确实需要裁剪文件建议从原始镜像里用editcap复制并且保留原文件作为后续核查的基准。最终的企业内部调查确认这个IP对应的设备是一台未经登记的外来调试笔记本被某个承包商带进了车间凌晨时有人用它连接了产线网络。虽然攻击的动机不一定是恶意破坏但行为本身已经对企业生产造成了实质性影响。整个过程证明了Modbus流量分析在事件溯源中的价值同时也说明没有日志审计和网络分区分层防护的情况下一个未授权的接入点就能让产线陷入瘫痪。6. Modbus取证的低成本工具链与经验总结6.1 从Wireshark到开源脚本的工具组合工控取证的门槛并没有想象中那么高有一台笔记本和一套开源工具链大部分Modbus/TCP的分析工作都能完成。Wireshark负责可视化和快速定位tshark负责批量过滤和字段提取Python和pandas负责统计分析和异常检测再加上一个十六进制编辑器用来核查原始字节这套组合已经能覆盖从采集到报告输出的全过程。Wireshark在Modbus解析上做得其实相当完善。展开协议树可以直接看到功能码、寄存器地址、值等字段对不熟悉字节布局的人来说是很好的入门口径。配合Follow TCP Stream功能可以直观看到一次会话中请求和响应的顺序这种直观性对快速理解攻击模式很有帮助。在需要批量处理大量pcap的情况下tshark的字段提取功能更高效。比如导出所有Modbus写操作及其目标地址tshark -r trace.pcap -Y modbus.func_code 0x06 || modbus.func_code 0x10 \ -T fields -e frame.time -e ip.src -e ip.dst -e modbus.regnum -e modbus.value这样导出的CSV可以直接导入Pandas做后续分析。对于中小型OT网络用这套流程基本可以在半小时内完成一个初步的异常排查。6.2 商用工具的补充价值与局限开源工具之外市场上也有一些工控协议分析平台比如Surge Analysis、Nozomi、Claroty等它们能自动提取工控协议的语义建立资产和通信基线对大规模OT网络做持续监控。在取证场景下这类工具的价值在于它们长期运行保存了历史通信元数据可能记录了事件发生前后的上下文而不只是临时抓包的那一小段时间窗口。但商用工控平台并不普及很多工厂没有部署或者即便部署了也没有保存原始报文只保留了告警日志。遇到这种情况传统网络取证方法依然是兜底方案。另外商用工具在取证合法性上也有讲究如果平台自身没有做司法鉴定认证它的输出报告可能无法直接作为法律证据还得结合原始pcap的哈希和抓包采集过程的记录来补强。6.3 一份基于踩坑经验的检查清单这部分内容写得具体一点都是我在实际事件中犯过错或者吃过亏的地方到达现场后第一时间确认抓包机的时间基准并记录偏差。不要预设现场NTP是正常的。抓包文件命名时加入案件编号、采集点位、起止时间避免事后多个pcap分不清来源。采集期间禁止在抓包机上更新杀毒软件病毒库或操作系统补丁避免产生杂散流量污染镜像数据。对502端口抓包时建议同时开启-s 0保存完整报文不要用默认的snaplen否则报文尾部可能被截断影响CRC或数据字段分析。如果流量里有VLAN标签记录时保留802.1Q头不要用vlan过滤去掉因为VLAN ID本身可能是定位终端位置的关键信息。解析RTU模式时注意CRC校验的字节序Modbus RTU的CRC是低字节在前。一定要保留原始报文文件任何裁剪、导出、格式转换都会产生新文件不能覆盖或删除原始pcap。Modbus写操作的值本身只是原始数值要理解为物理量必须要有点表找不到点表时不要臆测写报告时如实标注具体物理含义待确认更加专业。6.4 后续可以继续深入的方向Modbus取证只是工控协议取证的一个起点。现在越来越多的OT环境里还跑着OPC UA、EtherNet/IP、PROFINET、IEC 61850等实时性更强的协议它们各自有复杂的会话状态机和加密机制取证难度比Modbus高不少。但底层思路是相通的理解协议字段、建立基线、聚焦异常、固定证据。从个人学习路径来看建议先把Modbus/TCP和Modbus RTU彻底啃透包括不依赖Wireshark、能徒手解析报文的程度再去接触其他协议会轻松很多。毕竟Modbus是所有工控协议里最简单也最原教旨的代表掌握了它的思路其他协议无非是在这个骨架上增加更复杂的语义和状态管理罢了。最后分享一下我的个人体会Modbus协议的设计放在今天来看确实太脆弱没有认证、没有加密、功能码暴露无遗但它巨大的存量决定了未来十年里工控取证仍然绕不开它。与其抱怨协议老旧不如踏踏实实把它玩明白。很多时候越简单的协议越能体现出分析人员基本功的扎实程度。
