You’re trying to figure out how a network attack happened, and you’ve got a packet capture (.pcap file) from the time of the incident. This is your primary evidence.
Imagine you’ve just been handed a .pcap file and told, "Figure out what happened here." The initial shock is realizing that a raw packet capture is less a narrative and more a massive, jumbled pile of Lego bricks. Your job is to find the specific bricks that form the weapon, the entry point, and the escape route, and then assemble them into a coherent story.
Let’s look at how a malicious actor might have moved around your network using this capture.
Reconnaissance & Initial Access
The attacker likely started by probing your network. This often looks like a flood of connection attempts.
Diagnosis: Use tshark (the command-line equivalent of Wireshark) to count connections from external IPs to internal ports.
tshark -r capture.pcap -Y "tcp.flags.syn == 1 and not ip.src in { <your_internal_network_cidr> }" -T fields -e ip.src -e ip.dst -e tcp.dstport | sort | uniq -c | sort -nr
This command:
-r capture.pcap: Reads from your capture file.-Y "tcp.flags.syn == 1 and not ip.src in { <your_internal_network_cidr> }": Filters for TCP SYN packets originating outside your internal network. Replace<your_internal_network_cidr>with your actual network range (e.g.,192.168.1.0/24).-T fields -e ip.src -e ip.dst -e tcp.dstport: Outputs the source IP, destination IP, and destination port for each packet.sort | uniq -c | sort -nr: Counts the unique source IP/destination/port combinations and sorts them to show the most frequent connection attempts.
Cause: You’ll likely see a single external IP address attempting to connect to many different internal IPs on common ports (like 22 for SSH, 80/443 for HTTP/S, 3389 for RDP, 445 for SMB). This is a port scan or a brute-force attempt.
Fix: If this is an active threat, the immediate fix is to block the offending IP address at your firewall.
# Example firewall rule (syntax varies by vendor)
iptables -A INPUT -s <malicious_ip_address> -j DROP
This command (iptables) blocks all incoming traffic from the <malicious_ip_address>. It works by telling the firewall to simply discard any packets that match this source IP, preventing further connection attempts.
Exploitation & Command and Control (C2)
Once the attacker gains access, they’ll try to establish a command and control channel to issue further instructions. This traffic is often disguised.
Diagnosis: Look for unusual outbound connections on non-standard ports or patterns that don’t match typical application behavior. For example, a long-lived TCP connection to an external IP on port 8080, but the payload isn’t HTTP.
Use tshark to filter for specific protocols or to examine the content of suspicious flows.
tshark -r capture.pcap -Y "tcp.flags.ack == 1 and ip.dst == <your_internal_ip_that_was_breached>" -T fields -e frame.time -e ip.src -e ip.dst -e tcp.srcport -e tcp.dstport -e data.len
This command:
-Y "tcp.flags.ack == 1 and ip.dst == <your_internal_ip_that_was_breached>": Filters for TCP packets that have the ACK flag set, indicating established communication, directed to the internal machine you suspect was compromised.-e frame.time -e ip.src -e ip.dst -e tcp.srcport -e tcp.dstport -e data.len: Displays the timestamp, source/destination IPs, source/destination ports, and the length of data in the payload for each packet.
Cause: You might observe a pattern of small, frequent outbound packets from the compromised internal machine to an external IP. This could be a beaconing signal for C2. Look for high data volume on unexpected ports.
Fix: Identify the external C2 server IP and port. Block this IP and port at your firewall.
# Example firewall rule
ufw deny out proto tcp from any to <c2_server_ip> port <c2_server_port>
This ufw (Uncomplicated Firewall) command denies all outbound TCP traffic originating from your network (any source IP) destined for the <c2_server_ip> on the specific <c2_server_port>. It stops the compromised machine from "phoning home."
Lateral Movement
After gaining a foothold, attackers often move to other machines on the network to spread their access and find valuable data.
Diagnosis: Look for traffic patterns between internal machines that are unusual. This could involve SMB (ports 139, 445), RDP (port 3389), or SSH (port 22) being initiated from a machine that doesn’t normally act as a client for these services.
Use tshark to filter for these protocols and examine the source/destination IPs.
tshark -r capture.pcap -Y "(smb or smb2) and ip.src == <compromised_internal_ip>" -T fields -e frame.time -e ip.src -e ip.dst -e tcp.dstport
This command:
-Y "(smb or smb2) and ip.src == <compromised_internal_ip>": Filters for SMB traffic originating from the machine you know was compromised.-e frame.time -e ip.src -e ip.dst -e tcp.dstport: Shows the time, source, destination, and destination port for these SMB connections.
Cause: You’ll see the <compromised_internal_ip> connecting to other internal IPs on ports 445 (SMB) or 3389 (RDP). This indicates an attempt to exploit vulnerabilities or use stolen credentials to spread.
Fix: Isolate the compromised machine from the network to prevent further spread. Then, investigate the target machines for signs of compromise.
# Example network isolation command (on managed switch)
# This would be done via the switch's management interface, not a direct command.
# Conceptually: port security disable <port_number_of_compromised_machine>
This action removes the compromised machine’s network connectivity, stopping it from initiating further lateral movement.
Data Exfiltration
The final stage is often stealing data. This can be done through various means, often disguised as legitimate traffic.
Diagnosis: Look for unusually large outbound data transfers, especially to external IPs that aren’t typical destinations for your organization’s data. Protocols like FTP, SFTP, or even disguised HTTP POST requests are common.
tshark -r capture.pcap -Y "ftp or sftp or (http.request.method == POST)" -T fields -e frame.time -e ip.src -e ip.dst -e tcp.dstport -e data.len | sort -k7 -nr
This command:
-Y "ftp or sftp or (http.request.method == POST)": Filters for FTP, SFTP, or HTTP POST requests, which are common for uploading data.sort -k7 -nr: Sorts the output by the data length (the 7th field in this case) in reverse numerical order, showing the largest transfers first.
Cause: You might see a large data.len value for outbound connections, especially if the destination is an unusual external IP or a cloud storage service not sanctioned for use.
Fix: If the exfiltration is ongoing, block the destination IP/domain at the firewall and DNS level. If it’s completed, this evidence is crucial for incident response and legal proceedings.
# Example DNS sinkhole configuration (concept)
# Add the exfiltration domain to your DNS server's blocklist.
# For BIND:
# zone "exfiltrated-domain.com" { type master; file "/etc/bind/db.blocked"; };
This conceptually prevents any internal machine from resolving the domain name of the exfiltration server, effectively cutting off communication.
The next problem you’ll face is reconstructing the timeline of events from these disparate pieces of evidence, often requiring cross-referencing with system logs.