Labs / cisco security

Packet Analysis with Wireshark: Spotting Plaintext Risk

beginner Wireshark on any PC, plus a lab network (EVE-NG, GNS3, or your home network) wiresharkpacket-analysisnetwork-security

Scenario

A colleague insists “our internal FTP server is fine, it’s only used inside the office.” Your goal is to prove — with an actual packet capture — why plaintext protocols are a real security risk even on a “trusted” internal network, and to practise the filtering skills needed to find that evidence quickly.

What you need

  • Wireshark installed on a PC connected to your lab network (or a SPAN/mirror port, if using a switch).
  • A test FTP server and client (any lab VM or container is fine) on the same network segment as your capture point.
  • One test account with a throwaway password — never use a real password for this lab.

Step 1 — Start the capture

Open Wireshark, select the interface facing your lab network, and start capturing before generating any traffic. This mirrors real investigations, where you often can’t know in advance exactly which packet you’ll need.

Step 2 — Generate the traffic to analyse

From the client, log into the FTP server with your throwaway test credentials and transfer one small file.

ftp> open <ftp-server-ip>
ftp> USER testuser
ftp> PASS testpass123
ftp> get sample.txt

Step 3 — Filter down to the relevant traffic

In Wireshark’s filter bar:

ftp

This isolates FTP control-channel packets from everything else on the capture.

Step 4 — Find the plaintext credentials

Right-click the PASS packet and choose Follow → TCP Stream. You will see the username and password in plain, readable text — nothing about “internal only” prevented this from being fully visible to anyone who could capture traffic on that segment.

Step 5 — Compare against encrypted traffic

Generate an SSH or HTTPS session instead, then filter and follow that stream the same way:

tcp.port == 22

Notice the payload is unreadable ciphertext — this is the practical, visible difference that VPN Fundamentals and IPsec Fundamentals describe in theory: encryption protects confidentiality even if someone captures the traffic.

Step 6 — Document the finding like a real report

Note down: source/destination IP, port, protocol, and the exact evidence (screenshot of the follow-stream output with the visible credentials). This is the format used in Security Logging and Monitoring when escalating a finding.

Break it (in the good sense)

Repeat the capture using SFTP instead of FTP, and confirm you can no longer read the credentials in the stream — this is the concrete, hands-on argument to bring back to your colleague instead of “plaintext is bad” as an abstract statement.

Reference

  • AddySec original content — written for the Network Security track, connecting directly to VPN Fundamentals and Security Logging and Monitoring.