analyzing-network-traffic

分析网络流量

数据包捕获是真实情况：端点可以撒谎，但网络线路不会： 每个连接、DNS 查询和传输的字节都会被记录下来，无论主机日志是否 留存。分析就是将平铺的捕获内容还原成一个故事——谁与谁通信、 使用什么协议、通信模式是人为还是自动化，以及哪些数据离开了网络。 你是在根据帧还原意图，而不是从工具中读取判定结果。

适用场景

• 需要对 .pcap / .pcapng 捕获文件进行取证审查，以寻找入侵证据
• 需要确认疑似 C2 信标，并分析其间隔、抖动和通信渠道
• 怀疑存在数据外泄，需要确定其规模、时间和目的地
• 需要根据恶意软件实际发出的流量记录其网络行为
• 需要进一步调查 Zeek notice.log 或 Suricata eve.json 告警，并得出结论
• 怀疑存在 DNS 隧道、DGA 或异常 TLS（证书异常、JA3 罕见、SNI 不匹配）

不适用场景

• 主动扫描端点、网络、云和身份遥测，以发现未检测到的失陷——使用 hunting-threats；此技能分析单个捕获文件，而威胁搜寻会跨数据源进行
• 处理更广泛的事件响应——使用 responding-to-incidents；流量分析是为该流程提供证据的一条线索
• 引爆样本以生成流量——使用 analyzing-malware；此处用于分析样本发出的 pcap，而不是运行二进制文件
• 证据是云控制平面活动，而非数据包（CloudTrail、VPC 流量日志缺失、API 调用）——使用 investigating-aws-incidents
• 主动测试正在运行的应用，而不是分析其捕获文件——使用 testing-web-applications

捕获与处理

正确获取捕获文件，否则后续每一步都会受到缺失数据的影响。截断的 snaplen 或存在丢包的捕获文件，事后都无法修复。

# Full-frame capture, no name resolution, write to disk (never parse live)
tcpdump -i eth0 -nn -s 0 -w case.pcap
# -s 0 takes full frames; a default snaplen truncates payloads and breaks carving

# Ring buffer for long-running capture: 20 files of 200 MB, oldest recycled
tcpdump -i eth0 -nn -s 0 -w case-%Y%m%d-%H%M%S.pcap -G 3600 -C 200 -W 20

# Capture without dropping under load: raise the kernel buffer, filter tightly
tcpdump -i eth0 -nn -s 0 -B 4096 'not port 22' -w case.pcap
# Confirm drops after: the summary line reports "packets dropped by kernel"

检查捕获文件是否完整，以及你拿到的是什么：

capinfos case.pcap        # packet count, duration, drop stats, snaplen, file type
tshark -r case.pcap -q -z io,phs   # protocol hierarchy — is the snaplen truncating?

• pcapng 与 pcap：pcapng 会保存每个数据包的接口、注释和名称 记录；传统 .pcap 是一种扁平的单链路格式。editcap -F libpcap in.pcapng out.pcap 可将其转换为仅支持读取 pcap 的工具所需格式。
• 拆分超大文件，以便工具和内存能够应对： editcap -c 1000000 big.pcap chunk.pcap（按数据包数量），或 editcap -i 600 big.pcap chunk.pcap（每 600 秒）。
• 合并相关捕获文件，统一时间线：mergecap -w all.pcap a.pcap b.pcap（按时间戳排序）。
• 裁剪时间窗口后再发送：editcap -A "2026-07-26 00:00:00" -B "2026-07-26 06:00:00" case.pcap window.pcap。
• 匿名化后再对外分享：使用 tcprewrite/bittwiste 重写地址，或使用 editcap -s <snaplen> 将每个数据包截断为前 snaplen 个字节（保留报头，丢弃后续负载）；更深入的报头/负载清理可使用 TraceWrangler。记录所做的更改，避免接收方将你的改写误认为原始痕迹。

为原始文件计算哈希，并在副本上操作。将 sha256sum case.pcap 的结果写入案件 记录；从此以后，证据文件应保持只读。

分诊漏斗

先广泛查看，再缩小范围，聚焦重要流量。在 Wireshark 中自上而下操作：

• Statistics > Protocol Hierarchy——查看有哪些协议及其占比。预期使用 TLS 却出现明文，或少量 DNS 流量承载了大部分字节，都是最初的线索。
• Statistics > Conversations——按字节数和持续时间排序。持续时间最长和数据量最大的流量是最先要调查的两条线索（信标与批量传输）。
• Statistics > Endpoints——查看哪些主机与最多对端通信；快速区分内部与外部主机。
• Follow > TCP/HTTP/TLS Stream——重组单次通信，以应用程序看到的方式读取内容。

Wireshark 中所有可交互完成的操作，都可以用 tshark 通过脚本执行——这样就能从整个捕获文件中提取字段，而不必逐项点击：

# Top talkers by bytes
tshark -r case.pcap -q -z conv,tcp

# Extract just the fields you want, tab-separated, for further processing
tshark -r case.pcap -T fields -E separator=/t \
  -e frame.time_epoch -e ip.src -e ip.dst -e tcp.dstport -e frame.len \
  -Y 'tcp.flags.syn==1 && tcp.flags.ack==0'   # every connection attempt

# Every HTTP request: host, method, URI, user-agent
tshark -r case.pcap -T fields -e http.host -e http.request.method \
  -e http.request.uri -e http.user_agent -Y http.request

显示过滤器熟练度

显示过滤器是手术刀。价值最高的过滤器：

过滤器	显示内容
http.request	每个出站 HTTP 请求——URI、主机、用户代理
dns	所有 DNS；添加 dns.flags.rcode == 3 可筛选 NXDOMAIN（DGA 迹象）
tls.handshake.type == 1	仅 ClientHello——SNI、JA3 输入、提供的密码套件
tls.handshake.type == 2	ServerHello——选定的密码套件、JA3S 输入
ip.addr == 10.0.0.5	与某主机之间的所有流量（用 src/dst 确定方向）
tcp.flags.syn==1 && tcp.flags.ack==0	连接尝试——扫描和信标节奏
tcp.flags.reset==1	RST——连接被拒绝/关闭、端口扫描响应
frame contains "password"	跨载荷搜索字节字符串（明文凭据、标记）
tcp.stream eq 7	按流索引隔离一段重组后的对话
tcp.analysis.retransmission	可能影响时间分析的丢包/不稳定情况
http.response.code == 200 && http.content_type contains "octet-stream"	通过 HTTP 传输文件

组合使用：ip.dst == 185.100.87.0/24 && dns 可将 DNS 限定到一个可疑网段。dns.qry.name matches "[a-f0-9]{20,}" 可标记较长的十六进制标签。

Zeek：主力工具

Zeek 可将 pcap 转换为结构化、可查询的日志——对于任何包含数千个以上数据包的捕获，这是最具杠杆效应的一步。

zeek -r case.pcap
# Or add the community-id field for cross-tool pivoting:
zeek -r case.pcap policy/protocols/conn/community-id-logging
ls   # conn.log dns.log http.log ssl.log x509.log files.log notice.log weird.log ...

日志集及每种日志可回答的问题：

日志	可回答的问题
conn.log	每条流：持续时间、发起方/响应方字节数、状态、服务——信标和数据外泄分析的基础
dns.log	每个查询/响应——隧道、DGA、TXT/NULL 滥用
http.log	主机、URI、方法、用户代理、状态、引荐来源
ssl.log	TLS 版本、SNI、JA3/JA3S、证书链、验证状态
x509.log	证书主题、颁发者、有效期、自签名标记
files.log	在线路上看到的每个文件——MIME、大小、MD5/SHA1、来源流
notice.log	Zeek 自身的检测结果（SSL::Invalid_Server_Cert、扫描等）
weird.log	协议违规——协议与端口不匹配、帧格式错误

使用 zeek-cut 挖掘日志（按名称提取字段，顺序不限）：

# Longest connections first — beacons and tunnels live at the top
cat conn.log | zeek-cut id.orig_h id.resp_h duration orig_bytes resp_bytes \
  | sort -t$'\t' -k3 -rn | head

# Every distinct destination one host reached, with hit counts
cat conn.log | zeek-cut id.orig_h id.resp_h | grep '^10\.0\.0\.5' \
  | sort | uniq -c | sort -rn

# DNS query names + types, to eyeball tunneling and DGA
cat dns.log | zeek-cut query qtype_name answers | sort | uniq -c | sort -rn | head -50

# Pivot a suspicious flow across all logs by its community-id
cat conn.log | zeek-cut community_id id.orig_h id.resp_h service

对于同一条流，community-id 字段在 Zeek、Suricata 和许多 EDR 中都是相同的字符串——用它将告警与数据包对应起来。

使用 Suricata 分析 pcap

离线运行规则，对捕获数据进行检测，查看规则集会标记哪些内容：

# Run ET Open / community rules over the pcap, write structured events
suricata -r case.pcap -S /etc/suricata/rules/suricata.rules -l ./out/
# eve.json holds alerts, plus dns/http/tls/flow records if enabled

提取并排列告警：

jq -c 'select(.event_type=="alert") | {sig:.alert.signature, src:.src_ip, dst:.dest_ip}' \
  out/eve.json | sort | uniq -c | sort -rn

将告警视为线索，而非定论。签名命中会告诉你该去哪里调查，但不能据此结案；没有命中也不能证明捕获数据没有问题。

信标检测

自动回连会暴露在时间规律和流量形态中，而非内容中。在 conn.log 中查找反复出现的源/目标对：它们以固定间隔重复，持续很长时间，且请求大小较小、基本恒定。人类流量突发且多变；信标则像节拍器。

# Inter-arrival deltas for one src/dst pair — near-constant gaps = beacon
tshark -r case.pcap -T fields -e frame.time_epoch \
  -Y 'ip.src==10.0.0.5 && ip.dst==185.100.87.202' \
  | awk 'NR>1{print $1-prev} {prev=$1}' | sort -n | uniq -c

• 间隔规律（例如每 60s 一次）且带有抖动（存在 ±% 的波动），是典型的 C2 特征——完全规律的情况在恶意软件中较少见，轻微抖动则很常见。
• 较小且恒定的请求大小，偶尔出现较大的响应 = 检查是否为携带任务指令的轮询。
• 连接持续时间较长，或某条流数小时内按固定节奏重新连接，表明存在持久通道。

使用 Zeek 日志通过 RITA 或 beacon-analysis 工具自动评分——它们会计算每一对流的间隔和大小一致性，因此你无需逐一人工检查：

rita import --database case --logs ./ && rita view case beacon:'>=90'

DNS 分析

DNS 是首选隐蔽通道，因为它很少被拦截，也经常不记录日志。在 dns.log 中，有两种截然不同的模式：

隧道——将 DNS 用作数据管道：

• 向单个父域名发出大量查询（数千个唯一子域名）
• 标签很长：MFRGG43FMQ.tunnel.evil.com，子域名看起来像 base32/十六进制编码
• TXT 和 NULL 记录类型承载上行或下行的编码负载
• 每个标签的熵值高于普通的类英语主机名

# Subdomain cardinality per parent domain — a tunnel spikes on one domain
cat dns.log | zeek-cut query | rev | cut -d. -f1-2 | rev \
  | sort | uniq -c | sort -rn | head

# TXT queries only — legitimate use is sparse; volume is a flag
cat dns.log | zeek-cut query qtype_name | awk -F'\t' '$2=="TXT"' | wc -l

DGA——通过算法生成会合域名：

• NXDOMAIN 比率很高（rcode 为 3），因为恶意软件会不断尝试已失效的域名
• 二级域名看起来随机，没有语言结构

cat dns.log | zeek-cut rcode_name query | awk -F'\t' '$1=="NXDOMAIN"' \
  | wc -l   # a burst of NXDOMAIN from one host is a DGA tell

通过计算标签熵或使用 DGA 分类器，区分 cdn-3f2a.example（良性哈希）和 qwzjxkbvmn.info（生成的域名）。流量量、熵值和 NXDOMAIN 综合起来才能构成有力证据；单独任何一项都可能有良性解释。

TLS 和加密流量

没有密钥就无法读取明文，但握手仍可用于识别客户端、服务端和意图。加密隐藏的是内容，而不是元数据。

• JA3 / JA3S（以及 JA4/JA4S）会将 ClientHello / ServerHello 参数哈希为客户端和服务端指纹。多个无关主机共享一个罕见的 JA3，或某个 JA3 与已知 C2 框架匹配，都是重要线索。Zeek 的 ssl.log 包含 ja3/ja3s；可与公开及内部的已知恶意列表进行关联。
• 在 ssl.log / x509.log 中查找：自签名证书、与证书 CN/SAN 不匹配的 SNI、异常的有效期（1000 年或仅一天的证书）、空白或乱码的主题字段，以及 指向可疑或新注册域名的 SNI。

# Self-signed or validation-failed TLS, with the SNI and JA3
cat ssl.log | zeek-cut server_name validation_status ja3 ja3s \
  | grep -iv '\bok$' | sort | uniq -c | sort -rn

# SNI vs certificate subject mismatch — join ssl.log and x509.log on cert id
cat x509.log | zeek-cut certificate.subject certificate.issuer \
  certificate.not_valid_before certificate.not_valid_after

如果你合法持有会话密钥（例如设置了 SSLKEYLOGFILE 的实验室引爆环境，或已导出的主密钥），可在 Wireshark 中解密：Preferences > Protocols > TLS > (Pre)-Master-Secret log filename，或使用 tshark -r case.pcap -o tls.keylog_file:keys.log -Y http2。切勿假定自己能解密没有密钥的生产环境 TLS——你做的是指纹识别，而不是读取内容。

HTTP 和文件提取

明文 HTTP（以及已解密的 TLS）会暴露完整的通信内容：

• User-Agent 异常——出站流量中出现硬编码、格式错误或库默认的 UA（python-requests、空 UA、拼写错误的浏览器字符串），是恶意软件的常见迹象。汇总 UA 并调查罕见项。
• http.log 中的可疑 URI——看起来像 base64 的路径、很长的随机查询字符串、原始 IP 上的 .php 端点，或包含不透明数据块的 POST 请求。

提取传输的文件并计算哈希，以便后续关联：

# Zeek extracts files automatically when configured; otherwise from files.log:
cat files.log | zeek-cut fuid mime_type filename md5 sha1 tx_hosts rx_hosts

# Carve without Zeek:
foremost -i case.pcap -o carved/          # signature-based file recovery
tcpflow -r case.pcap -o flows/            # reassemble every TCP stream to a file
# NetworkMiner (GUI/CLI) reassembles files, images, and credentials from a pcap

对每个提取出的文件计算哈希，并将可疑文件关联到 analyzing-malware：sha256sum carved/* ——在线路上出现、且与任何良性文件都不匹配的文件，就是下一个要引爆分析的样本。

数据外传狩猎

数据外流是最重要的结果。在 conn.log 中按 orig_bytes 降序排序——大流量的出站连接最值得关注，而方向（orig = 内部主机发送）是关键。

# Biggest outbound transfers from internal hosts
cat conn.log | zeek-cut id.orig_h id.resp_h resp_p orig_bytes duration \
  | awk -F'\t' '$4>10000000' | sort -t$'\t' -k4 -rn

• 非工作时间传输——凌晨 03:00 从白天处于空闲状态的工作站发起的大批量上传。将连接时间戳与工作时间进行比对。
• 隐蔽通道——带负载的持续 ICMP 流量，或承载上行数据的 DNS（参见 DNS 分析）。数据包小、数量多、目标唯一。
• 目标信誉——将云存储（*.s3.amazonaws.com、*.blob.core.windows.net）、粘贴站点（pastebin、ghostbin）和文件共享域名，作为大规模上传的目标；尤其是发起上传的服务器没有正当理由使用这些服务时。

协议异常

攻击者会把流量藏在错误的端口和错误的协议上：

• 非标准端口——在 8443 或 4443 上使用 TLS，在 8080/8888 上使用 HTTP，或在随机高位端口上进行 C2 通信。conn.log 的 service 字段记录的是 Zeek 检测到的协议，与端口号无关。
• 协议与端口不匹配——Zeek 的 DPI 会在 conn.log（service 与 id.resp_p 不一致）和 weird.log 中标记 443 上的 SSH、53 上的 HTTP 或 22 上的 TLS。

# Detected service does not match the port — tunneling / evasion
cat conn.log | zeek-cut id.resp_p service | awk -F'\t' \
  '($1=="443" && $2!="ssl") || ($1=="53" && $2!="dns")' | sort | uniq -c

• 明文凭据——FTP、Telnet、HTTP Basic、SMTP AUTH、LDAP 简单绑定。在 Wireshark 中使用 frame contains "PASS "，或查看 NetworkMiner 的凭据选项卡，即可直接提取这些凭据。

交接 IOC

抓包的价值在于提取可复用的内容。像处理其他来源一样，对指标分级——行为比基础设施更持久——并将每项输出交由相应流程处理：

• 从提取的样本中获得的文件特征——在 writing-yara-rules 中编写 .yar 规则，针对文件结构，而不是它碰巧使用的 URI。
• 将封装相关 IOC、攻击者线索和基础设施聚类整理成完整成果——producing-threat-intelligence。
• 将流量模式转化为已部署的检测规则——日志规则使用 writing-sigma-rules，更广泛的规则流水线使用 engineering-detections（例如，针对 JA3 的 Suricata 特征、针对信标通信频率的 Zeek notice，以及针对 DNS 模式的 Sigma 规则）。
• 为利益相关方撰写最终报告——reporting-security-findings。

每项指标都要记录其来源流、时间戳和置信度。没有上下文的 IP 对接收者而言只是噪声。

应当驳斥的自我安慰

• “全是 TLS，我什么也看不到。” JA3/JA3S、SNI、证书字段和连接时序都能在不解密的情况下为加密流量建立指纹。元数据本身就是分析内容。
• “没有触发警报，所以很干净。” 信标通信和 DNS 隧道经常绕过默认规则集。没有 Suricata 命中不代表没有 C2。
• “pcap 太大，没法分析。” 运行 Zeek，检查日志并逐步筛选。你要分诊的是结构化日志，而不是五百万个原始帧。
• “这里没有 C2 流量。” 下结论前先检查 DNS、ICMP 和持续时间长但流量少的通信。C2 会藏在你没有按字节数排序的信道中。
• “流量量正常，所以没有数据外传。” 按出站字节数和时间排序。数天内缓慢滴漏，或一次发生在非工作时段的突发流量，都不会拉高平均值。
• “那个目的地只是 CDN／云服务商。” 云存储和 CDN 域名正是现代数据外传和 C2 藏身的地方。确认流量特征，不要仅凭域名就放行。
• “我只要看看负载就行。” 快照长度截断、加密和重组缺口意味着从负载入手会错过关键信息。先从流元数据入手，再查看值得深入分析的流。

ATT&CK 覆盖范围

根据 secskills-core/ttp-index.json 生成——编辑该文件，然后运行 python3 scripts/sync_attack.py --write。在报告中引用这些 ID 前，请根据 当前 ATT&CK 版本重新核验。

命令与控制（TA0011）

• T1071 应用层协议——另见 analyzing-malware、engineering-detections
• T1071.004 DNS——另见 engineering-detections、hunting-threats
• T1132 数据编码——另见 transferring-files、analyzing-malware
• T1568 动态解析——另见 analyzing-malware、hunting-threats
• T1573 加密通道——另见 analyzing-malware、engineering-detections

数据渗出（TA0010）

• T1048 通过替代协议进行数据渗出——另见 transferring-files、hunting-threats

针对上述任一项的检测内容：engineering-detections。主动搜索：hunting-threats。入侵后处置：responding-to-incidents。

参考资料

• hunting-threats——针对多种遥测数据源开展主动、基于假设的搜索，网络数据是其中一种
• responding-to-incidents——此证据流所服务的事件处置流程
• analyzing-malware——引爆样本以生成流量，并接收此技能提取的文件进行分析
• investigating-aws-incidents——证据来自云控制平面日志而非数据包时使用
• writing-yara-rules——为提取出的制品编写文件特征签名
• producing-threat-intelligence——将提取的 IOC 整理成产品
• reporting-security-findings——面向利益相关方撰写报告
• Wireshark / tshark 和 capinfos——交互式与脚本化数据包解析
• Zeek 配合 zeek-cut 和 community-id——从任意捕获数据中生成结构化日志
• Suricata（ET Open / community rules）——对 pcap 离线运行特征签名
• NetworkMiner——从捕获数据中重组文件、图像和凭据
• RITA / beacon-analysis——基于 Zeek 日志自动进行信标评分
• tcpdump——捕获；editcap / mergecap——拆分、合并、裁剪和转换