"Lab 09 — SIEM Detection and Correlation Lab"

Mission Information

Item	Details
Lab	09
Lab Name	SIEM Detection and Correlation Lab
Track	CompTIA CySA+
Difficulty	Intermediate
Estimated Time	120–150 minutes
Primary Role	Cybersecurity Analyst / SOC Analyst
Environment	CySA+ SOC / SIEM Lab
Primary Systems	SIEM + Windows Endpoint + Linux Server + Zeek + Suricata
Skills	Detection Engineering, Event Correlation, Threshold Detection, Alert Triage, False-Positive Reduction

Mission Scenario

You are working as a Cybersecurity Analyst at GHC Enterprise.

Your SIEM is now ingesting telemetry from:

Windows
Linux
Zeek
Suricata

Centralized visibility is useful, but manually searching thousands of events is not enough.

The SOC needs the SIEM to automatically identify suspicious patterns.

For example:

One failed login

may simply represent a user typing the wrong password.

But:

10 Failed Logins
        ↓
Successful Login
        ↓
Privileged Activity

is much more interesting.

Your task is to create and test SIEM detections that identify patterns such as:

• repeated authentication failures

• successful authentication after failures

• suspicious PowerShell execution

• unusual privileged activity

• IDS alerts associated with endpoint events

• network activity followed by authentication

You will then tune those detections to reduce unnecessary alerts.

Mission Objective: Build, validate, and tune SIEM detections that transform security telemetry into actionable SOC alerts.

Mission Objectives

By completing this lab, you will be able to:

• understand detection engineering fundamentals

• distinguish events, detections, alerts, and incidents

• create search-based detections

• detect repeated authentication failures

• use thresholds and time windows

• correlate failed and successful authentication

• detect suspicious process activity

• correlate endpoint and network telemetry

• correlate Suricata alerts with host activity

• assign alert severity

• test detection logic

• investigate generated alerts

• identify false positives

• tune noisy detections

• document detection logic and analyst findings

1. From Telemetry to Detection

Your SIEM currently receives events such as:

4624 — Successful Windows logon
4625 — Failed Windows logon
4688 — Windows process creation

Linux SSH authentication
Linux sudo activity

Zeek network connections

Suricata IDS alerts

Without detection logic:

Telemetry
   ↓
Manual Search
   ↓
Analyst

With detection logic:

Telemetry
   ↓
Detection Rule
   ↓
Pattern Match
   ↓
Alert
   ↓
SOC Analyst

Detection engineering helps the SOC focus attention on activity most likely to matter.

2. Event vs Detection vs Alert vs Incident

Understand these terms clearly.

Event

A record describing activity.

Example:

Failed login

Detection

Logic used to identify activity of interest.

Example:

More than 5 failed logins
from the same source
within 5 minutes

Alert

Generated when detection conditions are satisfied.

Incident

A security event or collection of events determined to require formal response.

The relationship is:

Event
  ↓
Detection Logic
  ↓
Alert
  ↓
Investigation
  ↓
Incident?

Not every alert becomes an incident.

3. Detection Engineering Principles

A useful detection should answer:

What behavior are we detecting?

Which telemetry supports it?

Which fields are required?

What threshold is appropriate?

What time window should be used?

What severity should be assigned?

What legitimate behavior could trigger it?

How will analysts investigate it?

Detection creation without investigation context often leads to noisy SOC environments.

4. Start the Lab Environment

Start:

CYSA-SIEM
10.10.10.40

CYSA-ANALYST
10.10.10.10

CYSA-WIN01
10.10.10.20

CYSA-LINUX01
10.10.10.30

Verify that your SIEM agents and telemetry sources are connected.

You should have data from:

Windows
Linux
Zeek
Suricata

5. Create the Investigation Workspace

On CYSA-ANALYST:

mkdir -p ~/CySA-Lab/Investigations/LAB09/{Detections,Screenshots,Findings}

Create notes:

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

Use:

Investigation ID:
LAB09-DETECT-001

6. Validate SIEM Data Before Building Detections

Before writing detection logic, verify the required telemetry exists.

Search for Windows failed authentication:

4625

Search for successful Windows authentication:

4624

Search Linux:

Failed password
Accepted password
sudo

Search Suricata alerts.

Search Zeek connections.

If the underlying telemetry is missing, detection logic cannot work correctly.

7. Detection 01 — Repeated Windows Authentication Failures

Your first use case:

Detect multiple failed Windows authentication attempts involving the same account or source within a short period.

Relevant telemetry:

Windows Security Event ID:
4625

Detection concept:

Event ID 4625
       +
Same User or Source
       +
5 or More Events
       +
5 Minute Window
       =
Authentication Failure Alert

8. Create the Base Search

Search only:

4625

Filter to:

CYSA-WIN01

Review fields representing:

Timestamp
Account
Source IP
Logon Type
Failure Reason

Your SIEM field names will depend on its normalization model.

9. Generate Controlled Failed Authentication

On your own CYSA-WIN01 lab VM, generate several incorrect password attempts manually.

For example:

5 controlled failures

Then authenticate normally.

Do not automate password guessing.

Wait until events reach the SIEM.

10. Aggregate Authentication Failures

Group failed authentication events by:

Account

or:

Source IP

Then count events inside a defined window.

For example:

User: analyst01
Failures: 5
Window: 5 minutes

The detection condition becomes:

Failures >= 5
within 5 minutes

11. Create the Authentication Failure Detection

Create a detection using the equivalent functionality provided by your SIEM.

Use:

Detection Name:
Repeated Windows Authentication Failures

Data Source:
Windows Security

Event:
4625

Threshold:
5

Window:
5 minutes

Assign initial severity:

Medium

Save the detection.

12. Validate Detection 01

Generate another controlled set of failed authentication events.

Confirm:

Events Generated
      ↓
SIEM Ingests Events
      ↓
Threshold Reached
      ↓
Detection Fires
      ↓
Alert Generated

Record:

Alert Timestamp
User
Source
Destination
Number of Failures
Detection Name
Severity

13. Investigate the Generated Alert

Do not stop at:

Detection worked.

Investigate:

Which user?

Which endpoint?

Which source?

How many failures?

Which logon type?

Was the activity expected?

Did a successful login occur afterward?

This turns detection testing into an analyst exercise.

14. Detection 02 — Linux SSH Authentication Failures

Now build an equivalent detection for Linux.

Relevant telemetry:

Failed password

Detection concept:

SSH Authentication Failure
         +
Same Source
         +
Multiple Attempts
         +
Short Time Window
         =
Potential SSH Authentication Attack

15. Generate Linux Authentication Failures

From CYSA-ANALYST:

ssh <username>@10.10.10.30

Enter an incorrect password several times manually.

Terminate the connection.

Verify the events appear in the SIEM.

16. Create the Linux Detection

Use:

Detection Name:
Repeated Linux SSH Authentication Failures

Source:
CYSA-LINUX01

Event:
Failed SSH authentication

Threshold:
5

Window:
5 minutes

Severity:
Medium

Use the correct parsed field names available in your SIEM.

17. Compare Windows and Linux Detections

You now have:

Windows 4625
      ↓
Windows Authentication Detection

and:

Linux SSH Failure
      ↓
Linux Authentication Detection

But both represent essentially the same security behavior:

Repeated authentication failure.

This demonstrates why normalization is useful.

18. Detection 03 — Successful Login After Repeated Failures

This detection is more valuable because it correlates multiple event types.

Scenario:

Multiple Failed Logins
          ↓
Successful Authentication

This can indicate:

• user eventually remembered the password

• administrator troubleshooting

• password guessing followed by compromise

• credential attack followed by successful access

Context determines the outcome.

19. Build the Correlation Logic

The detection concept is:

5+ Failed Authentication Events
             ↓
Same User / Source
             ↓
Successful Authentication
             ↓
Within 10 Minutes
             =
Higher-Priority Alert

Relevant Windows events:

4625
+
4624

Relevant Linux telemetry:

Failed password
+
Accepted password

20. Generate the Correlated Activity

On one controlled lab endpoint:

1. Generate several failed authentication attempts.

2. Wait briefly.

3. Authenticate successfully.

Verify all events arrive in the SIEM.

Your sequence should resemble:

20:01 — Failure
20:01 — Failure
20:02 — Failure
20:02 — Failure
20:03 — Failure
20:04 — Success

21. Create Detection 03

Use:

Detection Name:
Successful Authentication After Repeated Failures

Suggested severity:

High

because this pattern is generally more interesting than failed attempts alone.

Detection logic should include:

Multiple Authentication Failures
+
Successful Authentication
+
Same Account or Source
+
Short Time Window

22. Why Correlation Improves Detection Quality

Consider:

Alert A:
5 Failed Logins

versus:

Alert B:
5 Failed Logins
      ↓
Successful Login

Alert B provides more meaningful context.

Correlation can reduce the analyst workload by detecting behavioral sequences instead of isolated events.

23. Detection 04 — Privileged Activity After Authentication

Now extend the sequence.

Windows example:

Authentication
      ↓
4672
Special Privileges Assigned

Linux example:

SSH Login
      ↓
sudo

The pattern becomes:

Repeated Failures
      ↓
Successful Login
      ↓
Privilege Activity

This should receive greater analyst attention.

24. Generate Linux Privileged Activity

After successfully connecting to your Linux lab system:

sudo whoami

Then:

sudo systemctl status ssh

Verify the sudo telemetry reaches the SIEM.

25. Correlate Authentication and Privilege Activity

Build a search or investigation timeline showing:

Authentication failures
       ↓
Successful authentication
       ↓
sudo activity

Ask:

Was the same account involved?

Did privilege use happen immediately afterward?

Was the privileged action expected?

26. Detection 05 — Suspicious PowerShell Execution

Windows PowerShell is widely used for legitimate administration.

It can also appear during attacker activity.

Relevant telemetry may include:

4688
PowerShell Operational Logs
4104

The objective is not to alert simply because PowerShell starts.

That would create excessive noise.

27. Generate Safe PowerShell Activity

On CYSA-WIN01:

whoami

Then:

Get-Process

Then:

Get-NetIPAddress

Verify the process and PowerShell events reach your SIEM.

28. Search PowerShell Telemetry

Search for:

powershell.exe

Review fields such as:

User
Host
Parent Process
Command Line
Timestamp

Also inspect Event ID:

4104

if Script Block Logging is available.

29. Build a PowerShell Detection

Instead of:

PowerShell executed

use additional context.

Example concept:

PowerShell
     +
Unexpected User
     OR
Unusual Parent Process
     OR
Suspicious Command Pattern
     =
Investigation Alert

For this introductory lab, create a simple informational detection for PowerShell execution, then observe how noisy it becomes.

30. Experience Detection Noise

Create:

Detection Name:
PowerShell Execution Observed

Generate normal administrative PowerShell activity.

Notice how easily the alert can trigger during legitimate work.

This introduces an important lesson:

A technically correct detection can still be operationally poor.

31. Tune the PowerShell Detection

Improve your rule by adding context.

For example, exclude known expected activity or increase severity only when additional conditions are present.

Potential contexts include:

Unexpected endpoint
Unexpected account
Unusual parent process
Execution outside expected hours
Encoded command indicators
Network activity immediately afterward

Do not rely on one field alone.

32. Detection 06 — Suricata Alert Correlation

Your SIEM already receives Suricata alerts.

Instead of investigating every IDS alert independently, correlate them with additional events.

Example:

Suricata Alert
      ↓
Same Source IP
      ↓
Endpoint Authentication Event
      ↓
Within 5 Minutes

This can provide stronger context.

33. Generate a Controlled Suricata Alert

Use the safe ICMP or HTTP lab rule created in Lab 07.

For example:

ping -c 4 10.10.10.30

Verify:

GHC LAB ICMP Activity

appears in the SIEM.

34. Search Related Events

Pivot on:

10.10.10.10

Look for:

Suricata Alert
Zeek Connection
Linux Authentication

within the same time window.

Your timeline may resemble:

20:20 Suricata Alert
20:21 Zeek Connection
20:22 Linux SSH Failure
20:23 Linux SSH Success

35. Build a Multi-Source Correlation

Concept:

Network Alert
     +
Network Connection
     +
Authentication Activity
     =
Higher Investigation Confidence

This is where SIEM correlation becomes substantially more useful than isolated alerting.

36. Detection 07 — Network Connection Followed by Authentication

Using Zeek and Linux logs, detect:

Connection to TCP/22
       ↓
SSH Authentication
       ↓
Same Source / Destination
       ↓
Short Time Window

This may seem obvious, but it teaches cross-source field correlation.

Useful fields include:

Source IP
Destination IP
Destination Port
Timestamp
Host
Username

37. Detection Thresholds

Thresholds determine how much activity is required before alerting.

Example:

1 failed login

would generate excessive alerts.

Instead:

5 failures in 5 minutes

might be more useful.

But:

500 failures in 24 hours

may detect very different behavior.

Threshold selection changes the behavior your rule detects.

38. Time Windows Matter

Compare:

5 failures within 1 minute

with:

5 failures within 24 hours

The first suggests rapid activity.

The second may represent normal mistakes.

Detection logic must consider:

Count
+
Time
+
Context

39. Understand Detection Sensitivity

A highly sensitive rule detects more activity:

Low Threshold
      ↓
More Alerts

But often creates:

More False Positives

A restrictive rule:

High Threshold
      ↓
Fewer Alerts

but can risk:

Missed Activity

The goal is balance.

40. False Positives

Example:

10 Failed Logins

may trigger your authentication rule.

Investigation shows:

User changed password recently
Old credentials stored in application
Application repeatedly attempted authentication

The detection worked correctly.

But the activity may not represent an attack.

This is where analyst context matters.

41. Detection Tuning

Tuning may include:

Adjust Threshold
Change Time Window
Exclude Known Scanner
Exclude Service Account
Limit Detection to Critical Systems
Add Additional Context
Change Severity

Never suppress activity without understanding why it occurs.

42. Build a Detection Inventory

Create a simple detection inventory.

ID	Detection	Data Source	Severity
DET-001	Windows Authentication Failures	Windows	Medium
DET-002	Linux SSH Failures	Linux	Medium
DET-003	Success After Failures	Windows/Linux	High
DET-004	Privilege After Login	Windows/Linux	High
DET-005	PowerShell Execution	Windows	Low
DET-006	IDS + Authentication	Suricata + Endpoint	High
DET-007	Network + Authentication	Zeek + Linux	Medium

This provides basic detection governance.

43. Map Detections to MITRE ATT&CK

Map observed behaviors where appropriate.

Detection	Possible ATT&CK Context
Repeated login failures	Brute Force
Successful login	Valid Accounts
PowerShell execution	Command and Scripting Interpreter
sudo / privileged activity	Privilege-related activity
Remote SSH	Remote Services
Network discovery behavior	Network Service Discovery

MITRE ATT&CK provides a common vocabulary.

It does not prove attacker intent.

44. Assign Alert Severity

A simple severity model might be:

Low
Informational or weak signal

Medium
Suspicious behavior requiring review

High
Strong multi-event pattern

Critical
Confirmed or highly credible severe activity

For example:

5 Failed Logins:
Medium

versus:

5 Failures
+
Successful Login
+
Privilege Activity:
High

45. Build an Alert Investigation Workflow

For every generated detection:

Alert
  ↓
Validate Source Telemetry
  ↓
Identify User / Host / IP
  ↓
Review Previous Events
  ↓
Review Following Events
  ↓
Check Network Context
  ↓
Check Endpoint Context
  ↓
Determine Expected Behavior
  ↓
True Positive / False Positive
  ↓
Escalate / Close

46. Test Detection Reliability

A detection should be tested against at least two conditions.

Positive Test

Generate activity expected to trigger it.

Expected:
Alert generated

Negative Test

Generate normal behavior that should not trigger it.

Expected:
No alert

This helps validate that the rule behaves as intended.

47. Detection Validation Table

Create:

Detection	Positive Test	Negative Test	Result
DET-001	5 failed logins	1 failed login	Pass
DET-002	5 SSH failures	Normal SSH login	Pass
DET-003	Failures + success	Success only	Pass
DET-005	PowerShell activity	Non-PowerShell process	Review

Rules generating unexpected results require tuning.

48. Investigate Alert Clustering

Suppose the SIEM generates:

Authentication Failure Alert

Successful Login After Failures Alert

Privilege Activity Alert

Suricata Alert

all involving:

10.10.10.10

within five minutes.

These should not necessarily be treated as four unrelated cases.

They may represent one investigation cluster.

Multiple Alerts
      ↓
Same User / Host / IP / Time
      ↓
Single Investigation

49. Build a Correlated Incident Timeline

Example:

Time	Source	Event
20:01	Suricata	Network alert
20:01	Zeek	Connection to TCP/22
20:02	Linux	SSH failure
20:02	Linux	SSH failure
20:03	Linux	SSH failure
20:04	Linux	Successful SSH login
20:05	Linux	sudo execution
20:06	SIEM	Correlation alert

This is the type of timeline analysts use to understand multi-stage behavior.

50. Detection Documentation

Every detection should have documentation.

Create:

~/CySA-Lab/Investigations/LAB09/Detections/

For each detection, record:

Detection ID

Detection Name

Purpose

Data Sources

Required Fields

Logic

Threshold

Time Window

Severity

MITRE ATT&CK Mapping

Expected False Positives

Investigation Steps

Response Recommendation

51. Example Detection Documentation

## DET-003 — Successful Authentication After Repeated Failures

### Purpose

Identify accounts that successfully authenticate after multiple failures.

### Data Sources

Windows Security Logs
Linux Authentication Logs

### Logic

Five or more failed authentication events followed by successful authentication for the same user or source within ten minutes.

### Severity

High

### Possible False Positives

User repeatedly entering an incorrect password before remembering the correct credential.

### Investigation

Review:
- source IP
- account
- affected host
- authentication type
- subsequent processes
- privilege activity
- network connections

### ATT&CK Context

Brute Force
Valid Accounts

52. Mission Challenge — Multi-Stage Detection

The SOC reports several correlated alerts involving CYSA-LINUX01.

Using the SIEM, determine:

1. Which detection triggered first?

2. Which source IP generated the activity?

3. Which account was targeted?

4. How many authentication failures occurred?

5. Over what time period?

6. Was authentication eventually successful?

7. Did the successful login originate from the same source?

8. Was privileged activity observed afterward?

9. Did Zeek observe the network session?

10. Did Suricata generate a related alert?

11. Which events should be treated as part of one investigation?

12. Which ATT&CK techniques describe the behavior?

13. Which detection produced the strongest signal?

14. Were any detections noisy?

15. Should the event be escalated?

53. Document Your Findings

Update:

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

Use:

# LAB09 Detection Investigation

## Investigation ID

LAB09-DETECT-001

## Alerts

Document all detections generated during the investigation.

## Source

Document:
- IP
- Host
- User

## Authentication Activity

Document:
- failed attempts
- threshold
- successful login
- time window

## Privilege Activity

Document privileged activity following authentication.

## Network Evidence

Document:
- Zeek connections
- Suricata alerts

## Detection Correlation

Identify which alerts are related.

## Timeline

Construct the complete sequence.

## Detection Quality

For each detection, determine:
- useful
- noisy
- needs tuning
- missed expected behavior

## Assessment

Determine whether the activity appears expected, suspicious, or malicious.

## Analyst Decision

Escalate / Close / Continue Investigation

## Tuning Recommendations

Document any threshold, exclusion, or correlation improvements.

54. Analyst Findings

A controlled lab assessment may resemble:

Investigation:
LAB09-DETECT-001

Source:
CYSA-ANALYST
10.10.10.10

Target:
CYSA-LINUX01
10.10.10.30

Detected Sequence:
Multiple SSH authentication failures
        ↓
Successful SSH authentication
        ↓
Privileged sudo activity

Network Evidence:
Zeek confirmed the SSH connection.

IDS Evidence:
Related Suricata lab telemetry was present.

SIEM Correlation:
Multiple security events were successfully grouped into one investigation timeline.

Assessment:
Activity was intentionally generated during the laboratory.

Detection Result:
Correlation logic successfully identified the multi-stage sequence.

Real-World Interpretation:
The same pattern from an unauthorized source would warrant immediate investigation and potentially containment.

Severity:
High Pattern — Controlled Laboratory Activity

55. Evidence to Capture

Capture:

01-siem-data-validation.png
02-windows-failure-detection.png
03-linux-ssh-detection.png
04-threshold-rule.png
05-success-after-failures.png
06-privilege-correlation.png
07-powershell-detection.png
08-powershell-tuning.png
09-suricata-correlation.png
10-zeek-correlation.png
11-detection-inventory.png
12-attack-mapping.png
13-alert-clustering.png
14-correlated-timeline.png
15-detection-validation.png
16-detection-documentation.png
17-analyst-findings.png

56. Validation Checklist

• SIEM telemetry was validated before detection creation

• Detection engineering concepts were understood

• Windows authentication-failure detection was created

• Linux SSH failure detection was created

• Detection thresholds were tested

• Time windows were applied

• Successful login after failures was correlated

• Privileged activity was correlated

• PowerShell telemetry was investigated

• PowerShell detection was created

• Detection noise was observed

• Detection tuning was performed

• Suricata alert correlation was tested

• Zeek network correlation was tested

• Multi-source correlation was performed

• Alert severity was assigned

• Detections were mapped to ATT&CK where appropriate

• Positive detection tests were completed

• Negative tests were completed

• Alert clustering was understood

• Correlated incident timeline was built

• Detection inventory was created

• Detection documentation was created

• Analyst findings were documented

• Evidence was captured

57. Mission Review

In this lab, your SIEM evolved from a centralized search platform into a security detection platform.

You moved from:

Security Events
      ↓
Manual Search

to:

Security Events
      ↓
Detection Rules
      ↓
Thresholds
      ↓
Correlation
      ↓
Alerts
      ↓
Investigation

You also learned that effective detections are rarely built from a single event.

The strongest investigation context often comes from:

Identity
   +
Endpoint
   +
Network
   +
IDS
   +
Time
   =
Correlated Detection

The key lesson is:

Detection engineering is not about generating the most alerts. It is about generating the right alerts with enough context for analysts to make good decisions.

Skills Developed

After completing this mission, you should be able to:

• understand detection engineering fundamentals

• create search-based SIEM detections

• create threshold-based detections

• detect repeated authentication failures

• correlate failures with successful authentication

• correlate privilege activity

• investigate suspicious process activity

• build PowerShell detection logic

• identify noisy detections

• tune detection thresholds

• correlate endpoint and network telemetry

• correlate Suricata and Zeek telemetry

• assign alert severity

• perform positive and negative detection testing

• cluster related alerts

• map detections to MITRE ATT&CK

• document detection logic

• build correlated investigation timelines

What’s Next?

Lab 10 — Authentication Attack Investigation

You have now created detections capable of identifying suspicious authentication behavior.

In the next mission, you will use those detections to conduct a deeper identity and authentication investigation.

You will investigate patterns such as:

• repeated login failures

• brute-force indicators

• password spraying patterns

• account targeting

• source-IP analysis

• successful authentication after failures

• unusual logon types

• remote authentication

• privileged-account activity

• authentication timelines

• identity-based indicator pivoting

• SIEM correlation

• analyst escalation decisions

The focus shifts from:

Can the SIEM detect suspicious authentication?

to:

What actually happened to the account?

➡️ Next: Lab 10 — Authentication Attack Investigation