Four Attacks, One Tool: Reading the Story Packets Tell
This lab worked through four completely different network attack patterns, credential theft over plaintext HTTP, a DNS-based remote shell, an FTP brute-force attempt, and a SYN flooding denial-of-service, all using the same single tool, Wireshark, applied with different filters and a different question in mind each time.
A packet capture is just a recording, raw traffic, frozen in time, with no built-in explanation of what any of it means. This lab worked through four completely different network attack patterns, credential theft over plaintext HTTP, a DNS-based remote shell, an FTP brute-force attempt, and a SYN flooding denial-of-service, all using the same single tool, Wireshark, applied with different filters and a different question in mind each time. What stood out wasn't the tool itself, it was how much the actual investigative skill came down to knowing exactly which filter to apply and which specific packet sequence to look for, depending on what kind of attack you're hunting.
Finding Plaintext Credentials in HTTP Traffic
The first capture file,
HTTP Traffic.pcapng , held traffic to and from a WordPress site. I applied a simple http filter to isolate web traffic from everything else in the capture, and the results immediately showed something worth flagging: this traffic was unencrypted, plain HTTP rather than HTTPS, meaning anything transmitted, including login credentials, would be visible in plain text to anyone capturing the traffic.The lab's specific technique for finding credentials was precise: filter further with
http.request.method == POST . That's not an arbitrary choice. Login forms and other data-submission actions on the web are typically transmitted via HTTP POST requests, as opposed to GET requests, which are generally used for retrieving content rather than submitting it. Filtering specifically for POST traffic cuts straight to the handful of packets most likely to contain submitted form data, out of what could otherwise be an overwhelming volume of unrelated HTTP traffic.Expanding the HTML Form URL Encoded node within one of those filtered packets revealed exactly what the filter was built to find: a user's login credentials, submitted as plain, readable text. That's the concrete, demonstrable risk of unencrypted HTTP for anything involving authentication: anyone positioned to capture that traffic, a compromised network device, a malicious actor on the same network segment, doesn't need to crack or guess anything. The credentials are simply sitting there, readable, in the traffic itself.
Tracing a DNS-Based Remote Shell
The second file,
DNS Remote Shell.pcap , demonstrated something more subtle: an attacker using DNS's own port, port 53, not for actual domain name resolution, but as a channel to establish a remote shell connection, exactly the kind of technique that can slip past security controls built around the assumption that DNS traffic is routine and uninteresting.I filtered with
tcp.port == 53 to isolate everything flowing to or from that port, then traced the classic TCP three-way handshake across three specific packets: a [SYN] request from one IP's ephemeral port toward port 53 on another IP (identifying that second address as the one acting as a DNS server, or in this case, the compromised target), a [SYN, ACK] response acknowledging it, and a final [ACK] completing the handshake and establishing the connection. That sequence alone, SYN, SYN-ACK, ACK, confirmed a genuine, established TCP connection had formed between the two addresses, not just an isolated, failed, or probing packet.The real payoff came from using Wireshark's Follow TCP Stream feature on that connection, which reconstructs and displays an entire conversation's data in sequence, rather than requiring an investigator to manually piece together dozens of individual packets. That reconstructed stream revealed the attacker had performed a directory listing on the victim machine, direct evidence that the established connection wasn't incidental network noise, but an active remote shell being used to browse the compromised system's file structure.
Identifying an FTP Brute-Force in Progress
The third file,
FTP Brute-Force.pcapng , demonstrated a more straightforward but equally telling pattern: a large volume of repeated login failures, followed by eventual success.FTP's response codes made this filterable with precision. I applied
ftp.response.code == 530 , the specific FTP response code for an authentication failure, and found a large number of failed login attempts from a single source IP directed at a single target, exactly the signature of an automated credential-guessing attack rather than a person occasionally mistyping a password.Switching the filter to
ftp.response.code == 230 , the code for a successful login, revealed that the same source IP had, after all those failures, eventually succeeded, meaning the brute-force attempt had actually worked and the attacker had obtained valid credentials to the target system. Seeing both filtered views side by side tells a complete, unambiguous story: sustained automated guessing, followed by a confirmed compromise.Recognizing a SYN Flood by Its Broken Handshake
The fourth file,
SYN Flooding.pcapng , required understanding the normal TCP handshake specifically in order to recognize how this attack deliberately breaks it.A legitimate connection completes a three-way handshake: SYN, SYN-ACK, ACK. A SYN flood attack exploits the gap in that sequence. The attacker sends a SYN packet, the victim dutifully responds with SYN-ACK and waits for the final ACK to complete the connection, and the attacker simply never sends it, instead sending another fresh SYN, or in this capture's case, a
[RST] (reset) packet, forcing the victim to tear down its half-open connection attempt and immediately repeating the cycle. Each of those half-open connections consumes a small amount of the victim's resources while it waits for an acknowledgment that will never come, and enough of them, repeated rapidly, exhausts those resources entirely.Scrolling through the capture, I could see the actual pattern directly: a stream of SYN packets from a single attacking IP, met each time with a SYN-ACK from the victim, followed not by a completing ACK but by a reset, over and over. Beyond manually scrolling, Wireshark's I/O Graph (filtered specifically to TCP Errors) turned that pattern into a visual spike in packets per second, and the Protocol Hierarchy statistics view showed an unusually disproportionate volume of raw TCP traffic relative to everything else in the capture, both of which independently corroborated what the manual packet-by-packet reading had already suggested.
Spotting ARP Poisoning Through a Built-In Warning
The final file,
ARP Poisoning.pcapng , demonstrated an attack where Wireshark essentially does the detection work directly. ARP poisoning (or ARP spoofing) involves an attacker sending forged ARP messages to associate their own MAC address with another device's IP address on the local network, letting them intercept traffic meant for that device.Wireshark has a specific built-in detection for exactly this pattern: it flags a "Duplicate IP address detected" warning when the same IP address appears to be claimed by more than one MAC address on the network, precisely the signature ARP poisoning produces. Applying the
arp.duplicate-address-detected filter surfaced that warning directly, confirming the specific duplicated IP address involved, without requiring the kind of multi-packet sequence tracing the earlier attacks needed.What Ties These Four Investigations Together
A few things stood out, working through four genuinely different attack types in the same session.
The right filter is the actual investigative skill, not just a technical shortcut.
http.request.method == POST to find credentials, tcp.port == 53 to isolate a DNS-channel exploit, ftp.response.code == 530 and 230 to bracket a brute-force attempt, arp.duplicate-address-detected to catch spoofing directly, each filter encodes real knowledge about what that specific attack actually looks like at the protocol level. Knowing Wireshark's interface means nothing without knowing which filter corresponds to which attack signature.Protocol-level knowledge is what turns raw packets into a story. Recognizing that POST requests typically carry submitted form data, that a SYN flood specifically withholds the handshake's final step, that FTP has dedicated response codes for success and failure, none of that comes from the tool itself. It comes from understanding how the underlying protocols are actually supposed to behave, which is precisely what makes a deviation from that behavior recognizable as an attack in the first place.
Different attacks reveal themselves at different levels of effort. ARP poisoning was essentially handed to me by Wireshark's own built-in warning. A SYN flood needed manual packet tracing, corroborated by statistical views. A DNS remote shell needed following an entire reconstructed conversation to find the actual payload evidence. Forensic tooling doesn't make every investigation equally easy, some attacks leave an obvious fingerprint, others require genuinely reconstructing a sequence of events by hand.
Plaintext protocols remain a real, demonstrable risk, not a theoretical one. Watching actual login credentials appear in cleartext inside captured HTTP traffic is a far more convincing argument for encrypted protocols than simply being told, in the abstract, that unencrypted connections are risky.
Multiple confirmation methods matter even within a single investigation. For the SYN flood specifically, manual packet inspection, the I/O graph, and the Protocol Hierarchy statistics all independently pointed to the same conclusion. That kind of convergence across different analysis methods is what turns a plausible read of the traffic into a confident, well-supported finding.
This lab was really four separate investigations wearing the same interface. Each attack type, credential theft, a covert remote shell, brute-forcing, denial of service, and spoofing, left a genuinely different signature in the traffic, and reading that signature correctly required specific protocol knowledge each time, not just familiarity with Wireshark's menus.
That's really the core skill network forensics demands: a packet capture doesn't explain itself. Understanding what normal traffic is supposed to look like for a given protocol, and recognizing precisely how and where a specific attack deviates from it, is what actually turns a raw recording of network traffic into forensic evidence.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article