Cleartext HTTP Login: Find the Password in a PCAP
The network team mirrored a user workstation’s switch port for a few minutes this morning while they investigated a slow intranet. You have been handed the capture with one question: is anything sensitive crossing the network in the clear?
The internal network is 10.20.30.0/24. The intranet web server lives in a server subnet behind the gateway. Everything in this file is synthetic: documentation IP ranges, .example names and a made-up account.
What you will find in the capture
- Background noise: ARP, DNS lookups from two hosts and an encrypted TLS session
- A short browsing session on an http:// intranet site
- A sign-in form submitted over plain HTTP, and what the server sent back
Cleartext HTTP Login: Find the Password in a PCAP
The network team mirrored a user workstation’s switch port for a few minutes this morning while they investigated a slow intranet. You have been handed the capture with one question: is anything sensitive crossing the network in the clear?
The internal network is 10.20.30.0/24. The intranet web server lives in a server subnet behind the gateway. Everything in this file is synthetic: documentation IP ranges, .example names and a made-up account.
You will practise
- Read a packet list and narrow it down with display filters
- Find an HTTP form submission and read its body
- Tell a credential in transit from a page that merely mentions one
- Confirm a successful sign-in from the server’s response and cookie
- Turn the finding into a fix a web team can act on
7 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.
10.3 kB · 57 packets · SHA-256 0b4320f67b9c0a4e6f110defcff795a8b963ac79cc141c3b281d32627ecf9e39
Sample of the debrief
This capture shows a routine sign-in to an internal web application over plain HTTP. Anyone who can see that traffic (a mirror port, a compromised machine on the same segment, a rogue access point) can read the username and password and copy the session cookie, without breaking any encryption.
The full debrief, with next steps and the MITRE ATT&CK mapping, appears when you finish the case.
What you will learn
- Read a packet list and narrow it down with display filters
- Find an HTTP form submission and read its body
- Tell a credential in transit from a page that merely mentions one
- Confirm a successful sign-in from the server’s response and cookie
- Turn the finding into a fix a web team can act on
Frequently asked questions
How do you find a password in a PCAP with Wireshark?
Filter for form submissions with http.request.method == "POST", or search raw bytes with frame contains "password", then open the HTTP layer or use Follow TCP Stream to read the body. Over plain HTTP the username and password are readable as typed (URL-encoded).
Why can you see the password in this capture?
The intranet site uses http:// rather than https://, so nothing encrypts the request. Anyone who can see the traffic can read it. The webmail session in the same capture uses TLS, and its contents are not readable.
How do you know the login succeeded?
The server answered the POST with 302 Found, a redirect to /dashboard, and a Set-Cookie header; the next request sends that cookie. A failed login would usually return the form again or a 401.
Is this real traffic?
No. PlayCISO generated it with its own script from a fixed seed: documentation IP ranges (RFC 5737) and private RFC 1918 addresses, .example and example.com names, locally administered MAC addresses and a made-up account.
Can I open the file in Wireshark?
Yes. It is a classic pcap (Ethernet link type) with correct IP, TCP and UDP checksums, so Wireshark, tshark, Zeek and Security Onion read it. The SHA-256 next to the download lets you check the file.