See Security Labs

SEC401 – Network Forensics

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

  • Packet capture triage
  • tcpdump filtering
  • HTTP session analysis
  • DNS correlation
  • Attacker pattern recognition

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

tcpdumpdigPCAP analysisCLI

Steps taken

1. Initial 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 -#

Flags

  • -n: no DNS/port lookup
  • -r: read from file
  • -c 20: stop after 20 packets
  • -#: print packet number

2. Filtering 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)'

Flags

  • Filter: tcp + host/port pair

3. Read session.pcap

Read session.pcap to view the filtered wp-login session packets.

tcpdump -n -r session.pcap -#

4. HTTP 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

Flags

  • -X: hex and ASCII payload; -v: verbose; -c 4: stop after 4 packets

5. Correlate with dig

Used dig to query NS records for alphainc.ca, correlating with the captured DNS traffic.

dig alphainc.ca NS

Flags

  • alphainc.ca: domain; NS: name server

6. Live 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

Flags

  • -i: interface; -w: write to file; Filter: udp port 53

7. DNS payload extraction

Dumped DNS packet contents in hex and ASCII, revealing domain names in the payload.

tcpdump -n -r created_capture.pcap -X

Key findings

  • HTTP GET /.env from 135.125.217.54 to 10.130.8.94; server returned 404
  • HTTP POST /wp-login.php with Hydra user-agent
  • DNS NS lookup mapped alphainc.ca to AWS nameservers

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)