tcpdump Security Incident Triage: Capture Evidence Fast (2026)

tcpdump is not just a packet sniffer; it’s a time machine for network events, and in a security incident, it’s your most critical diagnostic tool for capturing evidence before it vanishes. The core problem is that network traffic is ephemeral. Without capturing it, you’re trying to understand a crime scene after the forensic team has already cleaned it up. tcpdump lets you rewind and examine exactly what happened on the wire, providing the irrefutable data needed to identify attackers, understand their methods, and prove compromise.

Let’s see tcpdump in action, not just as a command, but as a critical part of incident response. Imagine you’ve just received an alert: a server is exhibiting unusual outbound traffic patterns, potentially indicating data exfiltration.

Here’s a typical, focused capture command:

sudo tcpdump -i eth0 -w /tmp/incident_capture_$(date +%Y%m%d_%H%M%S).pcap 'host 192.168.1.100 and port 443'

Let’s break this down:

• sudo: You need root privileges to capture network traffic.
• -i eth0: This specifies the network interface to listen on. Replace eth0 with the actual interface name of your server (e.g., ens192, bond0). You can find this using ip addr show or ifconfig.
• -w /tmp/incident_capture_$(date +%Y%m%d_%H%M%S).pcap: This is crucial. It writes the captured packets directly to a file in the PCAP format. The filename includes a timestamp, ensuring you can organize multiple captures. Saving to /tmp is common for temporary incident data, but consider a more persistent location if disk space is tight or if /tmp is frequently cleared.
• 'host 192.168.1.100 and port 443': This is the filter. It’s the most important part for efficiency. We’re only capturing traffic to or from the suspect IP address (192.168.1.100) and specifically on port 443 (HTTPS). This drastically reduces the amount of data captured, making analysis faster and more manageable.

When you run this, tcpdump will sit quietly, and for every packet that matches your filter, it will be written to the specified file. You’d typically run this command on the suspected compromised host, or on a network tap/SPAN port if you need to see traffic to that host from an external perspective.

The mental model tcpdump provides is one of raw, unfiltered (or carefully filtered) network reality. It captures Layer 2 (Ethernet frames), Layer 3 (IP packets), and Layer 4 (TCP/UDP segments) information, along with their payloads. This means you can see:

• Who is talking to whom: Source and destination IP addresses and ports.
• What protocol is being used: TCP, UDP, ICMP, etc.
• The sequence of communication: For TCP, you can see SYN, SYN-ACK, ACK, FIN, RST flags, sequence numbers, and acknowledgments, allowing you to reconstruct a TCP session.
• The actual data being transmitted: If the traffic isn’t encrypted, you’ll see the plaintext payload. Even with encryption, you’ll see the encrypted blobs, which can still be useful for identifying patterns or volume.

The power comes from combining tcpdump with analysis tools like Wireshark or tshark. You can then open the .pcap file and:

• Filter further: Apply more granular filters in Wireshark to isolate specific conversations or data patterns.
• Follow TCP streams: Reconstruct entire application-level conversations.
• Inspect packet payloads: Look for suspicious strings, URLs, or commands.
• Analyze timings and latencies: Identify unusual delays or rapid-fire communications.

The most surprising thing about tcpdump is how often its basic filtering syntax is overlooked in favor of capturing everything and then trying to sort through gigabytes of data later. The true power for incident response lies in crafting precise filters upfront to capture only the traffic relevant to the suspected activity. For example, if you suspect an internal SSH brute-force attack from 192.168.1.50 against internal servers on port 22, a filter like 'src host 192.168.1.50 and dst port 22' will give you exactly what you need, rather than overwhelming you with all other network traffic.

When analyzing the captured data, a common mistake is to only look at the "happy path" – the successful connections. However, in security incidents, the failed attempts are often just as revealing. Pay close attention to TCP RST (reset) packets, ICMP error messages (like "destination unreachable"), and repeated connection attempts that never succeed. These can indicate scanning activity, firewall rejections, or attempts to exploit services that aren’t actually running or are misconfigured.

After successfully capturing and analyzing your initial tcpdump data, the next challenge will likely be correlating this network evidence with host-based logs to pinpoint the exact process or user responsible for the malicious network activity.