Lab Environment
This lab builds directly on Lab Log 001 where network reconnaissance was performed using Nmap. Here we capture the raw network packets generated by that same scan — shifting from the attacker's view (what ports are open) to the defender's view (what does that traffic actually look like at the packet level).
Objective
Lab Log 001 answered the question: what can an attacker see from outside? This lab answers the complementary question: what does that attack traffic look like from inside?
Network traffic analysis is a foundational blue team skill. Intrusion Detection Systems (IDS), Security Information and Event Management platforms (SIEM), and network forensics all depend on the analyst's ability to read packet captures and identify what they represent. Before you can detect an attack in traffic, you need to know what an attack looks like in traffic.
This exercise captures a live Nmap port scan at the packet level — reading the raw TCP handshake attempts that an Nmap fast-mode scan generates — and interprets what each packet field reveals about the scanner's behavior and intent.
Methodology
tcpdump was run in the background on interface eth0 with a 20-packet capture limit. Simultaneously, Nmap was run in fast mode against the Docker host. The combination produced 206 packets on the wire — tcpdump captured the first 20 before stopping, providing a representative sample of the scan traffic.
┌──(root㉿kali)-[/] └─# tcpdump -i eth0 -n -c 20 -v & sleep 2 && nmap -Pn -F 172.17.0.1 # tcpdump flags: # -i eth0 : capture on Docker bridge interface # -n : no DNS resolution (show raw IPs) # -c 20 : stop after 20 packets # -v : verbose output (show TTL, flags, checksums) # # nmap flags: # -Pn : skip host discovery ping (treat host as up) # -F : fast mode (top 100 ports only)
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes 23:43:05.156625 IP (tos 0x0, ttl 52, id 25479, offset 0, flags [none], proto TCP (6), length 44) 172.17.0.2.47648 > 172.17.0.1.143: Flags [S], cksum 0x62a7 (correct), seq 3780590930, win 1024, options [mss 1460], length 0 23:43:05.157015 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 172.17.0.1.143 > 172.17.0.2.47648: Flags [R.], cksum 0x7e50 (correct), seq 0, ack 3780590931, win 0, length 0 23:43:05.157076 IP (tos 0x0, ttl 47, id 32616, offset 0, flags [none], proto TCP (6), length 44) 172.17.0.2.47648 > 172.17.0.1.23: Flags [S], cksum 0x631f (correct), seq 3780590930, win 1024, options [mss 1460], length 0 23:43:05.157177 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 172.17.0.1.23 > 172.17.0.2.47648: Flags [R.], cksum 0x7ec8 (correct), seq 0, ack 3780590931, win 0, length 0 23:43:05.157209 IP (tos 0x0, ttl 59, id 12029, offset 0, flags [none], proto TCP (6), length 44) 172.17.0.2.47648 > 172.17.0.1.135: Flags [S], cksum 0x62af (correct), seq 3780590930, win 1024, options [mss 1460], length 0 23:43:05.157292 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 172.17.0.1.135 > 172.17.0.2.47648: Flags [R.], cksum 0x7e58 (correct), seq 0, ack 3780590931, win 0, length 0 23:43:05.157306 IP (tos 0x0, ttl 53, id 44193, offset 0, flags [none], proto TCP (6), length 44) 172.17.0.2.47648 > 172.17.0.1.22: Flags [S], cksum 0x6320 (correct), seq 3780590930, win 1024, options [mss 1460], length 0 23:43:05.157371 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 172.17.0.1.22 > 172.17.0.2.47648: Flags [R.], cksum 0x7ec9 (correct), seq 0, ack 3780590931, win 0, length 0 23:43:05.157384 IP (tos 0x0, ttl 54, id 31202, offset 0, flags [none], proto TCP (6), length 44) 172.17.0.2.47648 > 172.17.0.1.995: Flags [S], cksum 0x5f53 (correct), seq 3780590930, win 1024, options [mss 1460], length 0 23:43:05.157450 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 172.17.0.1.995 > 172.17.0.2.47648: Flags [R.], cksum 0x7afc (correct), seq 0, ack 3780590931, win 0, length 0 23:43:05.157477 IP (tos 0x0, ttl 37, id 55897, offset 0, flags [none], proto TCP (6), length 44) 172.17.0.2.47648 > 172.17.0.1.3306: Flags [S], cksum 0x564c (correct), seq 3780590930, win 1024, options [mss 1460], length 0 23:43:05.157515 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 172.17.0.1.3306 > 172.17.0.2.47648: Flags [R.], cksum 0x71f5 (correct), seq 0, ack 3780590931, win 0, length 0 23:43:05.157542 IP (tos 0x0, ttl 43, id 35746, offset 0, flags [none], proto TCP (6), length 44) 172.17.0.2.47648 > 172.17.0.1.1723: Flags [S], cksum 0x5c7b (correct), seq 3780590930, win 1024, options [mss 1460], length 0 23:43:05.157626 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 172.17.0.1.1723 > 172.17.0.2.47648: Flags [R.], cksum 0x7824 (correct), seq 0, ack 3780590931, win 0, length 0 23:43:05.157648 IP (tos 0x0, ttl 37, id 42359, offset 0, flags [none], proto TCP (6), length 44) 172.17.0.2.47648 > 172.17.0.1.443: Flags [S], cksum 0x617b (correct), seq 3780590930, win 1024, options [mss 1460], length 0 20 packets captured 206 packets received by filter 0 packets dropped by kernel
Reading the Packets — Anatomy of a TCP SYN
Every line in a tcpdump capture is a packet. Each packet contains structured fields that tell a precise story about what is happening on the network. Understanding these fields is how analysts identify normal traffic, detect anomalies, and attribute behavior to specific tools or attackers.
Below is a detailed breakdown of a single SYN packet from the capture — the probe Nmap sent to port 22 (SSH):
23:43:05.157306 IP (tos 0x0, ttl 53, id 44193, offset 0, flags [none], proto TCP (6), length 44)
172.17.0.2.47648 > 172.17.0.1.22: Flags [S], cksum 0x6320 (correct), seq 3780590930, win 1024, options [mss 1460], length 0Analyst insight: Three fields alone — window size 1024, randomized TTL per packet, and identical sequence numbers across probes — are sufficient to identify this traffic as an Nmap SYN scan with high confidence, even without seeing the source IP. Modern IDS signatures detect Nmap by exactly these behavioral fingerprints.
Findings
Finding 1 — Nmap Behavioral Fingerprint Visible in Traffic
The capture reveals multiple Nmap-specific behavioral signatures that would trigger alerts in a properly configured IDS. The consistent source port (47648) used across all probes, the non-standard window size of 1024, and the randomized but low TTL values are all characteristic of Nmap's default SYN scan behavior.
In a real network environment, a SIEM rule as simple as "more than 10 SYN packets from the same source to different destination ports within 1 second" would generate an alert. The captured traffic shows 10 port probes in 0.001 seconds (1 millisecond) — a rate that no legitimate application produces.
Finding 2 — All Ports Returned RST — Confirmed Closed
Every SYN in the capture received a RST+ACK response. This is packet-level confirmation of what the Nmap scan reported: these ports are closed. The RST response means the TCP stack is active and responding — the host is up — but no application is listening on these ports.
| Port Probed | Service | SYN Sent | Response | Status |
|---|---|---|---|---|
| 143 | IMAP (email) | Flags [S] | Flags [R.] | Closed |
| 23 | Telnet | Flags [S] | Flags [R.] | Closed |
| 135 | RPC (Windows) | Flags [S] | Flags [R.] | Closed |
| 22 | SSH | Flags [S] | Flags [R.] | Closed |
| 995 | POP3S (email) | Flags [S] | Flags [R.] | Closed |
| 3306 | MySQL | Flags [S] | Flags [R.] | Closed |
| 1723 | PPTP VPN | Flags [S] | Flags [R.] | Closed |
| 443 | HTTPS | Flags [S] | — (capture ended) | Unknown |
Finding 3 — ICMP Blocked — Stealth Posture
Before the Nmap scan, a ping test was run from the Mac host to the Kali container (172.17.0.2). All 10 packets resulted in 100% packet loss — the container did not respond to ICMP echo requests. This is the default Docker container behavior: ICMP is not forwarded through the bridge without explicit configuration.
From a security perspective, this is a positive finding. A host that does not respond to ping is harder to discover passively. Attackers who rely on ping sweeps to map live hosts would not detect this container. This is sometimes called a stealth posture — the host processes traffic but does not advertise its presence.
206 packets observed vs 20 captured: tcpdump reported 206 packets received by the filter but only 20 were captured before the limit was hit. The remaining 186 packets represent the rest of the Nmap fast-mode scan across all 100 ports. The 20 captured are a representative sample — the pattern (SYN → RST) was consistent throughout.
Security Analysis
What This Traffic Looks Like to a Defender
A network analyst watching this traffic in real time would see an unmistakable pattern: a single source IP sending SYN packets to sequential destination ports at machine speed with no completed handshakes. This is the textbook signature of a port scan. No legitimate application behavior produces this pattern.
In a defense contractor environment with a properly configured SIEM, this traffic would generate an alert within seconds. The alert would include the source IP, the number of ports probed, the time window, and a confidence score indicating automated scanning behavior. The SOC analyst would then investigate whether the source is internal (authorized scanner) or external (threat actor).
The Defender's Advantage — Traffic Never Lies
Logs can be deleted. Malware can be hidden. But network traffic captured at the packet level cannot be retroactively altered. This is why network forensics is a critical discipline in incident response — even after a Volt Typhoon-style campaign deletes its logs, the network capture may still contain evidence of lateral movement, command-and-control communication, and data exfiltration.
The Stryker wiper attack destroyed 200,000 devices — but the network traffic generated during that destruction was still visible to anyone capturing at the perimeter. Packet capture is often the last line of forensic evidence when everything else has been destroyed.
CMMC Relevance — Continuous Monitoring
CMMC Level 2 requires organizations to monitor their networks for anomalous activity. The practical implementation of that requirement is exactly what was demonstrated here: capture traffic, analyze it, identify deviations from normal behavior. A defense contractor that cannot read a packet capture cannot demonstrate compliance with the monitoring controls — and cannot detect an intrusion when it happens.
NIST SP 800-171 Control Mapping
Lessons Learned
The Attacker Leaves Evidence
The most important takeaway from this lab is that scanning activity is visible. Every SYN packet Nmap sent was captured. The tool, the technique, the target ports, the timing — all of it is preserved in the packet capture. An attacker who scans a network with tcpdump running anywhere on that network has already left evidence of their reconnaissance.
This changes how defenders think about monitoring. You don't need to catch an attacker in the act of exploitation — reconnaissance alone is detectable, and detecting reconnaissance early is the highest-value intervention in the kill chain.
Packet Analysis Is a Skill, Not a Tool
tcpdump produced 20 lines of output. Reading those 20 lines and extracting meaningful security conclusions — Nmap fingerprint, scan rate, port response pattern, stealth posture implications — required understanding TCP fundamentals, Nmap behavior, and network forensics methodology. The tool is simple. The analysis requires knowledge.
This is why CMMC consulting firms value analysts who can do both: run the tools and interpret what the output means for a client's security posture.
Lab Limitations
This capture was limited to 20 packets on an isolated Docker bridge network. Real-world traffic analysis involves millions of packets per hour across complex multi-segment networks. The fundamentals demonstrated here — flag interpretation, timing analysis, behavioral fingerprinting — apply at any scale, but production environments use dedicated capture infrastructure (full packet capture appliances, NetFlow, PCAP at network taps) rather than tcpdump on a single host.
Next Lab
Lab Log 003 will cover password cracking fundamentals using hashcat inside the Kali container — generating password hashes, running dictionary attacks with the rockyou wordlist, and understanding why password storage and complexity requirements are a core CMMC compliance requirement. This directly supports NIST SP 800-171 Control 3.5.7 (password complexity) and maps to the credential abuse vector seen in the Stryker and Volt Typhoon cases.
Connection to portfolio research: The Stryker wiper attack began with a single compromised administrative credential. Lab 003 will demonstrate how quickly weak credentials can be compromised — and why the CMMC requirement for strong authentication is not bureaucratic overhead but operational necessity.