Handling a Fake Port Scan in SOC Lab
Manish Rawat
From Alert to Action: How I Handled a Fake Port Scan in My SOC Lab
3 min read
·
2 days ago
By Manish — Security Operations | Blue Team Analyst
Summary
It’s easy to detect a port scan. What matters is what you do next.
This write-up walks through how I simulated a basic Nmap port scan, detected it using Wazuh + Suricata, and walked the alert through the triage process — just like it would happen in a real SOC.
More than just detection, this is about answering:
Is it a threat? A false positive? Do we escalate or tune it out?
Environment
Detection Stack: Wazuh + Suricata + ELK Stack
Monitored Host: Kali Linux (dual role: attacker + monitored endpoint)
SIEM Interface: Kibana (Wazuh dashboard)
The focus was on triggering, capturing, and analyzing alert activity based on a simple but common network event.
Simulating the Attack: Nmap Scan
To trigger a controlled detection, I ran the following Nmap scan:
This performed a TCP SYN scan on the localhost, mimicking the most common early-stage reconnaissance behavior.
Detection: Suricata + Wazuh Integration
Suricata — running in IDS mode — flagged the scan with the following alert:
This alert was then parsed by Wazuh and forwarded to Elasticsearch. In Kibana, it appeared under the
suricata.eve.alert dataset with full packet and rule context.Investigation: Log Context + Behavioral Patterns
My triage approach focused on the investigation pipeline, not just the raw alert.
Source/Destination Analysis:
Internal IP scanning localhost
No lateral or external IPs observed
Confined within test subnet
Frequency & Pattern:
Single occurrence
No follow-up connections or payloads
System Behavior:
No abnormal process activity (
ps, top, audit logs clean)No outbound data transfer
Triage Decision
Based on correlation and lack of post-scan behavior, the scan was:
🔎 Low-confidence recon activity, likely benign/internal
I marked it as Informational, with no escalation required.
But I didn’t dismiss it blindly. I documented:
Detection rule hit
Asset impacted
Time of event
Why it was not escalated
This creates traceability — a key part of a SOC analyst’s job.
Analyst Thought Process (What I’d Do in a Real SOC)
Question Answer Was this alert expected? No, but controlled and explainable Was it targeted? No — localhost only Did anything follow the scan? No lateral movement, no payloads Do I suppress this alert? No — one-time internal scan Do I need a case in TheHive or equivalent? Not for this — but notes were recorded
Noise Management
Rather than disabling the signature, I tuned the rule to:
Alert only when scan targets more than 10 ports
Suppress alerts from known internal testing tools via tag (
nmap_local_test)This kept visibility open while reducing false flags during dev/test cycles.
Final Thoughts
This exercise was less about catching the scan — and more about showing the discipline to ask the right questions, trust the data, and make a defensible call.
That’s what separates a rule-writer from a real blue team analyst.
What’s Next
Add TheHive to capture triage documentation formally
Trigger a multi-host scan to simulate horizontal recon
Enrich alerts with asset criticality scoring for better triage filters
#BlueTeam #SOCAnalyst #ThreatDetection #CyberSecurity #Suricata #Wazuh #ELKStack #IncidentResponse #SecurityOperations #DetectionEngineering #AlertTriage #Nmap #NetworkSecurity #HomeLab #InfoSecLike this project
Posted Jun 16, 2025
Simulated and triaged a fake port scan in a SOC lab.
Likes
0
Views
0
Timeline
Jun 13, 2025 - Jun 14, 2025
