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 Let’s Encrypt, which pushed global HTTPS traffic past 95%.

Question: What is the three-letter acronym for the DNS protocol that uses TLS?

Answer: DoT (DNS over TLS)

Part 4 — SSH: Secure Remote Administration

SSH (Secure Shell) is the secure replacement for Telnet. It is the universal way to administer servers, network gear, and cloud infrastructure.

The “S” means you can confirm the server’s identity, your messages are encrypted for the intended recipient only, and any data tampering is instantly detectable.

It handles confidentiality and integrity seamlessly over port 22.

Authentication methods

• Password — The simplest method. The password rides the encrypted channel, but weak choices can still fall to brute-force attacks.
• Public key (recommended) — A private key stays on your machine, while the public key goes on the server. The server challenges you to prove you hold the private key without ever transmitting it.
• Certificate-based — An SSH CA signs user and host keys. This scales incredibly well because you don’t have to manually distribute public keys to every single server.
• MFA — Combines a traditional key or password with a one-time code for high-security environments.

Connecting

• To connect, you run:

ssh mark@MACHINE_IP

Enter the password or let your key authenticate, and you are on the remote terminal. Every single command you send runs over an encrypted channel.

Question: Connect as mark (password XBtc49AB) and find the kernel release with uname -r.

Commands: ssh mark@MACHINE_IP uname -r

Answer: 5.15.0–119-generic

Host key verification

On your very first connection, SSH shows the server’s key fingerprint and asks if you want to continue.

Ideally, you verify this fingerprint through an admin or config management before typing “yes”. It is then saved in your local known_hosts file.

If that key ever changes unexpectedly in the future, SSH throws a massive warning, a major indicator of a potential MITM attack or a reinstalled server.

Generating keys

• To create a new key pair, run:

ssh-keygen -t ed25519 -C "[email protected]"

The private key stays strictly on your machine and should be passphrase-protected. The public key (.pub) is safe to share. You can push it to a remote server easily using:

ssh-copy-id mark@MACHINE_IP

Useful options

+--------------------------------------------+------------------------------------------------------------+
| Command                                    | Purpose                                                    |
+--------------------------------------------+------------------------------------------------------------+
| ssh -p 2222 mark@MACHINE_IP                | Connect to a remote server running on a non-standard port   |
| ssh -i ~/.ssh/custom_key mark@MACHINE_IP   | Specify a specific private key file to use for login       |
| ssh -J bastion.example.com mark@internal   | Jump through a secure bastion host to reach an internal IP |
| ssh -L 8080:localhost:80 mark@MACHINE_IP   | Set up a local port forward to tunnel traffic through SSH  |
| ssh -D 9050 mark@MACHINE_IP                | Create a dynamic SOCKS proxy forward for traffic routing   |
| ssh mark@MACHINE_IP "cat /etc/passwd"      | Run a single, one-off command without opening a full shell |
+--------------------------------------------+------------------------------------------------------------+

Secure file transfer

• SFTP — Interactive, FTP-like file management running completely over SSH. This is the recommended choice today.
• SCP — Simple file copies over SSH. This is now deprecated by OpenSSH in favor of SFTP, though it still works on most systems.
• rsync over SSH — The best option for large or repeated transfers because it only copies the specific parts of files that changed.

To copy files via SCP:

scp mark@MACHINE_IP:/home/mark/archive.tar.gz ~/ (remote to local)

scp backup.tar.bz2 mark@MACHINE_IP:/home/mark/ (local to remote)

Quick clarifier:

SFTP runs over SSH (port 22).

FTPS is FTP-over-TLS (port 990).

They are entirely different protocols despite having similar names.

Question: Download book.txt from the remote system; what download size did scp display in KB?

Command: scp mark@MACHINE_IP:/home/mark/book.txt ~/

Answer: 415

Hardening SSH

To protect a server, you can modify its config file (/etc/ssh/sshd_config):

• Set PasswordAuthentication to “no” once public keys are established.
• Set PermitRootLogin to “no” to force users to log in with regular accounts first.
• Use AllowUsers or AllowGroups to create an explicit access whitelist.
• Change the default port to reduce automated log noise.
• Deploy fail2ban to automatically block IPs with repeated failed login attempts.

Part 5 — Password Attacks

Even with a network fully encrypted, authentication remains a primary target. Authentication is simply the act of proving your identity, like entering a password to access a service.

The three factors:

• Something you know — a password or PIN
• Something you have — a phone, hardware security key, or smart card
• Something you are — a fingerprint or facial scan

This section focuses entirely on attacking “something you know.”

Why weak passwords persist

Massive historic breaches show that old habits die hard.

The most common passwords found in modern breaches still include variations like 123456, password, qwerty, Password1, and seasonal choices like Summer2024.

Because people constantly reuse passwords across multiple sites, a single leak frequently gives attackers access to entirely unrelated corporate or personal accounts.

Types of attacks

• Guessing — using personal info like a target’s pet, birth year, or favorite sports team harvested from social media.
• Dictionary— automatically trying lists of real words and common variations.
• Brute force — systematically trying every possible characters combination. This is exhaustive, which is why password length matters so much.
• Credential stuffing — taking leaked username/password pairs from old breaches and automatically testing them against other web services.
• Password spraying — testing one or two incredibly common passwords against a massive list of user accounts to dodge lockout policies.
• Hybrid — combining dictionary words with systematic patterns, like capitalizing the first letter and adding a year to the end.

Wordlists

• The classic go-to wordlist is RockYou, located on the TryHackMe AttackBox at:

/usr/share/wordlists/rockyou.txt

Beyond that, security professionals use collections like SecLists, CrackStation lists, or custom-generated lists tailored specifically to the target’s language, region, or industry habits.

THC Hydra

Hydra is a fast network login cracker that throws wordlists at live services like FTP, POP3, IMAP, SSH, and HTTP.

The basic syntax looks like this:

hydra -l username -P wordlist.txt server service

• -l specifies a single username (-L for a text file of names)
• -P specifies a password wordlist (-p for a single password)
• server is the target IP or hostname
• service is the protocol you are targeting

Examples:

hydra -l mark -P /usr/share/wordlists/rockyou.txt MACHINE_IP ftp
hydra -l frank -P /usr/share/wordlists/rockyou.txt MACHINE_IP ssh
hydra -l lazie -P /usr/share/wordlists/rockyou.txt MACHINE_IP imap

Handy options include -s to target a non-default port, -vV for detailed verbosity, -t to adjust parallel attack threads, and -f to immediately stop execution when the first valid password is found.

Other tools

Alternative online crackers include Medusa and Ncrack.

For Windows and Active Directory environments, tools like NetExec excel at spraying credentials over SMB and LDAP.

If you manage to dump password hashes from a database, offline tools like Hashcat or John the Ripper are used because they can guess millions of combinations per second without worrying about network lag or lockouts.

Mitigation

Defending against password attacks requires a modern approach to identity management:

• Enforce length-first password policies based on NIST guidelines. Favor overall length over complex character rotation, and check new passwords against lists of known compromised credentials.
• Implement strict account lockout or throttling mechanisms to kill automated automated guessing, while remaining aware of password spraying patterns.
• Use CAPTCHAs to prevent basic bot execution on login forms.
• Deploy Multi-Factor Authentication (MFA) across all external endpoints.
• Transition toward passwordless ecosystems, utilizing passkeys (FIDO2/WebAuthn), hardware keys, or verified magic links.

Question: One email account is lazie; what password accesses the IMAP service?

Command: hydra -l lazie -P /usr/share/wordlists/rockyou.txt MACHINE_IP imap

Answer: butterfly

Key Takeaways

The fundamental rule of network security is simple:

Cleartext protocols are inherently insecure.

Anything sent without encryption can be effortlessly intercepted by sniffing or manipulated via a Man-in-the-Middle attack.

The security path forward is uniform across all services:

• Use HTTPS instead of HTTP
• Use SSH instead of Telnet
• Use SFTP or FTPS instead of basic FTP
• Use IMAPS, POP3S, and SMTPS instead of their legacy cleartext variants

Even when a connection is perfectly encrypted, weak passwords remain a glaring vulnerability.

Secure the protocol with robust encryption, then secure the account with long passwords, rate limiting, and multi-factor authentication.

Quick Port Reference Guide

+-------------------+------+----------------+
| Protocol          | Port | Security       |
+-------------------+------+----------------+
| FTP               | 21   | Cleartext      |
| FTPS              | 990  | TLS (implicit) |
| HTTP              | 80   | Cleartext      |
| HTTPS             | 443  | TLS (implicit) |
| IMAP              | 143  | Cleartext      |
| IMAPS             | 993  | TLS (implicit) |
| POP3              | 110  | Cleartext      |
| POP3S             | 995  | TLS (implicit) |
| SMTP              | 25   | Cleartext      |
| SMTP submission   | 587  | STARTTLS       |
| SMTPS             | 465  | TLS (implicit) |
| SSH / SFTP        | 22   | Encrypted (SSH)|
| Telnet            | 23   | Cleartext      |
+-------------------+------+----------------+

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