Identify Intrusion Elements

IDS/IPS alert analysis and intrusion indicators

Week 4 TOPIC

Understanding IDS/IPS Alerts

Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS) generate alerts when they detect suspicious or malicious activity. SOC analysts must understand alert elements to triage effectively. An alert is not proof of attack -- it is a signal that requires investigation. Your job is to determine if the alert represents a true positive (real threat) or false positive (benign activity that triggered the rule).

IDS vs IPS -- Deployment and Impact

IDS (Detection)

Monitors traffic passively via SPAN/mirror port. Generates alerts but does NOT block traffic. The threat reaches its destination. Used for visibility, forensics, and detection tuning. If the IDS fails, traffic continues to flow uninterrupted (fail-open by nature).

IPS (Prevention)

Deployed inline with traffic. Can block, drop, or reset malicious connections in real-time. Risk: false positives block legitimate traffic (potential business impact). Must choose fail-open (risky) or fail-closed (availability impact) mode. Requires careful rule tuning before deployment.

Signature-Based

Matches known attack patterns using rules (Snort/Suricata signatures). Fast, accurate for known threats, low false positive rate when well-maintained. Cannot detect zero-day attacks or novel techniques not yet catalogued in the rule set.

Anomaly-Based

Detects deviations from baseline behavior. Catches novel attacks that have no signature. Higher false positive rate because "unusual" does not always mean "malicious." Requires initial learning period to build accurate baseline. Complements signature-based detection.

Source: Shield House > Network > IDS/IPS Training Open IDS/IPS Module

Alert Elements

Every IDS/IPS alert contains structured data that tells you what happened, when, where, and why the rule fired. Understanding each element is critical for accurate triage:

Element	Description	Analysis Value
Signature ID (SID)	Unique identifier for the detection rule	Research known attack via vendor docs (rules.emergingthreats.net), understand what triggered the alert
Source IP	Origin of the suspicious traffic	Internal vs external? Reputation lookup (AbuseIPDB, VirusTotal). If internal, the host may be compromised
Destination IP	Target of the attack	What asset is targeted? Check asset inventory for criticality. Crown jewel system = higher priority
Source Port	Ephemeral port used by the client	High port (49152+) is normal for client. Low port may indicate spoofing
Destination Port	Service port being targeted	Is the service expected? Port 445 from external = SMB attack. Port 4444 = possible Metasploit
Protocol	TCP, UDP, ICMP, etc.	Expected for the service? ICMP to a web server may indicate tunneling
Timestamp	When the event occurred	Business hours vs off-hours. Correlate with other events in the same time window
Priority/Severity	Risk level (1=critical, 3=low)	Determines SLA for response. Priority 1 = respond within 15 minutes
Classification	Category of the threat	"A Network Trojan was detected" vs "Attempted Information Leak" -- directs investigation focus
Payload	Relevant packet content that matched	The actual malicious data. Contains IOCs you can search for across other log sources

Snort Alert Example (Classic Format)

[**] [1:2024217:3] ET TROJAN Cobalt Strike Beacon Detected [**] [Classification: A Network Trojan was detected] [Priority: 1] 01/05-14:32:17.123456 192.168.1.50:49721 -> 203.0.113.50:443 TCP TTL:128 TOS:0x0 ID:12345 IpLen:20 DgmLen:1500 ***AP*** Seq: 0x12345678 Ack: 0x87654321 Win: 0x4000 TcpLen: 20

Suricata EVE JSON (Modern SOC Format)

Most modern SOCs use Suricata with EVE JSON output -- it feeds directly into SIEM platforms (Splunk, ELK, Sentinel). JSON format enables automated parsing, enrichment, and correlation:

{ "timestamp": "2026-01-05T14:32:17.123456+0000", "event_type": "alert", "src_ip": "192.168.1.50", "src_port": 49721, "dest_ip": "203.0.113.50", "dest_port": 443, "proto": "TCP", "alert": { "action": "allowed", "gid": 1, "signature_id": 2024217, "rev": 3, "signature": "ET TROJAN Cobalt Strike Beacon Detected", "category": "A Network Trojan was detected", "severity": 1 }, "flow": { "pkts_toserver": 47, "bytes_toserver": 28340, "pkts_toclient": 12, "bytes_toclient": 4200 } }

Action: "allowed" Does NOT Mean Safe

If your IDS is in detection mode (not inline IPS), "action": "allowed" means the traffic was detected but NOT blocked. The malicious traffic reached its destination. This requires immediate investigation and potential manual containment. Think of it as: "We saw the burglar enter the building but did not stop them."

SOC Analyst Tip

SID Research: Always look up the SID. For Emerging Threats rules, search sid:2024217 at rules.emergingthreats.net. For Snort community rules, check snort.org/rule_docs. The rule documentation tells you exactly what pattern matched, why it matters, what the expected false positive rate is, and recommended response actions. Without reading the rule docs, you are guessing.

Snort/Suricata Rule Anatomy

Understanding how detection rules work helps you interpret alerts and assess their accuracy. Every Snort/Suricata rule has two parts: the header (who/where) and the options (what to look for).

Example Rule: SQL Injection Detection

                    alert
                    tcp
                    any any
                    ->
                    $HOME_NET 80
                    (

                      msg:"SQL Injection Attempt";

                      content:"' OR '1'='1"; nocase;

                      http_uri;

                      classtype:web-application-attack;

                      sid:1000001; rev:1;

                    )
                

Component	Value	Meaning
Action	alert	Generate an alert (alternatives: drop, reject, pass)
Protocol	tcp	Match TCP traffic only
Source	any any	Any source IP, any source port
Destination	$HOME_NET 80	Traffic going to our network on port 80 (HTTP)
content	' OR '1'='1	Look for this exact string in the packet payload
http_uri	---	Only search within the HTTP URI (not the full packet)
classtype	web-application-attack	Categorization for SIEM dashboards
sid	1000001	Unique rule ID for reference and research

Key Content Modifiers

nocase

Case-insensitive matching. Critical for web attacks where "SELECT" and "select" are equivalent.

depth / offset

Limit where in the payload to search. Reduces false positives by targeting specific positions.

pcre

Perl-Compatible Regular Expression. For complex pattern matching beyond simple string search.

flowbits

Track state across multiple packets. Enables multi-step detection (e.g., login attempt followed by data download).

Common False Positive Sources

Source	Why It Triggers	How to Confirm FP
Vulnerability scanners (Nessus, Qualys)	Deliberately send attack payloads to test defenses	Check if source IP is in the authorized scanner list
Penetration testing	Security team running authorized attack simulations	Check the change management/pentest schedule
Backup software	Large, unusual data transfers that look like exfiltration	Verify source/dest are backup infrastructure
Security tools	AV updates, EDR telemetry may match malware signatures	Check if the process is a known security product
Web applications	User-generated content containing "attack-like" strings	Check if the destination is a content platform

Alert Triage Simulation

Analyze the following IDS alerts as a Tier 1 SOC analyst. For each alert, determine the classification and appropriate action. Read every field carefully -- the details matter.