在应急响应和攻防演练里流量分析永远是绕不开的一关。很多时候攻击者扫完、打进来、传完东西、擦完日志走人了但网络流量是会说话的。你手上只要有一份完整的pcap哪怕终端已经被还原干净攻击者干了什么、传了什么、想把什么藏在流量里都能一帧一帧地抠出来。这篇文章记录一次靶场实战攻击者通过SMB共享会话投递了一个pcap流量包里面藏着后续攻击行为的全部痕迹。我们要做的就是从SMB共享中把包拿出来用Wireshark完成一次完整的流量溯源最后从疑似数据流里提取出被篡改的传输载荷并尝试修复它。整个过程覆盖了SMB共享挂载、pcap过滤分析、流追踪、载荷提取和修复这几个关键技能点非常适合安全运营、蓝队应急、以及刚入门流量分析的朋友作为实战参考。1. 靶场环境与SMB共享连接先说场景。靶场内部网里有一台Windows Server主机被标记为“失陷主机”。情报显示攻击者曾在这台机器上开启过一个SMB共享共享目录里遗留了一个可疑的pcap文件。我们的任务是把包取出来分析清楚攻击者的完整攻击链路。1.1 环境拓扑与角色划分这个靶场的网络模型非常经典三台设备组成一个小型内网角色系统IP地址说明攻击机Kali Linux192.168.1.100模拟攻击者用于横向移动和数据共享受害主机Windows Server 2016192.168.1.20被攻破的服务器开启SMB共享分析机安全人员本机192.168.1.10我们用来分析pcap的工作站靶场提示受害主机的SMB共享目录名是shared共享路径为\\192.168.1.20\shared里面除了常规文件还有一个名为cap_20250212.pcap的流量包文件。这类场景在真实应急中也有对应原型攻击者拿到一台机器权限后经常会利用SMB共享来回传文件比如把内网扫描结果、抓到的密码哈希、甚至流量包临时存放在共享目录里方便后续其他工具读取。所以看到SMB共享上有奇怪的pcap文件别急着当垃圾删掉先拖下来分析。1.2 连接SMB共享并获取pcap包在Kali上连接SMB共享最常用的就是smbclient工具。如果你用的不是KaliWindows上也可以直接通过资源管理器访问或者用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秒内知道流量包的大致构成。我在这次靶场分析里看到的分布如下协议数据包数量占比备注TCP184272.5%SMB、HTTP等均基于TCPSMB262124.5%SMB相关会话流量HTTP2178.5%有HTTP请求响应重点关注TLS963.8%少量加密流量暂时放一边DNS451.8%域名解析请求其他401.2%广播、ICMP等这个分布透露了几个重要信息有SMB2流量说明这台机器确实存在SMB通信而且有600多个包应该是一次完整的SMB会话包含了文件枚举、读取等行为。有HTTP流量而且数量不少。在攻击链分析中HTTP是最常见的C2通道攻击者通过HTTP上传/下载数据非常普遍。有少量TLS流量目前先标记为“待定”加密流量无法直接读取明文但可以记录证书信息、SNI域名等元数据作为线索。再点“统计 - 对话”或者“统计 - 端点”看IP通信对和流量大小。通常情况下流量最大的那对IP就是主要分析对象。这次靶场里192.168.1.100Kali攻击机和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流。从流内容可以看到以下命令序列SMB2 Create Request File: readme.txtSMB2 Read Request从readme.txt中读取了内容SMB2 Create Request File: cap_20250212.pcapSMB2 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; charsetUTF-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流”会弹出流内容窗口。这个窗口分为上下两个区域分别展示了请求和响应的原始内容。如果你只想提取请求中的二进制载荷不要直接复制粘贴那样会因为文本渲染问题导致数据损坏。正确做法是在HTTP流窗口右键 - “另存为”保存为原始二进制文件。或者在主界面菜单“文件 - 导出对象 - HTTP”中选择对应的POST请求URI点击“Save”保存为二进制文件。我保存为payload_upload.bin。用file命令查看file payload_upload.bin # 输出: payload_upload.bin: datadata类型说明这不是一个已知的可执行文件格式文件头缺失或内容被加密/编码了。再看十六进制内容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字段明确提示base64data字段里也是典型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 修复截断载荷到了最关键的修复环节。这里有两个问题需要解决文件尾部确实少了一截导致PE结构不完整。靶场给的是截断后的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 常见问题速查表问题可能原因解决办法smbclient连不上目标共享SMB协议版本不匹配加-m SMB3或-m SMB2强制指定版本Wireshark打开pcap为空pcap链路类型不是Ethernet用capinfos查看链路类型可能是Linux loopback等需避免误判HTTP对象导出不完整Wireshark处理Content-Length边界有bug改用“追踪TCP流”后按原始模式保存再脚本切割Base64解码后不是可执行文件载荷可能是加密或嵌套了多层编码用file先看格式用strings提取可读信息辅助判断pcap里HTTP流和SMB流时间对不上攻击者使用了代理或多跳全局时间线排序关注TCP连接建立时间建多个过滤器交叉确认提取的载荷文件显示data类型文件头缺失或被编码检查文件的前16~32字节结合上下文还原文件头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-3005.4 十六进制查找定位关键字节Wireshark的“查找包”功能支持十六进制值查找。当你知道某个恶意文件的关键特征时比如PE文件的4D 5A或者MZ头直接在查找框输入十六进制值4d 5aWireshark会在所有数据包中扫描包含该特征的包对于从大型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不用太复杂关键是养成“分析一阵、记录一段”的习惯。