re-netcap

网络流量捕获

何时使用 / 何时不用

• 用：任何需要拿到网络流量的任务——恶意样本回连观察、固件通信分析、协议逆向的原料获取
• 用：已有 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]] で使用できるようにします。

1. キャプチャポイントを選択する（ローカル / ゲートウェイ / 中間者）：

   • ローカル: 対象プログラムがローカルで実行されている場合 → tcpdump -i eth0 host <目标IP>（または Wireshark でインターフェースを選択して直接キャプチャ）
   • ゲートウェイ/転送ポイント: 対象がサンドボックス VM / 別のホストにある場合 → ゲートウェイホストまたは VM の仮想 NIC（virbr0 / vboxnet0）でキャプチャし、tcpdump -i virbr0 を実行
   • 中間者: HTTPS の平文を確認する必要がある場合 → mitmproxy の透過プロキシで対象トラフィックを強制的にローカルへ転送します（手順 4、5 を参照）。TLS を分解しないパケットレベルの傍受のみなら nfqueue handler を使用します
   • サンドボックス環境: キャプチャポイントはサンドボックスの仮想 NIC + [[re-sandbox]] の INetSim/fake DNS の着地点にします（手順 5 を参照）
   • 判断記録：キャプチャポイントとその理由（なぜそのポイントでリクエストとレスポンスの両方を確認できるのか）を記録します

2. 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 個のファイルを保持することで、ディスクの容量超過を防ぎます

3. 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、プロトコルデコードへの移動）には、同じ pcap を Wireshark GUI で開きます

4. 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 環境変数またはシステムプロキシを設定します。プロキシを経由しないプロセスには透過モードを使用します

5. サンドボックス内での隔離キャプチャ（[[re-sandbox]] のネットワーク隔離）：

   • 前提条件：[[re-sandbox]] の手順 2 に従い、デフォルト拒否のアウトバウンド（default-deny egress）を設定します。分析インフラ（INetSim / プロキシ / キャプチャホスト）のホワイトリストのみ許可し、それ以外のアウトバウンドはすべて破棄します。「ネットワーク切断 / fake DNS / INetSim のいずれかを選ぶ」という考え方は使わないでください。この 3 つは同じ問題を解決するものではありません：
     • 完全なネットワーク切断（Host-only / --net=none）：サンプルはまったく外部へ再接続できません——C2 をキャプチャするには、完全なネットワーク切断にしてはいけません
     • fake DNS（/etc/hosts または dnsmasq）：ドメイン名の名前解決にのみ影響し、ハードコードされた IP の C2 は阻止できません
     • INetSim：サービスをシミュレートしますが、「デフォルト拒否 + 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
       

   • キャプチャポイント：INetSim ホスト側で全トラフィックをキャプチャします（tcpdump -i eth0 -w c2.pcap）。これにより、サンプルのリクエストとシミュレートされたレスポンスを同時に取得できます——C2 分析の標準的な手法です
   • 確認：3 つの項目をそれぞれ独立して検証する必要があります。また、ping 不通はどの項目の検証にもなりません（ICMP と TCP/UDP は別の経路であり、それぞれ個別に許可/遮断されるのが一般的です）：
     • TCP アウトバウンド：サンドボックス内から nc -zv <外部IP> 443 を実行すると失敗すること
     • UDP アウトバウンド：サンドボックス内から nc -zuv <外部IP> 53 を実行すると失敗すること（UDP は最もテスト漏れが起こりやすい項目です）
     • ハードコードされた IP への直接接続：DNS に依存せず外部 IP に直接接続しても失敗すること（「fake DNS ではハードコードされた C2 を阻止できない」ことへの対策です）
   • あわせて確認：サンドボックス内のサンプルの再接続が INetSim に記録され、pcap にも対応するトラフィックが存在すること（[[re-analyze/platform-tips]] の最重要原則）
   • 透過プロキシ（mitmproxy）が必要な場合は、nat REDIRECT を使ってリスニングポートへ転送します（mitmproxy は NFQUEUE キューを処理しません）:

     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 を転送してください
     

     mitmproxy を透過モードで 8080 にバインドして受信します。分析後は nat ルールを削除し、ip_forward を元に戻します
   • NFQUEUE は、明示的にバインドされたユーザー空間 handler（例：各パケットに verdict を返す python netfilterqueue）にのみ使用します。handler がない場合、トラフィックはブロックされます:

     sudo iptables -I FORWARD -j NFQUEUE --queue-num 1      # 転送チェーン
     sudo iptables -I OUTPUT -j NFQUEUE --queue-num 1       # ローカルからのアウトバウンド（必要に応じて）
     

     分析後は FORWARD と OUTPUT の両方のルールを削除する必要があります

クロスドメイン連携

• [[re-protocol]]：このスキルは、そのワークフローの第 1 段階（キャプチャ）です——すべてのプロトコル分析の素材となる入口です
• [[re-malware]]：C2 再接続のキャプチャ——re-malware ワークフローの第 4 段階にあるキャプチャ工程で、[[re-sandbox]] の INetSim/fake DNS 環境と組み合わせます
• [[re-firmware]]：ファームウェア通信のキャプチャ——エミュレーション環境の仮想 NIC でキャプチャします（[[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]]