iterverse Packets Bridgerland Technical College

Analyzing Insecure Traffic with Wireshark

Capture a plaintext HTTP login with Wireshark and find the unencrypted username and password in the raw packet data.

Submit this worksheet
Opens your browser's print dialog. Choose "Save as PDF" to create your Canvas upload.
Only capture your own traffic

Only capture traffic on networks and hosts you have explicit permission to capture on. Do not capture traffic from other users or networks where you lack authorization. This lab uses a login app that runs on your own machine and talks only to 127.0.0.1 (your own computer talking to itself), so everything you capture here is your own traffic. Save and upload your capture securely, and don't post it anywhere public.

Why a local app instead of a live site

This lab used to point at a public demo site, testphp.vulnweb.com/login.php, which no longer exists. Instead, you'll run a tiny insecure login app on your own machine. It behaves the same way: a login form served over plain HTTP that submits your username and password with no encryption. The difference is that it's entirely local, so there's no question of permission or availability.

Where to run this

Run the login app from a BTECH Lab Laptop. Not a high school computer, and not a BTECH PC. If you're doing this lab from home instead, only run the file if you trust the copy you downloaded.

Set Up Wireshark

  1. Open Wireshark.
  2. Because the login app only talks to 127.0.0.1, its traffic never touches your Wi-Fi or Ethernet adapter. It travels over the loopback interface instead. In the interface list, select Loopback (Windows with Npcap: "Npcap Loopback Adapter" or "Adapter for loopback traffic capture"; macOS/Linux: lo0 or lo).
  3. Double-click the loopback interface to begin capturing.

Three panels make up the Wireshark window:

  1. Packet list (top): a table of every captured packet: No., Time, Source, Destination, Protocol, Length, Info. Click any row to inspect that packet.
  2. Packet details (middle): a hierarchical, decoded view of the selected packet (Ethernet → IP → TCP → HTTP...). Expand the layers to find headers and application fields, e.g. Hypertext Transfer Protocol → HTML Form URL Encoded.
  3. Packet bytes (bottom): the raw hex and ASCII of the selected packet. Good for confirming the exact payload text.

Run the Insecure Login App

Pick whichever matches your machine:

  1. Either way, it starts on http://127.0.0.1:8080/login.php. Open that in a browser.
  2. Notice there's no lock icon next to the address. This page is served over HTTP, so nothing submitted through it is encrypted.
  3. Log in with the demo credentials:
    • username: test
    • password: test
  4. Click Login to submit the form.
  5. Return to Wireshark and click the red square (Stop) to end the capture.

Filter Down to the Login Request

You captured everything on the loopback interface, which is more than you need. Narrow it down with display filters typed into the filter bar at the top of Wireshark.

  1. Show only HTTP traffic: 
    http
  2. Narrow further to just POST requests (the form submission): 
    http.request.method == "POST"
  3. You can combine that with the loopback address itself, since everything here is 127.0.0.1: 
    ip.addr == 127.0.0.1 && http.request.method == "POST"

Find the Plaintext Credentials

  1. In the packet list, find the packet whose Info column shows POST /login.php.
  2. Click it to select it.
  3. In the packet details pane, expand Hypertext Transfer Protocol.
  4. Expand HTML Form URL Encoded (or look for Line-based text data if the tree shows it that way). You should see username: test and password: test in plain text.
  5. In the packet bytes pane, confirm you can read username=test&password=test in the ASCII column, exactly as it was typed.
What this demonstrates

HTTP has no built-in encryption. The entire request, including form fields, travels as plain text inside the TCP payload. HTTPS wraps that same request in TLS before it ever reaches the network, which is why a login form on an HTTPS site doesn't hand its credentials to anyone capturing traffic in the middle. The lock icon in a browser's address bar is really just a visible signal that TLS is doing that work.

Self-Check

Answer from what you observed in your own capture. The checker only tells you right or wrong; it won't fill anything in for you.

QuestionYour answer
Which Wireshark pane shows the raw hex and ASCII of a selected packet?
What display filter shows only HTTP traffic?
What display filter (typed exactly, with straight quotes) narrows to only POST requests?
Which Wireshark interface did you capture on, since the app only talks to 127.0.0.1?
What plaintext username did you find in the POST request body?
What plaintext password did you find in the POST request body?
What protocol, used in place of HTTP, encrypts this traffic so credentials aren't readable in transit?
Need a hint?

Every answer here comes directly from something you saw on screen in either the login app's page or Wireshark's own panels. None of it needs to be calculated or looked up externally. If you're stuck on a filter syntax question, re-read the "Filter Down to the Login Request" section above and copy the filter exactly as written, including the quotation marks.

Save and Export Your Capture

  1. In Wireshark, go to File → Save As.
  2. Name the file with your last name and the lab, e.g. LASTNAME_WiresharkLab.pcapng.
  3. Upload this file to Canvas per the assignment instructions.
Grading requirement

To receive full credit, you must upload your captured .pcapng file with the unencrypted credentials visible, and thoughtfully answer the quiz questions in Canvas.

Reflection

In Canvas you'll be asked to answer the following. Keep them in mind as you work through the lab, but you don't need to answer them here:

Grading

To receive credit for this lab, submit the following in Canvas: