Protocols and Servers 2 TryHackMe Writeup

Somewhere on a network right now, a username and password are crossing the wire in plain, readable text — and someone could be quietly reading them.

No exploit. No zero-day. Just a protocol that was never built to keep a secret.

That’s the uncomfortable little truth this room is built around. So let’s pull it apart.

Most of the internet’s classic protocols were designed in a more trusting era. It was a time when the people sharing a network mostly knew each other, and “someone might be listening” wasn’t the default assumption.

Those protocols still run everywhere. And many of them still send your credentials across the wire in plain text.

Protocols and Servers 2 on TryHackMe is about exactly that gap, and what closes it. It walks through three foundational attacks against network protocols, then the defenses that neutralize each one:

• Sniffing — quietly reading traffic off the wire
• Man-in-the-Middle (MITM) — sitting between two parties and tampering
• Password attacks — guessing or cracking the credentials themselves

This is a writeup of the whole room: the concepts in plain language, the commands that matter, and the task answers explained. If you’re working through it yourself, follow along.

One idea ties the entire room together: cleartext protocols are insecure by design. Everything else is a consequence of that single fact.

Part 1 — Sniffing Attacks

A sniffing attack is the simplest idea in the room: use a packet-capture tool to grab traffic as it crosses the network, then read it.

If a protocol talks in cleartext, anyone positioned to see that traffic can pull out private messages or login credentials. Nothing is encrypted before it leaves your machine.

"Isn't everything encrypted now?"

It’s tempting to think sniffing is a solved, retro problem now that TLS is everywhere. It isn’t. It stays dangerous wherever cleartext still lives:

• Internal corporate networks, where machine-to-machine traffic is often left unencrypted
• Legacy systems like old mail servers, embedded devices, and industrial control systems
• Misconfigured services where TLS is available but not strictly enforced
• IoT devices that habitually use plain protocols
• Wireless networks, where anyone in range can listen
• After a MITM attack that has successfully downgraded or stripped encryption

In real internal pentests and red-team work, sniffing is still one of the most reliable ways to harvest credentials and learn how systems actually talk to each other.

The tools

Capturing packets needs a network card and the right privileges (root on Linux, administrator on Windows). Here are the staples:

• tcpdump — lightweight open-source CLI capture tool, preinstalled on most Linux systems.
• Wireshark — the GUI standard, with powerful filtering, protocol dissection, and visualization.
• tshark — Wireshark’s command-line sibling, great for scripting.

Worth knowing too: tcpflow (reassembles TCP streams), ngrep (pattern-matching in traffic), and NetworkMiner (extracts files from captures).

Specialized credential-grabbers exist, but tcpdump and Wireshark can do the job with a little effort.

Capturing POP3 credentials with tcpdump

The classic demo: a user checks email over POP3 (port 110, cleartext).

With access to the traffic — via a wiretap, a switch’s port mirroring, ARP spoofing, a compromised host, or a successful MITM — you run this command:

sudo tcpdump port 110 -A

Breaking that down:

• sudo — packet capture needs root privileges.
• port 110 — only keep traffic to or from the POP3 server.
• -A — print packet contents as ASCII, so cleartext is human-readable.

In the capture, the login arrives across two packets and reads straight out:

… USER frank … PASS D2xc9CgD

Username frank, password D2xc9CgD, handed over in plain sight.

Wireshark gets you there even faster: type “pop” in the display filter, and only POP3 traffic remains, credentials included.

Handy tcpdump filters

+------------------------------------+-----------------------------------------------------------+
| Command                            | Purpose                                                   |
+------------------------------------+-----------------------------------------------------------+
| sudo tcpdump port 110 -A           | Capture traffic on port 110 (POP3) in readable ASCII      |
| sudo tcpdump host 10.20.30.148 -A  | Capture ASCII traffic to/from a specific host IP          |
| sudo tcpdump port 80 -A            | Capture HTTP traffic (credentials in POST data)           |
| sudo tcpdump port 21 -A            | Capture FTP traffic (cleartext credentials)               |
| sudo tcpdump -w capture.pcap       | Save raw network packets to a file for later analysis     |
| tcpdump -r capture.pcap -A         | Read and display a saved capture file in ASCII text       |
+------------------------------------+-----------------------------------------------------------+

Mitigation

Any cleartext protocol is exposed. The only requirement for the attack is a vantage point between the two parties or on the same network segment.

The core fix is encryption. This means wrapping the protocol in TLS (like HTTP to HTTPS, FTP to FTPS, or POP3 to POP3S) and replacing Telnet with SSH.

Layered on top of that:

• Network segmentation to limit who can see whose traffic
• Encrypted VLANs or tunnels for sensitive internal traffic
• 802.1X port-based authentication so unknown devices can’t connect
• Zero-trust thinking: treat every network as hostile and encrypt everything
• Monitoring for ARP spoofing and other redirection to catch sniffing in progress

Question: How do you capture only Telnet traffic with tcpdump? Answer: Telnet runs on port 23, so you add “port 23”.

Question: What is the simplest Wireshark display filter for IMAP? Answer: “imap”.

Part 2 — Man-in-the-Middle (MITM) Attacks

Sniffing is passive listening. A MITM attack is active.

The attacker slips between two parties (A and B) so that A thinks it’s talking to B, while everything actually flows through the attacker. They can read and completely alter the data.

The room’s example says it best: A asks to transfer $20, the attacker rewrites the amount mid-flight, and B acts on the tampered message.

It works whenever the protocol doesn’t verify the authenticity and integrity of each message.

Getting into the middle

To sit between two parties, an attacker has to redirect traffic through their own machine. Common routes include:

• ARP spoofing — on a local network, the attacker sends forged ARP messages tying their own MAC address to the gateway’s IP, routing traffic directly to them.
• DNS spoofing — feeding false DNS answers to send victims to attacker-controlled servers.
• Rogue access points — fake Wi-Fi setups (like “Airport_WiFi_Free”) that route every connected victim’s traffic through the attacker.
• BGP hijacking — announcing false routes at the internet’s routing layer to reroute traffic for whole organizations or regions.

The tooling

• Bettercap — the modern, actively maintained successor to Ettercap. Handles ARP/DNS spoofing, HTTP/HTTPS proxying, and is modular.
• Ettercap — the classic LAN MITM tool. It still works, but Bettercap is generally preferred today.
• mitmproxy — an interactive HTTPS proxy used for inspecting and modifying web traffic on the fly.
• Responder — Windows-focused. Abuses fallback name-resolution protocols (LLMNR, NBT-NS) that kick in when DNS fails, answering with its own IP to capture authentication hashes. A staple of internal Active Directory pentests.

MITM against encrypted traffic

Encryption raises the bar, but it isn’t a magic shield:

• SSL stripping — quietly downgrade the victim’s connection to plain HTTP while the attacker keeps an HTTPS link to the real server. This is easy to miss if the user never typed “https://” or didn’t check for the padlock icon.
• Fake certificates — present your own certificate and run two separate encrypted legs. This works if the victim blindly clicks through the browser warning or if a Certificate Authority is compromised.
• Compromised or rogue CAs — the most serious case. If an attacker controls a trusted CA, they can mint valid-looking certificates for absolutely any domain.

Modern defenses

A decade of security hardening makes MITM much harder now:

• HTTPS by default (browsers flag plain HTTP as “Not Secure”)
• HSTS (forces HTTPS and blocks stripping attacks)
• Certificate Transparency (public, auditable logs of all issued certificates)
• Certificate pinning (apps accept only specific, hardcoded keys)
• DANE (publishing certificate info in DNSSEC-signed DNS)

MITM still succeeds when users ignore certificate warnings, apps validate keys poorly, the target speaks cleartext, or legacy gear lacks modern features.

The fundamental fix remains the same: cryptography. You need authentication plus encryption/signing, which is exactly what properly implemented TLS provides.

Question 1: How many interfaces does Ettercap offer?

Answer: 3

Question 2: How many ways can you invoke Bettercap?

Answer: 3

Part 3 — TLS: The Fix for Both Attacks

Both sniffing and MITM share one cure: TLS (Transport Layer Security). This part of the room is the solution chapter.

A quick history

SSL appeared in 1994 via Netscape, with SSL 3.0 dropping in 1996 as the web grew into shopping and payments. TLS succeeded it in 1999.

Where things stand now:

• SSL 2.0 and 3.0 are deprecated and highly insecure. Never use them.
• TLS 1.0 and 1.1 were officially deprecated in 2021 and dropped by major browsers.
• TLS 1.2 (from 2008) is still widely used and secure when configured with modern ciphers.
• TLS 1.3 (from 2018) is the current standard. It features fewer algorithms, a faster handshake, and forward secrecy by default.

People still say “SSL certificate” out of habit, but in practice, everything modern uses TLS.

Where TLS sits

Cleartext application-layer protocols send data entirely in the open.

TLS adds encryption just below the application protocol, wrapping its data before it hits the network card. On the OSI model, it lives right between the transport and application layers.

Upgrading protocols with TLS

• HTTP (Port 80) upgrades to HTTPS (Port 443)
• FTP (Port 21) upgrades to FTPS (Port 990)
• SMTP (Port 25) upgrades to SMTPS (Port 465)
• POP3 (Port 110) upgrades to POP3S (Port 995)
• IMAP (Port 143) upgrades to IMAPS (Port 993)

It’s not just web and mail. DNS can be wrapped too via DoT (DNS over TLS) on port 853, or DoH (DNS over HTTPS) on port 443. Both stop eavesdroppers from seeing which sites you look up.

Implicit TLS vs STARTTLS

• Implicit TLS uses a dedicated port that is fully encrypted from the very first byte (like 443 or 993).
• STARTTLS connects in cleartext on the normal port, then issues a “STARTTLS” command to upgrade the connection in place. This is common for email setup.

Both offer encryption, but implicit TLS is highly preferred.

A MITM attacker can easily strip the STARTTLS command during negotiation and force the session to stay in cleartext if the client isn’t configured to require it.

How HTTPS works

Plain HTTP takes two steps: open a TCP connection, then send requests. HTTPS inserts a step in between:

1. Establish a standard TCP connection.
2. Establish a TLS connection (the handshake).
3. Send the HTTP requests, which are now fully encrypted.

A simplified TLS 1.2 handshake goes like this:

ClientHello (client offers its TLS versions and cipher suites) → ServerHello (server picks the parameters and sends its certificate) → Key Exchange (both derive a shared secret) → Finished (both confirm and switch to encrypted communication):

ClientHello → ServerHello → Key Exchange → Finished

Certificates and trust

HTTPS leans on certificates signed by trusted Certificate Authorities (CAs). Your browser expects a valid certificate from a trusted CA, which proves you’re talking to the real server and blocks easy MITM attempts.

A certificate shows who it was issued to, who issued it, and its validity period. An expired certificate should never be trusted.

The modern ecosystem made this nearly universal thanks to automated platforms like ). This writeup is for educational purposes; only test systems you’re authorized to. Have fun!

This article was written by Pop123 as a walkthrough for the TryHackMe lab. I am as always open to further discussing the topic.

on Medium, where people are continuing the conversation by highlighting and responding to this story.