手里拿到一道靶场题名字写得很直白“通过 SMB 共享获取 pcap 流量包Wireshark 溯源攻击者并提取修复传输载荷”。说白了就是一套完整的流量取证流程先想办法从 SMB 共享里把攻击者留下的 pcap 抓包文件搞到手再用 Wireshark 把这个文件掰开揉碎还原出攻击者当时干了什么最后从流量里把恶意传输载荷捞出来处理干净变成能直接分析或应急响应的样本。这套东西在真实应急响应和威胁狩猎里特别实用搞蓝队、做安全运维、或者正在入门流量分析的朋友照着走一遍基本就能摸清“从流量中还原攻击行为”的标准姿势。我先把整个流程拆开来讲从靶场思路、环境准备到 SMB 连接、pcap 分析再到载荷提取、修复落地每一步都配上实操记录和踩过的坑。1. 靶场任务拆解这条溯源链路到底在考什么1.1 四个关键词串成的一条证据链这个标题里其实塞了四个关键词SMB、pcap、Wireshark、传输载荷。很多人一看到“一堆工具名”就头晕觉得是四件独立的事其实它们是一条完整证据链上的四个环节。SMB 是这题里的传输通道。真实内网里 Windows 机器之间共享文件、打印机、各种管理通道走的都是 SMB445 端口遍地都是。攻击者拿下内网一台机器后大概率会通过 SMB 横向移动把工具传过去把数据传出来。这个流量不会消失要么被抓包软件截获要么被网络侧的审计系统记录下来落成一个 pcap 文件。pcap 就是“案发现场的监控录像”。它保留了流量的时间戳、源目的 IP、端口、协议细节甚至还能还原出当时传输的文件内容。Wireshark 就是播放这个录像的播放器只是它比普通播放器多一个“逐帧慢放 数据透视”的能力。而传输载荷就是录像里攻击者真正想塞进去的东西——一个木马文件、一段 PowerShell 命令、一个 webshell都有可能。所以这道题考的不是单点工具的使用而是你能不能把“通道发现—流量取证—行为还原—样本提取”这条链路完整跑通。很多新手卡住不是因为不会点 Wireshark 的按钮而是脑子里没有这条链看到 pcap 就盲目点点点最后啥也没看出来。1.2 为什么靶场偏偏选了 SMB 当入口我见过不少靶场和真实案例攻击链之所以选 SMB 共享当入口是有实际考虑的。第一SMB 在真实环境里覆盖率极高。办公网里总有几台机器开了共享什么“公共盘”“部门共享文件夹”一抓一大把。攻击者不需要费劲去找一个冷门协议直接用最常见、最不缺目标的方式就能完成投递。第二SMB 是 Windows 生态的原生协议很多安全设备对它的检测粒度比较粗攻击者把恶意文件通过 SMB 共享传进去比走 HTTP 上传更容易被忽略。第三SMB 流量本身结构复杂里面会嵌套命名管道、RPC 调用、文件写入操作分析起来比单纯看 HTTP 请求难一个量级正好用来练手。靶场这么设计本质上是逼你去练两个硬功夫一是“在杂乱流量里快速找出异常会话”的能力二是“从协议字段里精确还原文件数据”的能力。这两点在真实溯源里都是吃饭的本事。2. 前置准备搭建分析环境并连接 SMB 共享2.1 分析机环境清单拿到这种题不要急着去连靶场先把分析环境备齐不然中途缺工具会非常难受。我建议直接拿 Kali 当主力分析机因为 Kali 里 smbclient、mount.cifs、tshark 都是预装好的省去不少麻烦。Wireshark 建议用 4.x 以上的版本老版本对 SMB2 和 SMB3 的解析有些字段不完善遇到分片写请求容易翻车。除了 Wireshark我还会装这两个工具tsharkWireshark 的命令行版本批量提取字段比鼠标点快得多后面提取载荷要大量用它。hexedit 或 HxDWindows 下用处理原始字节修分片、看十六进制都离不开。另外建议准备一个 010 Editor 或者 Notepad 加 Hex Editor 插件用来直接打开 pcap 文件看文件头。后面有一个坑——有的靶场给的“pcap”其实是 pcapng 格式文件名却是 .pcap直接拿 Wireshark 能打开但用某些脚本读取时就会报魔法字节错误提前看一眼文件头能省很多时间。2.2 实测连 SMB 的三种姿势连接 SMB 共享实操里最常见的就是下面三种方式我一个个说。第一种交互式客户端 smbclient。这是最常用、也最轻量的方式smbclient //192.168.1.20/share -U analyst%Passw0rd进去之后就是 FTP 风格的交互界面ls 看目录、get 下载文件、put 上传文件。如果靶场开了匿名访问可以不加 -U直接 smbclient //IP/share 试试能不能免密进去。我实战中遇到过很多次匿名可读的共享里面就扔着一个流量包连口令都不需要。第二种挂载到本地目录。当你要从共享里下载大量文件或者打算直接在共享目录上跑工具的时候smbclient 的逐个下载效率太低直接用 cifs 挂载更舒服mkdir /mnt/smb mount -t cifs //192.168.1.20/share /mnt/smb -o usernameanalyst,passwordPassw0rd,vers3.0,iocharsetutf8注意这个 vers 参数很重要SMB 协议版本有 1.0、2.0、2.1、3.0 之分靶机的 Windows 版本不同能协商的版本也不一样。如果用默认参数挂载失败报 “mount error(112): Connection refused” 或者协议协商错误改成 vers2.0 或 vers1.0 再试。Windows Server 2008 时代的靶机有时只有 SMB 1.0需要明确指定 vers1.0虽然老但这是靶机实际情况。第三种图形化访问。如果你用的不是 Kali而是 Windows 分析机直接 WinR 输入\\192.168.1.20\share会弹窗让你输凭据进去了就是资源管理器界面。这种方式适合快速浏览不适合做精确的取证下载因为资源管理器有时候会偷偷缓存或加锁下载文件的哈希和源文件不一致虽然概率低但取证场景下我不建议用图形方式下载关键物证。2.3 拉取 pcap 前先做取证留痕拿到共享访问权限之后不要看到 pcap 就闷头 get先做三件事第一ls 查看目录里的文件注意看修改时间、文件大小。某个 pcap 文件如果时间正好卡在靶场公告的“攻击发生时间段”那基本就是关键物证了。第二用 file 命令确认格式file capture.pcap如果输出是 “pcap capture file, microsecond timestamps”说明是经典 pcap 格式。如果输出是 “pcapng capture file”那就要注意后面工具的选择。第三计算哈希留存md5sum capture.pcap这一步是取证习惯。后面你分析完如果怀疑 pcap 被人动过手脚这个哈希能帮你验明正身。我就吃过亏分析到一半发现数据逻辑不对回去一验哈希发现自己下载的文件和共享里的原始文件根本不一样——共享原来绑的是被攻破的机器文件被其他分析师改了。下载文件时用 smbclient 的 get 或者挂载后的 cp都要确保磁盘空间足够pcap 文件有时候非常大几个 GB 也不稀奇提前 df -h 看一眼。3. Wireshark 流量分析从杂乱包中定位攻击者行为链3.1 打开 pcap 后的第一步不是点包而是先看整体很多人拿到 pcap打开 Wireshark 就开始盯着第一屏的包乱翻这是大忌。流量分析跟看病一样先做全身检查再精准定位病灶。先看 Statistics - Capture File Properties那里显示包数量、时间跨度、文件格式。重点看时间跨度如果靶场说明攻击发生在某天而 pcap 里只有几分钟的流量那这几分钟一定高度浓缩了攻击行为可以放心放大来看。再看 Statistics - Protocol Hierarchy按协议占比看个大概。正常情况下一个内网靶场 pcap 里ARP、TCP、SMB 会是主流。如果发现 TLS 或 HTTP 占了大头那后面分析思路要往 C2 通信方向偏如果 SMB 流量异常多那八成就是题目想让你注意的点。截图不方便放但你可以自己在 Wireshark 里点开这两项信息量非常大而且能帮你建立全局观。3.2 用会话列表快速锁定可疑 IP 对整体画像看完后下一步就是找到“谁和谁在通信”。点 Statistics - Conversations切到 TCP 标签页按“Bytes”列排序。通常攻击者会从自己机器往靶机传文件所以那一对 IP 的会话字节数会明显高于其它。我在这个靶场里看到的情况是一个 IP 和 SMB 服务器之间产生了超过 90% 的 TCP 流量其中大量是 SMB WRITE 请求——这就是攻击者在下发文件。记住可疑 IP 之后可以用显示过滤器把它锁死ip.addr 192.168.1.10然后再叠加协议过滤比如想看它跟 SMB 相关的交互ip.addr 192.168.1.10 smb2这里 SMB2 对应 Windows 7/2008 及以后的系统如果靶机更老可能要过滤 smb 或 msmb。观察一会儿就能看到攻击者完整的行为链条先连上共享然后创建文件再向文件里写数据最后可能是断开连接或者继续执行其他命令。3.3 通过特征还原攻击行为链光知道谁和谁通信还不够要还原攻击行为得看关键的 SMB 命令。在 Wireshark 的显示过滤器里SMB 家族的命令是分得很细的。我常用这么几组smb2.cmd 5 # SMB2 WRITE写文件操作 smb2.cmd 2 # SMB2 CREATE创建/打开文件 smb2.cmd 4 # SMB2 READ读文件操作 smb2.cmd 6 # SMB2 SET_INFO smb2.cmd 9 # SMB2 TREE_CONNECT如果攻击者是先创建了一个文件再持续往里面写入数据那在过滤结果里你会看到 CREATE 请求后面跟着一大堆 WRITE 请求。鼠标点开一个 WRITE 请求在 Packet Details 面板里能找到偏移量Offset和数据长度Length这些字段在后面提取载荷时就是关键坐标。如果是爆破攻击你会看到大量 SMB2 SESSION_SETUP 请求且响应里的状态是 STATUS_LOGON_FAILURE。我经常会用下面这个过滤器快速统计smb2.cmd 13 # SMB2 SESSION_SETUP再配合 ntlmssp 字段比如过滤 ntlmssp.messagetype 3可以直接把 NTLM 认证请求都筛出来。如果这种消息在一小段时间内出现几十次基本可以断定是口令爆破。如果是利用 SMB 相关漏洞进行攻击流量里可能会出现畸形或者异常长度的 TRANS2 请求、异常命名管道访问比如访问 IPC$ 共享里奇怪的服务名这些特征很值得注意。靶场题一般不会让你从零逆向漏洞利用细节能识别出“这里不对劲”就够了。3.4 Follow Stream把散包拼成对话定位到重点会话后右键某个包选择 Follow - TCP StreamWireshark 会把整个 TCP 连接里的双向数据按顺序拼成一段连续的字节流。这一步特别适合快速看明文内容。SMB 流量里有一部分是明文协议头比如 SMB2 的头部有固定的 “\xfeSMB” 签名后面跟着命令和文件路径这些在 Follow Stream 里看起来会像乱码加夹杂着可读字符串。别慌我们不是要肉眼看完整内容而是要定位“数据从哪开始、到哪结束”。尤其当你看到类似 MZ 头PE 文件开头或者 7F 45 4C 46ELF 文件头这样的字节特征那就说明传输载荷已经出现可以进入下一步提取了。4. 提取并修复传输载荷从原始字节到可分析样本4.1 用 Export Objects 快速导出 SMB 传输的文件Wireshark 有一个“从流量里导出文件”的功能简直是取证神器。File - Export Objects - SMBWireshark 会解析所有通过 SMB 传输的文件对象列出一个表格包括文件名、大小、传输时间、MD5 哈希。选中可疑文件点击 Save 就能直接导出。这个功能对传输完整、且没有被分片搞乱的文件非常高效。但我必须提醒一句Export Objects 导出的文件有时和攻击者真正传输的原始内容并不完全一致因为 SMB 协议可能在数据传输前加了元数据或者文件被分片后部分包丢失。所以导出的文件只能作为参考要拿到最干净的载荷还是得走下面这种更精细的提取方式。4.2 用 tshark 按偏移量提取 SMB WRITE 数据当你要从一堆 WRITE 请求里把真实文件数据抠出来最可靠的方式是用 tshark 提取字段然后按偏移量重组。原理是这样的SMB2 的 WRITE 请求里每个包都带一个 Offset 字段表示这段数据要写到文件中的什么位置还有 Length 字段表示数据长度。攻击者传一个大文件时会把文件切成很多个 WRITE 请求一块块发出去。我们要做的就是抓出所有 WRITE 请求里的数据按偏移量摆回正确的位置。一条命令就能提取所有 SMB2 WRITE 的原始数据字段tshark -r capture.pcap -Y smb2.cmd 5 -T fields -e tcp.stream -e smb2.offset -e smb2.length -e smb2.write.data如果你用的是老靶机SMB1 的话字段名会不一样用 smb.offset 和 smb.data 试试。输出会是类似这样的内容12 0 4096 MZ... 12 4096 4096 ... 12 8192 4096 ...第一列是 TCP 流编号第二列是文件内偏移第三列是长度第四列是十六进制数据。把同一流号的数据按偏移量拼接起来就得到了一个接近原始文件的 payload。这里我给一个小脚本思路用 Python 处理上面 tshark 的输出import sys payload bytearray() for line in sys.stdin: stream, offset, length, data line.strip().split(\t, 3) if int(stream) ! 12: # 选定目标流 continue offset int(offset) raw bytes.fromhex(data.replace(:, )) # 确保缓冲区够大 if len(payload) offset len(raw): payload.extend(b\x00 * (offset len(raw) - len(payload))) payload[offset:offset len(raw)] raw open(payload.bin, wb).write(bytes(payload))注意一点在 Wireshark 的某些版本里-e smb2.write.data 输出的十六进制字符串会带有冒号分隔符比如 “4d:5a:90:00”Python 处理时需要先把冒号去掉。上面代码里 replace(:, ) 就是干这个的。不同 Wireshark 版本的字段输出格式略有差异建议先提取一行出来肉眼确认一下再写脚本。4.3 处理“脏数据”padding、编码和分片通过 SMB 传输的文件提取出来之后很少是干干净净的原始样本常见的有三类问题。第一类是尾部 padding。SMB 写请求的数据长度往往是按 8 字节或 16 字节对齐的也就是说文件真实长度是 1000 字节最后一个 WRITE 请求里可能带了 1008 字节的数据多出来的 8 个字节是填充。拼接完所有数据后需要自己判断真实文件长度。判断方法很简单先看文件头比如 MZ 头后面找到 PE 头再看文件尾部是不是有一串无意义的 00 或周期性填充字节。也可以用 file 命令先猜一下比如 file payload.bin 报错说 unrecognized往往就是尾部长了或头部偏移不对。第二类是编码包装。有些载荷在传输前会被攻击者用 base64、十六进制甚至 URL 编码包装一下。头部特征通常是 “TVqQAAMAAAAEAAAA/...” 这种以大写字母开头的长字符串——注意 “TVqQ” 就是 “MZ” 的 base64 编码。如果你提取的数据一看全是可读字符没有二进制头那多半是编码过的先用 base64 -d 解码cat payload.b64 | base64 -d payload.bin解码完再看文件头。有些攻击者为了过检测还会做二次编码比如先 hex 再 base64那就要多解几层。判断“解几层”的诀窍是每解一层用 file 看一次类型直到它变成真正的可执行文件或脚本。第三类是分片乱序。tcp 流的重组在 Wireshark 里做得很漂亮但如果你直接用 tshark 提取下来的数据拼接可能遇到乱序的问题。这种情况推荐回到 Wireshark GUI右键任意一个 WRITE 包Follow - TCP Stream把 Stream 内容 “Show data as Raw”另存为二进制文件。Wireshark 会按正确的 TCP 序列号把数据排好省去自己拼偏移量的麻烦。4.4 修复并确认载荷的有效性拿到 payload.bin 之后按顺序做这几步file payload.bin xxd payload.bin | head -20 strings payload.bin | head -50file 会告诉你它是什么类型。如果识别成 “PE32 executable” 或 “ELF 64-bit executable”基本就成功了一大半。如果 file 识别不出来就用 xxd 看头部十六进制。我遇到过一次情况文件头是 “63 6D 64 3A 2F 63” 也就是 ASCII 字符串 cmd:/c那其实不是一个二进制文件而是一段命令行指令攻击者把命令包装成文件写在共享里用来触发下载下一阶段工具。确认载荷有效后再计算哈希md5sum payload.bin这个小哈希在应急响应里非常值钱。你可以拿它去威胁情报平台查看这个文件是否已经被标记为恶意。就算查不出来把这个哈希写进检测规则比如 Suricata 或 YARA下次这个文件再出现在内网里就能第一时间报警。5. 实操中常见的坑与排查实录5.1 SMB 共享连不上按这个顺序排查我在这类靶场实操里SMB 连不上的情况起码占了三成原因五花八门。最常见的五个坑现象可能原因解决动作mount error(112): Connection refused目标 445 被防火墙拦或服务没启动确认靶机防火墙确认 smbd 服务状态Protocol negotiation failedSMB 版本不匹配换 vers1.0 / 2.0 / 3.0 重试NT_STATUS_ACCESS_DENIED凭据错误或者无权限检查用户名密码尝试匿名访问NT_STATUS_LOGON_FAILURE用户名或密码不对核对靶场提供的凭据NT_STATUS_DUPLICATE_NAMEIP 或主机名冲突检查本机 IP 是否和靶场网段重叠还有一个隐蔽的坑Kali 自身如果开了防火墙比如 ufw也可能到不了靶机。先 ping 一下再看端口nc -vz 192.168.1.20 445这个命令能快速判断是网络层可达性问题还是 SMB 服务本身的问题。5.2 Wireshark 只显示 520 字节其实不是数据丢了很多新手打开 Wireshark 看到数据包内容栏只有 520 字节就以为 pcap 被截断了其实有两个完全不同的可能性。第一种可能抓包时设置的 snaplen 太小。wireshark 抓包时默认是 262144 字节上限但如果你在 Capture Options 里把 “Limit each packet to” 设成了 520那么超出部分根本不会被记录文件里就只有前 520 字节。这种情况下显示 520 是对的但数据确实不完整需要重新抓包。判断方法是看包信息里有没有 “[Packet size limited during capture: ...]” 字样。第二种可能Wireshark 的 Packet Bytes 面板显示区宽度有限虽然包里实际有 2090 字节但界面上只显示出一部分。解决方式是鼠标拖大 Packet Bytes 面板或者点击面板左上角的箭头按钮扩展。也可以右键该面板选择 “Set 16/8 bits per byte” 切换显示格式而不是直接认为数据丢失。5.3 pcap 转文本导出后乱码或导入 Excel 报错把分析结果导出给同事或者写报告时经常要把 pcap 转成 txt 或 CSV。tshark 是首选tshark -r capture.pcap -Y smb2.cmd 5 -T fields -e frame.number -e ip.src -e ip.dst -e smb2.offset -e smb2.length dump.tsv这里 -T fields 配合 -e 参数可以按你需要提取的字段输出。导出后用 Excel 打开 TSV 文件如果中文乱码一般是因为文件没有 BOM 头用记事本另存为 UTF-8 with BOM或者用 WPS 打开时选择 UTF-8 编码即可。如果 Excel 导入报错多半是分隔符问题TSV 应该用“制表符分隔”导入而不是逗号。至于“导入数据时候出错”这类问题我还见过是因为文件里包含不合规的十六进制字符导致 Excel 把某些列识别成科学计数法。处理方式是导出前在 tshark 命令里把提取的字段用引号包起来或者提前把二进制数据列去掉只导出元数据列。5.4 大 pcap 卡死AI 辅助分析怎么用靶场的 pcap 还不算太离谱但真实场景里一个 pcap 动辄几个 GBWireshark 打开都卡半分钟。遇到大文件我在项目里一般这么做先用 editcap 按时间切片只留攻击时间窗口的数据editcap -A 2025-01-10 09:00:00 -B 2025-01-10 09:10:00 big.pcap window.pcap然后在这个小窗口里做深入分析。要是还卡就纯 tshark 批量提取别开 GUI。这两年 AI 辅助分析也火我的用法是把关键会话用 tshark 导出成纯文本去掉二进制乱码部分只保留请求响应的摘要字段然后喂给大模型让它帮我看协议交互的先后逻辑。注意不要直接把几千行的原始十六进制 dump 整个丢进去模型会迷失。保留这种格式2025-01-10 09:00:01 192.168.1.10:49152 - 192.168.1.20:445 SMB2 CREATE File: share\\update.exe 2025-01-10 09:00:01 192.168.1.10:49152 - 192.168.1.20:445 SMB2 WRITE Offset:0 Len:4096模型在这种结构化输入下能较快帮你梳理出攻击步骤轮廓但最后的证据确认和载荷提取还是得靠你手动完成别全指望它。5.5 二进制查看 pcap 文件头的冷门技巧有些场景下Wireshark 打不开 pcap或者你怀疑这个文件不是真 pcap那就用十六进制工具直接看文件头。经典 pcap 文件头的前四个字节是固定的魔法字节d4 c3 b2 a1小端序或 a1 b2 c3 d4大端序后面跟着版本号、时间戳精度等字段。pcapng 则不同文件头是 0a 0d 0d 0a。用 xxd 看一眼xxd capture.pcap | head -4如果是 0a 0d 0d 0a 开头说明是 pcapng 格式虽然 Wireshark 能打开但部分老工具比如某些 Python 库默认只解析 pcap 格式会报错。这时候要么用 Wireshark 另存为 .pcap要么用 editcap 转换格式editcap -F pcap capture.pcapng capture.pcap6. 分析过程中的记录习惯与经验沉淀最后聊点我自己的实操习惯跳过总觉得少了点什么。流量分析到一半如果发现了攻击者的 IP、下载到的恶意样本哈希、SMB 共享路径里的文件名我会第一时间记到一张草稿表里。这个不光是交报告用而是分析过程本身就需要不断回看“我最早是怎么筛到这个流的”“中间哪一步把思路带偏了”。把关键判断点记录下来后面复查会轻松很多。另外我建议手头常备一份常见的 SMB 命令速查写到自己的笔记里。SMB2 CREATE 是 2READ 是 4WRITE 是 5SET_INFO 是 6SESSION_SETUP 是 13。这些数字记多了自然就熟悉了临时翻文档真的容易打断思路。再加上 Wireshark 的显示过滤器语法比如组合过滤 ip.addr、tcp.port、smb2.cmd能把分析速度提高一个量级。还有一个经验Wireshark 里看到包含 SMB 的流量不要只在 Packet List 里看一定要下钻到 Packet Details把 SMB 头部展开。很多关键数据文件路径、写入偏移、打开标志都藏在细节里列表视图根本显示不全。用鼠标点开这些字段的时候记得留意左下角的状态栏Wireshark 经常会提示你某个字段的取值含义这对理解 SMB 协议行为非常有帮助。