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.
The manual edition of this lab has you drive Wireshark yourself. Here you drive Claude Code instead: you write the question, it picks the command, runs it, and shows you the output. The investigation is the same one. What changes is that you now have a second thing to examine — the tool's own work.
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 — Claude Code and evidence
You need Claude Code installed and signed in. If it is not, work through the setup guide first — it takes about thirty minutes and this lab assumes it is done. Check with claude --version; a version number means you are ready.
Claude Code works inside the folder you launch it in, so give the evidence a folder of its own. Download DrDoS_SYN.pcap into it first.
mkdir ~/Lab1-DDoS
# move the downloaded DrDoS_SYN.pcap into that folder, then:
cd ~/Lab1-DDoS
claudemkdir $env:USERPROFILE\Lab1-DDoS, then cd $env:USERPROFILE\Lab1-DDoS, then claude.Claude cannot read a capture file by staring at it. It needs the same command-line tools the manual edition uses — tshark and capinfos, both installed with Wireshark. Ask it to check.
Check whether tshark and capinfos are installed on this machine, and if they are not, tell me the exact command to install them for my operating system.What Claude should do: run something like which tshark, tell you what it found, and hand you an install command to run yourself. Claude asks permission before it runs anything; read what it proposes before you press Enter. That habit matters more here than anywhere else — you are about to let a tool touch evidence.
Hash the file before you analyse it. A hash proves the copy on your disk is byte-for-byte the copy that was published — a routine step in any forensic process, not a formality.
Calculate the SHA256 hash of DrDoS_SYN.pcap and show me the command you ran.Check its work: run that command yourself and compare, character for character. This is the one figure in the lab that certifies every other figure, so it is the last one you should take on trust.
# Linux, macOS, WSL
shasum -a 256 DrDoS_SYN.pcap
# Windows command prompt
certutil -hashfile DrDoS_SYN.pcap SHA256Checkpoint 0
Answer both to complete this step.
-
What is the SHA256 hash of your copy of
DrDoS_SYN.pcap?That matches the published hash, so your copy is the evidence and anything you find in it can be tied back to what was seized.
-
Claude tells you the hash matches the published value, but does not show the command it ran. What do you do before recording it?
An unsupported figure is not evidence, and asking twice only tells you the model is consistent, not that it is right. What you can defend later is what you produced yourself, with a command you can name.
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. Ask one question at a time — a prompt that asks for five things at once gets you a summary, and a summary is where figures go missing.
Show me the summary of DrDoS_SYN.pcap with capinfos, and paste the output exactly as it printed.What Claude should do: run capinfos DrDoS_SYN.pcap and show you its output rather than a paraphrase of it. If it hands you three tidy bullet points instead, ask for the raw output — you want the numbers as the tool printed them, including the exact packet count rather than a rounded one.
How many packets in DrDoS_SYN.pcap carry at least one byte of application data, and what command tells you that?Check its work: the command should filter on tcp.len > 0 and count what matches. Run it yourself:
tshark -r DrDoS_SYN.pcap -Y "tcp.len > 0" | wc -lWhat to look for: the packet count against the duration gives 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.
Break DrDoS_SYN.pcap down into one-second buckets and show me how many packets arrived in each.What to look for: this traffic does not arrive as a smooth plateau. Note where the peaks are and how high they go — 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 here 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?
-
Claude summarises the file as “small packets, consistent with a flood”. What turns that into a finding you could defend?
Traffic that is all envelope and no letter is the first sign of a flood rather than customers — but what makes it a finding is the header arithmetic and the zero-match filter, both of which you can reproduce. “Consistent with” is a conclusion borrowed from the tool, and it will not survive being asked how you know.
2 — Find the dominant protocol
You have confirmed a flood. Now find out what kind of traffic it is made of. One command breaks the whole capture down by protocol, and the answer to this step is in what the breakdown does not contain.
Show me the full protocol hierarchy of DrDoS_SYN.pcap exactly as tshark prints it.What Claude should do: run tshark -r DrDoS_SYN.pcap -q -z io,phs and paste the tree. Insist on the tree itself. A model asked about protocols will happily describe the traffic as “predominantly TCP” and stop there, and the sentence is true and nearly useless.
Read it 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 from a live, customer-facing server, and check which of them appear here at all.
Does this capture contain any HTTP, TLS or DNS packets at all, and what command did you use to check?Checkpoint 2
Both must be right to complete this step.
-
What percentage of the capture’s packets are TCP? Give a whole number.
-
Claude reports that the capture is “almost entirely TCP traffic”. What did it leave out that matters more?
A live customer-facing host produces application traffic constantly. Its total absence means this file contains attack traffic and nothing else, which is also why you cannot use it to compare the flood against a normal baseline. A summary that reports what dominates will rarely report what is missing — absence is something you have to go looking for.
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.
So count the requests, then count the replies. Two numbers, two prompts.
How many packets in DrDoS_SYN.pcap have the SYN flag set and the ACK flag clear, and what was the command?Now count the SYN-ACK replies and the RST packets in the same capture, and give me both numbers exactly.Check its work: the filters are tcp.flags.syn==1 and tcp.flags.ack==0 for requests and tcp.flags.syn==1 and tcp.flags.ack==1 for replies. Run both yourself:
# 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 -lWhat 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, and what it additionally means that no RST packets were sent either.
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?
-
Claude reports “no significant response traffic”. What makes that statement usable in your report?
Not one reply out of tens of thousands of requests, and no RST either — a deliberate refusal would have produced resets. This silence is the strongest single piece of evidence in the file: the service was not merely slow, it was gone. That finding is worth exactly as much as your ability to reproduce it on demand.
4 — Victim, service and source
List the busiest IP endpoints in DrDoS_SYN.pcap with their packets sent and received, and show me the command.What to look for: one address received everything and sent nothing back. Read the transmitted and received columns separately, not just the totals — the asymmetry is the point.
Count how many packets went to each TCP destination port and list them from most to least.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.
How many distinct source IP addresses sent SYN packets, and how many packets did the busiest single source send?Check its work: this is the step where a plausible-sounding number costs you most, so produce it yourself.
tshark -r DrDoS_SYN.pcap -Y "tcp.flags.syn==1 and tcp.flags.ack==0" -T fields -e ip.src | sort -u | wc -lWhat to look for: compare the number of distinct sources against the total packet count, and see how few packets even the busiest single source managed to send. Then ask whether that looks like a botnet, where a few thousand compromised machines each send many packets.
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.
Show me every distinct TTL value in DrDoS_SYN.pcap with a count of how many packets carry each one.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 hosts scattered across the internet 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?
-
Claude concludes that the source addresses are spoofed. What in your own output actually proves it?
Addresses spanning close to the whole routable internet, arriving at only two distinct hop distances. That is one sender on one or two paths, rewriting the source field on each packet. The source count alone was only circumstantial, and a model’s assertion of spoofing — however confident, however correct — is not evidence of it.
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.
You may use Claude to check your own draft, which is a different thing from having it write one:
Read my report and list every claim in it that is not backed by a figure I produced from the capture.