13 KiB
13 KiB
name, description, capabilities
| name | description | capabilities | |
|---|---|---|---|
| re-netcap | 网络流量捕获:tcpdump/Wireshark/抓包。 触发词:抓包、tcpdump、wireshark、流量分析、pcap |
|
网络流量捕获
何时使用 / 何时不用
- 用:任何需要拿到网络流量的任务——恶意样本回连观察、固件通信分析、协议逆向的原料获取
- 用:已有 pcap 需要导出/统计/过滤(tshark 环节)
- 用:HTTPS/TLS 通信需要解密看明文(mitmproxy 中间人)
- 不用:流量已解密/无加密且只要协议语义(直接 re-proto-rev)
- 不用:样本不联网(静态分析先做 re-triage)
- 不用:只要抓一个包的 quick look(
tcpdump -i any -c N一次搞定,不必搭全流程)
工具准备
所有工具先验证再使用。运行样本抓包默认在沙箱内(re-sandbox 网络隔离,re-analyze/platform-tips 最高原则)——捕获环境与隔离环境要同时就绪。
tcpdump —— 命令行抓包主力
- Linux:
apt install tcpdump/dnf install tcpdump/pacman -S tcpdump - macOS:
brew install tcpdump(或系统自带版本) - Windows/WSL: WSL 内 Linux 版;Windows 本机用 Wireshark 或 Npcap 自带 dumpcap
- 验证:
tcpdump --version;tcpdump -D列出接口
wireshark / tshark —— GUI + CLI 分析(tshark 用于导出与统计)
- Linux:
apt install wireshark tshark/dnf install wireshark-cli wireshark/pacman -S wireshark-cli wireshark-qt(Arch 已拆分为 wireshark-cli + wireshark-qt;Debian 安装时选"允许非 root 抓包",或sudo dpkg-reconfigure wireshark-common后把用户加入 wireshark 组) - macOS:
brew install --cask wireshark(含 tshark CLI;或brew install wireshark仅 CLI) - Windows:
choco install wireshark(或官方安装包);WSL 内用 Linux 版 - 验证:
tshark --version;tshark -D列出接口;dumpcap -D - 同族 CLI:
capinfos(pcap 元信息:包数/时长/截断)、mergecap(合并)、editcap(切分/去重/改写时间戳),随 Wireshark 一起安装
mitmproxy —— HTTPS/TLS 中间人解密
- 全平台:
pip install mitmproxy(当前 12.x 要求 Python >=3.12;旧 Python 环境需 pin 对应的旧版本) - macOS:
brew install mitmproxy - Windows: pip 版即可(或官方安装包);WSL 内 pip 版
- 验证:
mitmproxy --version;mitmdump --version
nfqueue —— 内核态流量转发/中间人抓包点(Linux)
- Linux:
apt install iptables libnetfilter-queue1 python3-netfilterqueue/dnf install iptables libnetfilter_queue-devel python3-netfilterqueue/pacman -S iptables libnetfilter_queue python-netfilterqueue;或pip install NetfilterQueue(需内核 nfnetlink_queue 支持) - macOS/Windows: 不支持(用 WSL2 内核或 Linux VM 做转发点)
- 验证:
python3 -c "from netfilterqueue import NetfilterQueue";iptables -L -n | grep -i NFQUEUE能看到规则
操作步骤
按顺序执行,每步记下结果。捕获产物(pcap 路径 + sha256)存档供 re-proto-rev / re-crypto-decrypt 使用。
-
选择抓包点(本机 / 网关 / 中间人):
- 本机: 目标程序跑在本机 →
tcpdump -i eth0 host <目标IP>(或 Wireshark 选接口直接抓) - 网关/转发点: 目标在沙箱 VM / 其他主机 → 在网关主机或 VM 虚拟网卡(virbr0 / vboxnet0)抓,
tcpdump -i virbr0 - 中间人: 需要看 HTTPS 明文 → mitmproxy 透明代理把目标流量强制引到本机(见步骤 4、5);纯包级截获(不拆 TLS)才用 nfqueue handler
- 沙箱场景: 抓包点在沙箱虚拟网卡 + re-sandbox 的 INetSim/fake DNS 落点(见步骤 5)
- 决策记录:写下抓包点与理由(为什么这个点能同时看到请求与响应)
- 本机: 目标程序跑在本机 →
-
tcpdump 过滤语法(先过滤再存盘):
sudo tcpdump -i eth0 -w out.pcap # 全量(先别这么干,见坑 4) # 常用过滤: sudo tcpdump -i eth0 host 1.2.3.4 -w out.pcap # 按 IP sudo tcpdump -i eth0 port 443 -w out.pcap # 按端口 sudo tcpdump -i eth0 host 1.2.3.4 and tcp port 8080 # 组合,先屏显验证再存 sudo tcpdump -i eth0 -c 500 -w out.pcap # 限包数- BPF 语法要点:
and/or/not、host/port/proto、括号分组;先不带-w屏显验证过滤命中目标再写盘 - 组合多个条件用括号:
tcpdump -i eth0 '(host 1.2.3.4 or host 5.6.7.8) and not port 53' -w out.pcap - 抓包期选项:
-n禁反向 DNS 解析(避免解析延迟与结果污染);-s 200限定捕获长度(默认 262144 全包长);长时抓包加-C 100 -W 10按 100MB 轮转、保留 10 个文件防爆盘
- BPF 语法要点:
-
tshark 导出与统计(从已有 pcap 提取关键流):
tshark -r out.pcap -T fields -e ip.src -e ip.dst -e tcp.dstport | sort | uniq -c | sort -rn # 会话统计(目标端口字段名是 tcp.dstport / tcp.port,不存在 tcp.dport 字段) tshark -r out.pcap -Y 'http.request' -T fields -e http.host -e http.request.uri # 只看 HTTP 请求 tshark -r out.pcap -Y 'tls.handshake.type == 1' -T fields -e tls.handshake.extensions_server_name # SNI tshark -r out.pcap -q -z conv,tcp -z io,phs # 会话表 + 协议层级统计(-q 静默,只出统计) tshark -r out.pcap -T json -e ip.src -e dns.qry.name -Y dns | jq . # JSON 输出(脚本后续处理) tshark -r out.pcap -w filtered.pcap -Y 'ip.addr == 1.2.3.4' # 按显示过滤导出子集(display filter 语法,`host` 是 BPF 捕获语法不适用) capinfos out.pcap # pcap 元信息:包数/时长/是否截断- 字段名以
tshark -G fields | grep <关键字>核验为准——写错字段名 tshark 直接报 "Some fields aren't valid",不会静默 - 统计结论(会话数、协议分布、异常连接)记入分析笔记,是 re-proto-rev 步骤 1 的输入
- 复杂交互分析(Follow TCP Stream、协议解码跳转)用 Wireshark GUI 打开同一 pcap
- 字段名以
-
HTTPS 解密准备(mitmproxy CA):
mitmproxy -p 8080 --mode transparent # 透明模式(配合步骤 5 的 nat REDIRECT 引流) # 或 mitmproxy --set console_eventlog_verbosity=error --listen-port 8080 --mode regular # 常规代理模式- 首次运行生成 CA 于
~/.mitmproxy/mitmproxy-ca-cert.pem;把该 CA 装进目标系统/进程信任库(沙箱内cp mitmproxy-ca-cert.pem /usr/local/share/ca-certificates/ && update-ca-certificates) - 验证: 目标进程访问 HTTPS 站点,mitmproxy 界面出现明文请求(未出现 = 证书未信任或流量没引过来,见坑 2)
- 目标进程需要代理时: 设置
HTTP_PROXY/HTTPS_PROXY环境变量或系统代理;不走代理的进程用透明模式
- 首次运行生成 CA 于
-
沙箱内隔离抓包(re-sandbox 网络隔离):
- 前置:按 re-sandbox 步骤 2 做默认拒绝出站(default-deny egress)——只放行分析基础设施(INetSim / 代理 / 抓包主机)的白名单,其余出站一律丢弃。不要用"断网 / fake DNS / INetSim 三选一"的心智模型,三者解决的不是同一件事:
- 纯断网(Host-only /
--net=none):样本根本无法回连——要抓 C2 就不能纯断网 - fake DNS(/etc/hosts 或 dnsmasq):只影响域名解析,挡不住硬编码 IP 的 C2
- INetSim:模拟服务,但如果不是"默认拒绝 + 只放行它",样本仍可能直连真实网络
- 正确形态:默认拒绝 + 白名单到 INetSim(示例按实际网段调整):
sudo iptables -P FORWARD DROP # 默认拒绝转发(或等价的路由/防火墙策略) sudo iptables -A FORWARD -d <INetSim_IP> -j ACCEPT # 只放行到分析基础设施 sudo iptables -A FORWARD -s <INetSim_IP> -j ACCEPT
- 纯断网(Host-only /
- 抓包点:INetSim 主机侧抓全量(
tcpdump -i eth0 -w c2.pcap),同时拿到样本请求与模拟响应——C2 分析标准做法 - 验证:必须分三条独立验证,且
ping 不通不构成任何一条(ICMP 与 TCP/UDP 是不同通路,被分别放行/阻断是常态):- TCP 出站:从沙箱内
nc -zv <外部IP> 443应失败 - UDP 出站:从沙箱内
nc -zuv <外部IP> 53应失败(UDP 最常被漏测) - 硬编码 IP 直连:不依赖 DNS 直接连外部 IP,仍应失败(对应"fake DNS 挡不住硬编码 C2")
- TCP 出站:从沙箱内
- 同时确认:沙箱内样本回连被 INetSim 记录,且 pcap 有对应流量(re-analyze/platform-tips 最高原则)
- 需要透明代理(mitmproxy)时用 nat REDIRECT 引流到其监听端口(mitmproxy 不消费 NFQUEUE 队列):
mitmproxy 以透明模式监听 8080 承接;分析完清理 nat 规则并还原 ip_forward
sudo sysctl -w net.ipv4.ip_forward=1 # 明文 HTTP 与 TLS 两条都要引——只写 80 是最常见的失误:目标访问 443 时根本不会进入 mitmproxy sudo iptables -t nat -I PREROUTING -p tcp -m multiport --dports 80,443 -j REDIRECT --to-port 8080 # 网关入口 sudo iptables -t nat -I OUTPUT -p tcp -m multiport --dports 80,443 -j REDIRECT --to-port 8080 # 本机出站(按需) # 样本可能使用非标准 TLS 端口(8443 等)或纯明文的其它端口——按实际观测补齐,或直接对全部 TCP 引流 - NFQUEUE 仅留给显式绑定的用户态 handler(如 python
netfilterqueue对每个包返回 verdict),无 handler 时流量阻塞:分析完需同时删除 FORWARD 与 OUTPUT 两条规则sudo iptables -I FORWARD -j NFQUEUE --queue-num 1 # 转发链 sudo iptables -I OUTPUT -j NFQUEUE --queue-num 1 # 本机出站(按需)
- 前置:按 re-sandbox 步骤 2 做默认拒绝出站(default-deny egress)——只放行分析基础设施(INetSim / 代理 / 抓包主机)的白名单,其余出站一律丢弃。不要用"断网 / fake DNS / INetSim 三选一"的心智模型,三者解决的不是同一件事:
跨域联合
- re-protocol:本技能是其工作流第 1 步(捕获)——所有协议分析的原料入口
- re-malware:C2 回连捕获——re-malware 工作流第 4 步的捕获环节,配合 re-sandbox INetSim/fake DNS 环境
- re-firmware:固件通信捕获——仿真环境的虚拟网卡抓包(re-fw-emulate 启动后在本机抓)
- re-sandbox:网络隔离是捕获的前置(INetSim / fake DNS / 断网),防真外联(re-analyze/platform-tips 最高原则)
- 捕获产物供 re-proto-rev(明文)与 re-crypto-decrypt(密文)消费
常见坑与陷阱
- 沙箱网络不隔离 → 真外联:现象——样本真实访问了外网 C2,行为结果与流量都不可信;原因——跳过 re-sandbox 网络隔离直接联网跑(NAT 默认允许出站),或只做了"断网 / fake DNS / INetSim"其中之一就以为隔离完成(三者不等价:纯断网抓不到 C2、fake DNS 挡不住硬编码 IP);对策——抓包前落地默认拒绝出站 + 白名单到分析基础设施,并分别验证 TCP、UDP、硬编码 IP 直连三条路径都不通——只测
ping不构成结论(ICMP 与 TCP/UDP 是不同通路) - TLS/HTTPS 抓包只见密文:现象——pcap 里全是 TLS 握手与加密记录,看不到明文协议内容;原因——没有中间人,TLS 会话两端加密;对策——步骤 4 上 mitmproxy 透明/常规代理,目标信任 mitmproxy CA 后再抓,界面应出现明文
- 过滤表达式写错漏关键流:现象——抓了半天 pcap 里没有目标流量(比如只按了 IP 没按端口,或
and/or优先级用错);原因——BPF 语法组合错误且没先屏显验证;对策——先不带-w屏显跑几秒确认命中目标(IP/端口/方向都对)再写盘 - 抓包文件巨大 → 分析卡死:现象——全量抓包 pcap 几十 GB,tshark 统计/导出长时间无响应;原因——没先过滤就存盘(步骤 2 的正确做法是先过滤再存);对策——用 BPF 过滤 +
-c限包数 +-s限捕获长度,先按会话统计缩小范围再导出子集(步骤 3) - DoH/DoT 回连抓不到查询内容:现象——fake DNS/INetSim 日志零查询,pcap 里只有到 dns.google / cloudflare-dns.com 的 443(DoH)或 853(DoT/DoQ)密文流,样本回连域名线索完全缺失;原因——样本实现自有 DNS 客户端直连加密解析器,不经系统 resolver——DNS 层监控看不到查询,内容又被 TLS 加密;对策——把"已知 DoH 端点 + 无 SNI 的 TLS 握手 + 非浏览器进程直连 DoH 解析器"当 C2 信号捕获(DoT/DoQ 的 853 端口可防火墙直断,DoH 只能重定向端点 IP 或 mitmproxy 中间人 443),配合信标周期分析补内容缺失,单凭"查询内容"定位回连在此场景不成立
- 命令族速查与操作序列见 commands;工具特有坑与版本差异见 gotchas