## https://sploitus.com/exploit?id=7D18D33A-EB04-5EED-AE09-4481C58B1CFE
# IDS Deployment & Packet Analysis
**Network intrusion detection with Suricata, packet-level verification in Wireshark, and alert correlation in Splunk — mapped to the MITRE ATT&CK framework.**
**Author:** Kehinde Oyewumi
**Date:** August 19, 2026
---
## Relevance to the Cybersecurity Field
Network Intrusion Detection and packet analysis sit at the core of the Security Operations Center (SOC) function. Organizations rely on analysts who can not only deploy detection tooling, but critically evaluate its output — distinguishing genuine threats from noise, and default coverage from real gaps. I built this project to mirror that exact workflow:
- **Detection Engineering** — I wrote and tuned a custom Suricata rule, demonstrating my ability to close real coverage gaps rather than relying solely on a vendor/community ruleset.
- **Alert Triage & Verification** — I cross-referenced every IDS alert against raw packet captures, reflecting the standard SOC Tier 1/2 workflow of confirming true positives before escalation.
- **SIEM Correlation** — I forwarded IDS and NSM data into Splunk, applying the log-forwarding and correlation-search skills expected of SOC and Detection Engineering roles.
- **Threat Intelligence Framing** — I mapped my findings to MITRE ATT&CK, now a baseline expectation in incident reporting and threat hunting across the industry.
---
## Architecture
```
Network Traffic → Suricata (signature alerts) ─┐
→ Zeek (network metadata) ─┼→ Splunk (correlation) → Investigation → MITRE ATT&CK
→ Wireshark (packet verification) ─────────────────────↗
```
*Figure 1. End-to-end detection pipeline: traffic is observed by Suricata, Zeek, and Wireshark in parallel; Suricata and Zeek converge in Splunk for correlation; all confirmed findings are mapped to MITRE ATT&CK.*
### Environment
| Component | Role | Details |
|---|---|---|
| Kali Linux (VMware) | Attacker / Sensor host | Runs Suricata, tcpdump, attack tooling (nmap, nikto) |
| Windows 10 (VMware) | Target | Isolated host-only network; SSH, RPC, NetBIOS, SMB services present |
| Splunk Enterprise | SIEM / correlation layer | Running on host laptop; receives forwarded Suricata & Zeek data via Universal Forwarder |
| Suricata 8.0.6 | Network IDS | Emerging Threats Open ruleset + custom local rule |
---
## Scenario 1 — TCP Port Scan
`MITRE T1046 — Network Service Scanning`
### Suricata Deployment
I installed Suricata on my Kali sensor host and updated it with the Emerging Threats Open ruleset (68,360 rules loaded), then validated it with a clean configuration test.
*Figure 2. Suricata installation via apt, followed by suricata-update pulling the Emerging Threats Open ruleset.*
*Figure 3. Ruleset successfully compiled (68,360 rules loaded, 52,415 enabled) and configuration test passed cleanly.*
### Attack Simulation
I ran a TCP SYN scan (`nmap -sS -T4`) from my Kali attacker host against the Windows 10 target, identifying four open services.
*Figure 4. Nmap SYN scan results — SSH (22), MSRPC (135), NetBIOS-SSN (139), and Microsoft-DS/SMB (445) identified as open.*
### Detection Engineering
> **Finding:** Generic TCP SYN port scans are not reliably flagged by Suricata's default community ruleset, since scan detection depends on behavioral thresholds (many connection attempts in a short window) rather than a single-packet signature. I wrote a custom rule myself to close this gap.
```
alert tcp any any -> $HOME_NET any (msg:"Possible Nmap TCP SYN Scan Detected";
flags:S; threshold:type both, track by_src, count 20, seconds 10;
classtype:attempted-recon; sid:1000001; rev:1;)
```
This rule triggers when a single source sends 20+ SYN packets to the protected network within 10 seconds — a reliable behavioral indicator of scanning activity.
*Figure 5. Custom local.rules entry written and verified via direct file inspection.*
### IDS Perspective
| Field | Value |
|---|---|
| Signature | Possible Nmap TCP SYN Scan Detected |
| Rule Source | Custom (`local.rules`, sid:1000001) |
| Classification | Attempted Information Leak |
| Severity | Priority 2 |
| Source → Destination | 192.168.184.129:62095 → 192.168.184.128:9878 |
| Timestamp | 2026-08-19 08:37:47 UTC |
*Figure 6. Suricata fast.log showing the custom rule firing against the live scan traffic.*
### Packet-Level Verification
I filtered this in Wireshark using:
```
ip.addr==192.168.184.128 and tcp.flags.syn==1 and tcp.flags.ack==0
```
*Figure 7. Wireshark confirms the scan pattern: rapid sequential SYN packets across many ports from a single source, verifying the alert as a true positive.*
**Verdict: True Positive.** The custom rule correctly identified genuine port scanning behavior, independently confirmed at the packet level.
---
## Scenario 2 — HTTP Reconnaissance (Nikto)
`MITRE T1595.002 — Active Scanning: Vulnerability Scanning`
### Attack Simulation
I stood up a lightweight practice web server on Kali (Python `http.server`, port 8080) and scanned it using **Nikto**, generating 8,192 automated probe requests.
*Figure 8. Nikto scan launched against the target web service.*
*Figure 9. Scan completion: 8,192 requests sent, 8 findings reported (missing security headers, deprecated headers, configuration weaknesses).*
### IDS Perspective
Unlike Scenario 1, Suricata's **default** ruleset flagged this traffic on its own — I didn't need a custom rule here. One of Nikto's generic probes matched a specific, named CVE signature:
| Field | Value |
|---|---|
| Signature | ET EXPLOIT F5 TMUI RCE vulnerability CVE-2020-5902 Attempt M1 |
| Rule Source | Emerging Threats Open (default ruleset) |
| Classification | Attempted Administrator Privilege Gain |
| Severity | Priority 1 |
| Source → Destination | 127.0.0.1:49172 → 127.0.0.1:8080 |
*Figure 10. Filtered alerts showing the F5 TMUI RCE (CVE-2020-5902) signature and HTTP protocol anomaly detections.*
*Figure 11. Extended alert log showing repeated CVE-2020-5902 attempts alongside HTTP host-header anomaly detections.*
### Packet-Level Verification
```
tcp.port==8080 and http
```
*Figure 12. Nikto's systematic probing — sequential requests for common vulnerable paths (/server-status, /icons/, /trace.axd, etc.).*
I followed the exact stream tied to the CVE-2020-5902 alert:
```
GET /tmui/login.jsp/..;/tmui/locallb/workspace/fileRead.jsp?fileName=/etc/hosts HTTP/1.1
User-Agent: Mozilla/5.0 (Android 14; Mobile; rv:133.0) Gecko/133.0 Firefox/133.0
Host: 127.0.0.1
```
*Figure 13. Full HTTP stream showing the path-traversal request pattern for CVE-2020-5902, and the server's 404 response confirming no actual vulnerable F5 device was present.*
### Analyst Assessment
> **Key finding:** The request path (`/tmui/login.jsp/..;/tmui/...`) is the literal, textbook exploitation pattern for CVE-2020-5902 — a real and severe F5 BIG-IP vulnerability. The alert is a **true positive for suspicious/malicious-shaped traffic**. Packet inspection confirms the request originated from Nikto's automated, generic probing routine (evidenced by the broader scan pattern and a spoofed mobile browser User-Agent) rather than a targeted exploitation attempt, and the target returned a 404 — confirming no actual compromise occurred.
This distinction — correctly identifying that a signature fired accurately on a real exploit *pattern*, while using packet-level context to attribute the activity to automated reconnaissance rather than an active attack — is a core SOC analyst skill.
**Verdict: True Positive (Reconnaissance).** Confirmed via packet inspection as Nikto-driven automated scanning, not active exploitation.
---
## Correlation in Splunk
I forwarded Suricata's structured `eve.json` output from Kali to Splunk via the Universal Forwarder, alongside my existing Zeek NSM pipeline, giving me centralized search across both scenarios.
*Figure 14. Data ingestion confirmed — 33,202 Suricata events indexed across alert, flow, DNS, HTTP, and file-info event types.*
My correlation search (filtering out decoder-level checksum noise):
```
sourcetype=suricata event_type=alert NOT "invalid checksum"
| table _time, alert.signature, alert.severity, src_ip, dest_ip, dest_port
| sort _time
```
*Figure 15. Correlated timeline showing both confirmed detections — the custom port-scan rule and the CVE-2020-5902 signature — unified in a single searchable view.*
---
## MITRE ATT&CK Mapping
| Scenario | Technique | ID | Evidence |
|---|---|---|---|
| Port Scan | Active Scanning: Network Service Scanning | T1046 | Figures 4, 6, 7 |
| HTTP Recon | Active Scanning: Vulnerability Scanning | T1595.002 | Figures 8–13 |
| HTTP Recon (CVE probe) | Exploit Public-Facing Application (attempted) | T1190 | Figures 10–13 |
---
## Skills Demonstrated
| Category | Skills |
|---|---|
| Network Intrusion Detection | Suricata IDS deployment, ruleset management (Emerging Threats Open), configuration validation, custom signature development (threshold-based detection logic) |
| Packet Analysis | Traffic capture with tcpdump, Wireshark display filters, TCP stream reconstruction, protocol-level traffic interpretation (TCP handshake analysis, HTTP request/response inspection) |
| Offensive Tooling (for detection validation) | Nmap (SYN scanning, service enumeration), Nikto (automated web vulnerability scanning) — used to generate realistic, attributable attack traffic |
| SIEM & Log Correlation | Splunk Universal Forwarder deployment and configuration, SPL (Search Processing Language) query construction, multi-source log correlation (Suricata + Zeek) |
| Detection Engineering | Identifying coverage gaps in default rulesets, writing and validating custom detection logic against live traffic, distinguishing true positives from benign/misattributed alerts |
| Threat Intelligence | MITRE ATT&CK technique mapping, CVE identification and contextual risk assessment (CVE-2020-5902) |
| Systems & Lab Administration | Linux command-line administration (Kali), isolated virtual network design (VMware), cross-platform troubleshooting, YAML configuration management |
| Analytical & Reporting | Evidence-based verdict writing (true positive/false positive determination), structured incident documentation, technical writing for both analyst and management audiences |
---
## Lessons Learned
- **Default rulesets are not comprehensive.** Community rulesets like Emerging Threats Open excel at known exploit signatures (as seen with CVE-2020-5902) but don't reliably catch generic behavioral patterns like port scanning without an explicit threshold-based rule.
- **Every alert needs packet-level context.** The F5 CVE alert was technically accurate in matching a known exploit pattern, but only my packet inspection revealed the true nature of the activity — the core discipline that separates alert-reading from analysis.
- **Detection engineering is iterative.** Writing, testing, and validating a custom rule against real traffic is a foundational Detection Engineer skill, directly transferable to production SOC environments.
- **Centralized correlation multiplies value.** Feeding IDS alerts into the same SIEM as existing NSM (Zeek) data creates a single pane of glass for investigation, rather than siloed, tool-specific views.
---
## Full Report
A formatted PDF version of this report is available: [`IDS_Deployment_Packet_Analysis_Report_Kehinde_Oyewumi.pdf`](./IDS_Deployment_Packet_Analysis_Report_Kehinde_Oyewumi.pdf)