2026-11-01 01:34:56 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

流量分析与溯源-从一包PCAP里把人揪出来

原创

围巢安全笔记
围巢安全笔记

围巢安全笔记

2026年10月30日 09:00
北京

去阅读

应急响应 · 溯源篇

给你一个 800MB 的 pcap，问你「这台机器是怎么被黑的」。

大部分人的第一反应是打开 Wireshark 往下翻。翻到第两百个包，眼睛花了，结论还是没有。

这篇讲的是另一套方法：先有假设，再去验证。怎么在五分钟内把范围从百万个包砍到几十个，怎么看懂四类工具的流量长相，怎么从会话里把样本抠出来，以及溯源能到哪一步、不能到哪一步。约 5000 字。

01｜不要在没方向的时候打开 Wireshark

Wireshark 的默认界面是一个滚动的包列表。这个设计对新手很不友好——它诱导你去「看」，而流量分析的核心是「筛」。

打开之前，你手上应该已经有一个假设。比如：

· 告警说是这台机器在挖矿 → 那就找长连接、找矿池端口、找固定心跳

· 告警说是 webshell 通信 → 那就找那个可疑 URL 的 POST 会话

· 用户说「文件被加密了」→ 那就找 SMB 大量读写、找加密前的批量访问

· 只给你一个 pcap，什么都不知道 → 那就先做统计，找异常量级

图 1｜先定方向，再缩范围，最后才看细节

这个顺序反过来的代价很实在：先翻包，翻三个小时你还在看 DNS 查询记录，而且越看越困，最后随便挑一个看着可疑的 IP 交差。

一个实用习惯
开包之前，先写一句话：「我怀疑 \\\\\\，如果成立，流量里应该有 \\\\\\」。
写完这句再打开 Wireshark，效率差十倍。

02｜怎么在五分钟内砍掉 99% 的包

有几个动作是固定套路，不用想，上来就做。

第一步：看统计，不看包

统计 → 会话（Conversations），按字节数排序。

攻击流量有个特征：数据量往往非常突出。传马要传文件，拖库要传数据，回连要持续心跳。所以按流量排序，前几名里经常就有答案。

第二步：按协议排除噪音

一个企业网的 pcap 里，大部分是这些：ARP 广播、mDNS、NBNS、STP、LLMNR、各种组播。它们占了包数但毫无信息量。

!arp && !mdns && !nbns && !llmnr && !stp && !igmp

这一条下去，包数经常直接掉一半。

第三步：只留 HTTP / DNS / TLS

绝大多数入侵的证据在这三个协议里：HTTP 有请求内容，DNS 有域名解析（隧道和 DGA 都藏这儿），TLS 有 SNI 和证书（外联目标暴露在这）。

http || dns || tls.handshake.type == 1

第四步：按可疑主机过滤

知道是哪台机器出问题，就直接锁 IP：

ip.addr == 192.168.32.181 && !(ip.addr == 192.168.32.1)

排除网关之后，剩下的基本都是这台机器主动发起的对外通信。

过滤器的正确用法
不要一次把所有条件写上，容易写成空集然后怀疑人生。
一层一层加，每加一层看一眼剩余包数——包数骤降到 0，说明上一个条件写错了。

03｜四类工具的流量长相

流量分析最有价值的部分是「认人」——看到这种加密方式、这种请求节奏，能大致判断对面用的是什么工具。这决定了后面怎么解密、怎么提取。

图 2｜特征会变，行为不变

展开说几个细节。

蚁剑：最「不加密」的那类

早期蚁剑的流量几乎是明文，参数名固定成 z0、z1 这种，body 里能看到 @ini_set、base64_decode。

现在默认会开 base64 或 RSA 编码，但结构没变：一个参数、一段编码后的内容、POST 到一个 .php 文件。看多了就知道，那个「只有一次 POST、没有 GET、没有静态资源」的对话，八成是它。

冰蝎：长度恒定是硬伤

冰蝎的 body 全是 AES 密文，看不出来内容。但它有个改不掉的毛病：加密之后的长度是固定的。

因为它的明文是一个固定结构的序列化数据，补位规则固定，所以密文长度也固定。你看一串 POST 请求，每个 body 都是 800 多字节，一个不差——这不是正常业务能有的特征。

再配合固定的 UA（有些版本常年不换），基本可以锁定。

哥斯拉：请求头最诚实

哥斯拉的流量会带一个自定义的请求头，名字是可以配的，但默认值很多人不改。它还有固定的 Cookie 名和固定的参数结构。

所以抓哥斯拉，先看请求头，比看 body 快得多。

Cobalt Strike：节奏暴露一切

CS 的 beacon 最典型的特征是心跳间隔。默认 60 秒一次，加上随机的抖动（jitter）。你在会话列表里看，会发现某个 IP 每隔一分钟往外发一次几百字节的小包——像定时器一样准。

再往下可以看 JA3 指纹、看 TLS 证书字段（默认证书里有些固定字符串）、看 HTTP 的 URI 规律（checksum8 校验）。这些特征比 UA 稳得多，因为改起来麻烦。

别只记特征，记「为什么」
UA 能改、参数名能改、加密方式能换。改不掉的是行为约束：
webshell 必须「请求-响应」一来一回；beacon 必须周期性回连；隧道必须把数据塞进 DNS 或 ICMP。
抓行为，比抓特征活得久。

04｜把文件从流量里抠出来

找到可疑会话之后，第一件事是把传输的文件导出来。有样本才能算 Hash、才能送情报平台、才能写进报告。

Wireshark 里：文件 → 导出对象 → HTTP，能列出这次抓包里所有通过 HTTP 传输的文件。

如果是分片传输（大文件），用「追踪 TCP 流」，把整个会话的原始字节 dump 出来，再按文件头切。

常见的文件头，记几个就够：

4D 5A —— Windows PE（exe / dll）

50 4B 03 04 —— ZIP（docx / jar / apk 都是它）

7F 45 4C 46 —— ELF（Linux 可执行）

FF D8 FF —— JPEG

拿到样本之后，先算 Hash，再扔到威胁情报平台。这一步能解决的问题比你想的多：如果这个 Hash 已经被标记成某个家族的样本，你连分析都省了。

但要注意：Hash 查不到不等于安全。攻击者改一个字节，Hash 就变了。查不到只能说明「这个具体样本没被收录」，不能说明「它是干净的」。

05｜溯源：五个维度，互相印证

溯源这个词被用得很泛。这里说的是具体动作：从证据出发，尽可能往上追，追到「是谁、从哪、为什么」。

图 3｜单个维度到「疑似」，两个以上交叉才到「确认」

数据包是最硬的一层。它不说谎（除非被抓包的主机本身被控）。谁连了谁、什么时候、传了多少，这些是客观事实。

样本是第二层。文件里的字符串、编译信息、PDB 路径、硬编码的 C2 地址——这些东西经常能暴露开发者的习惯，甚至暴露母语。

日志是第三层。Web 日志告诉你入口，系统日志告诉你登录，安全设备日志补上时间线。三层日志对不上，说明中间有环节缺失，那本身就是线索。

域名与 DNS是第四层。解析记录、Whois、备案信息、历史 IP——攻击者换 IP 容易，换域名注册信息难。同一批域名注册在同一时间、用同一个邮箱，这就是关联证据。

资产与组织是第五层。这个 IP 还打过哪些目标？如果多个受害单位被同一批 IP 打过，那就不是随机扫描，是有组织的活动。

溯源的红线
溯源是为了搞清楚发生了什么、怎么防下次，不是去「反打」对方。
对目标系统做任何未授权的访问、扫描、探测，都越界了。查到 IP 归属地就够了，别往下点。

06｜把时间点连成线

零散的时间点没有意义。「10:31 有个 POST」和「11:05 有 SMB 扫描」是两条孤立信息。连成线之后，故事才出来：

图 4｜时间线的价值，在于找出「哪一步本来可以拦住」

连线的关键是找因果，不是按时间排序。顺序谁都会排，难的是回答「B 是不是 A 导致的」。

几个常用的判断方法：

看源端口是否连续。同一个工具发起的多个连接，源端口往往在一个区间内递增。这是同一批操作的技术证据。

看时间间隔是否合理。上传成功之后 2 秒就开始回连，说明是自动化工具；隔了 6 个小时才回连，说明是人工操作，中间可能有人去吃饭了。

看是否有「试探—成功」的模式。先打一个 404，再打一个 200，中间隔几秒——这是典型的漏洞验证。

串完线，你在报告里就能写出一句有用的话：「攻击者在 10:31 通过上传接口获得执行权限，10:33 建立首个 C2 通道，11:05 开始内网探测。如果上传目录禁止执行，第一环就断了。」

这比「发现大量可疑流量，建议加强监控」有价值一百倍。

07｜溯源能到哪一步，说清楚

这一节是写给要交报告的人的。

溯源结论分三档，写的时候必须标清楚，别混：

已验证。有直接证据支撑。比如「样本 Hash 为 xxx，该 Hash 在情报平台标记为某某家族」——这是查得到的。

推断。有间接证据，逻辑成立，但缺一环。比如「根据回连间隔和加密方式判断为 CS beacon」——特征吻合，但没有拿到样本。

无法判断。证据不足。比如「攻击者身份」——除非对方留下明显失误，否则基本查不到，别硬写。

很多报告的问题就在这儿：把推断写成已验证，把无法判断写成「疑似某组织」。前者会导致处置方向错误，后者会显得不专业。

一句能救命的表述
「根据现有证据，可以确认 A 和 B；C 无法排除，需要补充 D 日志才能判断。」
这句话看着啰嗦，但它让读报告的人知道哪里能信、哪里要再查。这比一个漂亮的结论有用。

08｜加密流量怎么办

现在大部分外联都是 HTTPS。你会遇到一个很现实的问题：抓到的是密文，什么都看不见。

先说结论：大部分情况下你不需要解密，也能定性。

因为 TLS 握手阶段暴露的信息，比很多人以为的多：

SNI 是明文的。ClientHello 里带着目标域名，除非对方用了 ECH（加密客户端问候），否则 Wireshark 里直接能看到。过滤器：tls.handshake.extensions_server_name。

证书是明文的。ServerHello 之后服务器会发证书，里面有 CN、颁发者、有效期、SAN 列表。自签证书、刚注册三天的域名、和业务完全不搭的 CN——这些都是信号。

JA3 指纹。它是对 ClientHello 里几个字段做哈希算出来的值。同一个客户端程序，JA3 基本固定。所以你可以用「这个 JA3 是不是正常浏览器」来判断——CS 默认的 JA3 和 Chrome 差很远。

Wireshark 4.x 已经内置 JA3 计算，在 统计 → 对话 里能看到。

还有更朴素的办法：看通信节奏和包大小。

一个每 60 秒发一次、每次 300 字节左右的连接，不用解密也知道是心跳。一个先上行 2MB、再下行 50KB 的连接，不用解密也知道是在传文件出去。

真正需要解密的场景只有两个：

一，要提取里面的样本。那得有密钥。途径有三个：拿到服务器私钥（RSA 密钥交换才能用，现在基本都是 ECDHE，用不了）、拿到客户端浏览器导出的 SSLKEYLOGFILE、或者在有解密能力的设备上抓。

二，要确认具体传了什么数据。这个通常靠主机侧证据更靠谱——内存、临时文件、进程打开的句柄，比解密流量快得多。

一个判断习惯
遇到「全是加密流量」的包，不要卡在解密上。
先问：我要证明的是什么？ 如果只是「这台机器在跟可疑地址通信」，那 SNI + 时间 + 包大小就够了。定性不需要内容。

09｜几个能立刻用上的过滤器

最后留一份速查。这些是我平时用得最多的：

# 1. 只看 HTTP 的 POST 请求 http.request.method == \"POST\"  # 2. 找上传行为（有 multipart 或 filename） http contains \"filename=\"  # 3. 找命令执行特征 http contains \"cmd=\" || http contains \"exec\"  # 4. 找 DNS 隧道（超长域名、TXT 查询多） dns.qry.name.len > 50 || dns.qry.type == 16  # 5. 找异常大流量会话 tcp.len > 1400  # 6. 找 ICMP 隧道（payload 异常长） icmp && data.len > 100  # 7. 按 TLS SNI 找外联目标 tls.handshake.extensions_server_name contains \"xxx\"

这些不是万能的。真正的分析永远靠「这个流量长得不对」的直觉，加上「去验证这个直觉」的动作。

而直觉是练出来的：多抓包、多对比、多问一句「正常的流量长什么样」。你对正常有多熟，对异常就有多敏感。

围巢安全笔记

不生产焦虑，只分享踩过的坑和挖过的洞

你用哪个过滤器抓到过「大鱼」？👇

有想聊的话题，后台留言告诉我

往期回顾