Network Traffic Analysis
A packet investigation using a deterministic DNS and HTTP training capture.
20 frames, 12 decoded observations, and two review signals.
The question
Can a compact packet analyzer identify useful review leads while preserving the packets behind each observation? The capture contains generated Ethernet/IPv4 traffic, not traffic recorded from a real network.
What I did
Generated the capture, decoded the supported DNS and HTTP records, and traced each candidate to source frames and timestamps. Compared unusual behavior with benign DNS and HTTP controls.
What I found
Four DNS NXDOMAIN replies and a POST to a reserved test destination produced two review signals. Neither establishes command-and-control or exfiltration. The analyst report records alternatives and missing corroboration under LAB-NET-001.
Investigating two different signals
The DNS failures and HTTP POST need separate explanations before they can be linked. I would inspect the queried names, response codes, request destination and timing, then ask whether endpoint or proxy evidence connects them. Temporal proximity alone does not establish a causal relationship.
A reasoned disposition
The generated capture supports two review signals, not a finding of command-and-control or exfiltration. The case report preserves decoded observations and their limits so another analyst can challenge the interpretation without losing the packet context.
Scope
Generated 20-frame PCAP with a deliberately bounded parser. Wireshark GUI validation remains pending. This is separate from the larger Kali/Wireshark/Snort lab listed on my résumé.
Read the full analyst report on GitHub ↗
