Network Forensics Analysis of a DDoS Attack

The brief

You are a junior investigator in the Digital Forensics Unit. The Security Operations Center has escalated a ticket: a small e-commerce company, GadgetGalaxy, hosts a multiplayer game server alongside its storefront, and that server became completely unresponsive for about an hour this morning. Revenue was lost. Their network team managed to capture a short sample of traffic — roughly twenty-four seconds — while the incident was still under way.

Your job is a preliminary analysis: establish what kind of attack this was, identify what it targeted, and give an honest assessment of what the evidence can and cannot prove. Your findings will guide whether the unit approaches upstream ISPs next.

How this page works

Each step ends with a checkpoint. Answer it from the evidence file — every question tells you both the Wireshark menu path and the tshark command that produces the answer. A step only counts toward your progress once every one of its checkpoint questions is right. Nothing is sent anywhere; your progress is stored in this browser.

The capture is real attack traffic from the public StopDDoS packet-captures archive. The victim's address was rewritten to a private one by the collectors; the attack traffic itself is untouched.

0 — Tools and evidence

Install Wireshark

Wireshark is the standard network protocol analyzer, and installing it also gives you the two command-line tools this lab uses: capinfos for file summaries and tshark for filtering and statistics. Every step below can be done either way — menus or terminal.

Windows / macOS: download the installer from wireshark.org/download and follow the prompts. Windows users: when the installer offers Npcap, leave that box ticked. Default Npcap settings are fine.
Linux: use your package manager, then add yourself to the wireshark group and log out and back in.

bash

# Debian / Ubuntu
sudo apt update && sudo apt install wireshark -y

# Fedora / RHEL
sudo dnf install wireshark -y

# then, on either:
sudo usermod -aG wireshark $USER

When Debian's installer asks “Should non-superusers be able to capture packets?”, answer Yes so you do not have to run Wireshark as root.

Acquire the evidence

Download DrDoS_SYN.pcap and move it into a dedicated folder, for example ~/Lab1-DDoS.
Verify its hash before you open it. A hash proves the copy on your disk is byte-for-byte the copy that was published — this is a routine step in any forensic process, not a formality.

bash

# Linux, macOS, WSL
shasum -a 256 DrDoS_SYN.pcap

# Windows command prompt
certutil -hashfile DrDoS_SYN.pcap SHA256

In the GUI, once the file is open, Statistics › Capture File Properties shows the same SHA256.

Checkpoint 0

Answer both to complete this step.

What is the SHA256 hash of your copy of DrDoS_SYN.pcap?
Suppose your hash had not matched. What is the correct next action?

Stop, discard the copy and download it again -- findings from an unverified file cannot be tied back to the seized evidence. Carry on with the analysis and note the mismatch in the report. Recalculate the hash with a different algorithm until one of them matches.

1 — Gauge the traffic volume

Start with the shape of the file as a whole. Before you filter anything, find out how much traffic there is, over how long, and how big the packets are.

Open the file and read its properties

GUI: launch Wireshark, then File › Open and select DrDoS_SYN.pcap. Then open Statistics › Capture File Properties.

bash

capinfos DrDoS_SYN.pcap
tshark -r DrDoS_SYN.pcap -Y "tcp.len > 0" | wc -l

What to look for: the packet count against the duration tells you the average rate. The average packet size tells you something else entirely — work out how many bytes an Ethernet, IP and TCP header take up with no data after them, and compare. The second command counts packets carrying any application data at all.

Graph the traffic over time

GUI: Statistics › I/O Graph. It plots packets per second by default.

bash

tshark -r DrDoS_SYN.pcap -q -z io,stat,1

What to look for: this traffic does not arrive as a smooth plateau. Note where the peaks are, how high they go, and what happens in between and afterwards — the peak rate is the number your report will quote as the measure of impact. Note too that there is no quiet period at the start to use as a baseline: the sample was taken with the incident already under way, so everything on this graph is attack.

Checkpoint 1

All three must be right to complete this step.

How many packets does the capture contain?
What is the average packet size, in bytes?
What does that average packet size tell you about these packets?

They are unusually large, so the attacker is trying to saturate the link with volume. They have been truncated by the capture filter, so the payloads exist but were not recorded. They carry no payload at all -- every packet is a bare header, so this is not a conversation.

2 — Find the dominant protocol

You have confirmed a flood. Now find out what kind of traffic it is made of. The Protocol Hierarchy breaks the whole capture down by protocol in one view.

GUI: Statistics › Protocol Hierarchy.

bash

tshark -r DrDoS_SYN.pcap -q -z io,phs

What to look for: read the tree twice. Once for what dominates, which narrows the rest of your investigation to a single transport protocol. Then read it again for what is missing — list the protocols you would expect to see on a live, customer-facing server and check which of them appear here at all.

Checkpoint 2

Both must be right to complete this step.

What percentage of the capture’s packets are TCP? Give a whole number.
What is the most significant thing missing from the hierarchy?

There is no IPv6 traffic, which suggests the capture was filtered before it was saved. There are no application-layer protocols at all, so the capture holds no legitimate sessions to compare against. There is no ARP traffic, which means the capture was taken outside the victim’s local network.

3 — Isolate the attack signature

A TCP connection opens with a three-way handshake: the client sends a SYN, the server answers with a SYN-ACK, the client confirms with an ACK. A SYN flood sends the first packet over and over and never finishes, leaving the server holding half-open connections until it runs out of room for new ones.

A filter that matches SYN set and ACK unset therefore isolates connection requests only — the opening packet of a handshake, never a reply.

display filter

tcp.flags.syn == 1 and tcp.flags.ack == 0

GUI: paste that into the green display-filter bar at the top of the Wireshark window and press Enter. Then read the status bar at the very bottom, which reports how many packets are Displayed and what share of the file that is. Then change ack == 0 to ack == 1 to look for the server’s replies, and read the status bar again.

bash

# connection requests
tshark -r DrDoS_SYN.pcap -Y "tcp.flags.syn==1 and tcp.flags.ack==0" | wc -l

# the server's replies
tshark -r DrDoS_SYN.pcap -Y "tcp.flags.syn==1 and tcp.flags.ack==1" | wc -l

Do not judge the first filter by whether the packet list looks different. Read the Displayed count. If a filter changes nothing on screen, that is itself a result worth explaining.

What to look for: the ratio between those two numbers is the whole story. A healthy server under heavy legitimate load produces requests and replies in roughly equal measure. Ask yourself what it means if one of these two numbers is zero.

Checkpoint 3

All three must be right to complete this step.

How many packets match tcp.flags.syn == 1 and tcp.flags.ack == 0?
How many SYN-ACK replies — completed handshakes — does the capture contain?
What do those two figures, taken together, establish?

The server was refusing connections deliberately, which is why no handshake completed. The replies were sent but travelled by a different route and so were not captured. The server never answered a single request, neither accepting nor refusing -- the denial of service is visible in its silence.

4 — Victim, service and source

Who was hit

GUI: Statistics › Endpoints, then the IPv4 tab, sorted by Packets. Do not scroll the packet list hunting for a pattern — with tens of thousands of packets that does not scale, and this view answers the question in one screen. Read the Tx and Rx columns as well as the totals.

bash

tshark -r DrDoS_SYN.pcap -q -z endpoints,ip | head

What was hit

GUI: read the destination port in the Info column, or open Statistics › Conversations and select the TCP tab.

bash

tshark -r DrDoS_SYN.pcap -T fields -e tcp.dstport | sort | uniq -c | sort -nr | head

What to look for: a flood aimed at one port is aimed at one service, not at the machine in general. That is what tells you which of GadgetGalaxy’s services went down, and it is what a responder needs in order to write a mitigation rule narrow enough to leave the rest of the host working.

Where it came from

bash

# the busiest sources
tshark -r DrDoS_SYN.pcap -Y "tcp.flags.syn==1 and tcp.flags.ack==0" -T fields -e ip.src | sort | uniq -c | sort -nr | head -n 20

# how many distinct sources in total
tshark -r DrDoS_SYN.pcap -Y "tcp.flags.syn==1 and tcp.flags.ack==0" -T fields -e ip.src | sort -u | wc -l

What to look for: compare the number of distinct source addresses against the total packet count, and see how many packets even the busiest single source managed to send. Then ask whether that pattern looks like a botnet, where a few thousand compromised machines each send many packets.

Prove the spoofing

A large source count is suggestive, but on its own it is not proof — a genuinely enormous botnet would also show many addresses. One field in the IP header settles it.

GUI: select any packet, expand Internet Protocol Version 4 in the detail pane, right-click the Time to Live field and choose Apply as Column. Sort the new column.

bash

tshark -r DrDoS_SYN.pcap -T fields -e ip.ttl | sort | uniq -c

What to look for: every IP packet leaves its sender with an operating-system default TTL and loses one for each router it crosses. Packets genuinely originating from thousands of different hosts scattered across the internet therefore arrive with a wide spread of TTL values, because those hosts are different numbers of hops away. Count how many distinct values this capture actually contains.

Checkpoint 4

All five must be right to complete this step.

What is the victim’s IP address?
Which TCP destination port was targeted?
How many distinct source addresses sent SYN packets?
How many distinct TTL values appear across the whole capture?
Why does that TTL result contradict the idea that this traffic came from tens of thousands of separate hosts?

Hosts that far apart could not all be the same number of hops away, so the source addresses are forged by a single sender. A low TTL always indicates a forged packet, regardless of how many values appear. TTL is reset by every router, so any variation at all would prove the addresses were genuine.

Write the report

The checkpoints above establish the facts. The graded deliverable is the report you write from them — a preliminary analysis of the kind you would hand a supervisor in the DFU. Use the template in the PDF handout, which has the full structure and the blanks to fill.

It has four parts:

Evidence details — filename, SHA256, capture window.
Executive summary — three or four sentences for someone who will read nothing else: what happened, to whom, by what mechanism, and why naming the attacker is not straightforward.
Key findings — attack type with the evidence that establishes it, victim address, targeted port, source characteristics, the quantitative indicators, and your packet-level proof of spoofing.
Attribution challenges — what this evidence cannot establish, and what the next investigative step would be.

Write it in your own words. Every figure you need is one you produced yourself in the five checkpoints, and a finding stated without the evidence behind it is not a finding.