I used to think network traffic analysis was about finding “weird stuff.”
Spoiler:
Most of the time… nothing looks weird.
Everything looks normal. And that’s the problem.
After working through the first phase (Wireshark + Snort), I stopped chasing individual packets, I stopped looking for “malicious packets,” and started asking a different question.
Not what looks suspicious, but what does not make sense here.
Because the truth is, most malicious activity does not stand out immediately. It hides inside what looks normal. And if you are only scanning for obvious red flags, you will miss it.
When Traffic Stops Being Random
In the beginning, everything looked like noise. Packets moving in different directions, protocols overlapping, and no clear indication of what mattered.
But once I slowed down and started following patterns instead of isolated packets, things began to change. Traffic started to look less like chaos and more like behavior.
That shift was important. Because attacks are not just packets. They are sequences.
Suspicious HTTP Patterns
The first real signal came from HTTP traffic. At a glance, it looked like routine web requests, but something about it felt off.
📸 Evidence — Suspicious HTTP Behavior
Suspicious HTTP POST requests with randomized URIs identified using tshark, indicating potential command-and-control or data exfiltration activity.
The URIs were not readable. They were long, inconsistent, and appeared almost random. But they were also repeated, which made it unlikely to be accidental.
This is where pattern recognition matters. Random values that repeat are rarely random. They often indicate structured communication, possibly between a compromised system and an external controller.
At this stage, it was not confirmed malicious activity, but it was no longer normal browsing behavior.
Reconnaissance Before Action
Shortly after, I noticed another pattern that is easy to overlook.
ARP traffic.
It is something that usually fades into the background, but in this case, the volume stood out.
📸 Evidence — ARP Recon Activity
High volume of ARP requests indicating network reconnaissance and host discovery activity.
Multiple broadcast requests asking “who has this IP” across the network.
This was not communication. It was discovery.
It suggested that a system was actively mapping the network, trying to identify available hosts. And that is often the step that comes before any meaningful attack.
DNS as a Hidden Channel
DNS is typically one of the least suspicious protocols in a network. It is expected. Constant. Almost invisible.
But that is exactly why it can be abused.
📸 Evidence — DNS Tunneling
Suspicious DNS MX queries associated with DNS tunneling (dnscat), indicating covert command-and-control communication.
The queries did not resemble normal domain lookups. Instead of human-readable domains, they contained structured, encoded-looking strings.
That alone is unusual. But when combined with repetition and consistent patterns, it becomes a strong indicator of DNS tunneling.
📸 Evidence — Data Embedded in DNS
Encoded data embedded in DNS queries, demonstrating data exfiltration over DNS covert channels.
At this point, it became clear that DNS was not being used for resolution. It was being used for transport.
Data was leaving the network, hidden inside what would normally be ignored traffic.
This changes how you look at DNS entirely. It is no longer just a supporting service. It becomes a potential exfiltration channel.
When Exfiltration Is Not Hidden
Not every attacker relies on stealth. Some simply use what is available.
📸 Evidence — FTP Activity
FTP traffic showing unauthorized guest login and file upload activity, indicating potential data exfiltration via insecure services.
In this case, there was a guest login followed by a file upload.
No encryption. No obfuscation. Just direct transfer.
This highlights an important point. Security gaps are not always exploited through complex techniques. Sometimes, they are exploited because they exist.
HTTP as a Data Channel
Returning to HTTP traffic, I decided to follow a stream more closely instead of just observing requests.
📸 Evidence — Reconstructed HTTP Stream
Reconstructed HTTP stream revealing sensitive data transmitted in cleartext during an exfiltration attempt.
What initially looked like standard traffic revealed something else entirely when reconstructed.
Actual data.
Readable content.
Sensitive information moving across the network without protection.
At that point, it was no longer about identifying anomalies. It was about confirming impact.
Understanding the Bigger Picture
When viewed individually, each of these findings could be dismissed.
- HTTP requests could be normal
- ARP traffic could be routine
- DNS queries could be ignored
- FTP could be legitimate
But together, they tell a different story.
Reconnaissance. Communication. Data movement.
That is not coincidence. That is a sequence.
Detection Opportunities (Blue Team Takeaways)
This is where analysis turns into defense.
Unusual HTTP patterns, especially with randomized or repetitive URIs, should be investigated. High volumes of ARP requests can indicate internal reconnaissance. DNS queries containing encoded or non-standard structures should never be ignored.
Open or misused FTP services present clear risk, particularly when anonymous or guest access is allowed. And most importantly, unencrypted HTTP traffic carrying sensitive data is always a critical issue.
Detection is not about identifying one anomaly. It is about correlating behavior across protocols.
My Final Thoughts
This lab changed how I approach network traffic.
I no longer look for what is obviously malicious. I look for what does not align with expected behavior.
Because most attacks do not announce themselves. They blend in. They move quietly. They rely on the assumption that no one is paying close attention.
But once you start connecting patterns instead of packets, the story becomes clearer.
And when the story becomes clear, detection becomes possible.
View similar Lab: Let's go Phishing
