企业官网建设流程全解析

前阵子在某次内部红蓝对抗的靶场里，我接到一个比较典型的取证任务：红队在一台 Windows Server 上留了痕迹，但系统日志被清得差不多，事件目录基本是空的。唯一扎眼的是，这台机器多了一个名字很普通的共享目录，里面躺着一个 pcap 文件。看到这个共享的时候，我基本能确认两件事——要么是红队故意留了线索等我们还原，要么是他们转移文件时漏了一手。不管哪种，这个 pcap 都是还原整条攻击链最重要的原始物证。

后面整个流程，就是通过 SMB 共享把 pcap 取回来，用 Wireshark 一点点做流量溯源，把攻击者的 IP、行为和时序理清楚，最后从流量里把传输载荷提取出来、修复成可分析的样本。整个过程不算复杂，但每一步都有不少容易踩的坑。这篇文章就把这条链路完整拆开，从环境准备、SMB 挂载、Wireshark 分析，到载荷提取与修复，一次性讲透。

1. 先搞清楚这一套操作到底在做什么

很多人拿到 pcap 的第一反应是直接打开 Wireshark 翻包，这其实是最低效的路径。所谓“溯源攻击者”，并不是只看某一个可疑包，而是要把整个攻击时间线还原出来。所以动手之前，先花几分钟把任务拆明白，后面能省一大半时间。

1.1 SMB 共享为什么成了流量包的“中转站”

SMB 本身就是 Windows 文件共享的默认协议，内网里到处都是 445 端口的流量。红队拿到一台主机权限后，最自然的操作之一就是开一个共享目录存放工具、输出结果或者抓到的流量包。这个行为放进真实的攻防场景里非常常见，正因如此，分析人员也需要熟练掌握通过 SMB 获取文件的方式。

对我这类做流量分析的人来说，SMB 共享不只是“取文件”这么简单。它意味着三件事：第一，攻击者可能把这里当成临时文件中转站；第二，SMB 协议自身的访问日志和流量特征可以反推攻击者的来源 IP；第三，共享里的 pcap 往往是最真实的“攻击现场记录”，比系统日志可信度高得多。所以看到共享目录时，不要只想着把文件拷走，还要顺手把 SMB 会话相关的流量、日志一并保留。

从靶场设计角度看，这个环节也模拟了真实事件响应中“从受控主机提取物证”的操作流程。把 pcap 放到 SMB 共享里，比直接拖到 U 盘或者用 FTP 传更贴近实际场景，而且 SMB 传输本身就能在后续流量分析中形成一条完整的行为记录。

1.2 场景拆解：攻击路径与取证链路

这次靶场任务我把它拆成了四条线：攻击线、痕迹线、取证线、还原线。

攻击线是红队如何进来、做了什么；痕迹线是主机上剩下了什么；取证线是我要通过 SMB 拿到什么数据；还原线则是我拿到 pcap 之后如何通过流量把前三条线串起来。

单纯从取证的链路来看，顺序是这样的：红队攻击某一台机器后，在目标主机上开启 SMB 共享，并把抓包结果保存为 pcap 文件；防御侧发现异常后，通过 SMB 客户端挂载共享，把 pcap 取回分析机；接着用 Wireshark 做协议统计、会话还原、特征过滤，定位可疑 IP 与行为；最终从流量中提取传输载荷，修复文件损坏或解码编码数据，得到可进一步分析的样本。

这条链路里，最核心的原则是“先宏观后微观”。先看整个 pcap 的协议分布和会话记录，再顺着网络特征一步步收敛到具体的攻击行为，而不是一上来就对着某个可疑包死磕。这个原则在后面第 3 章会展开讲。

1.3 工具组合选型：为什么是 pcap + Wireshark

pcap 是 libpcap 定义的标准抓包文件格式，也是 Wireshark、tshark、NetworkMiner、Zeek 这些工具都能直接解析的通用格式。它的优势在于：兼容性强，几乎所有的抓包设备和软件都支持；信息完整，每一个数据包的时间戳、长度、协议头、负载数据都在；可还原性好，只要抓包时没有截断，理论上流量里传输的文件都能提取出来。

Wireshark 则是目前最主流的图形化流量分析工具。它的过滤器语法、协议解码器、统计图表和导出对象功能都足够成熟，尤其适合做人工溯源。配合命令行工具 tshark，还能把分析过程自动化，批量提取字段、转换输出格式。所以我常说，Wireshark + tshark 的组合，基本能覆盖流量取证的九个环节，从最基础的抓包看到最深入的载荷还原都够用。

2. 通过 SMB 共享把 pcap 流量包拿到手

SMB 挂载是个看似简单、实际操作起来很容易卡住的环节。版本不匹配、凭据不正确、防火墙拦截、共享名猜错，任何一步出了问题都会让流程断掉。我按自己的实战顺序把完整过程写出来。

2.1 靶场环境准备与共享配置检查

这次靶场我用的是一套比较标准的环境：攻击机用 Kali，目标机是一台 Windows Server，分析机也是 Kali，三者都在同一个虚拟网段里。红队在这台 Windows Server 上创建了一个名为red_team的共享目录，里面放着目标 pcap 文件。

拿到任务后，第一步不是急着挂载，而是先做连通性检查和共享列举。先用 ping 确认目标主机在线，再用 smbclient 的列举命令看目标机器对外开放了哪些共享。

ping -c 4 10.10.10.20 smbclient -L //10.10.10.20 -U analyst

这里有一个细节：smbclient -L不仅能看共享名，还能顺便验证凭据是否有效。如果目标主机开了防火墙或者 SMB 服务没起来，这一步就会直接报错。靶场里很多挂载失败的情况，其实在列举这一步就已经暴露了，只不过大家习惯直接挂载，反而忽略了更前置的检查。

如果连不上，我会接着检查 445 端口是否开放。Kali 里可以用 nc 或者 Nmap 扫一下。

nc -zv 10.10.10.20 445 nmap -p 445 --script smb-protocols 10.10.10.20

Nmap 的smb-protocols脚本还能直接看出目标系统启用了哪些 SMB 版本，这对后面选择挂载参数很有帮助。如果目标只开了 SMB 1.0，而你的客户端默认尝试 SMB 3.0，就会遇到版本协商失败的问题。

2.2 Kali 挂载 SMB 共享的三种姿势

我常用的方式有三种，按场景不同选择。

第一种是 smbclient 交互式访问，适合快速查看共享内容和下载单个文件。

smbclient //10.10.10.20/red_team -U analyst

进入共享后，用ls查看目录内容，用get capture.pcap下载文件，用exit退出。这个方式最轻量，适合临时查看。我实际操作时还喜欢加一个-c参数，一次性完成查看和下载，少敲几条命令：

smbclient //10.10.10.20/red_team -U analyst -c "ls; get capture.pcap"

第二种是把共享直接挂载到本地目录，适合需要持续访问共享里多个文件、或者在共享目录里临时做分析的情况。Kali 下用 mount.cifs。

mkdir -p /mnt/red_team mount -t cifs //10.10.10.20/red_team /mnt/red_team -o username=analyst,password=Passw0rd,vers=3.0,iocharset=utf8

这里重点说几个参数。vers=3.0是 SMB 协议版本，需要和目标主机协商一致；iocharset=utf8解决中文文件名乱码问题；file_mode和dir_mode可以控制挂载后文件的权限，如果后续要执行文件分析，建议显式指定：

mount -t cifs //10.10.10.20/red_team /mnt/red_team -o username=analyst,password=Passw0rd,vers=3.0,file_mode=0644,dir_mode=0755,iocharset=utf8

第三种是在 Windows 分析机上挂载。如果靶场分析机是 Windows，直接用 net use 命令最方便：

net use Z: \\10.10.10.20\red_team /user:analyst Passw0rd

net use 的优点是系统原生支持，不依赖额外工具。但要注意挂载成功后，Windows 会缓存凭据，后续如果切换账号分析，最好先执行net use Z: /delete把旧会话清掉，避免影响判断。

2.3 SMB 挂载失败的定位思路

我把自己踩过的坑总结成一套排查顺序，从外到内逐步收敛。

网络层面先确认三层通不通，再确认四层 445 是否开放。靶场里最常见的失败原因是虚拟机网段隔离，两台机器根本不在同一个网段，ping 都不通，后面一切免谈。

服务层面确认目标主机的 Server 服务是否运行、SMB 是否被禁用。有些加固过的 Windows 会主动关闭 SMB 服务，或者只保留 SMB 1.0。这里有一个快速判断方法，在 Windows 上执行：

Get-SmbServerConfiguration | Select EnableSMB1Protocol, EnableSMB2Protocol

如果 SMB2 协议被关闭，而客户端强制用 vers=3.0 会导致协商失败。这种情况下要么在目标主机重新启用协议，要么在客户端用vers=1.0（如果你确定环境安全，只是靶场拉到文件，临时使用是可行的，但我个人建议优先调整服务端，而不是降低协议版本）。

权限层面确认账号是否有共享目录的访问权限。很多 Windows 共享目录的共享权限和 NTFS 权限是双重控制的，即使共享权限给了 Everyone，NTFS 权限没有读权限一样报错。挂载时如果提示NT_STATUS_ACCESS_DENIED，基本都是这个原因。

防火墙层面要确认 SMB 相关规则是否放行。Windows 防火墙默认会拦截 445，靶场里需要在高级安全防火墙里放行“文件和打印机共享”规则，或者干脆把防火墙临时关闭用于调试。我一般是放行规则而不是直接关防火墙，这样更接近真实环境，也避免后续分析时误导判断。

3. 用 Wireshark 溯源攻击者：别一上来就翻包

拿到 pcap 之后最忌讳的就是双击打开然后海量翻包，这样看两小时也看不出所以然。熟练的分析人员会先让 Wireshark 把统计结果告诉我们，再用过滤器收敛到具体可疑流量。

3.1 从全局统计入手建立流量画像

打开 pcap 后，我第一件事永远是看 Statistics 菜单下的几个基础统计。

先用Statistics -> Protocol Hierarchy看整个流量里的协议分布。这一步能快速知道包里都有什么协议，HTTP 多不多、SMB 多不多、有没有明显的 TLS 加密流量、有没有 DNS 异常请求。如果某个协议出现在一个理论上不该出现的位置，那就是重点关注对象。

然后看Statistics -> Endpoints，按 IPv4 标签页排序。这里能看到每个 IP 的收发包数量和字节数。通常攻击者 IP 会有两个特征：一是与目标主机通信量明显高于其他主机，二是会连接多个目标端口。如果某个 IP 在列表里特别突出，我会直接标记为嫌疑对象。

接着看Statistics -> Conversations，切换到 TCP 标签页。这里能看出每个 TCP 会话的持续时间、上下行字节数。攻击者在利用漏洞或者上下传文件时，往往会产生大流量会话，而且方向特征明显。例如下行 5 兆、上行几十 KB 的会话，很可能就是文件下载。

最后用Statistics -> IO Graph看一下时间维度上的流量分布。这一步对发现周期性通信特别有用。攻击者的 C2 心跳往往是固定时间间隔的小流量，比如每 30 秒一次 200 字节的请求，图标上会呈现非常规律的脉冲。这种特征在纯协议统计里看不出来，但在 IO Graph 里一眼就能辨认。

3.2 顺着协议栈和会话还原攻击链条

全局统计做完之后，心里已经有了几个可疑 IP 和几条可疑会话。接下来就是顺着会话把攻击链条接起来。

举一个这次靶场里的实际例子。我在 Endpoints 里发现 IP 为10.10.1.50的地址，给目标主机发了大量 SYN 包，而且访问了 445、3389、80 三个端口。典型的扫描行为之后，它通过 445 端口与目标建立了连接，随后有几次 SMB2 的读写操作。

此时我会用过滤器把这个 IP 的所有流量都拉出来：

ip.addr == 10.10.1.50

再从这些流量里看是否存在文件读写痕迹。SMB2 协议里，读取文件对应smb2.cmd == 8（SMB2_READ），写入文件对应smb2.cmd == 6（SMB2_WRITE）。用过滤器限定一下：

smb2.cmd == 6 && ip.addr == 10.10.1.50

如果看到攻击者向共享目录写入文件，那基本就能还原出红队“通过 SMB 共享留文件”的动作。再追踪这条 TCP 流，右键选择 Follow TCP Stream，就能看到完整的 SMB 会话内容。虽然 SMB 协议本身的载荷格式不适合直接阅读，但文件操作的对象、时间、长度都能从里面提取出来。

HTTP 和 HTTPS 流量同样重要。在 sniff 到的交互里，如果攻击者通过 Web 漏洞上传了脚本，或者目标主机向某个外部地址下载了恶意文件，过滤http.request || tls.handshake.type == 1可以把所有 Web 请求和 TLS 握手列出来。我习惯再配合http.request.method == POST过滤，重点看有没有数据外传的可疑 POST 请求。

3.3 解密 TLS 流量与关键过滤规则

很多流量在传输时是加密的，尤其是 C2 通信和 HTTPS 下载。如果 pcap 里恰好记录了客户端和服务器之间的 TLS 握手，同时我们又拿到了密钥日志或者服务器私钥，就可以在 Wireshark 里把密文解出来看明文。

解密 TLS 有两种途径。第一种是配置客户端 SSLKEYLOGFILE，让客户端把每次会话的主密钥都记下来，然后把密钥文件导入 Wireshark。这是目前最常用的方法，因为现代 TLS 大多用 ECDHE 做密钥协商，即使拿到服务器私钥也无法解密流量，但 keylog 文件可以直接恢复每个会话的密钥。在 Wireshark 里打开Preferences -> Protocols -> TLS，把(Pre)-Master-Secret log filename指向密钥文件，重新打开 pcap 即可。

第二种是导入服务器 RSA 私钥。这种方式只在密钥交换算法为 RSA 时有效，现实中已经很少见了，但在靶场和内部系统中偶尔还能遇到。配置路径在同一个 TLS 设置界面里，点击 Edit 添加 RSA key 文件。

解密之后，原本看起来是乱码的 TLS 流量就会变成可读的 HTTP 请求、响应和 WebSocket 消息。C2 的指令内容、文件下载的 URL、上传的数据包就一目了然了。

除了 TLS 之外，还有几条过滤器是我每次溯源都会用到的：

# 查看所有 DNS 查询，关注有没有可疑域名 dns # 查看 DHCP 请求，定位陌生设备接入内网的行为 dhcp # 查看 ARP 异常，定位 IP 冲突或 ARP 欺骗 arp.duplicate-address-frame # 只看到 TCP SYN 包，快速发现扫描行为 tcp.flags.syn == 1 && tcp.flags.ack == 0

这里提一个细节：筛选 UDP 前后两包的时间间隔时，可以用 Wireshark 的frame.time_delta_displayed字段过滤。比如想找间隔超过 5 秒的 UDP 包，过滤器可以写成：

udp && frame.time_delta_displayed > 5

这个字段在分析 DNS 慢查询或某些自定义 UDP 协议时很管用。

3.4 把攻击时间线整理成可用的证据链

流量分析的最后一步，是把零散的可疑行为串成时间线。我会用一张表把关键节点记下来，类似下面这样：

这张表不需要做得多花哨，但对后续报告和复盘非常有用。尤其在应急响应时，时间线往往决定了整个事件性质的判断——是先有扫描再有攻击，还是攻击后直接外传，行为顺序完全不同。

4. 提取传输载荷并完成修复还原

溯源只是前半段，真正的硬骨头往往在“提取载荷”和“修复载荷”这两步。Wireshark 能把流量里的字节完整还原出来，但还原出来的对象经常是损坏的、加密的、或者被编码过的，必须要做二次处理才能用于分析。

4.1 传输载荷可能藏在哪些流量里

流量里的传输载荷并不只有常见的 HTTP 下载文件这一种。我按出现频率整理一下：

SMB 共享流量是这次靶场的核心，攻击者写入共享的文件本身就是一个载荷，可以直接从流量里还原。HTTP/Https 响应中经常包含文件下载、脚本下发和 API 返回的数据，最常见也最容易提取。DNS 流量也不能忽视，攻击者可能用 DNS TXT 记录或者子域名编码的方式传递数据，虽然单条数据很小，但组合起来可以拼出完整文件。TFTP、FTP 协议则常用于内网文件传输，流量里的载荷通常是明文。邮件协议里也可能有附件，SMTP/IMAP 流量极少有人关注，反而是很好的藏匿位置。

判断一个流量里是否“有货”，最简单的方法是看协议层次和传输长度。像 HTTP 200 响应后面跟着上万字节的数据段，基本就是在传文件；DNS 的 TXT 记录返回一段很长的字符串，也值得留意。

4.2 用 Wireshark 和 tshark 把载荷导出来

Wireshark 图形界面里有一个特别好用的功能：File -> Export Objects -> HTTP。它会自动把所有 HTTP 响应体里的文件对象列出来，鼠标点一下就能保存。这个方法对常见 Web 下载流量几乎零成本，是我首先会尝试的操作。

但 Export Objects 只支持 HTTP、SMB、TFTP 等少数协议。对于其他协议，或者需要从某个 TCP 流中按原始字节提取数据时，我会用 Follow TCP Stream，把 Show data as 切换成 Raw 模式，然后 Save as 保存为二进制文件。

命令行方式更适合批量操作和后续脚本处理。用 tshark 提取某个 TCP 流的所有数据：

tshark -r capture.pcap -Y "tcp.stream eq 7" -z follow,tcp,raw,7

这个命令会把第 7 条 TCP 流的原始数据以十六进制和 ASCII 形式打印出来，但格式还不太适合直接当文件用。所以我通常改用另一种方式：用 tshark 提取所有数据包的载荷字段，然后交给 Python 脚本拼接。

tshark -r capture.pcap -Y "tcp.stream eq 7 && data.data" -T fields -e data.data > payload_hex.txt

这样得到的是按包排列的十六进制字符串，再用 Python 把它转成二进制：

import binascii with open("payload_hex.txt", "r") as f: lines = f.readlines() data = b"" for line in lines: line = line.strip() if line: data += binascii.unhexlify(line) with open("payload.bin", "wb") as f: f.write(data)

这一步看似简单，但很实用。很多流量里的二进制文件就是被拆成多个 TCP 段传输的，用 Python 把每段数据按顺序拼起来，结果就是完整的文件。

4.3 载荷被截断或被编码时的修复还原

真正让我觉得“这活有技术含量”的，是在提取之后发现文件不完整，或者是一堆看不懂的乱码。

第一次遇到的情况是文件头缺损。那次从 HTTP 流量里导出的文件用file命令识别不出来，只显示data。用 xxd 查看前 64 字节，发现本该是MZ开头的 PE 文件头变成了别的数据，看起来像是请求头或者某个中间字段混进了文件开头。这种情况通常是因为提取位置不对，把 HTTP 响应头之前的缓冲数据也带了进来。

修复思路是找到真正的文件起始位置。PE 文件通常以4D 5A开头，在原始字节流里搜索这个特征，把前面的脏数据全部去掉：

with open("payload.bin", "rb") as f: data = f.read() idx = data.find(b"\x4d\x5a") if idx != -1: clean = data[idx:] with open("payload_fixed.exe", "wb") as f: f.write(clean)

如果同一个文件在流量里出现了多次，还可以用多次提取结果互相校验。比如一次提取的头部缺失，但另一次提取的尾部完整，那就可以把两部分拼起来。

第二种情况是编码传输。攻击者有时候会在传输前对文件做 Base64 编码，或者用 XOR 加密。Base64 的判断很简单，看数据里是不是大量出现 A-Z、a-z、0-9 和+/字符，长度是不是 4 的倍数。解码也容易：

import base64 with open("payload_b64.txt", "r") as f: b64_data = f.read() raw = base64.b64decode(b64_data) with open("payload_decoded.bin", "wb") as f: f.write(raw)

XOR 编码稍微麻烦一点，密钥可能是单字节，也可能是多字节。单字节 XOR 可以用暴力破解，遍历 0 到 255 这 256 个可能值，对每个值解码后看结果里是否有可读文本或者文件头特征。多字节 XOR 则通常要结合已知明文或者频繁字节统计来推断密钥长度，使用频率分析确定密钥，再还原数据。

第三种情况是混淆的脚本类载荷。比如 PowerShell 脚本经过编码后传输，本身是可读文本，但里面全是编码后的字符串。这时候需要先解码出可读脚本，再根据实际情况还原内容。靶场里常见的形式是：

powershell -enc SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoA...

-enc参数后面跟的是 Base64 编码的 UTF-16LE 字符串，用 Python 可以还原：

import base64 enc = "SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoA..." decoded = base64.b64decode(enc).decode("utf-16le") print(decoded)

还原出来之后就能看到实际执行的 PowerShell 命令，比如下载文件、创建计划任务之类的操作。这一步对判断攻击链的最后一步非常有价值。

4.4 修复后的样本验证与清洗

载荷修复完成不代表工作结束，还要做一轮验证，确认还原出来的文件是不是真的可分析样本。

第一步是用file命令重新识别文件类型，看识别结果是否从data变成了PE32 executable之类的正常类型。

file payload_fixed.exe

第二步是计算哈希值，并记录为样本的唯一标识。

sha256sum payload_fixed.exe

第三步是看文件内部结构是否完整。PE 文件可以用objdump -x查看节区表，也能用strings快速扫一遍可疑字符串，比如 URL、文件名、注册表项。如果文件可以被杀毒引擎或者沙箱识别并抛出威胁名称，说明修复基本成功。本地没有沙箱的时候，也可以先把文件放到临时目录里，用 VBoxManage 启动一台隔离虚拟机跑一下，结合进程监控和网络监控观察它的行为。

这里提醒一句：修复后的恶意样本一定要放在隔离环境里验证，绝不能在宿主机上直接双击运行。我习惯把所有样本存放在一个单独的目录里，文件名统一加上sample_前缀和哈希值，避免和其他文件混在一起。

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

整个 SMB + pcap + Wireshark 的链路里，我遇到过很多零碎问题，有些问题太小，甚至不值得单独写一篇，但不解决又确实影响效率。我把它们集中整理在这里，当作速查表用。

5.1 pcap 文件打不开或字段缺失怎么办

拿到 pcap 之后用 Wireshark 直接打开，有时候会报错，打不开的可能原因有三个。

文件头是坏的，这种情况最常见。pcap 文件本身有固定的文件头格式，标准 pcap 的十六进制开头是d4 c3 b2 a1或者4d 3c b2 a1，pcapng 格式的开头是0a 0d 0d 0a。用 notepad 或者其他十六进制编辑器打开文件，看前四个字节是否正常。如果文件头被破坏，可以用 tshark 尝试修复或者部分解析：

tshark -r damaged.pcap -T fields -e frame.number -e _ws.col.Info

文件太大导致解析慢，那就别用图形界面，直接用 tshark 过滤后再把小的子集保存出来：

tshark -r large.pcap -Y "ip.addr == 10.10.1.50" -w suspicious.pcap

文件格式本身是 pcapng 但扩展名被改成了 pcap，Wireshark 通常都能自动识别，但某些脚本工具不行，这时候用 editcap 转换格式：

editcap -F pcap input.pcapng output.pcap

5.2 Wireshark 为什么只显示部分字节数据

很多人问过类似的问题：明明抓到的包应该有 2000 多字节，为什么 Wireshark 里只显示 520 字节？其实问题大概率出在抓包时的 snaplen 设置上。

snaplen 指的是每个数据包最多被捕获的字节数。默认值通常很大，但有些工具或者脚本在抓包时会主动限制长度，比如只抓前 520 字节用来做简单统计。这种方式生成的 pcap 文件里，每个包只有前 520 字节内容，后面的数据已经彻底丢失，Wireshark 再聪明也无法还原。

如果包是在 Wireshark 里抓的，检查抓包选项：

Capture -> Options -> 每个包限制为 (Limit each packet to) 65535 字节

如果 pcap 已经抓完且被截断，就没有补救办法了，唯一的方案是用足够大的 snaplen 重新抓包。如果需要把截断的包“显示得更长”，那其实要从根源上换一个完整抓包的文件。另一个相关的坑是网卡驱动关闭了混杂模式，导致捕获不到完整的数据包，这种问题在虚拟机和无线网卡上尤其常见，抓包前要确认接口是否开启了 promiscuous mode。

5.3 pcap 转 txt 或 CSV 配合自动化分析

Wireshark 图形界面适合交互式分析，但要做自动化统计或者喂给其他程序时，我会选择把 pcap 转成文本或结构化格式。

最简单的命令是导出详细解析后的文本：

tshark -r capture.pcap -V > capture.txt

这种格式适合人阅读，但文件会非常大。更常用的是按字段导出成表格，用制表符分隔，方便直接导入 Excel 或者 Python：

tshark -r capture.pcap -T fields -e frame.time -e ip.src -e ip.dst -e tcp.srcport -e tcp.dstport -e frame.len -e _ws.col.Info

如果希望保留层级结构，可以用 JSON 输出：

tshark -r capture.pcap -T json > capture.json

至于热词里提到的“AI 解析 pcap 文件”，现在确实有团队尝试把 tshark 的文本输出喂给大语言模型辅助判断，比如让模型从流量摘要里找出可疑会话。这种方式能做初步提示，但最终判断还是要人工确认，毕竟流量分析对误报率容忍度很低。

5.4 抓取 VLAN 标签和串口数据

内网里如果启用了 802.1Q VLAN，普通抓包默认可能看不到 VLAN 标签，因为它属于二层信息。Wireshark 里想确认是否抓到 VLAN tag，需要看 Frame 协议的头部，如果有 VLAN 字段，可以用过滤器直接定位：

vlan.id == 100

如果抓包文件里完全没有 VLAN 信息，可能是网卡没有把 VLAN 标签交给抓包程序，需要在网卡高级属性里开启 VLAN tag 剥离开关，或者用支持 VLAN 的交换机镜像端口抓取。

Wireshark 能不能抓串口数据这个问题也常被问到。答案是能，Wireshark 自带 extcap 接口，可以读取串口设备数据。在 Kali 里给 Wireshark 安装 extcap 插件后，接口列表里会出现serial设备。但实际做串口分析时，Wireshark 并不方便，因为它不是为串口二进制流设计的。我通常还是用 socat 或 minicom 抓原始流，再用脚本做解析，只有需要分析串口里跑的某种网络协议时才会考虑 Wireshark。

5.5 SMB 常见场景问题

热搜里有一条“mf6100 扫描文件 SMB 传输失败”，其实这类多功能一体机通过 SMB 扫描到电脑是很典型的内网应用场景。问题通常出在三处：一体机配置的共享路径不对、电脑防火墙拦截了入站 445 端口、共享目录的写入权限没给够。排查时先把电脑防火墙的“文件和打印机共享”规则打开，再确认共享目录允许 everyone 写入，最后在机器面板上测试连接。

还有一条“windows server smb 1.1”和“windows2008 关闭 smb”，这里提醒一句：SMB 1.0 协议本身非常古老，历史上出过多次严重漏洞，测试环境用没问题，生产环境能关就关。关闭方式在 Windows Server 上可以用 PowerShell：

Set-SmbServerConfiguration -EnableSMB1Protocol $false

而在 Windows 10/11 里可以直接在“启用或关闭 Windows 功能”中取消勾选“SMB 1.0/CIFS 文件共享支持”。

6. 写在后面：几个容易被忽略的实操经验

最后分享几点我自己的体会，不算总结，就是一些反复踩过坑之后形成的习惯。

第一，分析 pcap 前一定要先复制一份工作副本，永远不要在原始文件上反复操作。尤其当你需要删包、修包、转换格式时，一个不小心就会把原始证据弄坏，后面就算有再好的分析工具也无济于事。我的习惯是建立一个工作目录，原始 pcap 放在raw/，提取出的文件放在extracted/，脚本统一放在scripts/，每一步的产物都有迹可循。

第二，SMB 挂载之后的权限问题不要忽略。很多时候你能够看到共享目录列表，但get文件时报权限不足，这并不一定是账号没有权限，也可能是共享权限和 NTFS 权限叠加后的结果。在靶场里可以通过修改目标主机共享权限快速解决，但在真实取证中，千万不要随手修改共享权限或文件权限，而是应该先完整复制整个共享目录的元数据，再做后续操作。

第三，流量分析里最有价值的东西往往不在“正常请求”里，而在那些一眼看去很普通的错误响应里。攻击者扫描端口时收到的连接失败、访问不存在目录时返回的 404、DNS 解析失败后重试的记录，这些在还原攻击时序时同样是重要拼图。所以我在整理证据链时，不会只记录成功的关键操作，也会把失败尝试和重试行为一并记录，因为很多攻击行为从失败中才能倒推出攻击者的下一步意图。

第四，我在实际用 tshark 批量提数据的时候，特别喜欢加一个-E separator=,参数，把输出直接变成 CSV，这样后续无论是用 Excel 还是写 Python 处理都省很多事。比如提取所有 HTTP 请求的源 IP、目的 IP、URI 和 User-Agent：

tshark -r capture.pcap -Y "http.request" -T fields -E separator=, -e ip.src -e ip.dst -e http.request.uri -e http.user_agent

这个习惯帮我节省了大量手工翻包的时间，也减少了漏看数据的概率。

流量溯源这行，做得越多越觉得，工具只是辅助，真正值钱的是有条理的思路和踩过坑之后的肌肉记忆。希望这篇靶场实战记录能把整条链路讲清楚，让大家在遇到 SMB 共享取包、Wireshark 溯源和载荷修复这类任务时，能少走几步弯路。