Lab 3.5 — PCAP Analysis with Wireshark

Lab Overview

The Scenario

The incident response team has confirmed that Operation Wire Tap involved multiple attack phases. The network team has provided PCAP files captured during the attack window. Your job is to analyze these captures at the packet level using tshark, extract concrete evidence, and document your findings. The EveBox alerts from previous labs serve as your roadmap — you know WHAT happened, now you need to see the raw proof.

Part 1: Getting Started with tshark

Accessing the Terminal

Your lab environment includes a browser-based terminal (ttyd). Access it through the lab interface to run tshark commands.

Essential tshark Commands

First Look: Capture Overview

Start with a high-level view of the capture:

tshark -r /data/capture.pcap -q -z io,stat,10

This shows packet counts in 10-second intervals. Note any traffic spikes — these often correlate with attack phases.

Next, get a conversation summary:

tshark -r /data/capture.pcap -q -z conv,tcp

Record the top talkers (most packets exchanged) and note any external IP addresses.

Part 2: TCP Handshakes — Connection Analysis

The Three-Way Handshake

Every TCP connection starts with:

1. SYN: Client → Server (request to connect)
2. SYN-ACK: Server → Client (connection accepted)
3. ACK: Client → Server (connection established)

Exercise: Find Scanning Activity

Look for SYN packets without completed handshakes — this indicates port scanning:

tshark -r /data/capture.pcap -Y "tcp.flags.syn==1 && tcp.flags.ack==0" -T fields -e ip.src -e ip.dst -e tcp.dstport | sort | uniq -c | sort -rn | head -20

This extracts all SYN-only packets (connection initiation without response acknowledgment), groups them by source, destination, and port, and shows the top 20.

Document your findings:

TCP HANDSHAKE ANALYSIS
══════════════════════
SYN-only packets (no completed handshake):
  Source IP: [IP]
  Target ports: [list top ports]
  Count: [number of SYN packets]
  Assessment: [port scan / service discovery / normal]

Completed handshakes to suspicious destinations:
  [IP]:[port] — [count] connections established
  [IP]:[port] — [count] connections established

Exercise: Find the Exploitation Connection

Filter for completed TCP connections to the web server:

tshark -r /data/capture.pcap -Y "tcp.flags.syn==1 && tcp.flags.ack==0 && tcp.dstport==80" -T fields -e ip.src -e frame.time

Identify when the attacker's IP first connected to port 80 — this is the start of the exploitation phase.

Part 3: HTTP Payload Extraction — SQL Injection Evidence

Extracting HTTP Requests

Filter for HTTP traffic and examine the request content:

tshark -r /data/capture.pcap -Y "http.request" -T fields -e ip.src -e http.request.method -e http.request.uri -e http.user_agent

Look for:

• sqlmap user-agent: Automated SQL injection tool signature
• UNION SELECT in URI: SQL injection payload in GET parameters
• POST requests: May contain injection payloads in the body

Deep Dive: Extract Full HTTP Payloads

For POST requests, extract the full request body:

tshark -r /data/capture.pcap -Y "http.request.method==POST" -T fields -e ip.src -e http.request.uri -e http.file_data

Exercise: Decode the SQL Injection

1. Find all HTTP requests containing "UNION" or "SELECT":

tshark -r /data/capture.pcap -Y "http.request.uri contains "UNION" || http.request.uri contains "SELECT"" -T fields -e frame.number -e ip.src -e http.request.uri

2. For each matching request, record:

SQL INJECTION PAYLOAD ANALYSIS
══════════════════════════════
Packet #: [frame number]
Source: [attacker IP]
Method: [GET/POST]
URI: [full request URI]
Payload: [decoded SQL injection query]
Target: [what database/table is being queried]
User-Agent: [tool signature if present]

Click to enlarge

Part 4: DNS Tunneling — Packet-Level Evidence

Filtering DNS Traffic

Extract all DNS queries from the capture:

tshark -r /data/capture.pcap -Y "dns.qry.name" -T fields -e ip.src -e dns.qry.name -e dns.qry.type

Exercise: Identify Tunneling Queries

1. Find unusually long DNS queries (>50 characters):

tshark -r /data/capture.pcap -Y "dns.qry.name" -T fields -e dns.qry.name | awk '{if(length($0) > 50) print length($0), $0}' | sort -rn

2. Examine the query patterns:

DNS TUNNELING PACKET ANALYSIS
═════════════════════════════
Query: [full DNS query]
Length: [characters]
Subdomain Labels: [first.second.third.domain.com]
Encoding: [base64 / hex / plaintext]
Source Host: [internal IP making the query]
DNS Server: [resolver being queried]
Query Type: [A / TXT / CNAME / MX]

3. Check for TXT record responses (commonly used for C2 return channel):

tshark -r /data/capture.pcap -Y "dns.resp.type == 16" -T fields -e ip.src -e dns.qry.name -e dns.txt

Exercise: Calculate DNS Query Rate

tshark -r /data/capture.pcap -Y "dns.qry.name contains \"tunnel\"" -T fields -e frame.time_relative | head -20

Plot the time intervals between queries. Consistent intervals indicate automated C2 beaconing.

Part 5: C2 Beacon Analysis — Timing and Size Patterns

Identifying Beacon Traffic

C2 beacons have distinctive patterns at the packet level:

Exercise: Extract Beacon Timing

Filter for traffic to the suspected C2 IP and examine timing:

tshark -r /data/capture.pcap -Y "ip.dst == [C2_IP]" -T fields -e frame.time_relative -e frame.len -e tcp.dstport

Calculate the intervals between consecutive packets:

C2 BEACON TIMING ANALYSIS
══════════════════════════
Destination: [C2 IP]:[port]
Packet Sizes: [list unique sizes observed]
Average Interval: [seconds between beacons]
Jitter: [variation in interval — max minus min]
Total Beacons: [count of packets matching pattern]
Duration: [first beacon time] to [last beacon time]
Assessment: [confirmed beacon / possible beacon / normal traffic]

Exercise: Extract Beacon Payloads

For TCP-based C2, follow the stream to see the actual data exchanged:

tshark -r /data/capture.pcap -Y "ip.addr == [C2_IP] && tcp.port == [C2_PORT]" -z "follow,tcp,ascii,0"

This reconstructs the TCP stream showing both client and server data. Look for:

• Encoded commands (base64, XOR, custom encoding)
• Command responses (directory listings, system info)
• File transfer indicators

Click to enlarge

Part 6: Evidence Summary and Cross-Reference

Cross-Reference with EveBox

For each piece of evidence you extracted from the PCAP, check whether EveBox generated a corresponding alert:

PCAP-TO-ALERT CROSS-REFERENCE
══════════════════════════════

PCAP Finding                    | EveBox Alert? | SID     | Match Quality
────────────────────────────────|───────────────|─────────|──────────────
SYN scan from [IP]              | [Yes/No]      | [SID]   | [exact/partial/none]
SQL injection in HTTP POST      | [Yes/No]      | [SID]   | [exact/partial/none]
DNS tunneling query >60 chars   | [Yes/No]      | [SID]   | [exact/partial/none]
C2 beacon to [IP]:[port]        | [Yes/No]      | [SID]   | [exact/partial/none]

This cross-reference reveals:

• Alerts that match PCAP evidence perfectly (confirmed detections)
• PCAP evidence with NO corresponding alert (detection gaps)
• Alerts with NO corresponding PCAP evidence (potential false positives)

Deliverable Checklist

Before completing the lab, ensure you have:

• Capture overview — I/O statistics, conversation summary, top talkers identified
• TCP handshake analysis — scanning activity detected, exploitation connection timestamped
• SQL injection payloads — at least 2 HTTP requests with decoded injection queries
• DNS tunneling evidence — long queries identified with encoding pattern and rate analysis
• C2 beacon analysis — timing intervals, packet sizes, and payload extraction documented
• Cross-reference table — PCAP findings mapped to EveBox alerts with match quality

What's Next

In Lab 3.6 — Network Forensics Challenge, you will put all your skills to the test in a minimally guided challenge lab. You will be given a scenario and must independently identify all attack phases, extract IOCs, build a timeline, and write an analyst report using everything you have learned in this module.