SEC401 - Network Security and Cloud Essentials
Lab 1.1 – tcpdump Traffic Analysis
Solo, Lab
Focus: Network Forensics
Level: SEC401
Date: Feb 2026
Artifacts: Sanitized screenshots + my own DNS capture PCAP
TL;DR
- •.env probing attempt observed
- •WordPress login brute force detected
- •Demonstrates credential exposure risk over plaintext HTTP
Skills demonstrated
Note: Course-provided PCAPs and lab instructions are not shared. Only my own captures and sanitized notes are published.
Why this matters
In a real attack, unencrypted HTTP exposes credentials to anyone on the network. This is what defenders see when investigating a breach, and why HTTPS and secure credential handling are non-negotiable in production.
Context
This lab demonstrates how to analyze network traffic using tcpdump and extract meaningful patterns from a PCAP file.
Tools used
Steps taken
1Initial packet overview
Read the first 20 packets from investigate.pcap to get a high-level view of traffic types (DNS, TCP, HTTP).
$ tcpdump -n -r investigate.pcap -c 20 -#-nno DNS/port lookup-rread from file-c 20stop after 20 packets-#print packet number2Filtering session 1: GET /.env
Filtered TCP traffic between 135.125.217.54 and 10.130.8.94 (ports 44366 and 80). Revealed an HTTP GET request for /.env; server responded 404 Not Found.
$ tcpdump -n -r investigate.pcap 'tcp and (host 135.125.217.54 and host 10.130.8.94) and (port 44366 and port 80)'Filtertcp + host/port pair3Read session.pcap
Read session.pcap to view the filtered wp-login session packets.
$ tcpdump -n -r session.pcap -#4HTTP payload extraction: visible login parameters
Dumped packet contents. Revealed cleartext HTTP POST to /wp-login.php with Hydra user-agent and visible login parameters (redacted).
$ tcpdump -n -r session.pcap -X -v -c 4-Xhex and ASCII payload; -v: verbose; -c 4: stop after 4 packets5Correlate with dig
Used dig to query NS records for alphainc.ca, correlating with the captured DNS traffic.
$ dig alphainc.ca NSalphainc.cadomain; NS: name server6Live DNS capture and read
Captured live UDP traffic on port 53 (DNS) with sudo tcpdump, wrote to created_capture.pcap, then read the capture to view DNS queries and responses.
$ sudo tcpdump -n -i eth0 -w created_capture.pcap 'udp port 53'
$ tcpdump -n -r created_capture.pcap-iinterface; -w: write to file; Filter: udp port 537DNS payload extraction
Dumped DNS packet contents in hex and ASCII, revealing domain names in the payload.
$ tcpdump -n -r created_capture.pcap -XKey findings
Outcome / Lessons learned
This lab reinforced how quickly attacker behavior stands out in raw packet captures once you know what to filter for. It also highlighted how dangerous plaintext HTTP is in real environments, since authentication data can be recovered directly from packet payloads.
If this were production: I'd confirm whether the source was internal or external, check web server logs for repeated attempts, enforce HTTPS, and apply rate limiting or WAF protections around authentication endpoints.
Security controls relevant
- Enforce HTTPS (HSTS)
- Rate-limit wp-login
- WAF rules for /.env probing
- Centralized logging + alerting (SIEM)
What I took away from this
The /.env probe is one of the most common automated scans on the internet, but most teams only monitor for it at the WAF layer. The real question isn't whether you block it, it's whether you alert on it. A 404 response means the file wasn't there, but the attacker now knows the server is live, running a web framework, and worth further probing. That single failed request often precedes the brute-force attempt that follows minutes later.
What stood out in this lab was how readable cleartext HTTP traffic is. The WordPress credentials were sitting in the packet payload, fully visible, with no decryption required. This is obvious in theory, but seeing it in a real PCAP changes how you think about HTTPS enforcement. It's not just a compliance checkbox. Any network segment without TLS is functionally broadcasting credentials to anyone with tcpdump access.
If I were building detection rules from this capture, I'd focus on two signals: any outbound DNS query to a domain immediately followed by HTTP POST to a login endpoint from a different source IP, and any user-agent string containing known tool signatures like Hydra. These are low-noise, high-confidence indicators that most SIEMs can correlate in real time.