1. 先把Modbus协议基础吃透1.1 为什么搞取证要先懂协议很多人一听到“取证”两个字脑子里全是硬盘镜像、内存dump、加密解密这些偏通用系统的技术觉得工控协议根本不是重点。但在我实际处理过的几起涉及工业控制系统的安全事件里最核心的证据往往不在Windows日志里而在PLC和上位机之间来回传递的那一帧帧Modbus报文里。原因很简单Modbus是1979年由Modicon现在的施耐德电气搞出来的一套应用层协议因为设计极其简单、实现成本低至今仍然是工业自动化领域应用最广泛的通信标准之一。无论是老旧的RS-485串口网络还是现在越来越普及的工业以太网Modbus都占着绝对统治地位。可以说只要你想对工控系统做取证分析或者想弄明白一次针对PLC的攻击是怎么发生的不懂Modbus就和无头苍蝇没什么区别。我之前和一些做传统取证的朋友交流他们对Windows痕迹如数家珍但一看到Wireshark里的Modbus TCP报文就懵了——那一堆十六进制数据根本不知道从哪看起。这其实很可惜因为Modbus协议本身反而是所有工业协议里最容易上手的报文结构固定、字段含义清晰、没有复杂的状态机。1.2 Modbus协议家族关系先厘清一个最常见的混淆点Modbus不是一个单独的协议而是一个家族。最常接触到的有三种变体变体物理层/传输层典型场景特点Modbus RTURS-232 / RS-485 串口工厂现场设备间通信报文紧凑用CRC校验Modbus ASCIIRS-232 / RS-485 串口老式设备调试报文是ASCII字符可读性强但效率低Modbus TCP以太网 / TCP/IP上位机与PLC、HMI通信基于502端口2000年后普及率极高其中RTU和TCP又是绝对的主流。我在现场见过最多的组合就是上位机通过Modbus TCP连接网关网关再通过Modbus RTU下挂多台仪表和现场IO。所以学Modbus取证RTU和TCP必须都吃透别只盯着一个。还要提一句Modbus还有一个隐藏分支叫Modbus Plus走的是专有令牌网络现在已经很少见普通取证场景基本碰不到我就不展开了。1.3 Modbus报文结构深度拆解Modbus协议的核心思想是主从模式主站通常是上位机、触摸屏、组态软件发起请求从站通常是PLC、仪表、变频器响应。在TCP版本里一个TCP连接上可以承载多个Modbus事务靠MBAP报文头里的事务元标识符来区分。先看Modbus TCP的报文结构这个必须背下来字节偏移字段长度说明0-1事务元标识符2字节用于匹配请求与响应2-3协议标识符2字节0x0000表示Modbus4-5长度字段2字节后续字节数6单元标识符1字节相当于RTU的从站地址7功能码1字节决定操作的寄存器类型8数据N字节寄存器地址、值等Modbus RTU的结构则是另一种风格没有MBAP头而是以从站地址开头以CRC校验结尾字段长度说明从站地址1字节0-247其中0是广播地址功能码1字节同上数据N字节寄存器地址、值等CRC162字节低字节在前循环冗余校验这里有个很关键的取证细节RTU没有内置的报文长度字段接收方是靠“帧间间隔大于等于3.5个字符时间”来判断一帧结束的。这意味着在串口抓包里如果采集设备的时间戳精度不够或者抓包软件对帧边界处理不正确很容易出现一帧被拆分或两帧合并的可疑现象。遇到这种数据先别急着下结论要结合CRC校验结果和寄存器数值连续性来综合判断。1.4 功能码与四种数据对象Modbus规定了四种基本数据对象线圈Coil可读可写按位寻址对应功能码01读、05写单个、15写多个离散输入Discrete Input只读按位寻址对应功能码02输入寄存器Input Register只读按16位字寻址对应功能码04保持寄存器Holding Register可读可写按16位字寻址对应功能码03读、06写单个、16写多个取证分析中功能码是判断攻击行为性质的核心依据。例如大量连续的功能码05或16写操作往往意味着有人在远程篡改PLC的输出状态而连续的04读操作则更像是信息收集阶段的扫描探测。我在后续流量分析部分会给出具体的实战判断逻辑。2. 流量取证从数据包里还原攻击现场2.1 流量采集的位置决定能不能采到东西Modbus取证的第一步不是打开Wireshark而是想清楚数据应该在哪里采。这决定了后期分析的完整度。我总结了三个级别的采集位置第一级是核心交换机或PLC直连端口的镜像流量。在PLC侧交换机上配置SPAN口端口镜像把进出PLC的流量复制到取证笔记本上。这是最理想的位置能完整看到所有与PLC通信的终端。唯一的问题是很多工厂车间的交换机是傻瓜式非网管交换机没有镜像功能这时候就需要插入一个物理TAP设备。第二级是在上位机或工控机上直接抓包。如果是已经发生安全事件的情况可以直接在现场工控机上用Wireshark或dumpcap后台采集采集再写进U盘。这里有个实操教训有些工控机性能很弱装Wireshark会卡成幻灯片建议只拷贝一个dumpcap.exe过去用命令行采集资源占用会小很多。第三级是串口侧采集。面对Modbus RTU网络需要用RS-485转USB的采集设备将A/B线并联接入总线。串口抓包工具方面我用过很多推荐Serial Studio或者自带抓包功能的串口调试助手。注意485总线的A/B线不能接反否则采到的全是乱码这个我早期踩过坑。2.2 用TShark和Wireshark快速过滤Modbus报文拿到pcap文件后过滤Modbus报文的语法很简单# 按端口过滤Modbus TCP tshark -r capture.pcap -Y tcp.port 502 # 按功能码过滤只保留写操作 tshark -r capture.pcap -Y modbus.func_code 5 || modbus.func_code 6 || modbus.func_code 16 # 按寄存器地址过滤 tshark -r capture.pcap -Y modbus.regnum 100Wireshark的过滤语法也相同只是把-Y换成显示过滤器即可。这里重点说一下modbus.func_code这个字段Wireshark对Modbus协议的支持非常完善几乎所有功能码都能解析出来包括一些冷门的如功能码20读文件记录、21写文件记录都有对应的字段定义。实际操作中还有个很实用的技巧Wireshark的“Telephony”菜单里没有Modbus流量统计但可以用“Statistics - Flow Graph”把整个Modbus会话的请求响应序列画出来。我在分析一次PLC被反复启停的事件时就是用这个方法快速定位到攻击者每隔2秒发送一次功能码05的写线圈请求频率规律极其明显。2.3 五种典型恶意Modbus流量特征以下是我在实战和研究中总结的几种高价值异常模式第一种是功能码滥用。正常的HMI组态软件功能码相对固定一般就是03和04读数据偶尔有06写参数。如果发现pcap里有大量功能码05、15、16的写操作且目标寄存器地址分布很广就要高度怀疑有人在做恶意篡改。尤其是目标地址覆盖了PLC的定时器、计数器特殊寄存器区的情况基本可以实锤是蓄意破坏。第二种是地址空间扫描。攻击者获取了工控网络访问权之后第一步往往是用Modbus扫描工具如ModbusScan遍历从站地址和寄存器地址。流量上的表现是短时间内对同一IP的不同单元标识符Unit ID发起请求或者对连续的寄存器地址逐点读取。这种扫描流量和正常轮询的核心区别在于——正常上位机的轮询周期是稳定均匀的扫描则是突发密集的间隔时间明显不规律。第三种是重放攻击。攻击者抓取一段合法报文稍作修改后重新发送。比如抓到一个写保持寄存器的请求把寄存器值改成恶意数值再重放。这种攻击在流量特征上很难识别因为报文结构和功能码都是合法的只能通过寄存器数值的突变时间点与其他日志如报警记录、工控组态软件的审计日志关联起来判断。第四种是异常长度报文。Modbus TCP的MBAP头里有长度字段可以根据它判断报文是否被异常截断或填充。如果一堆请求报文长度参数都相同但数据段内容却有大量随机字节可能是缓冲区溢出攻击的试探。第五种是慢速拒绝服务。攻击者建立大量TCP连接但不发送完整的Modbus请求把PLC的并发连接池占满导致合法上位机无法通信。这种在流量分析中看TCP握手包的数量和频率就够了不需要深入解析Modbus层。2.4 实战案例复盘一次针对保持寄存器的篡改分析某次事件中现场人员报修“车间里有一台变频器的频率老是自己变怀疑是设备老化。”我到场后先在上位机侧部署了端口镜像采集了30分钟流量拿回来一分析问题就很清晰了攻击者先是用功能码03从地址40001到40010读了一轮参数确认了从站响应正常然后直接对保持寄存器地址40003发起了功能码06的写单个寄存器请求把频率设定值改成了55Hz正常上限是50Hz。隔了大概二十分钟又发了一次功能码16写多个寄存器把加减速时间也改了。整个过程只用了三个Modbus请求就完成了对一台关键设备的破坏。这说明在工控网络里Modbus协议天然缺乏认证和加密机制只要攻击者能触达PLC的502端口后续操作几乎毫无障碍。这个案例后来我也写进了事件报告作为必须增加工控防火墙白名单策略的核心依据。3. 内存取证与主机痕迹排查3.1 为什么内存里藏着关键证据Modbus流量抓到的只是网络层面的数据但要搞清楚攻击者是怎么进到工控网络里的、在主机上执行了什么操作必须回到主机层面取证。Windows主机内存取证的意义在于很多恶意工具是绿色免安装的不落地硬盘文件只在内存中运行就算某些文件落地了攻击者也可能事后删除但内存镜像里仍然保留着进程执行痕迹、网络连接信息和解密后的明文配置。3.2 用Volatility配合netscan做内存网络取证工控现场最常见的主机系统是Windows 7 SP1 x64和Windows XP SP3这两个在Volatility的profile里都有成熟支持。拿一个典型的工控机镜像来分析流程如下# 先确认镜像类型 volatility -f memory.raw imageinfo # 使用匹配的profile进行扫描 volatility -f memory.raw --profileWin7SP1x64 netscannetscan是在内存镜像中扫描网络连接的核心插件它能列出连接建立时留在内核内存中的TCP/UDP连接信息包括本地IP、本地端口、远程IP、远程端口和对应的进程PID。在Modbus取证场景中我会特别关注那些连接远程502端口或者本地502端口的条目。如果一台工控机内存里出现了连接外部IP的TCP会话远程端口又是502但进程名是一个word文档或者svchost那几乎可以确定是恶意行为——合法上位机软件的进程名通常是组态软件自身的名称。另外还有connscan和sockscan两个候选插件netscan在Win7上更好用connscan在XP上更可靠。实际取证时我会把几个插件的输出都跑一遍交叉比对进程PID对应的可执行文件路径。Volatility里还有一个隐藏进程检查的经典操作用pslist和psscan对比。psscan能扫描进程对象池里残留的进程记录可以查到已退出但尚未完全清理的进程痕迹。我在一次事件中用psscan找到了一个名为“update.exe”的进程记录对应的命令行参数里带有一个内网IP这个IP又在防火墙日志里出现过多次整个攻击链就靠这一条线索串起来了。3.3 Windows主机痕迹排查五步走现场主机未必有条件做完整内存镜像或者需要快速处置时要按如下顺序排查痕迹第一步看当前活动和自启动项。用autoruns或直接在注册表Run键和启动文件夹里捞一遍重点关注名字伪装成驱动、系统服务的项。Modbus相关恶意软件通常会把自身注册为服务服务名还带“modbus”“plc”等关键字来降低管理员怀疑。第二步看进程列表和网络连接。用netstat -ano查看当前的TCP连接配合任务管理器核对PID对应的进程。重点看哪些进程在连接502端口或者哪些进程在监听非标准高位端口。第三步看计划任务和WMI事件订阅。攻击者常用于持久化的手法例如写一个每隔几分钟就执行一次恶意脚本的计划任务或者注册一个WMI事件消费器实现无文件驻留。第四步看日志。Windows事件日志中的登录事件ID 4624、4625、服务创建事件ID 7045、进程创建事件ID 4688是关键对象。如果攻击者用管理员账号远程登录过4624日志会留下源网络地址这能直接给出攻击来源IP。第五步看预读取文件Prefetch和快捷方式。这两类文件能反映程序执行历史对判断某个工具是否在系统上运行过非常有效。我曾经根据一个名为“plcscan.exe-1234ABCDEFGH.pf”的Prefetch文件确认了攻击者下载并运行过PLC扫描工具时间节点和流量中的扫描行为完全吻合。3.4 主机痕迹排查易忽略的工控特色点工控机和普通办公机有一个显著区别很多工控机装了组态软件如WinCC、组态王、KingSCADA这些软件自身有审计日志和报警记录。在排查时千万别只盯着Windows日志要把组态软件的工程文件和报警记录全部导出。我在一次事件里就是从WinCC的报警记录中发现PLC的某个寄存器在凌晨3点被写入了一个非法值但组态软件日志里操作员账号在那个时间点没有任何登录记录——这就直接证明了是外部入侵而非误操作。另外工控机的桌面、回收站、文档目录也值得翻一遍。现场操作员经常把临时脚本、抓包文件、系统截图放在桌面上这些文件有时候能反推出很多操作时间线。4. 测试工具箱用modbus poll/slave做协议验证4.1 为什么取证工作需要协议测试工具配合很多人觉得搞取证用不上modbus poll这类工具其实恰恰相反。当你从报文里提取到一串异常的16位寄存器数值时如何验证这些数值代表的含义最稳妥的方式就是用协议测试工具连上现场设备或者仿真器向同样的寄存器地址写入同样的值观察设备行为是否与事件描述一致。modbus poll是主站模拟工具modbus slave是从站模拟工具。这两个配合起来可以快速复原一个最小化的Modbus测试环境poll扮演上位机slave扮演PLC。我平时做协议分析、验证功能码行为、测试异常报文响应都靠这套组合。4.2 modbus poll的配置步骤安装好modbus poll之后第一件事是配置连接参数点击菜单“Connection - Connect”选择连接方式。RTU场景选“Serial”TCP场景选“TCP/IP”。TCP方式需要填写目标IP和端口默认502。串口方式则需要选择串口号、波特率、数据位、校验位、停止位。在“Setup”里设置从站地址Slave ID默认为1。在“Function”下拉框选择功能码比如03代表读保持寄存器06代表写单个寄存器。配置完成后主界面会显示寄存器的实时值。我强烈建议把所有配置好的参数保存为一个工程文件这样下次做同样的验证时可以直接加载不用重新配置。设置界面里有一个很关键的参数叫“Poll Delay”即轮询间隔单位是毫秒。在做正常功能测试时设个100ms就够了。但有些工程师会把这个值设成0来极限压测结果把下位机跑死这个操作我只建议在实验环境里尝试。4.3 modbus slave的使用要点modbus slave相对简单核心是建立从站后监听主站请求。启动后选择功能码和寄存器起始地址即可。它有一个特别实用的小功能可以手动修改寄存器值来模拟真实设备的行为变化这在复现攻击场景时非常重要。比如你想模拟一次“攻击者把温度传感器的输入寄存器值篡改成超高值”的场景只需要在slave面板上把对应寄存器的值从25改成85上位机的组态软件立刻就会弹出超温报警。这个验证过程对判断流量分析结论是否正确非常有效。4.4 必须补上的抓包验证环节modbus poll和slave的收发情况最好再用Wireshark抓一遍来交叉验证。具体做法是在电脑上启动Wireshark监听本地回环接口Modbus TCP连接本机时的VirtualBox或回环网卡或者监听实际网口然后操作modbus poll读写slave观察Wireshark里是否出现了对应的Modbus请求和响应。这个方法能直观看到Modbus TCP报文的每一个字节特别是事务元标识符和长度字段的对应关系对理解协议细节非常有帮助。我见过一些初学者搞不清楚为什么同一个TCP连接上的Modbus请求事务元标识符是不断递增的抓一次包就全明白了——因为每次新请求都会使事务元标识符加1响应报文必须回显相同的值。4.5 关于modbus poll密钥和注册码的提醒网上经常能看到“modbus poll注册码”“modbus slave密钥”之类的搜索很多新手会去下载所谓的破解版或者注册机这里我要认真提醒一句这种行为风险极高。原因有三点第一这类工具是工控行业通用软件使用盗版破解版一旦被扫描到企业会面临软件正版化检查的风险甚至影响项目验收。第二安全事件取证实操中非常忌讳使用来路不明的工具。如果法庭上对方律师质疑取证工具本身就带有恶意代码整个证据链的可信度都会崩塌。我见过一个真实案例某安全公司给客户做评估时用了非正版工具结果在保密协议审查环节被甲方安全团队直接拒绝。第三也是最重要的一点破解工具很可能是攻击者故意投放的诱饵里面藏着后门。你拿它去连PLC等于给攻击者送了一个通向工控网络的跳板。正版modbus poll在官网下载后有30天评估期到期会提示需要购买序列号。如果是个人学习30天足够把所有常用功能摸透了如果是公司项目需要长期使用建议直接走采购流程这类工具的授权费用并不算高对比一次生产事故造成的损失几乎可以忽略不计。4.6 用测试工具验证异常行为的过程示例假设流量分析怀疑攻击者向从站1的寄存器40001写入了数值300但正常范围应该是0到100。为了确认PLC收到这个值后会有什么反应我可以这样操作第一步启动modbus slave配置为从站1地址40001保持寄存器。第二步在slave的寄存器值手动改为300确认上位机组态软件是否会报警。第三步用modbus poll去读写同样的地址验证功能码和字节序是否与分析一致。特别要注意Modbus寄存器高字节在前如果需要写300这个值实际报文的十六进制是0x01 0x2C而不是0x2C 0x01。初学者很容易在这里翻车把300写成逆向字节序得到的实际值完全是另一码事。5. 常见问题排查与现场心得速查5.1 六个让取证人员头疼的实战问题现象可能原因解决办法串口抓包全是乱码485的A/B线接反、波特率不匹配确认线序、确认从站波特率优先尝试9600/8/N/1Modbus TCP抓包看不到502端口的流量抓包位置不对、交换机隔离了广播域接到PLC同网段或配置端口镜像检查VLAN划分内存镜像netscan扫不到连接记录进程可能已退出、镜像采集时间过晚改用psscan查残留记录对比防火墙和上位机日志寄存器数值解析后对不上现场设备字节序问题、数据类型的寄存器组合方式不同确认高低字节序32位浮点值确认寄存器组合方式ABC/AsyncWireshark无法解析某些Modbus报文端口不是标准502、报文被分片用“Decode As”手工指定为Modbus TCP协议PLC响应极慢或超时轮询周期太短、从站数量过多、链路拥塞观察modbus poll的“Delay”指标适当增加轮询间隔这里展开说下第六个问题。PLC响应超时在正常运行时也会出现区别在于故障的随机性如果是网络拥塞导致的偶发超时重试一次就成功了如果是攻击导致的通常会看到发送端不断重试但响应包完全不出现或者响应包内容长度明显偏短。建议把重试间隔和重试次数记录到备注栏里这个细节在写事件报告时非常有用。5.2 时间同步是取证工作中最容易踩的坑无论是流量包里的时间戳、内存镜像的文件时间还是Windows事件日志的登录时间如果取证笔记本的系统时间和被检设备相差太远整个时间线拼起来就会错乱。实际操作建议采集前先把取证笔记本的系统时间与目标系统做一次比对记录时间偏差。我用过一个笨办法但很可靠——在笔记本上拍一张带系统时钟和运行中命令行的照片这样至少能证明时间一致性的采集过程。如果你是在现场做应急响应更实用的办法是让PLC侧维护人员拍一张现场设备面板的照片面板自带时间显示然后和笔记本的抓包结束时间做差分。5.3 证据链完整性的几个小习惯第一采集的所有pcap、内存镜像、日志副本第一时间计算SHA-256并记录在采集记录表里。确保后续分析用的都是原始副本而不是某一个被修改过的中间文件。第二采集设备的存储介质不要使用被检现场电脑直接连接过的U盘。这个U盘最好提前做好格式化并杀毒检测避免交叉污染。第三现场的每一步操作都要有记录。不需要多复杂的表格至少写明时间、操作人、操作内容、备注。这份操作记录在很多人看来很麻烦但在真正需要出司法鉴定报告的时候它的价值比几十页分析报告还要高。6. 写给后来人的一点体会做了这么多年的工控安全相关分析和取证我的一个很深切的感受是工业控制系统这一块的取证难点不在技术深度而在知识面的跨度。你得懂一点传统取证的方法论又要愿意钻进Modbus这种老协议里去抠字节细节还得知道组态软件、PLC寄存器这些专属概念。我个人的学习路径是先啃协议规范原文再用modbus poll和slave做大量实验来验证理解最后再结合真实流量包做复盘分析。如果你也是从零开始建议按这个顺序走别一上来就找各种花哨的“取证神器”基础不牢工具再多也没用。最后再分享一个小技巧Wireshark的显示过滤器“modbus.regnum 40001”这类写法看起来简单但真正在现场最常用的是组合过滤例如同时限定从站地址和功能码modbus.unit_id 1 modbus.func_code 3这一条过滤语句能帮你快速从海量工控流量里定位到目标设备的所有正常读操作再反过来对比异常时间段的流量异常点往往就躲在几分钟内。把这个习惯练熟了Modbus取证的分析速度至少能提升一倍。
