Most organisations deploy Suricata or Snort with a default community ruleset and consider themselves covered. For perimeter threats — known exploits, malware hashes, blacklisted IPs — that's probably fine. But lateral movement is a completely different problem.
An attacker who has already compromised a host inside your network doesn't send exploit strings across the wire. They use SMB to access file shares — exactly like your IT team does. They use SSH for port forwarding — exactly like your developers do. They beacon out over HTTPS — exactly like every browser on your network does. Default rules have no behavioural baseline. They stay silent.
Known exploit strings · Malware signatures · Blacklisted IP addresses · Obvious protocol violations
Valid credentials · Legitimate protocols · Normal-looking traffic · No signature to match
In this project: 5 of the hardest scenarios produced zero default alerts from Suricata — including SSH pivoting, SOCKS tunnelling, admin share access, and Living-off-the-Land.
Behavioural baselines · Protocol metadata analysis · Multi-log correlation · Custom-engineered detection logic built around how attackers actually behave.
"The most damaging post-compromise activity happens in east-west traffic — between internal hosts that already trust each other. Traditional perimeter monitoring offers almost no visibility into this."
Rather than testing against generic attack traffic, I designed the lab around the specific problem of internal post-compromise detection. Three VMs, dual network interfaces, and a PCAP-based replay workflow that made the results repeatable and directly comparable.
The baseline-first approach was critical — you cannot tune detection rules meaningfully without knowing what normal traffic looks like on your network first. Every false positive analysis in this project is measured against that baseline.
The scenarios were chosen specifically because they're hard — legitimate protocols used maliciously, valid credentials, encrypted channels. This is the table that default IDS vendors don't show you.
| # | SCENARIO | MITRE | SURICATA DEFAULT | COMBINED CUSTOM |
|---|---|---|---|---|
| 01 | Internal Port Scan | T1595 | MEDIUM | STRONG |
| 02 | ICMP Reconnaissance | T1018 | LOW | PARTIAL |
| 03 | SMB Enumeration | T1021.002 | NONE | STRONG |
| 04 | Service Access | T1021 | LOW | STRONG |
| 05 | Admin Share Lateral Movement | T1021.002 | NONE | STRONG |
| 06 | SSH Port-Forwarding | T1572 | NONE | STRONG |
| 07 | SOCKS Proxy Tunnel | T1090 | NONE | STRONG |
| 08 | HTTPS-Wrapped Pivoting | T1572 | NONE | STRONG |
| 09 | DNS Tunnelling | T1071.004 | MEDIUM | STRONG |
| 10 | Living-off-the-Land | T1059 | NONE | STRONG |
| 11 | Encrypted C2 | T1573 | LOW | STRONG |
| 12 | Jittered C2 Beaconing | T1071 | NONE | PARTIAL |
| 13 | Cloud API Emulation | T1102 | HIGH | STRONG |
| 14 | LLMNR Poisoning | T1557.001 | NONE | STRONG |
Default Suricata produced zero alerts for SSH pivoting, SOCKS tunnelling, Admin Share access, and Living-off-the-Land. These aren't obscure techniques — they're in every real intrusion. Out-of-the-box is not enough.
Zeek's behavioural telemetry — connection logs, NTLM session linking, TLS metadata, SMB mapping — consistently outperformed signature matching in scenarios where the traffic looked legitimate. Context is what makes the difference.
LotL and Admin Share scenarios had the highest false positive risk — legitimate IT administration generates nearly identical traffic. A rule that fires on every sysadmin task gets disabled. Tuning against a real baseline is not optional.
Randomised beacon timing defeated every threshold-based rule even after significant tuning. Zeek provided partial detection through persistent destination behaviour — but not full confidence. Knowing where your model fails is as valuable as knowing where it works.
Suricata flags the anomaly fast. Zeek provides the context — who, from where, what protocol sequence, what behaviour preceded it. Together they reduce the ambiguity that makes lateral movement so hard to triage in a real SOC.
I was frustrated that most IDS research tests tools against perimeter-style attacks — obvious exploits, known malware — because that's where detection is easy. The hard problem is internal. An attacker who is already inside, using legitimate tools, blending into normal traffic. I wanted to understand that problem properly, not just read about it.
So I built the lab, ran the attacks, wrote the rules from scratch, and documented everything — including where the detection model fails. That last part is important to me. Understanding the ceiling of what you've built is how you make it better.
BSc (Hons) Ethical Hacking & Cyber Security
Coventry University · 2:1 · 2023–2026
Zeek · Suricata · Metasploit · Nmap · Responder · Wireshark · Tcpdump · ELK Stack · VMware
All detection rules, Zeek scripts, scenario documentation and false positive analysis on GitHub.
SOC analyst · Blue team · Detection engineering roles where I can keep building and keep learning.
All rules, scripts, and scenario documentation are open on GitHub.