Writeup 4 2020 - 之江杯 - 工控现场的恶意扫描-开发者社区

Writeup 4 2020 - 之江杯 - 工控现场的恶意扫描

一、最快的打法

1、用Wireshark打开题目给的附件：t4.pcap

2、在过滤器中输入：tcp，回车

3、右键点击分组列表中任意一个流量包，选择：追踪流 ->TCP Stream

4、在弹出的窗口中，点击右下角“流”的向上的箭头，直到数字变成7；或者，直接在框中输入7；

5、窗口中显示字符串：666c61677b7071634635716655516866713971386a7d

6、在https://cyberchef.org中解码（Hex解码），得到：

flag{pqcF5qfUQhfq9q8j}

二、更暴力一点

暴力1

把所有 TCP payload 转成二进制再提取可读字符串，flag经常直接出现。

root@Rambo:/工控现场的恶意扫描# tshark -r t4.pcap -T fields -e tcp.payload | xxd -r -p | stringsRunning as user"root"and group"root".This could be dangerous. 666c61677b7071634635716655516866713971386a7d666c61677b7071634635716655516866713971386a7d root@Rambo:/工控现场的恶意扫描#

暴力2

用strings直接扫整个包，很多题目的 flag 以明文或十六进制形式躺在包里，strings一步到位。

root@Rambo:/工控现场的恶意扫描# strings t4.pcap | grep -i flagroot@Rambo:/工控现场的恶意扫描#

这条命令失败了，不适用该题目。

暴力3

root@Rambo:/工控现场的恶意扫描# strings t4.pcap | grep -E "flag\{|666c6167"666c61677b7071634635716655516866713971386a7d 666c61677b7071634635716655516866713971386a7d root@Rambo:/工控现场的恶意扫描#

暴力4

root@Rambo:/工控现场的恶意扫描# tshark -r t4.pcap -T fields -e tcp.stream -e tcp.payload

运行结果（部分）：

...000000000000601010600000800000000000060101060000080000000000004010101020000000000006010300000002000000000000601030000000200000000000070103040000000000000000000060103010000020000000000006010301000002000000000000701030400000000000000000000f0143a8b9050a4200c419c48cc497c4000000000000f0143a8b9050a4200c419c48cc497c4000000000000c014309ff0100c8000000000000000000000020111000000000000201110000000000005011116008c0000000000003016d540000000000003016d540000000000003016d0077777736363663363136373762373037313633343633353731363635353531363836363731333937313338366137647363636633631363737623730373136333436333537313636353535313638363637313339373133383661376400000000000090141a8b902010c010600000000000090141a8b902010c0106000000000000401410102000000000000601010000000800000000000060101000000080000000000004010101000000000000006010106000008000000000000601010600000800000000000040101010270000000000006010300000002000000000000601030000000200000000000070103040000000000000000000060103010000020000000000006010301000002000000000000701030400000000000000000000f0143a8b9050a4200c419c48cc497c4000000000000f0143a8b9050a4200c419c48cc497c4000000000000c014309ff0100c8000000000000000000000020111000000000000201110000000000005011116008c0000000000003016d540000000000003016d540000000000003016d0000000000000090141a8b902010c010600000000000090141a8b902010c010600000000000040141010200000000000060101000000080000000000006010100000008...

从输出中可以清楚看到：

流 0 里全是Modbus/TCP的扫描请求/响应（功能码 01、03、17、65、67 等）
流 7里只有两条相同的 payload：

3636366336313637376237303731363334363335373136363535353136383636373133393731333836613764

这串本身就是十六进制字符串的 ASCII 编码，也就是“双重十六进制”。

解码过程

第一层：把流 7 的 payload 按 ASCII 解码

36 36 36 63 36 31 ...对应的 ASCII 是：

666c61677b7071634635716655516866713971386a7d

第二层：再把这串十六进制转 ASCII

66 6c 61 67 7b 70 71 63 46 35 71 66 55 51 68 66 71 39 71 38 6a 7d

得到：

flag{pqcF5qfUQhfq9q8j}

最终答案

flag{pqcF5qfUQhfq9q8j}

为什么流 7 这么特殊

其他所有流（stream 0）都是正常的Modbus请求/响应，payload以000000开头（MBAP头）。
流 7 的 payload 不以000000开头，而是直接以36 36 36 63...开头，这明显不是Modbus协议数据，是出题人故意塞进去的 flag 编码。
所以用-e tcp.stream -e tcp.payload按流分组后，流 7 一眼就能看出来是异常数据。

之前用strings也能直接看到那串十六进制，是因为它本身就是可打印 ASCII 字符。

三、常规打法

此类题目常见的出题套路

扫描器按顺序遍历寄存器，flag 被拆成多个寄存器值，需要按地址拼接。
恶意扫描的源 IP/端口、扫描次数、特定功能码组合转成字符串。
Modbus写多个寄存器里藏 ASCII。
扫描时间间隔或 TCP payload 长度作为编码。
过滤器里直接搜flag{：
frame contains "flag"
或tcp contains "flag"
或data.data contains "66:6c:61:67"（flag 的十六进制）。