Academy / Advanced Network Security & Traffic Analysis
MODULE 01 · Advanced
Advanced Network Security & Traffic Analysis
Read the wire like an analyst: from raw packets to high-fidelity detections.
Module overview
Network telemetry is ground truth. Endpoints lie, logs get cleared, but packets on the wire (and the flow records derived from them) are hard for an adversary to fully erase. This module builds the skill of turning capture into conclusions: structured packet analysis with Wireshark/tcpdump, flow and protocol logging with Zeek, and signature/anomaly detection with Suricata. You will work entirely inside an isolated lab range so every technique is legal and repeatable.
Lesson 1
Packet & Flow Analysis at Scale
Deep explanation
Full packet capture (PCAP) answers "what exactly happened," but it does not scale to weeks of an enterprise. The professional pattern is layered: keep cheap, queryable metadata (Zeek conn.log, NetFlow/IPFIX) for the long window, and retain full PCAP only for short rolling buffers or around alerts. An analyst pivots from a flow record ("this host talked to this IP for 4 hours on 443 with a strange byte ratio") into the matching PCAP to confirm.
Protocol literacy is the multiplier. TLS hides payloads, but the handshake still exposes SNI, certificate details, and JA3/JA3S fingerprints that cluster client and server stacks. DNS is the network's intent log. HTTP/1.1 in the clear still appears on internal segments and IoT. Knowing which fields survive encryption tells you where detection is still possible.
Examples
A beaconing implant shows up in conn.log as many short, regular connections to one destination with low jitter — visible even over TLS.
JA3 hash a0e9f5d64349fb13191bc781f81f42e1 recurring from many internal hosts to one external IP is a strong tooling fingerprint to pivot on.
Commands & tools
# Capture only what you need (ring buffer, 100MB x10 files) on the lab span port
sudo tcpdump -i eth0 -s 0 -w /cap/lab-%Y%m%d-%H%M.pcap -G 300 -W 10 'not port 22'
# Generate protocol logs from a pcap with Zeek (metadata, not payloads)
zeek -r /cap/lab.pcap
cat conn.log | zeek-cut id.orig_h id.resp_h id.resp_p proto duration orig_bytes resp_bytes
# Wireshark display filters analysts actually use
http.request and ip.dst == 10.10.10.5
tls.handshake.extensions_server_name contains "login"
dns.qry.name matches "[a-z0-9]{20,}\." # long random labels = possible DNS tunneling
In your isolated range, bring up DVWA (intentionally vulnerable) and a Kali analyst box on the same segment.
Start a capture on the analyst box: sudo tcpdump -i eth0 -w /cap/lab.pcap
From a victim VM, log in to DVWA over HTTP (cleartext) and browse a few pages.
Stop the capture. Open lab.pcap in Wireshark; apply filter http.request; right-click a POST to the login page and "Follow > HTTP Stream".
Run zeek -r /cap/lab.pcap and inspect conn.log and http.log with zeek-cut.
Expected output: Wireshark's HTTP stream shows the cleartext username/password POST body. Zeek's http.log lists the request method, host, URI and user-agent; conn.log shows the TCP session with byte counts.
What to observe: Cleartext credentials are trivially recovered on unencrypted internal traffic — the lesson is why TLS everywhere and network segmentation matter, and how an analyst would spot credential exposure.
How attackers exploit · how defenders respond
Exploit: On a shared segment an adversary positions a sniffer (span, tap, or via on-path techniques) and harvests anything unencrypted: HTTP logins, SNMP community strings, LDAP simple binds, internal dashboards.
Detect & respond: Alert on plaintext auth on internal VLANs (Suricata rules for HTTP basic auth, cleartext POST to /login). Hunt conn.log for long-lived or highly periodic sessions (beaconing) and DNS for high-entropy/long labels (tunneling). Baseline JA3 fingerprints and alert on new external ones.
Red teamRecon the segment, identify cleartext services, capture and extract credentials, fingerprint tooling to blend in with common JA3 hashes.
Blue teamDeploy Zeek+Suricata on a tap, enforce TLS and 802.1X, segment with VLANs/microsegmentation, and build beaconing + DNS-tunneling detections as code.
Real-world scenario
A retailer's flat network let a compromised HVAC vendor box sniff POS traffic. Flow analysis later showed steady low-jitter beacons to a single host — the exact pattern conn.log baselining would have flagged on day one.
Lesson 2
Detecting On-Path (MITM), ARP & DNS Abuse
Deep explanation
Layer-2 trust is implicit and therefore abusable. ARP has no authentication, so a host can claim to be the gateway (ARP poisoning) and place itself on-path. DNS is similarly trusting; a poisoned or spoofed response reroutes a victim. The defensive craft is recognizing the artifacts these techniques leave: duplicate/ flapping MAC-to-IP bindings, gratuitous ARP storms, and DNS answers that disagree with authoritative data.
Modern switched networks fight back with Dynamic ARP Inspection (DAI), DHCP snooping, and 802.1X. Detection complements prevention: arpwatch and Suricata can fire the moment a binding changes, turning a stealthy on-path attempt into a loud alert.
Examples
The gateway 10.10.10.1 suddenly resolves to a workstation MAC instead of the router MAC — a classic ARP-poisoning artifact.
A victim resolves internal-portal.lab to an attacker IP while the authoritative server returns a different address — DNS spoofing.
Commands & tools
# Watch for changing ARP bindings (detection, runs on a monitor host)
sudo arpwatch -i eth0 # logs "changed ethernet address" / "flip flop"
# Inspect a pcap for duplicate-address / poisoning artifacts in Wireshark
arp.duplicate-address-detected
arp.opcode == 2 # gratuitous/unsolicited ARP replies
# Suricata example: alert on excessive ARP replies (anomaly-style)
# (rule lives in your local.rules; tune thresholds to your lab)
alert arp any any -> any any (msg:"Possible ARP spoofing - reply storm"; \
threshold:type both, track by_src, count 20, seconds 10; sid:1000001; rev:1;)
# Switch-side prevention (Cisco) — the real fix
ip dhcp snooping
ip arp inspection vlan 10
Diagram
Normal: victim ---> [ gateway ] ---> internet
On-path: victim ---> [ attacker ] ---> [ gateway ] ---> internet
^___ attacker answers ARP "I am the gateway"
Detection: arpwatch/Suricata see IP 10.10.10.1 bind to TWO MACs -> ALERT
Hands-on lab
In the isolated range only, capture normal traffic and save baseline ARP table: ip neigh > baseline.txt
Replay or open a provided poisoning pcap in Wireshark and apply arp.opcode == 2 and arp.duplicate-address-detected.
Run arpwatch against the pcap/interface and read its log for "changed ethernet address".
Write a one-line detection note: which field changed, and what a SOC alert for it should contain.
Apply the fix conceptually: enable DAI + DHCP snooping on the lab switch (or document the config).
Expected output: Wireshark highlights duplicate address detection; arpwatch logs a binding change for the gateway IP. With DAI enabled, the poisoning attempt is dropped at the switch and logged.
What to observe: On-path attacks are loud at layer 2 if you are listening. Prevention (DAI/802.1X) plus detection (arpwatch/Suricata) converts a stealthy technique into a high-confidence alert.
How attackers exploit · how defenders respond
Exploit: Poison ARP to become the gateway, then downgrade/forward traffic, optionally spoof DNS to redirect a victim to a look-alike service. (Taught conceptually; not performed against any network you don't own.)
Detect & respond: Continuous ARP binding monitoring, DAI logs, and DNS response validation (compare client answers to authoritative). Alert on gateway MAC changes and on internal hosts answering DNS that shouldn't.
Red teamEstablish on-path position, harvest/relay credentials, selectively spoof DNS for high-value hosts.
Blue teamDHCP snooping + DAI + 802.1X for prevention; arpwatch/Suricata + DNS answer validation for detection; alert routing into the SIEM.
Real-world scenario
During an incident, duplicate-MAC alerts for the gateway pinned the exact minute an attacker went on-path, letting responders scope which sessions were exposed.
End-of-module assessment
Tap an answer to check it.
1. Which data source best scales to weeks of retention for hunting?
Flow/metadata is compact and queryable for long windows; full PCAP is kept short-term or around alerts.
2. What still leaks from a TLS session for detection?
Handshake metadata (SNI/cert/JA3) survives encryption and is highly useful for clustering and detection.
3. The strongest switch-side prevention for ARP poisoning is:
DAI validates ARP against DHCP-snooping bindings and drops spoofed replies at the switch.
Key takeaways
Layer telemetry: cheap metadata for the long window, full PCAP short-term and around alerts.
Encryption hides payloads, not patterns — beaconing, SNI, JA3, and DNS still enable detection.
Layer-2 attacks are loud if you monitor bindings; pair DAI/802.1X prevention with arpwatch/Suricata detection.
