Mohammed Shareek

About This Project

This is my Bachelor's thesis project at Hochschule Albstadt-Sigmaringen, built to answer a question that matters in every enterprise SOC: given the same network traffic and the same attack, do Snort and Suricata see the same thing? The answer, as this lab demonstrates, is more nuanced than the common assumptions — and the differences have real consequences for how organizations design their detection architecture.

To answer that question rigorously, I designed and built a fully segmented 7-node Proxmox virtualization cluster entirely from scratch, deployed four independent detection layers simultaneously, executed three realistic attack chains from attacker to target, and analyzed the resulting telemetry across 32 custom Splunk SPL queries — producing a forensic-grade, evidence-based comparison of both engines across every attack phase.

Lab Architecture

The lab runs on a 7-node Proxmox cluster (pve-01 through pve-07) backed by a TrueNAS CE storage server with RAIDZ1 redundancy. Network segmentation is enforced by a Cisco Catalyst 2960X switch with five dedicated VLANs, two hardware SPAN sessions for passive traffic mirroring, and pfSense as the perimeter firewall and inline IPS.

The detection stack runs four independent layers simultaneously, each receiving identical traffic from the same switch:

• pfSense inline IPS: Suricata and Snort deployed in Legacy IPS mode, sitting on the perimeter and capable of actively blocking traffic
• Security Onion (IDS): Suricata running in passive detection-only mode with Zeek handling deep protocol analysis (dns, dce_rpc, kerberos, weird, http, ftp)
• Snort IDS VM (Ubuntu): Snort in passive IDS mode with sfportscan plugin enabled, receiving mirrored traffic via dedicated SPAN port
• Splunk SIEM: Universal Forwarders on every VM feeding all logs centrally; pfSense forwarding Suricata→TCP 5515, Snort→TCP 5516, syslog→UDP 5514

Endpoint telemetry was collected via Sysmon with the SwiftOnSecurity ruleset on DC01 and Client01, with PowerShell Script Block Logging enabled via GPO. This ensured that every attack step left forensic traces across multiple data sources — network, host, and firewall — enabling full kill-chain correlation in Splunk.

Attack Scenarios

Three complete attack chains were executed against the lab environment, each chosen to represent a distinct phase of the MITRE ATT&CK framework and stress-test different detection capabilities of each engine.

Research Findings

The following table shows raw alert counts recorded by all four detection layers during Scenario 1 (Nmap Recon). The volume difference between engines is not simply a matter of sensitivity — it reflects fundamental architectural differences in how each engine handles alert aggregation and output format.

The following are the primary research conclusions drawn from all three scenarios:

Conclusion

Across 48,927 alerts correlated from four sensors over three attack chains, the data tells a consistent story:

• Snort and Suricata are largely equivalent in detection logic at identical rule coverage. Their real differences are log format (Suricata's structured EVE-JSON vs. Snort's CSV) and alert volume — which challenges the common assumption that Suricata is fundamentally the stronger engine.
• Signature-based IDS/IPS are dependable for known, network-visible attacks, but structurally blind to credential-based abuse of legitimate protocols (living-off-the-land).
• Effective detection therefore demands a layered architecture: behavioural protocol analysis (Zeek) and endpoint telemetry (Sysmon, Windows Event Logs) are necessary components, not optional extras. In this lab, the full lateral-movement kill chain could only be reconstructed by correlating Zeek's ntlm.log (19 cleartext-username captures) and dce_rpc.log with Windows and Sysmon telemetry in Splunk.

SIEM Integration & Splunk Dashboard

All seven virtual machines had Splunk Universal Forwarder deployed, feeding dedicated indexes (dc01, client01, kali, metasploitable, dvwa, seconion, snort). pfSense log forwarding required custom engineering: a persistent shell script using stdbuf with a while-true loop and pkill-based process management, persisted via the pfSense Cron package, to ensure reliable log streaming over TCP.

A Splunk Classic Simple XML dashboard was built grouping panels by detection mode — IPS panels on the left (Suricata in green, Snort in red) and IDS panels on the right — enabling instant side-by-side visual comparison of both engines across any given time window. 32 custom SPL queries covered all scenarios, sensors, and detection layers, including custom EXTRACT regex definitions for pfSense's BSD syslog filterlog format (TCP, UDP, and ICMP variants).

Key Highlights

• Built a fully segmented 7-node Proxmox cluster from scratch with 5 VLANs, a Cisco Catalyst enterprise switch, two hardware SPAN sessions for passive traffic mirroring, and TrueNAS CE RAIDZ1 storage
• Deployed four simultaneous, independent detection layers (pfSense IPS ×2, Security Onion IDS, Snort IDS VM) under identical network conditions — enabling direct, evidence-based engine comparison
• Executed three complete attack chains covering MITRE ATT&CK initial access, execution, credential access, discovery, lateral movement, and collection phases
• Surfaced the headline finding: credential-based lateral movement (PsExec / WMIExec) was nearly invisible to all four signature sensors — only Suricata IDS caught WMIExec, and only via low-severity INFO alerts — proving signature-based NIDS alone cannot detect living-off-the-land techniques
• Proven that perimeter IPS (both Suricata and Snort) is architecturally blind to east-west lateral movement — a finding that supports the need for internal NIDS placement in any enterprise detection strategy
• Documented a false positive pattern (Hydra triggering CSRF signatures) that reveals inherent limitations of signature-based detection without contextual rule tuning
• Built 32 custom Splunk SPL queries and a structured IPS/IDS comparison dashboard covering all scenarios, sensors, and detection layers
• Integrated Sysmon (SwiftOnSecurity config) and PowerShell Script Block Logging across the AD environment for full endpoint telemetry correlation alongside NIDS data

Challenges & Solutions

pfSense Log Forwarding Stability: Getting Suricata and Snort logs to stream reliably from pfSense to Splunk proved far from straightforward. The standard Splunk Universal Forwarder approach does not work natively on pfSense's FreeBSD environment. The solution was a custom persistent shell script using stdbuf -oL to disable output buffering, wrapped in a while true loop with pkill-based process cleanup to prevent duplicate forwarder instances — the entire script persisted via pfSense's Cron package to survive reboots. Suricata logs forwarded over TCP 5515, Snort over TCP 5516, and pfSense syslog over UDP 5514.

Splunk Field Extraction Conflicts: Three pre-installed Technology Add-ons — Splunk_TA_windows, Splunk_TA_nix, and Splunk_Security_Essentials — were silently overriding the src field across all indexes, producing incorrect source attribution in every SPL query. Identifying this required methodical elimination: each TA was removed individually and field values were re-validated. The fix required writing custom props.conf EXTRACT definitions for pfSense's BSD syslog filterlog format, covering TCP, UDP, and ICMP variants with separate regex patterns for each protocol's field layout.

HOME_NET Scope Across Four Engines: Ensuring the attacker VLAN (VLAN10, Kali) was consistently classified as EXTERNAL_NET — while all protected VLANs (20, 30, 40, 99) remained as HOME_NET — required synchronized configuration across pfSense Suricata, pfSense Snort, Security Onion's Suricata instance, and the standalone Snort VM. A misconfiguration in any single engine would silently invert alert directionality for that layer, invalidating the entire comparative dataset. Each engine required separate documentation and verification steps.

Eventtypes and Source Normalization: Building reliable SPL queries across five completely different log sources (Suricata eve.json, Snort CSV, pfSense filterlog, Sysmon XML, Zeek TSV) required creating a normalization layer via Splunk eventtypes, allowing queries to target eventtype=suricata_alert or eventtype=snort_alert regardless of the underlying index or field naming differences. Without this layer, cross-engine correlation in a single SPL query would have been impractical.