Level 2 · Easy · Brute force

SSH Brute Force in a PCAP: Find the Login That Worked

A Linux server in the server subnet started logging authentication failures this evening. The network team mirrored its switch port for about a minute and a half. You have the capture and one question: is someone guessing passwords, and did they get in?

The server subnet is 10.20.50.0/24 behind a gateway at 10.20.50.1. SSH is encrypted, so you will not see passwords: you will work from the shape of the sessions. Everything in this file is synthetic: documentation IP ranges, .example names and random bytes where encryption would be.

What you will find in the capture

Background noise: ARP, a DNS lookup and HTTP health checks from a monitoring host
Many short SSH sessions from a single internet address
One session that does not look like the others

Level 2 · Easy · Brute force · 1246 packets

SSH Brute Force in a PCAP: Find the Login That Worked

You will practise

Find connection floods to one service with TCP flag and port filters
Count attempts and estimate their rate from timestamps
Read what the cleartext SSH banners tell you about the client
Spot the session whose length and traffic pattern differ from the rest
Turn a brute-force finding into containment steps

8 questions. Each hint costs 25% of that question’s points; a wrong try costs a little. Your score is out of 100.

Loading the capture…

Loading…

Sample report · illustrative data

Sample result: Cleartext HTTP Login case

Example run of the starter case on a synthetic capture (documentation and private IP ranges, .example names, a made-up account).

Scoring

Score: 82/100 (example)
Grade: B, solid analysis
Hints used: 2 (example)
Time: 6m 40s (example)

Findings in the example run

Question	Filter that finds it	Read
Where is the login submitted?	http.request.method == "POST"	One POST to the intranet over port 80
What crossed the wire?	http.file_data contains "username="	Username and password readable as typed
Did it work?	http.response.code == 302	Redirect plus a session cookie without Secure

Recommended next steps (example)

Serve the intranet over HTTPS only, with HSTS and Secure cookies
Reset the exposed password and end the account's sessions
Search wider captures for other cleartext logins

Made-up example data. Your own run uses your inputs. Downloads of the full report need Pro.

Downloads

Take the capture into Wireshark or your own tools, and keep the analyst report with the answer key.

244.0 kB · 1246 packets · SHA-256 7b98b1deb95669f126737d8d3aed4cede469b3b169d07635cc4b8148dd6f3ab4

Sample of the debrief

This capture shows a password-guessing attack against an internet-facing SSH server: dozens of short sessions from one address, a few per second, each exchanging banners and keys, trying passwords and being closed by the server.

The full debrief, with next steps and the MITRE ATT&CK mapping, appears when you finish the case.

What you will learn

Find connection floods to one service with TCP flag and port filters
Count attempts and estimate their rate from timestamps
Read what the cleartext SSH banners tell you about the client
Spot the session whose length and traffic pattern differ from the rest
Turn a brute-force finding into containment steps

Frequently asked questions

How do you detect an SSH brute force attack in Wireshark?

Filter for new connections to port 22 with tcp.flags.syn == 1 && tcp.flags.ack == 0 && tcp.dstport == 22. Many short sessions from one source in a short time is brute forcing. Statistics > Conversations (TCP) shows how short each one is.

Can you see SSH passwords in a PCAP?

No. Everything after the key exchange is encrypted. Only the version banners (SSH-2.0-...) are readable. You work from the number, timing and length of sessions, and confirm with the server’s authentication log.

How do you tell a successful SSH login from failed ones in a capture?

Failed attempts are short and usually closed by the server after a few packets. A successful interactive login lasts longer, is often closed by the client, and shows small client packets (keystrokes) with larger server replies (output).

What does the SSH client banner tell you?

It names the client software. Library banners such as SSH-2.0-Go or unusual strings are common in automated tools, while people normally use OpenSSH or PuTTY clients. A banner can be faked, so treat it as a clue, not proof.

Is this real traffic?

No. PlayCISO generated it with its own script from a fixed seed: documentation IP ranges (RFC 5737), private RFC 1918 addresses, .example names, locally administered MAC addresses, and random bytes in place of SSH encryption.