4. 基于网络流量的IoC提取：从PCAP中提取恶意IP、端口、协议特征

好，咱们进入实战环节。前面几章讲了IoC是什么、怎么分类，现在该动手了。说白了，PCAP文件就是网络世界的“黑匣子”，里面记录了每一比特的流动。我当年第一次分析恶意软件流量时，打开Wireshark看到满屏的乱码，说实话有点懵。但后来摸清了门道，发现这东西其实有章可循。

这一章，我就带你用Wireshark和tshark，从PCAP里把恶意IP、端口、协议特征这些硬货给挖出来。嗯，咱们不搞花架子，直接上干货。

4.1 环境准备：你得有把好用的“手术刀”

工欲善其事，必先利其器。我个人习惯在分析前先确认工具版本，避免一些坑。

• Wireshark：图形化分析，适合“看”流量。版本建议3.6以上，对TLS 1.3解析更好。
• tshark：命令行版Wireshark，适合批量处理和自动化。我经常用它写脚本，一晚上能扫几百个PCAP。
• Python + scapy/pyshark：如果需要更灵活的处理，可以配合Python。但今天咱们主要用前两个。

4.2 恶意IP提取：谁在跟谁“私聊”？

恶意IP是最直接的IoC。攻击者控制的C2服务器、扫描器、矿池地址，都会在流量里留下痕迹。怎么找？我一般分三步走。

4.2.1 统计通信对端：找出“话最多”的那个IP

恶意IP通常跟内网主机通信频繁。用Wireshark的统计功能，或者tshark直接算。

# 统计所有IP对之间的流量字节数，按总量排序
tshark -r malicious.pcap -T fields -e ip.src -e ip.dst -e frame.len \
  | awk '{src[$1"-"$2]+=$3; dst[$2"-"$1]+=$3} END {for(k in src) print src[k]+dst[k], k}' \
  | sort -rn | head -10

输出结果里，如果某个外网IP跟内网多个主机都有大流量，那就要警惕了。我记得有一次分析一个IoT僵尸网络样本，发现一个IP 203.0.113.55 跟200多台摄像头都有心跳包，频率还特别稳定——这基本就是C2了。

4.2.2 过滤已知威胁情报：用黑名单“筛”一遍

如果你手头有威胁情报库（比如AlienVault OTX、VirusTotal的IP黑名单），可以直接用tshark做交集。

# 假设你有一个 blacklist.txt，每行一个恶意IP
for ip in $(cat blacklist.txt); do
  tshark -r sample.pcap -Y "ip.addr == $ip" -T fields -e frame.time -e ip.src -e ip.dst
done

4.2.3 关注“非对称”流量：上行远大于下行

正常上网，下载量通常远大于上传量。但如果某个内网设备上行流量异常大，比如上传了十几MB数据，而下载只有几KB——这很可能是数据外泄。用tshark可以快速算。

# 计算每个IP的上行和下行字节数
tshark -r sample.pcap -T fields -e ip.src -e ip.dst -e frame.len \
  | awk '{if($1 ~ /^192\.168\./) up[$1]+=$3; else down[$2]+=$3} END {for(k in up) print k, up[k], down[k]}'

4.3 恶意端口提取：别被“常见端口”骗了

端口号是另一个重要IoC。攻击者为了绕过防火墙，经常用非标准端口。比如，DNS协议跑在TCP 53上不奇怪，但如果HTTP流量出现在端口 8443 或 4443，那就要多留个心眼了。

4.3.1 统计端口分布：找出“异常”的服务

用Wireshark的“Statistics -> Endpoints”可以看端口分布。用tshark更灵活：

# 统计目的端口出现次数，按频率排序
tshark -r sample.pcap -T fields -e tcp.dstport -e udp.dstport \
  | awk '{for(i=1;i<=NF;i++) if($i!="") ports[$i]++} END {for(k in ports) print ports[k], k}' \
  | sort -rn | head -20

如果看到端口 12345、31337、4444 这些经典后门端口，基本可以确定有问题。但更隐蔽的是，攻击者会用 8080、443 这些常见端口，但协议不对。比如，443端口跑的不是TLS，而是明文HTTP——这就是典型的隧道行为。

4.3.2 协议与端口的“错配”检测

我个人写过一个简单的检测逻辑：用tshark提取每个流的协议和端口，然后做交叉比对。

# 提取每个TCP流的协议类型和端口
tshark -r sample.pcap -T fields -e tcp.stream -e tcp.dstport -e http.request.uri -e ssl.handshake.type \
  | sort -u | head -30

如果一个流有HTTP请求，但目的端口不是80/8080/443，那就要标记为可疑。我曾经在客户现场抓到过一个案例：内网摄像头定期向 203.0.113.88:2222 发送HTTP POST请求，数据是加密的Base64字符串——这就是典型的C2心跳。

4.4 协议特征提取：流量里的“指纹”

协议特征是最难伪造的IoC。攻击者可以换IP、换端口，但协议行为很难完全模仿正常流量。比如，DNS隧道、HTTP隧道、ICMP隧道，都有独特的模式。

4.4.1 DNS隧道检测：查询长度和频率

正常DNS查询很短，比如 www.baidu.com 也就十几个字符。但DNS隧道会把数据编码到域名里，查询长度可能超过50个字符，而且频率极高。

# 提取DNS查询名称及其长度
tshark -r sample.pcap -Y "dns.flags.response == 0" -T fields -e dns.qry.name \
  | awk '{len=length($0); if(len>30) print len, $0}' | sort -rn | head -10

如果看到类似 aGVsbG8ud29ybGQuZXhhbXBsZS5jb20= 这种Base64编码的域名，基本就是隧道了。我处理过一个案例，攻击者用DNS隧道每5秒发送一次心跳，域名长度平均62个字符——这明显不是正常上网。

4.4.2 HTTP User-Agent 异常：别信“Mozilla/5.0”

很多恶意软件会伪造User-Agent，但往往有破绽。比如，IoT设备通常不会用Chrome 120的UA。用tshark提取所有UA：

tshark -r sample.pcap -Y "http.request" -T fields -e http.user_agent | sort | uniq -c | sort -rn

如果看到大量请求的UA是 Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) 这种古董版本，或者干脆是自定义的 Bot/1.0，那就要深入分析了。

4.4.3 TLS 指纹：JA3 和 JA3S

TLS握手时的Client Hello包，包含了密码套件、扩展列表等信息，这些组合起来就是JA3指纹。恶意软件通常使用固定的TLS库，JA3指纹是唯一的。

# 提取JA3指纹（需要Wireshark 3.0+）
tshark -r sample.pcap -Y "tls.handshake.type == 1" -T fields -e tls.handshake.ja3

你可以把提取到的JA3跟已知恶意指纹库（比如 ja3er.com）做比对。我遇到过一款挖矿木马，它的JA3指纹是 51c64c77e60f3980eea90869b68c58a8，跟正常Chrome完全不同。

4.5 实战案例：从PCAP到IoC清单

咱们来个完整的例子。假设你拿到一个PCAP文件 iot_attack.pcap，里面疑似有Mirai变种的流量。

4.5.1 第一步：快速概览

tshark -r iot_attack.pcap -q -z io,phs

这个命令会输出协议层次统计。如果看到大量TCP SYN包，但没有对应的SYN-ACK，那可能是扫描行为。

4.5.2 第二步：提取可疑IP和端口

# 提取所有非内网IP的通信对
tshark -r iot_attack.pcap -T fields -e ip.src -e ip.dst -e tcp.dstport \
  | grep -v "^192\.168\.\|^10\.\|^172\.16\." | sort | uniq -c | sort -rn | head -20

4.5.3 第三步：提取协议特征

# 提取HTTP请求的URI和UA
tshark -r iot_attack.pcap -Y "http.request" -T fields -e http.request.uri -e http.user_agent

4.5.4 第四步：生成IoC清单

把上面提取到的信息整理成表格：

IoC类型	值	置信度	备注
恶意IP	203.0.113.55	高	与200+设备通信，心跳间隔5秒
恶意端口	TCP/2222	中	非标准端口，承载HTTP协议
协议特征	JA3: 51c64c77e60f3980eea90869b68c58a8	高	匹配已知挖矿木马指纹
协议特征	DNS查询长度>50字符	高	疑似DNS隧道

4.6 核心流程：一张图说清楚

下面这张图，是我自己总结的从PCAP提取IoC的流程。你照着这个思路走，基本不会漏掉关键线索。

4.7 避坑指南：我踩过的几个坑

最后，分享几个我实战中遇到的教训，希望能帮你少走弯路。

• 别只看IP，要看行为。 我曾经抓到一个IP，查了所有威胁情报都说干净。但仔细分析流量，发现它每10秒发一个SYN包到随机端口——这是典型的端口扫描。后来确认是失陷设备。
• PCAP可能被截断。 有些抓包工具默认只抓前96字节。如果只看到TCP头，没有应用层数据，很多特征就提取不到。建议抓包时设置 snaplen 为 0（全包捕获）。
• 加密流量不是“黑盒”。 即使流量是TLS加密的，握手阶段的JA3指纹、证书信息、SNI（服务器名称指示）都是明文。这些都可以作为IoC。
• 时间戳很重要。 记录每个IoC首次出现和最后出现的时间，有助于判断攻击的时间窗口。我习惯在提取时加上 -e frame.time_epoch。