🔄 Topic

I started working with Wireshark as part of the Google Cybersecurity Certificate. The first surprise was how quickly a packet capture becomes noisy: hundreds of rows, several protocols, addresses, ports, timing columns, and a packet-bytes pane all compete for attention.

The useful skill was not memorising every field. It was learning how to turn the capture into a small set of observations that another analyst could check.

🎯 Goal

Use a supplied sample.pcap file to identify the communication represented by selected packets, then record what is directly visible before drawing a security conclusion.

🛠 What I Did

I opened the capture in Wireshark and worked through the three main panes:

the packet list, where I could compare source, destination, protocol, length, and information;
the protocol tree, where a selected frame exposed Ethernet, IPv4, TCP, and application-layer details;
the packet-bytes view, which showed the encoded bytes behind the decoded fields.

The capture contained 200 displayed packets in the supplied exercise. Several visible rows represented SSH traffic involving TCP port 22. I selected a frame and inspected its Ethernet addresses, IPv4 source and destination, TCP ports, sequence information, and the SSH protocol label.

I also saw why a packet analyser needs context. A line showing an SSH packet is evidence that a packet was decoded as SSH in this capture. It is not, by itself, proof that an account was compromised, that the connection was malicious, or that the payload was readable. The protocol and direction are clues that need to be combined with timing, host ownership, authentication logs, and the rest of the investigation.

🧠 What I Learned

Wireshark is a tool for narrowing questions. I can start with the whole capture, select a protocol or address pattern, and then inspect a single frame without losing the surrounding conversation.

The packet list is useful for finding candidates. The protocol tree is better for explaining one candidate. The raw bytes are a useful reminder that the decoded view is an interpretation of a real network frame, not a magical source of intent.

I also learned to separate three statements:

Observed: this frame contains Ethernet, IPv4, TCP, and SSH fields.
Interpreted: the endpoints exchanged traffic associated with an SSH session.
Not yet proved: whether the session was authorised or suspicious.

That distinction is the same evidence discipline I have been practising in other security work: a tool result is not automatically a verdict.

⚠️ Limitations

This was a course capture, not a capture from a production network. The screenshots show the supplied file and its decoded fields, but they do not establish who owned the endpoints or whether the traffic was expected. I am treating the exercise as training evidence.

✅ Takeaway

Packet analysis becomes less intimidating when I treat it as a chain of small questions: what frame is this, which protocols are present, who are the endpoints, what direction is the traffic moving, and what additional evidence would confirm or challenge the first interpretation?