Network

What you're doing

A packet capture is a firehose — thousands of frames, most of them noise. The whole skill is throwing away the 99% you don't care about so the 1% that matters stands out, then reassembling what's left into something readable.

Capture vs display filters

• Capture filters (BPF, set before you start): decide what gets recorded at all — port 9080. You can't get back what you never captured.
• Display filters (the Wireshark search box, set after): hide what's already recorded — http, http.request, tcp.port == 9080.

The payoff move is Follow → TCP Stream: right-click a packet and Wireshark stitches every segment of that connection back into one readable transcript. And remember the request line itself is data — a secret in a URL (GET /search?token=…) or a form body is right there in cleartext.

Why plaintext is the problem

HTTP with no TLS puts everything — URLs, headers, bodies — in the clear. Anyone on the path reads it verbatim. The fix is TLS everywhere. These labs are deliberately plaintext so you see what an eavesdropper sees. Open the lab on :9080, capture, and hunt.

Cookies on the wire

A cookie is set by the server in a Set-Cookie: response header, and the browser then echoes it back in a Cookie: request header on every later call. Over plaintext, both are readable — and a session cookie is a bearer token: whoever holds it is the session, no password needed. Catching one is a session hijack.

Hidden form fields

"Hidden" (<input type="hidden">) means hidden from the page, not from the network. CSRF tokens, account ids, pricing — apps stash them in hidden fields and submit them in the form body. On the wire a hidden field looks exactly like any other name=value pair.

Structured bodies

Modern apps often POST JSON instead of a form: {"event":"open","token":"…"}. Same idea — Follow the stream (or read the request body) and the fields are right there. The takeaway: nothing the client sends is secret on plaintext HTTP, whatever it's called or however it's encoded.

Where credentials really live

The juiciest secrets usually aren't in the body — they're in the request headers the client attaches automatically on every call: credentials, bearer tokens, API keys. On plaintext HTTP every one of those rides along in the clear.

Basic auth is just Base64

Authorization: Basic YWRtaW46aHVudGVyMg==

That's not encryption — it's reversible Base64. Decode it and you get admin:hunter2 back verbatim. Wireshark even decodes it under the Authorization field; echo <b64> | base64 -d does it by hand.

Bearer tokens & API keys

Authorization: Bearer <token> and custom headers like X-API-Key are long-lived machine credentials. Unlike a password they often never expire and aren't tied to one login, so catching one in a capture is frequently worse than catching a login. The fix for all of this is TLS — it encrypts the headers too.

The server leaks too

Requests aren't the only place secrets hide. Server responses carry their own headers, and apps leak plenty there — build ids, internal tokens, and especially redirects.

Redirects

A 302 Found tells the browser "go here instead" via a Location: header. Apps routinely bake one-time tokens into that redirect URL (Location: /view?token=…). The browser follows it in a blink, so you never see it — but in a capture the 302 and its Location header sit there plainly, token and all.

Custom headers

Beyond the standard set, apps add their own: X-Build-Token, X-Debug, X-Powered-By. These often reveal versions, internal names, or tokens meant only for other services. Expand every response's header block — the interesting stuff is rarely on the rendered page.

What a WebSocket looks like on the wire

A WebSocket starts as an ordinary HTTP request — a GET with Upgrade: websocket and a Sec-WebSocket-Key. The server answers 101 Switching Protocols, and from then the same TCP connection carries frames: little length-prefixed messages pushed in either direction. Filter websocket and you'll see the handshake, then the frames.

Direction and masking

A quirk that trips people up: client→server frames are XOR-masked with a random key (which is right there in the frame, so it's not security — just proxy-safety), while server→client frames are sent in the clear. Wireshark unmasks automatically and shows the payload either way — so you can read what the browser sent and what the server pushed.

Fragmentation

One logical message can be split across several frames: the first carries the real opcode (text/binary) with the "final" bit off, and the rest are continuation frames (opcode 0) until one arrives with the final bit set. A naive reader sees three fragments of gibberish; the trick is to let Wireshark reassemble them (it flags "Reassembled PDU") — or stitch the payloads together yourself in order.

Binary frames

Not every frame is text. A binary frame (opcode 2) carries raw bytes — Wireshark shows you the hex, not a string. If those bytes happen to be ASCII, decode the hex to read it (CyberChef's "From Hex", or Wireshark's bytes pane). Real protocols use binary frames for everything from protobuf to game state; being able to pull readable data out of one is the skill.

The fix

wss://. Encrypted WebSockets look identical structurally but the frames are inside TLS, so a capture shows only ciphertext. Plaintext ws://, like these labs, shows everything.

FTP in the clear

The File Transfer Protocol is one of the oldest still in daily use, and plain FTP encrypts nothing: the login (USER/PASS), every command, and the file data all cross the wire as readable text. A control connection (port 21, here 2121) carries the commands; file contents move on a separate data connection.

What leaks

Even before you log in, the server announces itself with a 220 banner — often leaking the software, version, and sometimes tokens or internal names. And because PASS is sent verbatim, anyone capturing the control channel reads the password directly. The fix is FTPS (FTP-over-TLS) or, better, SFTP (which is SSH). Here you'll connect and read the banner token straight out of the session.

Telnet: a terminal over the wire, unencrypted

Telnet gives you an interactive shell/console on a remote host — and does it with zero encryption. It predates SSH and is exactly what SSH was invented to replace. Every keystroke you type and every byte the server prints, including the login prompt and password, travels as cleartext.

Why it still matters

Telnet is still all over the place on routers, switches, IoT gear, and industrial equipment. Capturing a Telnet session hands you the device's banner (model, firmware — great for finding exploits) and, if someone logs in, their credentials keystroke by keystroke. Here the edge router greets you with a firmware token in its banner; connect and read it off the wire.

How mail is sent

SMTP is a chatty, human-readable line protocol: the client says EHLO, MAIL FROM, RCPT TO, DATA, then the message, ending with a lone .. The server answers each with a 3-digit code (250 ok). On plaintext SMTP (port 25, here 2525) every line — sender, recipients, the whole message, and any AUTH LOGIN credentials (Base64, not encrypted) — is readable on the wire.

What you can pull

The 220 greeting leaks the server's identity, and after a message is accepted the server returns a queue id — the internal handle for that mail, useful for tracing and sometimes predictable. Here you'll both read the greeting and push a message through DATA to catch the queue id it comes back with. The fix, as ever, is TLS (STARTTLS / SMTPS).

How mail is fetched

POP3 is the classic "download your inbox" protocol, and just as plaintext-friendly as SMTP. The client sends USER, PASS, then commands like STAT, LIST, and RETR n to pull a message; the server answers with +OK / -ERR. On plaintext POP3 (port 110, here 2110) the password and the full message bodies are all readable on the wire.

What you can pull

The greeting leaks the server node, PASS leaks the password, and RETR dumps the entire message — headers and body — in cleartext. That's how an eavesdropper reads your mail, including one-time codes and reset links sitting in your inbox. Here you'll RETR a message and read a recovery code straight out of it.

Redis speaks RESP

Redis is an in-memory key-value store whose wire format, RESP, is deliberately simple and human-readable: a command like GET flag and its reply (a "bulk string", length-prefixed with $) are plain text. It listens on port 6379 (here 6390) and, classically, with no authentication and no TLS — it trusts that only your own servers can reach it.

Why that's dangerous

Expose Redis to a network an attacker can see and they can read every value and run CONFIG GET to pull settings (including requirepass if one is set) — all in cleartext. Capturing one GET hands over whatever secret was stored. Here you'll read a stored value and dump a config secret; the fix is a password, network isolation, and TLS (Redis 6+).

Why connections go backwards

Most firewalls block inbound connections but happily allow outbound ones. So a compromised machine inside a network can't be reached directly — but it can reach out. A reverse shell exploits exactly that: the target connects out to the attacker, who is running a listener, and the shell rides back over that outbound link. Same trick powers C2 beacons and plenty of legitimate tooling.

The two roles

The attacker runs a listener — classically nc -lvnp 4444 — and waits. The target runs the connect-back. When it lands, the listener suddenly has a session it never initiated. In this level you're the listener: start nc -lvnp <port>, click the button, and a mock implant on this box dials your IP and announces itself with a key.

The catch (literally)

For the call-back to arrive, your listener's port has to be reachable from the internet — trivial on a VPS, but behind home NAT you'd need a port-forward. That reachability requirement is precisely why attackers prefer reverse connections in one direction and why defenders watch egress in the other. Read the key the implant sends and submit it.