07 IDS Alert Investigation with Suricata

Mission Information

Item	Details
Lab	07
Lab Name	IDS Alert Investigation with Suricata
Track	CompTIA CySA+
Difficulty	Intermediate
Estimated Time	90–120 minutes
Primary Role	Cybersecurity Analyst / SOC Analyst
Environment	CySA+ Cybersecurity Analyst Lab
Primary Systems	Analyst Workstation + Linux Server
Primary Tool	Suricata
Skills	IDS Alert Analysis, EVE JSON, Signature Investigation, False-Positive Analysis, Network Detection, Event Correlation

Mission Scenario

You are working as a Cybersecurity Analyst at GHC Enterprise.

In the previous labs, you investigated:

Endpoint Logs
      ↓
Packet Captures
      ↓
Zeek Network Telemetry

Your SOC now adds another network security capability:

Suricata IDS

Suricata monitors network traffic and applies detection rules to identify activity that may require investigation.

The SOC has generated several IDS alerts involving communications between systems in your lab.

Your responsibility is to determine:

• what triggered each alert

• which systems were involved

• which signature matched

• how severe the alert is

• whether the alert represents malicious activity

• whether the activity is a false positive

• what additional evidence should be reviewed

• whether the alert should be escalated

Mission Objective: Use Suricata alerts and EVE JSON telemetry to perform structured IDS alert triage and validate detections with network evidence.

Mission Objectives

By completing this lab, you will be able to:

• understand IDS fundamentals

• explain how Suricata detects network activity

• install and verify Suricata

• understand Suricata rules

• process PCAP evidence

• generate controlled IDS alerts

• investigate eve.json

• identify signatures and categories

• analyze source and destination systems

• investigate protocols and ports

• evaluate alert severity

• distinguish alert from incident

• investigate false positives

• correlate Suricata with Zeek

• correlate alerts with PCAP evidence

• document SOC alert findings

1. What Is an IDS?

An Intrusion Detection System (IDS) monitors activity and generates alerts when traffic matches configured detection logic.

A simplified workflow is:

Network Traffic
      ↓
Suricata
      ↓
Detection Rules
      ↓
Rule Match
      ↓
Alert
      ↓
SOC Investigation

An alert does not automatically mean:

Compromise Confirmed

It means:

Something matched a detection condition and requires context.

2. IDS vs IPS

Suricata can operate in different roles.

IDS

Traffic
   ↓
Inspect
   ↓
Alert

The activity is detected but not necessarily blocked.

IPS

Traffic
   ↓
Inspect
   ↓
Detection
   ↓
Block / Drop

This lab focuses on IDS investigation.

3. Suricata vs Zeek

Suricata and Zeek complement one another.

Suricata	Zeek
Rule/signature-based detection	Structured network telemetry
Generates alerts	Generates detailed logs
Detects known patterns	Describes network behavior
IDS/IPS capabilities	Network security monitoring
Signature context	Behavioral context

A common SOC workflow is:

Suricata Alert
      ↓
Identify Source / Destination
      ↓
Zeek Investigation
      ↓
PCAP Investigation
      ↓
Endpoint Correlation
      ↓
Analyst Decision

4. Start the Lab Environment

Start:

CYSA-ANALYST
10.10.10.10

CYSA-LINUX01
10.10.10.30

Optionally start:

CYSA-WIN01
10.10.10.20

Verify connectivity:

ping -c 4 10.10.10.30

5. Create the Investigation Workspace

On CYSA-ANALYST:

mkdir -p ~/CySA-Lab/Investigations/LAB07/{SuricataLogs,PCAP,Screenshots,Findings}

Create investigation notes:

touch ~/CySA-Lab/Investigations/LAB07/investigation-notes.md

Use:

Investigation ID:
LAB07-IDS-001

6. Check Whether Suricata Is Installed

Run:

suricata --build-info

If installed, continue.

If not:

sudo apt update

Then:

sudo apt install suricata

Verify:

suricata --build-info

7. Identify Suricata Configuration

A common configuration location is:

/etc/suricata/suricata.yaml

Check:

ls -lh /etc/suricata/suricata.yaml

Do not make unnecessary changes yet.

The objective is to understand where the IDS configuration is stored.

8. Understand Suricata Rules

Suricata rules generally follow a structure similar to:

action protocol source_ip source_port -> destination_ip destination_port (options)

A simple educational rule might resemble:

alert icmp any any -> any any (msg:"LAB ICMP Activity Detected"; sid:1000001; rev:1;)

This means:

Action:
alert

Protocol:
icmp

Source:
any

Destination:
any

Message:
LAB ICMP Activity Detected

Signature ID:
1000001

9. Important Rule Components

Common rule elements include:

Element	Purpose
alert	Generate alert
tcp / udp / icmp	Protocol
Source IP	Originating system
Destination IP	Target system
msg	Alert message
sid	Signature identifier
rev	Rule revision
content	Data to match
classtype	Alert classification

You do not need to become a full detection engineer in this lab.

The focus is understanding why an alert exists.

10. Locate Local Rules

Check:

sudo find /etc/suricata -name "*.rules"

A common location is:

/etc/suricata/rules/

You may also have:

/var/lib/suricata/rules/

depending on the installation.

11. Create a Safe Lab Detection Rule

Create a dedicated local rules file:

sudo nano /etc/suricata/rules/local.rules

Add:

alert icmp any any -> any any (msg:"GHC LAB ICMP Activity"; sid:1000001; rev:1;)

Save the file.

This rule detects ICMP traffic and is safe for a controlled lab.

12. Verify Rule Configuration

Your Suricata configuration must load the local rules file.

Check relevant configuration:

grep -n "rule-files" -A 10 /etc/suricata/suricata.yaml

Verify that:

local.rules

is included.

If required, add it under the configured rule-files section.

13. Test the Suricata Configuration

Before running Suricata, validate the configuration:

sudo suricata -T -c /etc/suricata/suricata.yaml

You want validation to complete successfully.

Fix configuration errors before continuing.

14. Use an Existing PCAP

You can reuse your previous packet captures.

For example:

LAB06-ZEEK-001.pcap

Create an output directory:

mkdir -p ~/CySA-Lab/Investigations/LAB07/SuricataLogs/pcap-analysis

Process the PCAP:

sudo suricata \
-r ~/CySA-Lab/Investigations/LAB06/PCAP/LAB06-ZEEK-001.pcap \
-c /etc/suricata/suricata.yaml \
-l ~/CySA-Lab/Investigations/LAB07/SuricataLogs/pcap-analysis

List generated files:

ls -lh ~/CySA-Lab/Investigations/LAB07/SuricataLogs/pcap-analysis

15. Understand Suricata Output Files

Depending on your configuration, you may see:

eve.json
fast.log
stats.log
suricata.log

The most important file for modern SOC workflows is:

eve.json

EVE JSON contains structured security events.

16. Examine eve.json

Run:

head ~/CySA-Lab/Investigations/LAB07/SuricataLogs/pcap-analysis/eve.json

Because each event is JSON, raw output can be difficult to read.

Use:

jq '.' ~/CySA-Lab/Investigations/LAB07/SuricataLogs/pcap-analysis/eve.json | head -n 50

17. Understand EVE Event Types

EVE JSON may contain event types such as:

alert
flow
dns
http
tls
stats
fileinfo

Extract unique types:

jq -r '.event_type' ~/CySA-Lab/Investigations/LAB07/SuricataLogs/pcap-analysis/eve.json |
sort |
uniq -c

This tells you what telemetry exists.

18. Filter Only Alerts

Run:

jq 'select(.event_type=="alert")' \
~/CySA-Lab/Investigations/LAB07/SuricataLogs/pcap-analysis/eve.json

This removes unrelated telemetry and focuses on IDS detections.

19. Extract Important Alert Fields

Run:

jq -r '
select(.event_type=="alert") |
[
.timestamp,
.src_ip,
.src_port,
.dest_ip,
.dest_port,
.proto,
.alert.signature,
.alert.category,
.alert.severity
] | @tsv' \
~/CySA-Lab/Investigations/LAB07/SuricataLogs/pcap-analysis/eve.json

This provides a much cleaner SOC-style view.

20. Understand Alert Fields

Important fields include:

Field	Meaning
timestamp	When alert occurred
src_ip	Source IP
src_port	Source port
dest_ip	Destination IP
dest_port	Destination port
proto	Network protocol
signature	Detection message
signature_id	Rule identifier
category	Alert classification
severity	Relative priority

Your first goal is to answer:

What triggered?

Who triggered it?

Who was targeted?

When did it happen?

21. Generate Fresh ICMP Activity

To ensure your local rule triggers, capture fresh traffic.

First identify the analyst interface:

ip addr

Start Suricata on your authorized lab interface:

sudo suricata -i <interface> -c /etc/suricata/suricata.yaml

From another terminal:

ping -c 4 10.10.10.30

Stop Suricata after the test if you are running it interactively.

22. Locate the Live EVE Log

A common default is:

/var/log/suricata/eve.json

Check:

sudo ls -lh /var/log/suricata/eve.json

Filter recent alerts:

sudo jq 'select(.event_type=="alert")' /var/log/suricata/eve.json

Look for:

GHC LAB ICMP Activity

23. Investigate the ICMP Alert

Extract:

Timestamp
Source IP
Destination IP
Protocol
Signature
Signature ID

The traffic should correspond to:

10.10.10.10
      ↓
ICMP
      ↓
10.10.10.30

This demonstrates:

Traffic
   ↓
Rule Match
   ↓
IDS Alert

24. Understand Signature IDs

Your custom rule uses:

sid:1000001

Signature IDs allow analysts and detection engineers to identify specific rules.

During triage, record:

Signature
Signature ID
Revision
Category
Severity

This makes investigation and reporting more precise.

25. Understand Alert Severity

Suricata alerts may contain severity values.

Severity provides prioritization context, but do not treat it as a final incident classification.

For example:

Severity 1

does not automatically prove critical compromise.

An analyst still evaluates:

Asset importance
Source
Destination
User
Traffic context
Signature reliability
Known vulnerabilities
Threat intelligence
Related telemetry

26. Alert Does Not Equal Incident

This distinction is fundamental.

Alert
   ↓
Evidence of a detection condition

versus:

Incident
   ↓
Confirmed or sufficiently credible security event
requiring response

Your ICMP alert is a perfect example.

Suricata correctly detected traffic.

But:

ICMP observed

does not mean:

System compromised

27. Investigate Flow Events

Filter flow telemetry:

jq 'select(.event_type=="flow")' \
~/CySA-Lab/Investigations/LAB07/SuricataLogs/pcap-analysis/eve.json |
head

Flow events can provide:

Source
Destination
Packets
Bytes
Start Time
End Time
Protocol
State

These can help validate the alert context.

28. Investigate DNS Telemetry

Filter:

jq 'select(.event_type=="dns")' \
~/CySA-Lab/Investigations/LAB07/SuricataLogs/pcap-analysis/eve.json |
head

Depending on the PCAP and Suricata configuration, DNS records may expose:

Source IP
Destination IP
Query
Query Type
Response

29. Investigate HTTP Telemetry

Filter:

jq 'select(.event_type=="http")' \
~/CySA-Lab/Investigations/LAB07/SuricataLogs/pcap-analysis/eve.json |
head

Potentially useful fields include:

Hostname
URL
HTTP Method
User Agent
Status
Content Type

HTTP telemetry can provide valuable alert context.

30. Investigate TLS Telemetry

Filter:

jq 'select(.event_type=="tls")' \
~/CySA-Lab/Investigations/LAB07/SuricataLogs/pcap-analysis/eve.json |
head

TLS metadata may include:

SNI
TLS Version
Certificate Information
Issuer
Subject

Even when traffic is encrypted, metadata remains useful.

31. Create an HTTP Lab Detection Rule

For controlled traffic to your local HTTP server, add a simple rule:

alert http any any -> any any (msg:"GHC LAB HTTP Request Detected"; flow:to_server,established; http.method; content:"GET"; sid:1000002; rev:1;)

Add it to:

/etc/suricata/rules/local.rules

Validate again:

sudo suricata -T -c /etc/suricata/suricata.yaml

32. Generate Controlled HTTP Activity

On CYSA-LINUX01, start:

python3 -m http.server 8080

From CYSA-ANALYST:

curl http://10.10.10.30:8080

Stop the server when finished:

Ctrl + C

Only use this within your isolated lab.

33. Investigate the HTTP Alert

Filter:

sudo jq '
select(
.event_type=="alert" and
.alert.signature=="GHC LAB HTTP Request Detected"
)' /var/log/suricata/eve.json

Identify:

Source IP
Destination IP
Destination Port
HTTP Method
Signature
Timestamp

Now ask:

Is this malicious?

In this lab:

No

It was an expected web request.

This is an example of an accurate detection that does not represent an incident.

34. Understand False Positives

A false positive generally occurs when a detection identifies benign behavior as malicious or undesired security activity.

Example:

Signature:
Suspicious Administrative Tool

Observed Process:
Authorized IT administration

Context:
Approved change window

The detection may technically match, but the activity is authorized.

Analysts must understand the environment before escalating.

35. True Positive vs False Positive

True Positive

Alert generated
      +
Actual malicious / policy-violating activity

False Positive

Alert generated
      +
Benign legitimate activity

True Negative

Benign activity
      +
No alert

False Negative

Malicious activity
      +
No alert

False negatives are particularly dangerous because malicious behavior is missed.

36. Build an Alert Triage Workflow

Use this workflow:

Alert Received
      ↓
Read Signature
      ↓
Identify Source
      ↓
Identify Destination
      ↓
Identify Protocol / Port
      ↓
Check Timestamp
      ↓
Understand Rule Logic
      ↓
Review Related Telemetry
      ↓
Validate with Zeek / PCAP
      ↓
Determine Context
      ↓
True Positive / False Positive
      ↓
Escalate or Close

This workflow is central to SOC operations.

37. Correlate Suricata with Zeek

Suppose Suricata shows:

Source:
10.10.10.10

Destination:
10.10.10.30

Port:
22

Timestamp:
20:10

Search the Zeek conn.log from Lab 06:

grep "10.10.10.30" \
~/CySA-Lab/Investigations/LAB06/ZeekLogs/fresh/conn.log

Now you have:

Suricata
Detection Context
      +
Zeek
Connection Context

38. Correlate Suricata with Wireshark

Use the alert fields:

Timestamp
Source
Destination
Source Port
Destination Port
Protocol

Open the corresponding PCAP in Wireshark.

Use a filter such as:

ip.addr == 10.10.10.10 && ip.addr == 10.10.10.30

For port-specific investigation:

ip.addr == 10.10.10.10 &&
ip.addr == 10.10.10.30 &&
tcp.port == 8080

You can now inspect the packets that caused or surrounded the alert.

39. Build the Evidence Chain

The investigation can progress:

Suricata Alert
      ↓
Signature / Severity
      ↓
Source / Destination
      ↓
Zeek Logs
      ↓
PCAP
      ↓
Endpoint Logs
      ↓
Context
      ↓
Analyst Decision

Each source adds confidence to your assessment.

40. Investigate Alert Frequency

Count alerts:

jq -r '
select(.event_type=="alert") |
.alert.signature
' /var/log/suricata/eve.json |
sort |
uniq -c |
sort -nr

This helps determine which signatures are generating the most detections.

A noisy rule may require:

Investigation
Tuning
Thresholding
Environmental context

41. Identify Top Alerting Source IPs

Run:

jq -r '
select(.event_type=="alert") |
.src_ip
' /var/log/suricata/eve.json |
sort |
uniq -c |
sort -nr

A source generating many alerts may be:

Compromised endpoint
Security scanner
Administrator workstation
Monitoring system
Testing system

Context is required.

42. Identify Alerted Destination Systems

Run:

jq -r '
select(.event_type=="alert") |
.dest_ip
' /var/log/suricata/eve.json |
sort |
uniq -c |
sort -nr

This helps identify systems receiving the most alert-associated traffic.

43. Identify Alerted Destination Ports

Run:

jq -r '
select(.event_type=="alert") |
.dest_port
' /var/log/suricata/eve.json |
sort |
uniq -c |
sort -nr

This may reveal recurring services involved in detections.

44. Investigate fast.log

Suricata may also generate:

fast.log

Check:

sudo tail -n 20 /var/log/suricata/fast.log

This provides compact alert output.

Example structure:

Timestamp
Signature
Classification
Priority
Protocol
Source
Destination

eve.json is richer, but fast.log can be useful for quick review.

45. Create an Alert Triage Table

Build a table for your investigation.

Alert	Source	Destination	Signature	Context	Decision
1	10.10.10.10	10.10.10.30	ICMP Lab Rule	Expected ping	Close
2	10.10.10.10	10.10.10.30:8080	HTTP Lab Rule	Expected curl	Close

In future labs, this table will include genuine suspicious scenarios.

46. Prioritize Alerts

When deciding what to investigate first, consider:

Signature severity
      +
Asset criticality
      +
Source reputation
      +
Destination exposure
      +
Known vulnerabilities
      +
Authentication activity
      +
Threat intelligence
      +
Related endpoint events

A low-severity alert against a critical server can still matter.

A high-severity signature may be benign in a controlled testing environment.

47. Avoid Common Alert-Triage Mistakes

Do not assume:

High Severity = Incident

Do not assume:

IDS Alert = Compromise

Do not close an alert only because:

The source is internal

Do not escalate without asking:

What evidence supports this conclusion?

48. Mission Challenge — IDS Alert Triage

The SOC provides several Suricata alerts involving CYSA-LINUX01.

Investigate the alerts and determine:

1. How many alerts were generated?

2. Which signatures triggered?

3. What were the signature IDs?

4. Which source IP generated the activity?

5. Which system was targeted?

6. Which protocols were involved?

7. Which destination ports were involved?

8. What severity was assigned?

9. What category was assigned?

10. What traffic caused each alert?

11. Does Zeek confirm the communication?

12. Does the PCAP confirm the communication?

13. Does endpoint telemetry support the event?

14. Was the activity authorized?

15. Is each alert a true positive or false positive?

16. Should any alert be escalated?

49. Document Your Findings

Update:

~/CySA-Lab/Investigations/LAB07/investigation-notes.md

Use:

# LAB07 IDS Investigation

## Investigation ID

LAB07-IDS-001

## Alert Summary

Document:
- Timestamp
- Signature
- Signature ID
- Category
- Severity

## Network Information

Document:
- Source IP
- Source port
- Destination IP
- Destination port
- Protocol

## Rule Analysis

Explain what condition caused the rule to match.

## Zeek Correlation

Document corresponding network telemetry.

## PCAP Correlation

Document relevant packet evidence.

## Endpoint Correlation

Document any Windows or Linux telemetry supporting the investigation.

## Context

Determine whether the activity was expected or unauthorized.

## Classification

True Positive / False Positive / Requires Additional Investigation

## Analyst Decision

Escalate / Close / Monitor

## Recommended Actions

Document follow-up actions where appropriate.

50. Analyst Findings

For your controlled environment:

Investigation:
LAB07-IDS-001

Source:
CYSA-ANALYST
10.10.10.10

Destination:
CYSA-LINUX01
10.10.10.30

Alerts:
GHC LAB ICMP Activity
GHC LAB HTTP Request Detected

Suricata Assessment:
Detection rules correctly matched the generated lab traffic.

Zeek Correlation:
Corresponding network connections were observed.

PCAP Correlation:
Packet evidence confirmed the traffic.

Context:
Activity was intentionally generated during the CySA+ laboratory.

Classification:
Detection Valid
Activity Benign / Authorized

Analyst Decision:
Close

Severity:
Informational — Controlled Laboratory Activity

51. Evidence to Capture

Capture:

01-suricata-build-info.png
02-suricata-config-test.png
03-local-rules.png
04-eve-json.png
05-alert-filter.png
06-icmp-alert.png
07-http-alert.png
08-alert-fields.png
09-flow-analysis.png
10-dns-telemetry.png
11-http-telemetry.png
12-tls-telemetry.png
13-alert-frequency.png
14-zeek-correlation.png
15-wireshark-correlation.png
16-alert-triage-table.png
17-analyst-findings.png

52. Validation Checklist

• Suricata was installed and verified

• Suricata configuration was identified

• Rule structure was understood

• Local rule file was identified

• Safe ICMP rule was created

• Suricata configuration was validated

• Existing PCAP was processed

• eve.json was investigated

• Event types were identified

• Alerts were filtered

• Signature fields were analyzed

• Source and destination systems were identified

• Alert severity was investigated

• Controlled ICMP alert was generated

• HTTP detection rule was explored

• Controlled HTTP alert was generated

• Flow telemetry was investigated

• DNS telemetry was reviewed

• HTTP telemetry was reviewed

• TLS metadata was reviewed

• Alert frequency was analyzed

• Alerting source IPs were summarized

• Alerted destinations were summarized

• Alerts were correlated with Zeek

• Alerts were correlated with PCAP evidence

• True-positive and false-positive concepts were applied

• Analyst findings were documented

• Evidence was captured

53. Mission Review

In this mission, you moved from observing network activity to triaging network security detections.

You followed:

Network Activity
       ↓
Suricata Detection Rule
       ↓
IDS Alert
       ↓
Signature Analysis
       ↓
Source / Destination Analysis
       ↓
Zeek Correlation
       ↓
PCAP Validation
       ↓
Endpoint Context
       ↓
True / False Positive Decision
       ↓
Escalate or Close

The key lesson is:

An IDS alert is the beginning of an investigation, not the conclusion.

A strong analyst asks:

Why did this rule trigger?

What traffic caused it?

Is the source expected?

Is the destination critical?

Does other telemetry confirm the activity?

Is the behavior actually malicious?

Skills Developed

After completing this mission, you should be able to:

• understand IDS concepts

• explain Suricata detection logic

• interpret Suricata rules

• process network captures using Suricata

• investigate EVE JSON telemetry

• extract alert fields with jq

• analyze signatures and signature IDs

• interpret alert severity and category

• investigate network flows

• review DNS, HTTP, and TLS telemetry

• generate safe lab detection events

• distinguish an alert from an incident

• understand true and false positives

• perform structured SOC alert triage

• correlate Suricata with Zeek

• validate alerts with Wireshark

• document analyst decisions

What’s Next?

Lab 08 — SIEM Fundamentals and Log Ingestion

You have now investigated telemetry from:

Windows
Linux
Wireshark
Zeek
Suricata

Until now, most of these logs have been investigated separately.

In the next mission, you will introduce a Security Information and Event Management (SIEM) platform and begin centralizing security telemetry.

You will learn how SOC teams bring multiple data sources together so analysts can search and investigate events from one location.

You will work with:

• SIEM architecture

• centralized log collection

• Windows telemetry

• Linux telemetry

• Zeek logs

• Suricata EVE JSON

• timestamps and normalization

• fields and indexes

• security searches

• dashboards

• event ingestion validation

• basic correlation

The investigation model evolves from:

Separate Security Logs

to:

Windows ───────┐
Linux ─────────┤
Zeek ──────────┼──→ SIEM ──→ SOC Analyst
Suricata ──────┘

➡️ Next: Lab 08 — SIEM Fundamentals and Log Ingestion