流量分析实战：从Web后门到DNS隧道与图片隐写攻击链

拿到这份流量包的时候，我其实一开始是有点抵触的。文件名就叫 capture.pcap，没有任何额外说明，大小接近 200MB，时间跨度超过三个小时。懂行的人知道，这种“综合型流量分析”最麻烦的地方不在于流量本身有多复杂，而在于你不知道线索到底埋在哪一层——可能是某个不起眼的 HTTP 请求里，也可能藏在几百个看似正常的 DNS 查询中，甚至可能是某个图片下载背后的隐写内容。这种题的思路，和当年 DDCTF2018 出过的流量分析题风格很像，表面是给你一堆正常通讯，实际上要把攻击链完整还原出来才算结束。

“添柴不加火”这个标题是我自己起的，意思是整个分析过程并不要做什么暴力破解或者惊天动地的操作，更像是在灶台边不断添柴，让原本微弱的线索慢慢烧起来，最后自己就亮了。这篇文章我会把完整的分析步骤、判断依据和踩过的坑都写下来，有刚入门流量分析的朋友，也有想练综合题思路的老手，应该都能从里面找到一点能用的东西。

1. 拿到 pcap 先别急着翻包：文件的基本功决定了后续效率

很多人打开 Wireshark 的第一件事就是直接看包列表，然后滚鼠标滚轮，这种行为我见过太多次了。实际上对于一个大流量包来说，这种“随机漫游式”的操作基本等于大海捞针，效率极低且容易漏掉关键线索。我个人的习惯是先做三件事：确认文件本身的数据、统计协议分布、计算基本的流量指标。

1.1 文件信息与完整性校验：先确认样本“来路正常”

Wireshark 打开文件后，在菜单栏的 Statistics 里能找到一些基本信息，或者直接用命令行工具 capinfos 来看，我更喜欢后者，因为它在终端里输出得很干净：

bash复制capinfos capture.pcap

输出里我最关心这几个值：

• Capture duration：时间跨度是三小时十七分钟，这意味着很多行为是有时间铺垫的，不能只看某一个瞬间的流量。
• File size：约 200MB，不算太大也不算太小，处于适合手工分析的区间，如果上 GB 就得考虑用分段策略了。
• Number of packets：160 多万个包，这个数量级用 Wireshark 的图形界面已经会有些吃力，建议配合 tshark 做快速过滤。
• Capture end time：因为 pcap 不强制带时区信息，所以先看一下时间基准。后面分析时间关联时会用到，这步不做后面容易出乱子。

同时，我一般还会顺手算一下 hash，不管是比赛题还是真实的安全事件取证包，拿到手先算 md5 和 sha256 存下来。一方面是确认文件在传输过程中没有被破坏，另一方面做取证分析时，哈希值本身就是第一份证据记录。

bash复制md5sum capture.pcap
sha256sum capture.pcap

这步很多人觉得没用，觉得“包都打开了还校验什么”。但你在复盘报告里写“对样本文件进行哈希校验，确认与来源一致”时，就知道这个习惯多重要了。比如在一次真实的安全运营中心分析任务里，我们从一个受害者的交换机上导出的 pcap 就有问题，导出过程中丢包严重导致 pcap 文件尾部不完整，在校验时发现连 hash 都对不上，如果径直去分析必然会得出错误结论。

1.2 协议分层统计：快速锁定“异类”在哪个层级

拿到包之后，我第一个真正意义上的分析动作是看协议分层（Protocol Hierarchy）。在 Wireshark 里是 Statistics -> Protocol Hierarchy，命令行也一样：

bash复制tshark -r capture.pcap -q -z io,phs

这个统计会告诉你每一层协议有多少包、占多少字节。意义在于它能让一个 160 万包的文件在十几秒内暴露“性格”。

这次我看到的结果大概是这样：

TLS 加密流量占到四分之一，这是一个非常正常的现代网络比例。既然加密流量占比这么高，而题目显然不可能是让我们无密钥分析 TLS（这是另一个极其复杂的领域），那么重点就应该放在明文流量上。未加密的 HTTP 只有 18MB、DNS 3.6MB，加上 ICMP 那一点点，这些明文的体量才是我们做流量分析时真正能下手的东西。

不过这里有个很容易犯的错误：一看加密流量比例高就直接忽略，然后闷头去翻 HTTP。实际上，TLS 流量的元数据本身就很有价值——它里面的 Server Name Indication 字段会泄露目标域名，TLS 指纹也可以辅助判断访问方是什么类型的设备。后面我在分析的过程中就用到过一次 SNI 来定位一个 C2 域名，当时整个 C2 通信都是加密的，但握手阶段的域名信息是藏不住的。

1.3 不要只依赖图形界面：tshark 命令是流量分析的“第二双手”

如果前两步你看完还打算双击 Wireshark 的图形界面在 160 万包里硬翻，那我建议你先停一下。我用 Wireshark 图形界面看单条流很高效，但做粗粒度过滤时 tshark 才是效率之王。比如我需要快速查看所有 HTTP 请求的 URI 和域名，一句命令就出来了：

bash复制tshark -r capture.pcap -Y "http.request" -T fields -e ip.src -e ip.dst -e http.host -e http.request.uri | head -50

再比如把 DNS 查询快速列出来看有没有异常域名，也可以用类似的方式：

bash复制tshark -r capture.pcap -Y "dns.flags.response == 0" -T fields -e dns.qry.name -e dns.qry.type | head -100

我自己的流程是先跑几组 tshark 统计拿到整体轮廓，再回到 Wireshark 里针对特定流做交互式分析。图形界面有即时响应的好处，但批处理统计的效率和可复用性，图形界面给不了。这一步就好比去医院看病，先做血液化验、影像检查，拿到化验单再找医生面诊，你自己拿个听诊器到处听，听一天也听不出肺炎。

2. 用会话关系画“人物画像”：跟谁说话比说了什么更早暴露问题

协议分层看完以后，我的下一个动作是看通信对（Conversations）和端点（Endpoints）。这一步的作用是快速画出这个 pcap 里的“社会关系图”：有哪些 IP 在通信、各自产生了多少流量、端口是什么、协议是什么。可以说这就是给流量包里的每台主机做“人物画像”。

2.1 Conversations 里的不对称关系往往是第一个异常信号

在 Wireshark 中是 Statistics -> Conversations，也可以命令行：

bash复制tshark -r capture.pcap -q -z conv,tcp
tshark -r capture.pcap -q -z conv,udp

我看会话时主要关注两个方面：包的绝对数量和字节数。如果一个 IP 对之间的流量在数量上极不对称，比如 A 向 B 发了 200 个请求，每个都很小，但 B 只回了 5 个大包，这种就值得怀疑。

这次的流量分析里，我看到有几组比较显眼的会话：

第一组是一台内网主机 10.10.12.17 和某公网 IP 之间产生了大量 TCP 连接，连接数量好几千，但每个连接的数据量都很小。这种模式在正常业务里也有，比如长轮询，但如果一个内网主机和外网一个陌生 IP 有这么多连接，就需要高度警惕。最典型的恶意行为是：高频小包探测目标端口、C2 心跳、或者数据外传。

第二组是 10.10.12.17 对外部 DNS 服务器的查询量明显偏高，我在 DNS 查询统计里数了一下，它向外网DNS服务器发起解析的域名数有近三千个，其中很多格式看起来就不像正常业务域名。

第三组比较奇怪，有几条 ICMP 会话，数据量虽然不大，但 Echo 报文的大小和间隔明显不正常。很多搞安全的同行看到 ICMP 会习惯性忽略，觉得这就是 ping 的通讯，但 ICMP 隧道恰恰是最爱藏在这种“大家都不关注”的协议里。

看到这些之后，我心里基本有了几个嫌疑方向，给这个 10.10.12.17 贴了一个临时的标签：“可能是被控主机”。但这个结论还需要后面的取证去支撑。

2.2 用“行为素描”代替单包分析：流量分析的关键思维

很多刚学流量分析的人容易陷入一个细节泥潭——拿到一个可疑包就开始对照十六进制，仿佛每个可疑字节都有含义。但真正有经验的分析员的思路恰好相反：不是看到一个包定一个结论，而是把一段时间内同一来源的行为合并成一条链路，再判断它是否正常。

打个比方：你是一个保安，负责看商场监控。新手看到一个人在一个柜台前站了 30 秒，就会报告“可疑人员停留过久”；但有经验的保安不会马上行动，而是先看看这个人进了商场之后逛了哪些地方、有没有反复出现在不同楼层、有没有刻意躲避保安的巡逻路线。只有把这些行为拼起来，才能判断是小偷还是普通的顾客。

流量分析也一样。“10.10.12.17 在 14:23:15 发了一个 DNS 查询”这个信息本身毫无意义；但“10.10.12.17 在 14:20 到 14:30 之间每 1.5 秒向外网发起一次 DNS TXT 查询，查询域名是一串 32 位随机字符，同时在 14:21 从某个 HTTP 服务器下载了一张图片”这个信息链就很有判断价值了。

所以在做行为素描时，我的习惯是提取一段特定时间内某个 IP 的所有时间序列行为，按时间排序，再逐层补充协议细节。tshark 里最简单的做法是把包导入到文本里，或用 -T fields 抽出时间戳、源目 IP、协议、长度等关键字段，然后在电子表格里做排序分列。如果包数量少，直接 Wireshark 里按时间顺序看也好。

2.3 分离“背景噪声”和“信号”：别让加密流量带走你的注意力

刚才提到过，这个 pcap 里有大量 TLS，占整整四分之一。这些加密流量看起来最丰富，但也最容易消耗你的精力。在真实场景中，加密流量分析往往需要密钥、TLS 指纹库、恶意域名情报库这些东西配合，才能让一个加密流暴露它的真实意图。在纯流量分析题或一次快速排查中，如果拿到了 pcap 但没拿到密钥，我会先把加密流量放到一边，集中精力看明文的部分——包括 HTTP 的标头与正文、DNS 查询、证书握手阶段的明文元数据，还有 ICMP 这种很少加密的古老协议。

不过也不是完全跳过。我会在分析早期用 tshark 把所有 TLS 握手中的 SNI 拉一份出来，看看有没有连接向可疑域名。比如这次我列出来之后，看到一个域名从没在 HTTP/DNS 里出现过，但它却出现在某个主机的 TLS ClientHello 里，而且后续这个主机还不断向这个域名发起连接。当时就记下这个域名，后面发现它出现在某个恶意软件分析报告里，这就是一个非常硬的情报关联。

所以整个第 2 步结束以后，我手里已经攒了三条线索：一条是 10.10.12.17 到公网的异常高频 TCP 会话，一条是它异常的 DNS 查询群，还有一条是来自 ICMP 的异常 Echo 报文行为。线索还是散的，下一步需要找到一个切入点把它们串起来。

3. HTTP 流量里的“主角”与“路人”：异常请求如何一步步暴露攻击链

从协议分层统计里我们知道 HTTP 明文只有约 6 万个包，这个体量对于逐条排查来说不算大，但也不小，如果一条一条点开看，还是会花去大量时间。所以我用了一个更高效的过滤思路：先关注 HTTP 的请求方法、状态码和 URI 里可能存在的可疑参数。

3.1 拿 tshark 拉出所有 HTTP 请求清单，别急着 follow 任何一条流

第一步先不进入任何流，把请求的元数据拉成一张表：

bash复制tshark -r capture.pcap -Y "http.request" -T fields -e frame.time -e ip.src -e ip.dst -e http.host -e http.request.uri -e http.request.method -e http.user_agent -E separator="|"

输出很长，我一般会存入文本文件后打开看。当请求路径和 Host 放到一起，前面有时间和 IP，大部分“正常流量”可以一眼扫过去，比如 Windows 更新、安卓系统检查更新、某个统计 SDK 上报，这些都是模板行为，很像人群里的路人甲。

真正值得关注的是那种看起来不自然的东西：目录穿越符号（../）、超长参数、POST 一个原始二进制内容、User-Agent 和系统环境不匹配等。

这次我在列表里锁定了这几条请求：

• GET /admin/login.php：一个后台登录页面。内网机器访问外网服务器上的后台登录页不算稀奇，但我注意到这台内网机器在访问它之前和之后都没有其他正常业务请求流量，行为显得孤立。
• POST /upload.php：紧接着上面的后台登录，有一个 POST 请求，响应的状态码是 302，重定向到了 /admin/index.php。这说明它可能登录成功并上传了东西。
• GET /uploads/logo.png：上传之后过了十几秒，同一台内网主机又下载了这个 logo.png。

从这条链路来看，一个正常的“用户浏览后台并上传 Logo”的场景也能解释这些请求，但问题在于：这台内网主机在此之前并没有任何身份验证相关的流量，也没有浏览过前台页面，像是凭空出现了一个用户，直接精准地找到后台登录页、登录、上传、再下载。这种一上来就 POST /upload.php 的请求模式，在真实渗透场景里非常典型。

3.2 慢下来看时间线：流量里藏得最深的往往是“不太合理的时间间隔”

如果只盯着 HTTP 请求本身，那它无非就是“登录后台上传文件”。但时间线一旦铺开，就多了一些有意思的东西。

我把相关的 HTTP 请求时间列成了这张表：

上传和下载之间隔了约 50 秒。如果我是管理员传一个 Logo 验证效果，这个时间很正常。但注意到个细节：它下载的不是自己刚上传的那个文件名，而是另一个文件名 logo.png——我过滤时已经把上传的文件名记下来，确认上传的名是 avatar.php（大概），下载的却是 logo.png，说明服务器端可能进行了重命名或二次处理。

更关键的证据在后面：下载完 logo.png 之后，原本有几秒的静默期，之后异常 DNS 查询才集中出现。时间线只要一拉开，“上传文件 -> 下载文件 -> 开始发起可疑 DNS 查询”这条链路就非常清楚了。

这也是我为什么一直强调流量分析要看时间线而不要只看单包。攻击链是有先后顺序和因果关系的事件组合，时间戳就是那个因果关系的骨架。

3.3 跟进 HTTP 流：看看请求体里到底交了什么、响应里到底回了什么

锁定了 POST /upload.php 这条流之后，我才开始 follow 这条 TCP 流。在 Wireshark 里对着某个 HTTP 请求右键，选择 Follow -> HTTP Stream。

上传的请求体是一个很典型的 multipart/form-data 格式，文件字段名叫 file，文件名伪装成了 avatar.jpg。我扫了一眼文件头的十六进制，开头是 FF D8 FF E0，确实是 JPEG 头，看起来没有问题。但往下多拉了一段时间，在这个流的中后段发现了 PHP 代码的字符串片段。这说明这是一个典型的图片马：用合法的 JPEG 文件头作为伪装，实际内容里嵌入了一段 PHP 后门代码。很多 web 服务端在上传时会简单检查文件头来判断是否是图片，而不会去检查整个文件的内容，所以这种绕过方式至今仍然非常常见。

响应的部分更有意思，服务端返回的是一行 JSON，里面包含了上传后的新文件名，大概就是 logo.png。这就解释了为什么客户端之后去下载的是 logo.png——服务端对上传的文件做了重命名，扩展名也改了。但服务端应该没有过滤掉里面的 PHP 代码，所以从攻击者角度来讲，只要他访问这个 logo.png 时服务器用 PHP 解释器解析了其中的内容，代码就能执行。

到这里，攻击者通过 Web 途径在目标服务器上植入后门的这条链路已经比较清晰。但一个完整的流量分析不能停在这一步，因为后面那一大串 DNS 异常还没有解释。如果把现在已知的信息结合 DNS 那批数据一起看，会发现这里的“上传”只是一个“投递”阶段，后面真正干活的动作是那些 DNS 查询。这种“先用 Web 投递，再用 DNS 外传或通信”的思路，在真实攻击中经常出现。

4. DNS 隧道：流量里最“不起眼”的长期后门

HTTP 的上传是一条明线，但它的剧情到这里就差不多结束了。真正让这个流量包变得“综合”起来的，是那堆看起来每个单独拎出来都毫无危害的 DNS 查询。这也是流量分析里最难的环节之一——你面对的是一堆合法的 DNS 数据包，其中每一个查询的域名看起来都可能是随便编的，但它们拼起来却是一条完整的隐蔽通信隧道。

4.1 DNS 隧道为什么能藏流量：最小协议里的最大乾坤

DNS 是一个几乎每台能上网的设备都会发出的协议，正因为它的普遍性，很多防火墙对它睁一只眼闭一只眼。而 DNS 报文里天然有“用户可定义的字段”——比如查询的域名可以非常长，可以携带任意字符，很多系统根本没有细看到域名的长度和随机性。

用一句话概括 DNS 隧道的原理：把想传输的数据编码成域名的一部分，通过 DNS 查询发送出去；DNS 服务器返回的响应报文里也有数据记录字段，可以把回传的数据带回来。这样攻击者就可以不用建立 TCP 连接，在普通的 DNS 流量里完成数据通信。

为什么防火墙很难防？因为每一笔 DNS 查询都可能是“看似合法的域名解析”，很难单凭“某个域名没听过”来判断。对于大量企业网络，内网终端向外部 DNS 查询任何域名本来就是被允许的。

4.2 识别 DNS 异常的几个真实抓手：随机域名、TXT 记录、查询频率

回头看这次流量，我在第 2 步就注意到了 10.10.12.17 的 DNS 查询量偏高，但当时没直接下结论，因为“量高”太模糊了。等我用 tshark 把所有 DNS 查询按源 IP 和域名分别聚合之后，再筛选出 10.10.12.17 相关的查询，异常的特征就非常明显了：

第一，域名结构长而随机。正常域名像 login.microsoftonline.com 这种，每级都有词义。但这里大量域名是像 f8c3a9d2b4e6a1f0.www.example.com 这种东西。前面那串 16 到 32 位的十六进制字符串明显是高熵值内容。在判断高熵时不需要用到多复杂的算法，肉眼扫几行就能感觉到“太随机了”，但更加正规的推断可以用 Shannon 熵来量化，如果需要快速验证可以用 scipy 批量算一下。

第二，查询类型绝大多数是 TXT。为什么是 TXT？因为 TXT 记录的 RDATA 可以携带任意字符串，容量大且灵活，比 A 记录（只能丢几个 IP）好用得多。正常业务里 TXT 查询主要用于 SPF 校验和域名验证，如果一个 IP 在一个小时内只用 TXT 去查一堆奇怪的域名，这是非常可疑的信号。

第三，频率和规律性太强。正常终端对 DNS 查询的间隔是不规则的，但这里 10.10.12.17 对这个子域名的查询几乎保持在每 1 到 2 秒一次，非常均匀。我很好奇，于是拉了一下峰谷分布，发现在 14:21 上传文件后的六分钟里查询频率最高，之后逐渐下降。这种“一次投递动作后立刻出现规律性隐蔽通信”的时序特征，本身就是攻击链的直接证据。

4.3 提取 DNS 查询并解码：一个可以复制的解析脚本思路

Wireshark 本身能看到 DNS 查询里的域名，但要想整体解码，还是得把数据导出来。我当时先跑了这么一条命令，把所有可疑 DNS 查询抽出来：

bash复制tshark -r capture.pcap -Y "ip.src == 10.10.12.17 && dns.flags.response == 0 && dns.qry.type == 16" -T fields -e frame.time_relative -e dns.qry.name > dns_queries.txt

得到的数据大概是这种格式：

code复制84.201234 f8c3a9d2b4e6a1f0.www.example.com
85.712345 a1b2c3d4e5f60718.www.example.com
86.419876 4e5f6a7b8c9d0e1f.www.example.com

因为查询域名里的子域名标签部分显然是 hex 字符串，最直接的处理办法是去掉公共后缀，然后把子域名部分用 bytes.fromhex 解一次，看能不能得到可读的内容。我写了一段很短的 Python 来做：

python复制from collections import defaultdict

with open('dns_queries.txt') as f:
    lines = f.readlines()

hex_chars = []
for line in lines:
    parts = line.strip().split()
    if len(parts) < 2:
        continue
    # 取第一部分作为 hex 前缀，排除正常的公共域名部分
    sub = parts[1].split('.')[0]
    hex_chars.append(sub)

raw = ''.join(hex_chars)
try:
    data = bytes.fromhex(raw).decode('utf-8', errors='replace')
    print(data)
except Exception as e:
    print('decode error:', e)

当然，真实解码过程比这个要曲折一些——比如有些数据不是从第一个 hex 字符开始的，可能需要尝试不同的起始偏移；有些数据可能是经过了 Base64 编码，甚至先用私钥加密过的，那就不是一把梭能解决的问题了。但这次不同，解出来直接就能看到内容。前一段包含了类似 whoami 命令执行的回显，后面跟着一个文件内容的片段。

这说明什么？DNS 隧道在这里承载的是交互式命令控制：攻击者通过 Web 后门得到服务器的初步权限，然后建立了一条 DNS 隧道作为隐蔽通道，通过这条通道执行命令、把结果分割成小块塞进 DNS 查询发出来，每一块都不大，所以从单个包看，几乎没有任何攻击性。

这种把命令执行结果放在 DNS 查询的域名标签里传出来的方式，属于比较典型的“DNS 数据外带”手法，在一些恶意软件和攻击工具里都被大量使用。做流量分析的人如果不会抓这层，等于瞎了一只眼。

4.4 隧道流量的组装与还原：当每个小碎片拼出一个完整文件

单独一行 DNS 查询的解码可能只是一串乱码，真正让情报落地的是把所有碎片按时间顺序拼起来。DNS 隧道的客户端一般会把内容分割成小段，按顺序发送。所以我们的解码逻辑也需要用时间作为排序键，然后用连续的时间段作为序号来拼装。比如我看 frame.time_relative 从 84 秒到 270 秒这一段是连续的，就把这些查询的 hex 字符串按顺序拼接后再解码。拼接后的结果明显分成几个块：

code复制uid=0(root) gid=0(root) groups=0(root)        # 命令回显
cat /etc/passwd | head -c 512                  # 命令本身
...

这就像看两个人打哑谜，每个信封里只有一句话，但要按寄件时间排序才能还原完整的对话。流量分析里这种时间序的还原非常关键，拼错了偏移位、搞错了起始位置，解出来就是乱码，很容易误导后续的判断。

我在这里也用到了一个小技巧：先看第一段的开头是不是常见命令。如果第一段解出来是乱码，可能是数据本身经过了 Base64，也可能是偏移位搞错了，可以把 hex 子串尝试去掉前 1-2 个字符后再解一次，往往能解决因为协议里加了前缀导致的错位问题。

5. 图片下载里的“第二层内容”：隐写分析和组合还原

从 Web 到 DNS，攻击链路看上去已经闭环了：漏洞上传后门、命令执行、结果通过 DNS 外带。但我始终没放下当时那个 50 秒的间隔——为什么上传之后要特意下载一个 logo.png？如果只是为了验证后门在不在，命令执行直接返回结果就行了，为什么要下载一个图片？直觉告诉我，图片里应该还有内容。

5.1 Export Objects：在 pcap 里把传输过的文件直接拿出来

Wireshark 有一个非常实用的功能叫 File -> Export Objects -> HTTP，它可以把 HTTP 流里传输的文件对象直接导出来。这个功能在做恶意流量分析时几乎必用。

我把所有 HTTP 对象导出到本地文件夹，里面有很多杂七杂八的东西——JS 文件、CSS、图片、网页源码。其中我用到的脚本是 logo.png，大小约 2.8MB，作为一张 Logo 来说体积有点偏大。

文件导出后，第一步先用 file 命令看一眼真实的文件类型。平时我见过很多内容伪装成图片的恶意外壳程序，所以文件扩展名只是参考，真正的类型得靠 magic bytes 判断。

bash复制file logo.png

结果很老实，是一个 PNG 图片。接下来常规手段是用 binwalk 检查里面有没有夹杂其他文件：

bash复制binwalk logo.png

binwalk 扫完之后确实发现了问题，在 PNG 的数据块的中间某一段存在一个 Zlib 压缩流的特征。在 PNG 文件中出现正常的 IDAT 数据块内容也有可能是 zlib 压缩流，这是因为 PNG 的图像数据本身就是用 zlib 压缩的，所以这个发现单独拿出来还不能证明有问题。

这个时候我需要判断一下：这个隐藏的 zlib 数据到底是 PNG 本身的 IDAT 内容，还是被额外插入的数据。一个简单的判断标准是文件尺寸。这个 PNG 的宽高如果只有几百像素，正常图像数据的压缩体积通常是很小的。但 binwalk 扫出来可疑的数据段占了整张图片一大半的体积，这就很反常。

我可以用 exiftool 看一下 PNG 的规格：

bash复制exiftool logo.png

返回里图片宽高是 800 x 400，颜色类型是 RGBA，每个像素 4 字节，未压缩时的理论数据量大约 1.28MB。但 PNG 文件有 2.8MB，说明它除了正常图像数据之外，很可能附加了大量额外数据。

5.2 PNG 隐写的三板斧：检查 IDAT 异常、附加数据块、LSB 隐写

对于 PNG 隐写，业界常用的排查套路分这三层：

第一层，查文件尾部有没有附加的数据块。一个合法的 PNG 应该以 IEND 块结尾，如果你在文件尾部还能看到一长串字符长度超过正常块说明逻辑，那基本就是有人手动附加了内容。用十六进制编辑器打开拉到底部是最直接的验证方式。这次我在 binwalk 里已经看到了，所以不用再单独查。

第二层，检查额外数据块的类型。PNG 规范里除了 IHDR、IDAT、IEND 这些关键块，还有 tEXt、zTXt、iTXt 等辅助文本块，这些块也常被用来藏数据。用 pngcheck 这类工具可以列出所有块：

bash复制pngcheck -v logo.png

这次输出显示文件里有多个未知的非标准块，其中有两个块的名字叫 zTXt，但这种块正常应该包含压缩后的文本注释，体积通常很小。可这里每个 zTXt 块都有几 KB 以上，明显不正常。更合理的解释是：这些块是用来放置额外数据的载体。

第三层，查看 LSB 隐写。如果前两层都没有发现异常，就要检查图像本身的像素低位是否藏了信息。LSB 隐写的基本原理是修改像素颜色分量的最低有效位，肉眼完全看不出区别，却能携带大量数据。这次用 zsteg 扫一下：

bash复制zsteg -a logo.png

这里提醒一下，如果用在 Linux 上没装 zsteg，可以用 gem 安装，它依赖 Ruby。输出里出现了一段类似 Base64 的字符串，解码后就是一串 SSH 公钥格式的文本。这个提取结果把“下载图片”这个动作的动机解释清楚了：攻击者在拿到服务器权限后，把自己的公钥写到了目标服务器的 SSH 认证文件里，实现持久化访问。

5.3 组合还原的思路：流量包不是单线剧情，它是多条线索的交汇

把整个分析过程拉通看一遍，这个流量包实际上是两条攻击线并行在走：

• 线上攻击链路：Web 上传图片马拿权限 -> 建立 DNS 隧道做持久化通信 -> 命令执行结果外带。
• 线下持久化链路：通过 Web 后门下载一个藏有 SSH 公钥的 PNG -> 公钥写入目标服务器 -> 建立新的 SSH 访问通道。

这就解释了为什么之前看时间线时，DNS 隧道的高频期和下载图片的时间段有重叠但前后顺序有那么几秒的间隙——攻击者先完成对服务器的权限落地，再一步步把后门持久化。这种组合型攻击方式在真实案例中很常见，但很多流量分析新手容易在里面迷失方向，因为他们总期待一个流量包只有一条清晰的攻击链。

在真实的安全运营工作里，一个 pcap 可能混合着不同时间、不同手法的攻击事件，有失败的扫描、有成功的入侵、有内部的横向移动。如果不做时间线关联和事件链组合，只盯着一个单一的技术特征，就会漏掉后半段的关键信息。这也是为什么“综合型流量分析”这个知识点几乎成了安全行业面试、CTF 比赛、应急响应里必考的题库型技能。

6. 复盘：这套“不起火”的分析方法论和真正容易踩的坑

事后我重新梳理了整条分析链，觉得最值得分享的并不是某个具体手法，而是整个流程和心态。好比标题说的“添柴不加火”——我没有用任何爆破软件，也没有做任何主动扫描和反弹 shell 的验证，全程只是在 pcap 里跟数据、看会话、对比时间线、拆文件、看隐写。火是证据自己烧起来的，我只是不断添柴而已。

6.1 可复用的分析流水线：从拿到 pcap 到输出报告的五步法

我把这次使用的方法整理成一条标准流水线，个人觉得适用于 90% 的综合型流量分析场景，不管你是 CTF、HVV 复盘还是真实应急响应都可以参考：

1. 文件体检：capinfos 获知包数、时长、大小；计算哈希存证；确认文件没有因为抓包工具异常而产生截断或错误。
2. 轮廓感知：用 io,phs 查看协议分层，记录加密流量与明文流量的比例，把加密流量先放入“暂不考虑”区，集中处理明文。
3. 行为素描：用会话统计（conv）锁定高可疑 IP 对；用 DNS 查询明细看是否有高熵子域；用时间线把不同事件串起来，寻找事件之间的因果顺序。这个阶段我不开任何单包，也不 follow 任何流。
4. 精细取证：对锁定的链接做 follow，查看请求体和响应；导出 HTTP 对象，检查文件内容；对可疑 DNS 隧道进行提取和解码；对可疑图片做文件类型、binwalk、pngcheck、zsteg 检查。
5. 组合还原与复盘：将分散的线索按时间和因果顺序重新拼成攻击链；验证关键证据的时间戳和逻辑关系；输出报告。

每次分析结束我还会顺手做一件事，把这次用的 tshark 过滤器和关键结论记录在一个本地 Markdown 笔记里。下一次拿到一个类似的 pcap，就不用重新发明轮子了。

6.2 五个真实踩过的坑，新手很容易在这些地方绕远路

第一，pcap 尾部被截断导致关键证据丢失。不要以为每个流量包都是完整的，很多 pcap 因为抓包设备存储不足或者中途重启，最后一个连接往往只有前半个握手，甚至连 DNS 响应都没有。如果分析到的某个可疑连接突然中断，先别得出结论，需要看是不是文件截断造成的。

第二，时区问题导致时间线对不上。之前提过，一开始我确认了 pcap 的时区偏移，但分析中途有一阵我把 Wireshark 显示时间从 UTC 切到了本地时间，结果和其他日志对不上，差了好几个小时，当时差点做出一个“数据外传发生在漏洞利用之前”的错误判断。后来一律用 frame.time_relative，也就是相对文件开始的秒数来对齐，不再被绝对时间干扰。

第三，在 Wireshark 图形界面里过度放大单个包的分析，忽略全局的统计关系。这种情况特别容易发生在刚上手的人身上：看到一个 HTTP 请求里有点可疑内容，就顺着十六进制使劲抠。真正的问题往往不是这一个可疑点，而是可疑点在时间线里的位置以及它和其他事件的关系。建议在精细分析之前，先把全局统计看完。

第四，只抓“正面攻击特征”，忽略了隐写这类侧面动作。这次的 logo.png 从流量特征看完全正常，下载一个图片文件本身没有攻击性，如果不去检查文件内容，后半段 SSH 持久化根本发现不了。流量分析不能只回答“谁攻击了谁”，还要回答“攻击完成后留下了什么”。

第五，DNS 隧道分析时误解码偏移位。在 DNS 隧道中，子域名前面那一长串 hex 并非永远都是纯数据，可能有一部分是信道标识和包序号。如果解码时不分隔就当作 hex 整体解析，很可能在第一段就出现乱码，导致后续整个解码思路被带偏。遇到这种情况，可以尝试去掉前面几个字符或两字符一组的错位尝试，具体概率事件就不赘述了，但记住要保留一定灵活性。

6.3 比工具更重要的是一张“我要找什么”的清单

工具清单我简单列一下：

但工具只是手段。更有用的是做流量分析前先问自己几个问题：这个流量包里主要协议占比正常吗？有没有内外网之间异常频繁的小包通信？有没有大量 DNS 查询但查的域名从没见过？有没有时间线上先发生一件事、紧接着另一件事的因果链？把这些“要找什么”的问题列成一张检查清单，分析的时候按清单走，效率会高很多。

6.4 给 CTF 和实战入坑者的一点个人建议

如果你是想通过流量分析题来练习，我建议由易到难选几个方向练手。第一类是最常见的端口扫描与爆破识别，这种题主要练会话统计和 TCP 标志位分析。第二类是 Web 攻击流量分析，练 HTTP 方法、POST 内容、一句话木马的特征。第三类是 DNS/ICMP 隧道题，练流量里的异类协议识别和解码能力。第四类是文件隐写与下载型组合题，练导出的文件对象做逆向和隐写排查的能力。把这几类依次吃透，再回到这次的“上传+隧道+图片隐写”综合题，就会有种水到渠成的感觉。

真实应急响应里的流量分析往往比 CTF 更脏更乱，但方法论相通——先看整体，再画关系，再追细节，最后拼全图。每次分析完都要复盘一句话：我到底忽略了哪个层面的信号才导致晚发现了这个问题？比如这次，如果我在第一次看到 HTTP 上传后就直接下“Webshell 投递”的结论，就会完全错过 DNS 隧道和 SSH 公钥持久化这部分信息。面对一个流量包，永远保持“可能还有第二层、第三层”的意识，而不是急着给结论，我觉得是流量分析里最重要的一种软技能。