Study GNFA by pairing every analysis conclusion with a statement of evidence limitations: reconstruct sessions from pcaps knowing retransmissions and fragmentation distort content, profile TLS without assuming decryption, scope attacks with flow data while respecting sampling and asymmetry, and always corroborate a single-source finding with an independent log, flow, or capture before treating it as fact.
Reconstructing TCP sessions without over-reading capture artifacts
The Common Network Protocols domain requires interpreting TCP/IP behavior, HTTP, DNS, FTP, SMB, and SMTP from captures and logs, which means distinguishing protocol anomalies from normal mechanics like retransmission, fragmentation, and connection teardown.
Practice session reconstruction deliberately: follow a TCP stream, note how retransmissions duplicate segments, how out-of-order delivery reshuffles content, and how fragmentation splits objects across packets. Compare an HTTP object reassembled from a clean capture with one reassembled from a lossy capture, and observe how packet loss changes extracted files. This trains you to recognize capture artifacts as collection phenomena rather than attacker behavior, which is the judgment the syllabus calls evidence limitations.
Then profile application protocols against a baseline. Trace a normal DNS query-response pair, then compare it with a session carrying unusual record types, long labels, or high query volume. Do the same for SMTP commands and SMB operations. For each protocol, write one sentence describing normal state transitions and one sentence naming an observable anomaly. Compare your sentences across protocols: the analytical structure repeats even when the fields differ, which is exactly how the exam outcomes are framed.
Worked scenario: an analyst extracts an HTTP response body and finds it truncated mid-file. The mistaken decision is to declare evidence tampering or attacker interference. The better decision is to check for TCP retransmissions, zero-window events, and capture drop indicators first, then state that the capture itself is incomplete. This matters because the conclusion you deliver to stakeholders changes completely depending on whether the gap is in the network or in your sensor.
Encoding versus encryption: what TLS profiling proves and what it never will
This domain asks you to separate traffic encoding from cryptographic protection, profile TLS sessions through handshakes and certificates, and explain the prerequisites and limits of decryption, including forward secrecy.
Build the distinction by inspection. Base64 and hexadecimal encoding are reversible transformations anyone can undo; TLS protects content so that only key holders can read it. Take one HTTP capture and one HTTPS capture of the same request, and compare what remains visible after encoding versus encryption: headers, SNI, certificate details, and cipher negotiation stay observable in TLS even when payload content does not. Write a two-column list of what each transformation conceals, and check it against the coverage areas on certificates and cipher suites.
Decryption deserves the same precision. Trace a TLS handshake end to end, marking where keys are negotiated, and note that with forward secrecy the session keys cannot be recovered later from long-term secrets alone, so decryption requires keys captured or logged at session time or a controlled interception point. Compare a legitimate decryption workflow with indicators of a meddler-in-the-middle setup, such as certificate-chain anomalies. Your finding should always distinguish what is provable, what is inferred, and what is structurally unavailable.
Self-check: take any HTTPS capture and, without decrypting, state the negotiated TLS version, the certificate issuer and validity window, and the cipher suite. If you can fill in all four fields and name two things the capture can never reveal about the session's content, your mental model of this domain is in the right shape.
Scoping attacks with NetFlow while respecting sampling, NAT, and asymmetry
The NetFlow domain covers flow-record fields, exporters and collectors, sampling and retention, and using flow data to trace lateral movement and beaconing, all bounded by the limits flow data imposes on conclusions.
Learn flow records as evidence, not as a substitute for packets. Examine a flow record's fields, and reason through what each can and cannot show: flow data proves that communication occurred, its volume, timing, and endpoints, but not payload content. Practice tracing a lateral-movement path through sequential flow records, then deliberately study how asymmetric routing splits a conversation across two one-way records, and how NAT rewrites endpoints so the same host appears under different addresses at different collection points.
Worked scenario: flow records show regular connections every 60 seconds from an internal host to a single external IP, and the analyst concludes command-and-control beaconing and scopes the host. The mistaken decision is treating timing regularity alone as proof. The better decision is to check whether sampling influenced record timing, whether the interval survives NAT and exporter behavior, and whether DNS, proxy, or packet evidence corroborates the destination before naming it. The scope of your incident response follows directly, so an uncorroborated beaconing claim can trigger costly action on the wrong host.
Pair this domain with visualization practice: plot flow volume and timing for a suspected beaconing pattern and for ordinary periodic behavior such as time synchronization, then note which visual features actually differ. Expected observation: legitimate periodic traffic and beaconing can look similar in a single chart, which is the visual argument for corroboration.
Choosing collection points: matching evidence sources to investigative questions
Network Architecture asks where packet, flow, proxy, and log collection should sit in a network, how taps, SPAN ports, and sensors shape visibility, and how placement determines what any investigation can later prove.
Study architecture as an evidence-availability problem. For each collection technology, trace where data originates, what can be missed, and what the record ultimately looks like. Compare a network tap, which copies all traffic on a link, with a mirror port subject to oversubscription, and note how packet loss at either point becomes a permanent gap in the record. Add clock synchronization to the analysis: unsynchronized timestamps across sensors make later timeline correlation unreliable, so time discipline is part of defensible acquisition, not an afterthought.
Use the table below as a decision aid. For any investigative question you practice with, state which two sources you would consult and why the second source covers the first one's blind spot. Then reverse the exercise: pick a single sensor placement in a diagram, list the visibility gaps it creates, and identify which questions become unanswerable at that location. This converts deployment theory into the evidentiary reasoning the domain outcome statements emphasize.
Readiness check: sketch a small network with one tap, one flow exporter, one proxy, and one log aggregator. For each of the following questions, name the two best sources: did a file transfer occur, which hosts contacted a domain, what payload was delivered, and when did the connection start? If your answers consistently use two sources, your architecture reasoning matches the triangulation approach.
| Evidence source | Strongest for | Typical blind spots | Natural corroborating source |
|---|---|---|---|
| Full packet capture | Payload content, session reconstruction, protocol detail | Storage limits, capture-point gaps, loss and oversubscription | Flow records for scope, logs for timing |
| NetFlow records | Scoping, volume, timing patterns, lateral movement tracing | No content, sampling distortion, NAT and asymmetry ambiguity | Packet capture at a choke point, DNS or proxy logs |
| Proxy logs | Web request metadata, user and destination correlation, cached content | Only proxied protocols, encryption limits content visibility | Flow data for volume, endpoint logs for context |
| Event and syslog aggregation | Timelines, host-side context, source reliability assessment | Clock drift, format inconsistency, collector placement gaps | Network capture for independent timing |
| Wireless monitor-mode capture | Frame-level analysis, management traffic, roaming behavior | Channel coverage, signal-dependent loss, wired-side invisibility | Wired captures at the access point uplink |
Reverse engineering unknown protocols with controlled captures
Protocol Reverse Engineering covers recognizing framing, field boundaries, and state transitions in unfamiliar traffic, then validating hypotheses through comparative captures and controlled inputs rather than guesswork.
Adopt a hypothesis-driven method. Start with framing: locate message boundaries, then identify field boundaries by looking for length prefixes, delimiters, and fixed offsets. Infer field meaning by varying one input at a time between captures and observing which bytes change. A timestamp field changes with the clock, a counter increments, a length field tracks payload size. Document each field with its evidence, and record state transitions you observed, because a protocol's state machine is often more informative than any single message.
Worked exercise with a self-check rubric: take two captures of an unknown protocol where you changed only the message payload length between them. Grade your work against these observations: (1) you identified the boundary-delimiting mechanism and cited bytes supporting it; (2) you located the length field and matched its value to both captures' payload sizes; (3) you found at least one field whose value changed between captures and proposed a meaning; (4) you listed one hypothesis you could not confirm and named the capture you would need next. Four out of four means your inference process is disciplined; a missing item points to the specific skill to drill.
Keep corruption and implementation quirks in the analysis. Compare a protocol feature, such as an optional field, with an implementation quirk that sends a nonstandard value, and with corruption from a lossy capture. The distinguishing test is reproducibility: a feature appears consistently under controlled conditions, a quirk is vendor-specific but stable, and corruption varies with network conditions. Writing this distinction into your documentation is what makes reverse-engineered findings defensible.
Correlating proxy logs, event logs, and full-packet data across clock drift
Proxies and logging domains cover forward and reverse proxy evidence, secure log aggregation, normalization, and timeline construction, where reliability depends on collector placement, source corroboration, and clock discipline.
Treat each log as testimony with a perspective. A forward proxy records what clients requested through it; a reverse proxy records what outsiders requested of your servers; syslog carries whatever the generating process chose to emit. Practice normalizing records from these formats into a single timeline, preserving the original source of every entry. Then assess source reliability: a proxy entry about a connection is independent evidence from a host log about the same event, while two logs derived from the same sensor are not independent of each other.
Worked scenario: a proxy log places a suspicious request at 14:02 while flow records show the matching connection at 15:02, and the analyst concludes the records describe different events and drops the connection from the timeline. The better decision is to check clock synchronization and time-zone settings for each collection source first, correct for the drift, then re-evaluate whether the events align. This matters because an uncorrected hour of drift can silently remove true events from a timeline or insert false ones, and the whole investigative narrative inherits the error.
Extend the correlation with full-packet hunting using an open-source platform: start from a proxy log entry, pivot to the corresponding flow record for volume and duration, then retrieve the packet capture for content. Note at each pivot what the new source adds and what it contradicts. Expected observation: contradictions usually trace to collection mechanics, such as capture loss or address rewriting, rather than to malicious deception, and identifying that distinction is the analytical payoff of the exercise.
Wireless captures: monitor mode limits and 802.11 attack artifacts
The wireless domain covers 802.11 frame types, addressing, monitor-mode acquisition, authentication and encryption artifacts, and the capture limitations that shape what wireless evidence can establish.
Ground the domain in frame anatomy. Distinguish management, control, and data frames, and trace how addressing differs among them, since a single transmission can carry different addresses in different fields. Then study monitor-mode acquisition: unlike wired captures, a wireless sensor hears only the channels it monitors, so channel selection determines which conversations exist in your evidence at all. Compare a capture taken while hopping channels with one pinned to a single channel, and observe how the pinned capture preserves an individual conversation while the hopping capture preserves breadth.
Analyze wireless events as artifacts rather than conclusions. Examine deauthentication frames and note what their presence proves and what it does not: the frames are observable, but attributing intent or identity requires corroborating context. Study authentication and encryption exchanges to see what a capture reveals about association, roaming, and protection state, and compare roaming behavior across access points using sequence and timing. As with wired evidence, observation is the finding; interpretation requires a second source or a controlled comparison.
Adaptable preparation sequence: week one, work one capture per domain area and write a limitation statement for each; week two, complete the reverse-engineering exercise and the beaconing and clock-drift scenarios on your own captures; week three, run the architecture and readiness checks and drill the comparison table until you can reproduce it; final stretch, practice pivot chains from log to flow to packet and rebuild the wireless comparisons. Adjust pacing to your lab access and prior exposure rather than to any fixed schedule.
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.