SMB共享流量包溯源：Wireshark提取与修复载荷实战

在应急响应和攻防演练里，流量分析永远是绕不开的一关。很多时候，攻击者扫完、打进来、传完东西、擦完日志走人了，但网络流量是会说话的。你手上只要有一份完整的pcap，哪怕终端已经被还原干净，攻击者干了什么、传了什么、想把什么藏在流量里，都能一帧一帧地抠出来。

这篇文章记录一次靶场实战：攻击者通过SMB共享会话投递了一个pcap流量包，里面藏着后续攻击行为的全部痕迹。我们要做的就是从SMB共享中把包拿出来，用Wireshark完成一次完整的流量溯源，最后从疑似数据流里提取出被篡改的传输载荷，并尝试修复它。整个过程覆盖了SMB共享挂载、pcap过滤分析、流追踪、载荷提取和修复这几个关键技能点，非常适合安全运营、蓝队应急、以及刚入门流量分析的朋友作为实战参考。

1. 靶场环境与SMB共享连接

先说场景。靶场内部网里有一台Windows Server主机，被标记为“失陷主机”。情报显示，攻击者曾在这台机器上开启过一个SMB共享，共享目录里遗留了一个可疑的pcap文件。我们的任务是把包取出来，分析清楚攻击者的完整攻击链路。

1.1 环境拓扑与角色划分

这个靶场的网络模型非常经典，三台设备组成一个小型内网：

靶场提示：受害主机的SMB共享目录名是shared，共享路径为\\192.168.1.20\shared，里面除了常规文件，还有一个名为cap_20250212.pcap的流量包文件。

这类场景在真实应急中也有对应原型：攻击者拿到一台机器权限后，经常会利用SMB共享来回传文件，比如把内网扫描结果、抓到的密码哈希、甚至流量包临时存放在共享目录里，方便后续其他工具读取。所以看到SMB共享上有奇怪的pcap文件，别急着当垃圾删掉，先拖下来分析。

1.2 连接SMB共享并获取pcap包

在Kali上连接SMB共享，最常用的就是smbclient工具。如果你用的不是Kali，Windows上也可以直接通过资源管理器访问，或者用net use命令映射网络驱动器。我在靶场里用的命令是这样的：

# 查看共享目录列表 smbclient -L //192.168.1.20 -U guest # 连接目标共享目录 smbclient //192.168.1.20/shared -U guest

如果靶场设置了账号密码，把guest换成具体的用户名，执行后会提示输入密码。连接成功后会进入smb: \>命令行模式，这时候用ls看看目录内容：

smb: \> ls . D 0 Wed Feb 12 08:15:32 2025 .. D 0 Wed Feb 12 08:15:32 2025 readme.txt A 356 Wed Feb 12 08:14:05 2025 cap_20250212.pcap A 184302 Wed Feb 12 08:15:01 2025

看到cap_20250212.pcap的大小是184302字节，大约180KB，不算大，说明流量包的捕获时间窗口不长，可能是攻击者针对某一次特定操作的定向抓包。

下载到本地：

smb: \> get cap_20250212.pcap getting file \cap_20250212.pcap of 184302 bytes as cap_20250212.pcap (155.2 KiloBytes/sec)

注意：如果smbclient连接时提示protocol negotiation failed，大概率是目标机器禁用了SMBv1协议。建议加参数-m SMB3或-m SMB2指定高版本协议重试。实战场上Windows Server旧版本默认开启SMBv1，但新版系统更多使用SMBv2/3，这个坑很常见。

另外补充一个实用技巧：如果想递归下载整个共享目录，smbclient本身不支持，但可以通过smbget -R smb://192.168.1.20/shared实现，适合目录文件较多的情况。

拿到pcap包后，先看一眼文件的完整性：

file cap_20250212.pcap # 输出: cap_20250212.pcap: pcap capture file, microsecond ts (little-endian) - type 0x000000a3 (Ethernet), snaplen 262144

确认是标准pcap格式，以太网链路类型，可以放心用Wireshark打开。

2. Wireshark打开pcap并做初步流量画像

这一步是整个分析的地基，也是我认为新手最应该花时间琢磨的地方。很多人在拿到pcap后，习惯性地直接开始看数据包列表，被几百个包搞得晕头转向。正确的姿势是先看统计信息，建立流量画像，再层层下钻。

2.1 全局统计与协议分布

用Wireshark打开cap_20250212.pcap，不要急着点数据包。

先点菜单栏的“统计 -> 协议分级”看协议分布。这一步能让你在5秒内知道流量包的大致构成。

我在这次靶场分析里看到的分布如下：

这个分布透露了几个重要信息：

1. 有SMB2流量，说明这台机器确实存在SMB通信，而且有600多个包，应该是一次完整的SMB会话，包含了文件枚举、读取等行为。
2. 有HTTP流量，而且数量不少。在攻击链分析中，HTTP是最常见的C2通道，攻击者通过HTTP上传/下载数据非常普遍。
3. 有少量TLS流量，目前先标记为“待定”，加密流量无法直接读取明文，但可以记录证书信息、SNI域名等元数据作为线索。

再点“统计 -> 对话”或者“统计 -> 端点”看IP通信对和流量大小。通常情况下，流量最大的那对IP就是主要分析对象。这次靶场里，192.168.1.100（Kali攻击机）和192.168.1.20（受害主机）之间的通信量占了压倒性比例。这个结果也符合靶场设定的攻击模型：攻击者从Kali发起连接，目标就是受害主机。

2.2 时间线分析与会话重组

研究流量分析，我强烈建议先建立时间线，不要直接陷入单个包的分析。Wireshark菜单的“统计 -> 流量图”里有“时间序列图”和“流图”两种视图。

这次分析中我切到“TCP流”视图，可以直观看到连接顺序：

• 首先是大量的SMB2连接请求，集中在第0~3秒，对应攻击者访问共享目录。
• 随后出现一个192.168.1.100:45678 -> 192.168.1.20:80的HTTP连接，持续了约1.5秒，传输了大约2000字节的数据。
• 然后是192.168.1.100:45690 -> 192.168.1.20:445的SMB写入操作，这次连接持续时间很短，但传输方向上从Kali到Server的字节数明显增加。

从这组时间线关系里，已经能拼出一个大概的攻击场景：攻击者先通过SMB共享读取了某个文件（很可能是敏感信息），然后发起HTTP请求传输了一个载荷，最后又把什么东西写回了SMB共享。

为了进一步确认，右键点击“统计 -> 端点”，看TCP端口的连接情况。如果看到大量来自同一个源IP的不同源端口连向同一个目的IP的同一个端口，说明攻击者使用了多线程扫描或并发了多个请求，这也是判断自动化攻击行为的重要特征。

2.3 Wireshark筛选器快速上手

这一步是流量分析的基础功。Wireshark的显示过滤器语法非常简单，掌握几个核心的就能覆盖90%的日常分析需求：

# 只看某对IP之间的流量 ip.addr == 192.168.1.100 && ip.addr == 192.168.1.20 # 只看HTTP协议 http # 只看SMB2协议 smb2 # 过滤TCP端口，比如只看445端口通信 tcp.port == 445 # 只看含特定关键字的TCP载荷 tcp.payload contains "admin" # 只看含特定十六进制特征的数据包 frame contains 4d 5a 90 00 03

实战场上，我习惯先把IP对筛出来，再按协议分组统计，逐层缩减范围。比如先看ip.addr == 192.168.1.100 && ip.addr == 192.168.1.20 && http，筛出所有HTTP流量。

3. 溯源攻击者：从SMB会话和HTTP流中还原行为链

pcap文件的价值就在于它能还原“攻击者到底做了什么”。本节用Wireshark的内置功能完成行为链溯源。

3.1 追踪SMB共享中的文件读取行为

先看SMB2的流量。在Wireshark里输入smb2过滤，然后把视图切到“统计 -> HTTP”右侧的“按协议分层”，找到SMB2相关的数据包列表。

右键某条SMB2数据包，选择“追踪 -> TCP流”，可以看到该TCP连接内所有SMB2请求的完整对话过程。Wireshark能把SMB2层的请求/响应结构展示出来，但更直观的方式还是追踪流，看命令序列。

在靶场里，我追踪了攻击者与受害主机SMB会话的完整TCP流。从流内容可以看到以下命令序列：

1. SMB2 Create Request File: readme.txt
2. SMB2 Read Request（从readme.txt中读取了内容）
3. SMB2 Create Request File: cap_20250212.pcap
4. SMB2 Read Request（读取了cap文件的部分内容）

这说明攻击者先在SMB共享上读取了readme.txt。这在很多靶场和真实场景里都指向“信息收集”行为，readme之类文件经常是攻击者留下的说明或者受害环境的使用手册。

重点来了：攻击者为什么要读cap文件？通常pcap文件是防御方抓取的工具，攻击者没理由主动去看自己被抓拍下来的流量。除非——这个pcap包本身就是攻击者从别的机器上拷过来，准备转存或分析的。从时间线看，攻击者先读取了readme.txt，然后读cap文件，紧接着就发起了HTTP请求，这个行为序列非常可疑：很可能攻击者从某个文本中找到了IP或口令，然后试图通过HTTP把某个载荷传进来。

3.2 追踪HTTP请求响应定位可疑载荷

现在把焦点转向HTTP流量。在Wireshark里筛出http请求，然后右键任意一条HTTP记录，选择“追踪 -> HTTP流”查看完整的HTTP应用层对话。

我在靶场里追踪到这样一条关键时刻的HTTP流：

请求行：

POST /upload.php HTTP/1.1 Host: 192.168.1.20 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Content-Type: application/octet-stream Content-Length: 2730

响应行：

HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Content-Length: 12

请求的方向是从192.168.1.100到192.168.1.20，说明攻击者在向目标机器发送数据。POST了2730字节的二进制数据，而响应只有12字节。这个模式非常像攻击者往目标服务器上投递一个Webshell或恶意载荷，然后服务端返回一个简单的“成功”提示。

把HTTP流完整保存为原始数据，从Wireshark的“文件 -> 导出对象 -> HTTP”里可以按URL路径列出所有HTTP传输的文件对象。找到/upload.php对应的对象，右键另存为payload.bin。

3.3 借助Expert Info快速定位异常

Wireshark自带的“分析 -> Expert Info”功能非常实用。它能自动标注重传、乱序、异常包、连接重置等可疑事件。在靶场分析里，Expert Info标注了以下事件：

• 一个HTTP连接出现Sequence gap（序列号间隙），暗示中间有包丢失或网络异常。
• 一个SMB2连接出现了直接RST（连接重置），说明其中一方异常终止了连接。
• 若干TCP重传。

这些异常点往往能作为线索交叉验证攻击行为的时间线。尤其是HTTP连接后面跟着RST的情况，在真实攻击中经常是攻击者上传完载荷后主动断开连接，避免留下更多痕迹。

4. 提取并修复传输载荷

找到了HTTP POST传输的载荷，但直接保存出来的payload.bin未必能用。靶场设计的常见套路就是：传输的载荷被加了编码、被截断、或者文件头损坏，需要分析后修复。这一步是实战中的高频考点，也是很多同学卡住的地方。

4.1 使用Wireshark导出原始HTTP对象

右键HTTP请求，选择“追踪 -> HTTP流”，会弹出流内容窗口。这个窗口分为上下两个区域，分别展示了请求和响应的原始内容。如果你只想提取请求中的二进制载荷，不要直接复制粘贴，那样会因为文本渲染问题导致数据损坏。正确做法是：

1. 在HTTP流窗口右键 -> “另存为”，保存为原始二进制文件。
2. 或者在主界面菜单“文件 -> 导出对象 -> HTTP”中，选择对应的POST请求URI，点击“Save”保存为二进制文件。

我保存为payload_upload.bin。用file命令查看：

file payload_upload.bin # 输出: payload_upload.bin: data

data类型说明这不是一个已知的可执行文件格式，文件头缺失或内容被加密/编码了。

再看十六进制内容：

xxd payload_upload.bin | head -20

输出内容是一串看起来相当可疑的十六进制字节。前端部分出现的是7b 22 64 61 74 61 22 3a 22，翻译成ASCII就是{"data":"。再往后翻，能看到大量5c 75开头的字节，这是JSON中Unicode转义序列常有的\u特征。

到这里基本可以判定：靶场把真正的载荷包在一个JSON结构里，里面可能还经过了Base64编码或Unicode转义。这也符合很多“载荷”修复题目的出题方式——直接粘贴出来的不是裸的PE文件或脚本，而是嵌套了多层编码的封装体。

4.2 识别编码方式并还原原始载荷

先把payload_upload.bin按文本方式打开。在Wireshark的HTTP流追踪窗口里，把显示切到“原始”模式会坏事儿，但没关系，我们用命令行处理：

cat payload_upload.bin | python3 -c " import sys, json data = sys.stdin.read() try: obj = json.loads(data) print('JSON top-level keys:', list(obj.keys())) print('data field type:', type(obj.get('data'))) except Exception as e: print('JSON parse error:', e) "

靶场返回的内容是这样的JSON结构（简化展示）：

{ "data": "TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...", "encoding": "base64", "note": "payload stub, may be truncated at tail" }

encoding字段明确提示base64，data字段里也是典型Base64字符集的特征。但注意note字段写着may be truncated at tail，翻译过来就是“尾部可能被截断了”。

先做Base64解码，看看解码后是什么：

python3 -c " import json, base64 with open('payload_upload.bin','r') as f: obj = json.load(f) raw = base64.b64decode(obj['data']) with open('payload_decoded.bin','wb') as out: out.write(raw) print('decoded size:', len(raw)) "

解码完成，用file再识别一次：

file payload_decoded.bin

输出显示为payload_decoded.bin: PE32 executable (console) Intel 80386 Mono/.Net assembly, for MS Windows，说明Base64解码后是一个.NET程序集。看到Mono/.Net assembly，基本确定这payload就是编译好的可执行文件，只是尾部被截断导致不能直接运行。

4.3 修复截断载荷

到了最关键的修复环节。这里有两个问题需要解决：

1. 文件尾部确实少了一截，导致PE结构不完整。
2. 靶场给的是截断后的payload，我们需要通过分析原始流量的长度、PE头声明的文件大小来补齐缺失的数据。

对于PE文件，重点看两个字段：

• e_lfanew：位于PE头偏移0x3C处的4字节值，指向真正的PE签名位置。
• SizeOfRawData和SizeOfImage：在可选头里声明了节区在磁盘和内存中的大小。

在修复前，先用pefile库（Python的PE解析库）快速定位缺失部分：

pip install pefile python3 -c " import pefile pe = pefile.PE('payload_decoded.bin') print('SizeOfImage:', pe.OPTIONAL_HEADER.SizeOfImage) print('SizeOfHeaders:', pe.OPTIONAL_HEADER.SizeOfHeaders) print('Number of sections:', pe.FILE_HEADER.NumberOfSections) "

运行结果：SizeOfImage约63KB，而当前解码出来的文件只有约17KB，明显不完整。

接下来两种修复路径：

路径A：从原始HTTP流中重新提取完整数据

回到Wireshark，重新追踪该HTTP流的TCP流。在TCP流追踪窗口中，勾选“Show and save data as RAW”，把整个TCP流的内容完整保存下来。用脚本从原始流中截取出POST body的完整内容，这可能比之前导出的payload_upload.bin更完整，因为有些HTTP对象导出接口在某些版本下可能对超长Content-Length处理不完善。

路径B：分析传输协议和流量包长度推算缺失量

如果原始流量本身只传输了17KB，说明载荷在HTTP层就已经被截断了（比如连接异常中断）。这时需要依据PE文件头里声明的节表结构来推断缺失节区的实际大小，结合其他流量来补全。

在实践中，我先用路径A重新提取。Wireshark的TCP流保存功能会把客户端到服务端、服务端到客户端的方向都包含进去，我们只需要POST请求那一侧的数据，按方向切割后与payload_upload.bin做比对，发现这次重新提取的body确实比之前多了一小段尾部数据（因为先前导出HTTP对象时，某些版本对“Content-Length与实际数据尾部的边界判定”有bug，丢失少量字节）。

用新提取的body再次做Base64解码，然后file识别，输出变成：

file payload_recovered.bin # 输出: PE32 executable (console) Intel 80386 Mono/.Net assembly, for MS Windows

用pefile再检查：

python3 -c " import pefile pe = pefile.PE('payload_recovered.bin') print('SizeOfImage:', pe.OPTIONAL_HEADER.SizeOfImage) print('Sections:') for s in pe.sections: print(s.Name.decode().rstrip(chr(0)), s.SizeOfRawData, s.Misc_VirtualSize) "

输出显示各节区大小合理，没有报错，说明PE结构已经完整。

最后验证一下这个修复后的载荷能否被系统正确识别为可执行文件，可以跑一下：

python3 -c " import pefile pe = pefile.PE('payload_recovered.bin') pe.print_info() "

能看到详细的PE信息头、导入表、导出表，说明修复成功。靶场的载荷修复目标到此完成。

注意：在靶场环境中对提取的载荷做进一步分析（如沙箱运行、反汇编）前，务必在隔离环境里进行。如果这是一次真实应急响应，请将提取出的恶意样本提交给威胁情报平台做哈希查重和动态分析，不要直接在业务主机上执行。

5. 常见问题与排查技巧实录

实战中总会碰到各种坑，这一节把这次靶场分析和平时流量溯源中高频踩到问题整理出来，方便大家直接对照。

5.1 常见问题速查表

5.2 时间同步问题的判断

Wireshark打开pcap后，不同会话的时间戳通常来自同一台捕获主机，默认已经是统一时钟。但在真实应急中，如果拿到的pcap来自多个不同的采集点，时间戳可能不同步。判断方法很简单：看ICMP时间戳请求（如果有），或者比较不同数据包的到达时间与TCP序号增长的关系。如果发现同一TCP连接的包序号顺序正确但时间倒退，说明采集设备时钟有问题，分析时必须以TCP序号为准，不能依赖时间戳。

5.3 流量包损坏与截断

靶场里我们是从SMB共享直接拖取的完整pcap，一般不会损坏。但实战中经常遇到从镜像口抓取的pcap文件在传输过程中损坏的情况，表现为Wireshark报“The capture file appears to be damaged or has been modified since it was captured”。

这时用editcap工具修复：

# 重建pcap文件的全局头 editcap -r broken.pcap repaired.pcap # 或直接转为其他格式再转回 tshark -r broken.pcap -w repaired.pcap

如果某个时间戳段的数据包损坏，可以用editcap的时间过滤把损坏区域剔除：

# 举例：只保留前300秒的数据 editcap broken.pcap filtered.pcap 0-300

5.4 十六进制查找定位关键字节

Wireshark的“查找包”功能支持十六进制值查找。当你知道某个恶意文件的关键特征时，比如PE文件的4D 5A或者MZ头，直接在查找框输入十六进制值4d 5a，Wireshark会在所有数据包中扫描包含该特征的包，对于从大型pcap中快速定位恶意文件传输非常高效。

我在做这次靶场分析时，就用这个功能快速定位了HTTP流中携带Base64编码字符串的起点，准确找到了载荷投递的Wireshark数据包，效率比肉眼翻包高得多。

5.5 关于流量加密的应对思路

如果pcap里看到TLS流量，而服务端的私钥又拿不到，能不能直接还原明文？

答案是看情况。有些恶意软件使用了TLS配置不严谨的加密传输，实际上会泄露一些元数据，比如SNI（服务器名称指示）以明文出现在ClientHello中。通过“统计 -> 解析为TLS”或者筛选tls.handshake.extensions_server_name，可以看到TLS流量的目标域名。在靶场环境中，这也是一种常见的线索获取方式。

但这篇文章的场景是HTTP明文传输，所以我们能直接还原载荷。如果后续遇到纯TLS加密的jar包，方法就完全是另一个方向了。

6. 这次实战后我的一些体会

靶场打多了你会发现，流量分析真正考验的不是会不会点Wireshark的按钮，而是能不能从一堆看似杂乱的数据包中建立出行为的逻辑链条。这次实战从SMB共享拖出pcap、提取HTTP载荷、修复截断的PE文件，本质上一直在回答三个问题：攻击者从哪里来，做了什么，留下了什么。

我个人在实际操作中的体会是：拿到pcap后，前10分钟一定要用来观察全貌，不要急着进到某个包里去。先把“协议分级”“对话”“端点”三个统计看明白，再决定下一步往哪个方向筛。很多新手一上来就输入http过滤，然后盯着几十个请求不知道看哪个——这是因为你跳过了“先看森林再看树”的步骤。

再说说载荷修复这件事。靶场里专门给了“truncated at tail”的提示，但真实环境中不会有这种注释。你需要靠PE头部的节表信息来判断文件是否完整，靠HTTP Content-Length和实际传输字节数来判断流量是否被中断，再靠Wireshark的Expert Info来确认连接异常点。这些能力不是看一遍文档就能掌握的，建议找几个公开的pcap样本库，反复练上几遍，形成肌肉记忆。

最后再分享一个小技巧：做完一轮流量溯源后，把你用到的筛选器、追踪过的流、导出的对象整理成一份时间线文档。这次靶场虽然只有一台SMB服务器和一个HTTP传输，但在真实事件里，攻击链路通常横跨多个主机、多个协议、多段时间窗口，没有时间线支撑，分析到后面一定会把自己绕晕。用Markdown表格记录关键时间点、源目IP、协议类型、事件描述，既方便自己回溯，也方便最终出报告。工具可以选Obsidian或Notion，不用太复杂，关键是养成“分析一阵、记录一段”的习惯。