SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsre-netcap

re-netcap

Data & analytics

View repository

Updated 10-16 05:06

About this skill

Network Traffic Capture

When to Use / When Not to Use

  • Use: Any task that requires obtaining network traffic—observing malware callback connections, firmware communication analysis, obtaining raw material for protocol reverse engineering
  • Use: Existing pcap that needs exporting/statistics/filtering (tshark step)
  • Use: HTTPS/TLS communication that needs decryption to see plaintext (mitmproxy man-in-the-middle)
  • Don't use: Traffic is already decrypted/unencrypted and only protocol semantics are needed (directly [[re-proto-rev]])
  • Don't use: Sample does not connect to the network (do static analysis first with [[re-triage]])
  • Don't use: Just need a quick look at a single packet (tcpdump -i any -c N gets it done in one go, no need to set up the whole workflow)

Tool Preparation

Verify all tools before use. Running samples for packet capture defaults to inside the sandbox ([[re-sandbox]] network isolation, [[re-analyze/platform-tips]] highest principle)—the capture environment and the isolation environment must both be ready at the same time.

tcpdump — The Workhorse for Command-Line Packet Capture

  • Linux: apt install tcpdump / dnf install tcpdump / pacman -S tcpdump
  • macOS: brew install tcpdump(or the system's built-in version)
  • Windows/WSL: Linux version inside WSL; on native Windows use Wireshark or the dumpcap bundled with Npcap
  • Verify: tcpdump --version；tcpdump -D list interfaces

wireshark / tshark — GUI + CLI analysis (tshark for export and statistics)

  • Linux: apt install wireshark tshark / dnf install wireshark-cli wireshark / pacman -S wireshark-cli wireshark-qt(Arch has split it into wireshark-cli + wireshark-qt; when installing on Debian, select "allow non-root packet capture", or sudo dpkg-reconfigure wireshark-common then add the user to the wireshark group)
  • macOS: brew install --cask wireshark(includes tshark CLI; or brew install wireshark CLI only)
  • Windows: choco install wireshark(or the official installer); inside WSL use the Linux version
  • Verify: tshark --version；tshark -D list interfaces;dumpcap -D
  • Same-family CLI:capinfos(pcap metadata: packet count/duration/truncation),mergecap(merge),editcap(split/deduplicate/rewrite timestamps), installed together with Wireshark

mitmproxy — HTTPS/TLS Man-in-the-Middle Decryption

  • All platforms: pip install mitmproxy（current 12.x requires Python >=3.12; older Python environments need to pin the corresponding older version)
  • macOS: brew install mitmproxy
  • Windows: pip version is fine (or the official installer); inside WSL use the pip version
  • Verify: mitmproxy --version；mitmdump --version

nfqueue — Kernel-Space Traffic Forwarding/Man-in-the-Middle Capture Point (Linux)

  • Linux: apt install iptables libnetfilter-queue1 python3-netfilterqueue / dnf install iptables libnetfilter_queue-devel python3-netfilterqueue / pacman -S iptables libnetfilter_queue python-netfilterqueue; or pip install NetfilterQueue(requires kernel nfnetlink_queue support)
  • macOS/Windows: not supported (use the WSL2 kernel or a Linux VM as the forwarding point)
  • Verify: python3 -c "from netfilterqueue import NetfilterQueue"；iptables -L -n | grep -i NFQUEUE can see the rules

Operating Steps

Execute in order, recording the result of each step. Archive the capture artifacts (pcap path + sha256) for use by [[re-proto-rev]] / [[re-crypto-decrypt]].

  1. Choose the capture point (local machine / gateway / man-in-the-middle)：

    • Local machine: target program runs on the local machine → tcpdump -i eth0 host <目标IP>(or select an interface in Wireshark and capture directly)
    • Gateway/forwarding point: target is in a sandbox VM / another host → capture on the gateway host or the VM virtual NIC (virbr0 / vboxnet0),tcpdump -i virbr0
    • Man-in-the-middle: need to see HTTPS plaintext → mitmproxy transparent proxy forcibly directs the target traffic to the local machine (see steps 4, 5); only for pure packet-level interception (without breaking TLS) use an nfqueue handler
    • Sandbox scenario: the capture point is on the sandbox virtual NIC + [[re-sandbox]]'s INetSim/fake DNS landing point (see step 5)
    • Decision record: write down the capture point and the rationale (why this point can see both the request and the response)

  2. tcpdump filter syntax (filter first, then save to disk)：

    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 syntax key points:and/or/not、host/port/proto, parenthesized grouping; first verify without -w on-screen display that the filter matches the target before writing to disk
    • Combine multiple conditions with parentheses: tcpdump -i eth0 '(host 1.2.3.4 or host 5.6.7.8) and not port 53' -w out.pcap
    • Capture-period options:-n disable reverse DNS resolution (avoid resolution latency and result contamination);-s 200 limit capture length (default 262144 full packet length); for long captures add -C 100 -W 10 rotate every 100MB, keep 10 files to prevent disk exhaustion

  3. tshark export and statistics (extract key flows from an existing 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 元信息：包数/时长/是否截断
    • Field names are subject to verification with tshark -G fields | grep <关键字> —a wrong field name makes tshark directly report "Some fields aren't valid", it will not fail silently
    • Statistical conclusions (session count, protocol distribution, anomalous connections) are recorded in the analysis notes, which are the input for step 1 of [[re-proto-rev]]
    • For complex interaction analysis (Follow TCP Stream, protocol decode navigation), open the same pcap with the Wireshark GUI

  4. HTTPS decryption preparation (mitmproxy CA)：

    mitmproxy -p 8080 --mode transparent        # 透明模式（配合步骤 5 的 nat REDIRECT 引流）
# 或
mitmproxy --set console_eventlog_verbosity=error --listen-port 8080 --mode regular   # 常规代理模式
    • On first run the CA is generated at ~/.mitmproxy/mitmproxy-ca-cert.pem; install that CA into the target system/process trust store (inside the sandbox cp mitmproxy-ca-cert.pem /usr/local/share/ca-certificates/ && update-ca-certificates）
    • Verification: the target process accesses an HTTPS site, and plaintext requests appear in the mitmproxy interface (if they do not appear = the certificate is not trusted or the traffic is not being routed through, see pitfall 2)
    • When the target process needs a proxy: set the HTTP_PROXY/HTTPS_PROXY environment variable or system proxy; for processes that do not go through a proxy, use transparent mode

  5. Isolated capture inside the sandbox ([[re-sandbox]] network isolation)：

    • Prerequisite: dodefault-deny egressaccording to [[re-sandbox]] step 2—only allow the whitelist of analysis infrastructure (INetSim / proxy / capture host), and drop all other outbound traffic.Do not use the mental model of "choose one of network disconnection / fake DNS / INetSim", the three do not solve the same problem:
      • Pure network disconnection（Host-only / --net=none): the sample cannot call back at all—to capture C2 you cannot use pure network disconnection
      • fake DNS(/etc/hosts or dnsmasq): only affects domain name resolution,cannot block C2 with hardcoded IPs
      • INetSim: simulates services, but if it is not "default deny + only allow it", the sample may still connect directly to the real network
      • Correct form:default deny + whitelist to INetSim(adjust the example according to the actual network segment): 
        sudo iptables -P FORWARD DROP                        # 默认拒绝转发（或等价的路由/防火墙策略）
sudo iptables -A FORWARD -d <INetSim_IP> -j ACCEPT   # 只放行到分析基础设施
sudo iptables -A FORWARD -s <INetSim_IP> -j ACCEPT
    • Capture point: capture everything on the INetSim host side (tcpdump -i eth0 -w c2.pcap), obtaining both the sample request and the simulated response—the standard practice for C2 analysis
    • Verification:must be verified separately in three independent ways, and ping 不通does not constitute any one of them(ICMP and TCP/UDP are different pathways, and it is normal for them to be allowed/blocked separately):
      • TCP outbound: from inside the sandbox nc -zv <外部IP> 443 should fail
      • UDP outbound: from inside the sandbox nc -zuv <外部IP> 53 should fail (UDP is the most commonly missed test)
      • Hardcoded IP direct connection: Connecting directly to an external IP without relying on DNS should still fail (corresponding to "fake DNS cannot stop hardcoded C2")
    • Also confirm: the sample's callback connection inside the sandbox is recorded by INetSim, and the pcap has corresponding traffic ([[re-analyze/platform-tips]] highest principle)
    • When a transparent proxy (mitmproxy) is needed, use nat REDIRECT to steer traffic to its listening port (mitmproxy does not consume the NFQUEUE queue): 
      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 listens in transparent mode on 8080 to handle it; after analysis, clean up the nat rules and restore ip_forward
    • NFQUEUE is reserved only for explicitly bound user-space handlers (such as python netfilterqueue returns a verdict for each packet); when there is no handler, traffic is blocked: 
      sudo iptables -I FORWARD -j NFQUEUE --queue-num 1      # 转发链
sudo iptables -I OUTPUT -j NFQUEUE --queue-num 1       # 本机出站（按需）
      After analysis, both the FORWARD and OUTPUT rules need to be deleted

Cross-domain combination

  • [[re-protocol]]: This skill is step 1 of its workflow (capture) — the raw material entry point for all protocol analysis
  • [[re-malware]]: C2 callback capture — the capture phase of step 4 in the re-malware workflow, used with the [[re-sandbox]] INetSim/fake DNS environment
  • [[re-firmware]]: Firmware communication capture — packet capture on the virtual NIC of the emulation environment (capture locally after [[re-fw-emulate]] starts)
  • [[re-sandbox]]: Network isolation is a prerequisite for capture (INetSim / fake DNS / network disconnection), preventing real outbound connections ([[re-analyze/platform-tips]] highest principle)
  • Capture artifacts are consumed by [[re-proto-rev]] (plaintext) and [[re-crypto-decrypt]] (ciphertext)

Common pitfalls and traps

  • Sandbox network not isolated → real outbound connection: Symptom — the sample actually accessed an external C2, and both the behavioral results and traffic are untrustworthy; Cause — skipping [[re-sandbox]] network isolation and running directly online (NAT allows outbound by default),or doing only one of "network disconnection / fake DNS / INetSim" and assuming isolation is complete(the three are not equivalent: pure network disconnection cannot capture C2, fake DNS cannot stop hardcoded IPs); Countermeasure — before capturing, implementdeny outbound by default + whitelist to analysis infrastructure, andseparatelyverify that all three paths — TCP, UDP, and direct hardcoded IP connections — are blocked —testing only ping does not constitute a conclusion(ICMP and TCP/UDP are different paths)
  • TLS/HTTPS capture shows only ciphertext: Symptom — the pcap is full of TLS handshakes and encrypted records, with no plaintext protocol content visible; Cause — without a man-in-the-middle, both ends of the TLS session encrypt; Countermeasure — in step 4, set up mitmproxy as a transparent/regular proxy, have the target trust the mitmproxy CA, then capture again, and plaintext should appear in the interface
  • Incorrect filter expression misses key flows: Symptom — after capturing for a while, the pcap has no target traffic (for example, filtering only by IP and not by port, or and/or with incorrect precedence); Cause — incorrect BPF syntax combination and no on-screen verification first; Countermeasure — first run without -w on-screen for a few seconds to confirm it hits the target (IP/port/direction all correct), then write to disk
  • Huge capture file → analysis freezes: Symptom — full capture pcap is tens of GB, and tshark statistics/export become unresponsive for a long time; Cause — saving to disk without filtering first (the correct approach in step 2 is to filter first, then save); Countermeasure — use BPF filtering + -c packet count limit + -s capture length limit, first narrow the scope by session statistics, then export a subset (step 3)
  • DoH/DoT callbacks cannot capture query content: Phenomenon — fake DNS/INetSim logs show zero queries, and the pcap contains only ciphertext flows to dns.google / cloudflare-dns.com on 443 (DoH) or 853 (DoT/DoQ), with the sample's callback domain clues completely missing; Cause — the sample implements its own DNS client directly connecting to encrypted resolvers, bypassing the system resolver — DNS-layer monitoring cannot see the queries, and the content is encrypted by TLS; Countermeasures — treat "known DoH endpoints + TLS handshakes without SNI + non-browser processes directly connecting to DoH resolvers" as C2 signals to capture (port 853 for DoT/DoQ can be blocked directly by firewall; DoH can only be handled by redirecting endpoint IPs or mitmproxy man-in-the-middle on 443), and combine with beacon periodicity analysis to compensate for the missing content; locating the callback based solely on "query content" does not hold in this scenario
  • For a quick reference of command families and operation sequences, see [[commands]]; for tool-specific pitfalls and version differences, see [[gotchas]]