LetsDefend: ICS FuelStation — reading the attack in the packet capture

Industrial control system traffic is a good place to learn packet analysis, because the normal behaviour is so regular. A fuel station's control network does more or less the same thing all day. That makes anything irregular stand out — provided you know how to ask the capture the right question.

This challenge gives you a capture and asks you to reconstruct what happened. One tool does the whole job.

Tools#

• Wireshark — that is the entire toolkit for this one.

Where to start: separate the scan from the session#

The instinct with a large capture is to scroll it. Don't. Filter it.

TCP flags are the fastest way to understand the shape of what happened, because a scan and a real conversation look completely different at the flag level.

tcp.flags.syn == 1

This shows every connection attempt. A host methodically SYN-ing its way across a range of ports is scanning — and the port list it walks tells you what the attacker was looking for before they found anything.

tcp.flags.ack == 1

This shows traffic that got a response. The difference between these two sets is the whole story: hundreds of SYNs and a handful of ACKs means most of the scan hit closed ports, and the small set that came back is where the attacker actually got in.

Once a candidate port stands out, pivot to it:

tcp.port == [the port you identified]

Now you are looking only at the conversation that mattered, with the scan noise gone. Follow that stream and read what was actually exchanged.

Why this order matters#

It is tempting to jump straight to tcp.port filtering once you have a guess. Resist that. Filtering by flags first means the capture tells you which port is interesting, rather than you confirming a hunch and missing a second, quieter connection somewhere else.

That mistake — finding one thing and stopping — is the most common way a real incident gets under-scoped.

Turning it into a report#

Solving the challenge is only half of it. The output of an investigation is a document someone else can act on, and writing one is the part most people skip while practising.

Structure it around:

• The artefacts found — which hosts, which ports, which timestamps, and where in the capture each one came from. Anyone reading it should be able to reproduce your finding.
• The threat actor's steps, in order — reconnaissance through to whatever they achieved. A timeline, not a list of observations.

Writing that report is what turns "I found the flag" into "I can explain what happened to someone who wasn't there". Only one of those is a job skill.

What to take away#

TCP flag filtering is the cheapest triage available in Wireshark and it works on any capture, not just ICS ones. syn == 1 to find the attempts, ack == 1 to find what answered, then pivot to the port. That three-step pattern will orient you in an unfamiliar capture in under a minute.

References#

• LetsDefend — the platform this challenge runs on
• Wireshark display filter reference — the full TCP filter field list