Home > SOC Analysis

Building Detection Rules

Detection rules are the backbone of a SIEM. They convert raw, normalized logs into meaningful security alerts that analysts can act on. A detection rule defines what behavior is suspicious, what patterns indicate an attack, what thresholds matter, and when the SIEM should generate an alert.

This chapter teaches you how to build detection rules the way real SOCs do—deep, practical, and tied to actual logs, attacker behaviors, MITRE techniques, and event sources.

Understanding How Detection Rules Work

A detection rule is a logical condition built on:

  • Fields (src_ip, username, process_name, event_code)

  • Patterns (encoded PowerShell, new admin user, SMB traffic)

  • Thresholds (X failed logins in Y minutes)

  • Sequences (event A followed by event B)

  • Time windows (within 10 min)

  • Context (user role, asset value, threat intel)

  • Event relationships (same IP, same user)

A rule triggers when its conditions match one or more logs.

Components of a Detection Rule

Every detection rule has:

1. Scope (Which logs?)

Specify data sources used:

  • Windows logs

  • Sysmon

  • Linux

  • Firewall

  • EDR

  • Cloud logs

2. Logic (What to detect?)

Conditions using fields:

process_name = "powershell.exe"
event.code = 4625
src_ip in threat_intel.blacklist

3. Thresholds

Example:

failed_logons > 10 in 3 minutes

4. Time Window

How far back the SIEM should look:

10 minutes
1 hour
24 hours

5. Severity Level

Based on risk, impact, and asset criticality.

6. Alert Output

What the SOC sees:

  • Summary

  • User

  • Host

  • MITRE technique

  • Related logs

Rule Building Strategy

Detection rules must align with attacker behavior, not just single events.
Use MITRE ATT&CK tactics as a baseline.

Examples:

  • Initial Access → detect phishing, brute force

  • Execution → detect PowerShell abuse

  • Persistence → detect scheduled tasks

  • Credential Access → detect LSASS reads

  • Lateral Movement → detect remote logins

  • Exfiltration → detect large outbound traffic

You build rules based on how attackers truly behave.

Practical Detection Rule Examples (Full Depth)

Below are real, enterprise-grade detection rules used in SOCs.

1. Brute Force Attack Detection (Windows + Linux)

Raw logs

4625 - Failed logon
sshd: Failed password for root

Detection logic

IF failed_logon_count >= 10
AND same_source_ip
AND within 3 minutes
THEN trigger Brute Force Alert

Example rule output

ALERT: Brute Force Attempt
IP: 185.33.11.20
User: root/admin

2. Suspicious PowerShell Execution (Sysmon)

Raw log

Sysmon Event ID 1: parent=WINWORD.EXE → powershell.exe -enc <Base64>

Detection logic

IF process_name = powershell.exe
AND commandline contains "-enc"
AND parent_process = winword.exe
THEN possible macro-powered malware

This rule catches 90% of macro-based attacks.

3. Credential Dumping (LSASS Access)

Raw logs

Sysmon Event ID 10: process_access LSASS.exe

Detection logic

IF target_process = lsass.exe
AND access_granted = true
AND process_name != "lsm.exe" AND "winlogon.exe"
THEN alert: Credential Dump Attempt

Catches Mimikatz-like behavior.

4. Lateral Movement (SMB + Remote Execution)

Logs involved:

  • Windows event 4624 (logon type 3)

  • Sysmon 3 (network connection)

  • Sysmon 1 (remote execution)

Detection logic

IF logon_type = 3
AND destination_host != usual_hosts_for_user
AND SMB connection established
AND remote command executed
→ Possible Lateral Movement

5. Persistence via Scheduled Task

Raw logs

Sysmon Event ID 1: schtasks.exe
Sysmon Event ID 13: registry write under HKLM\Software\Microsoft\Windows\CurrentVersion\Run

Detection logic

IF process_name=schtasks.exe
AND new task created
THEN alert: Persistence Mechanism Created

6. Data Exfiltration (Firewall + Server Logs)

Raw firewall log:

Outbound connection 2.3GB to 91.22.119.22

Detection logic

IF outbound_bytes >= 1GB
AND destination_ip not in approved_list
→ Exfiltration Suspicion

7. Cloud Privilege Escalation (AWS)

Raw CloudTrail logs:

CreateUser
AttachPolicy (AdminAccess)
CreateAccessKey

Detection logic

IF policy = AdminAccess
AND new access keys created
AND user not in admin_group
→ Cloud PrivEsc Attack

8. Suspicious DNS Queries

Logs:

DNS request to base64-like domain or algorithmically generated domain

Rule logic

IF domain_pattern matches DGA
OR unusually high DNS request volume
→ Possible C2 Communication

How to Build Strong Rules (Professional Method)

1. Start with MITRE technique

Example:

T1059.001 PowerShell

2. Identify logs that contain evidence

Example:

  • Sysmon ID 1

  • PowerShell script block logs

  • EDR process logs

3. Extract fields

process_name
command_line
parent_process

4. Define suspicious behavior

encoded command
bypass flags
unexpected parent process

5. Create detection logic

Combine fields, thresholds, and time windows.

What Makes a Good Detection Rule?

A strong rule is:

  • Specific

  • Based on attacker behavior

  • Low false positive

  • High accuracy

  • Tied to MITRE ATT&CK

  • Correlates multiple log sources

  • Enriched with threat intel

  • Actionable for SOC analysts

Example of a good rule:

Suspicious PowerShell encoded command launched by Office application

Example of a bad rule:

Alert anytime PowerShell runs

Too many false positives.

Detection Rule Testing

Before deploying a rule:

  • Test against real logs

  • Use red-team simulations

  • Replay attack traffic

  • Validate with real-world malware samples

  • Tune thresholds

  • Remove noisy patterns

Example test:

Run Mimikatz → verify LSASS rule fires
Open Word macro → verify PowerShell rule fires

Real Attack Chain Example (Complete Rule Pipeline)

Attacker sends phishing email → user opens doc → macro runs → PowerShell spawns → downloads payload → outbound C2 → privilege escalation → lateral movement.

Detection rules firing sequence:

  1. Email Rule → risky attachment

  2. Execution Rule → powershell.exe -enc

  3. Download Rule → suspicious web request

  4. C2 Rule → outbound IP reputation hit

  5. LSASS Rule → credential dumping

  6. Lateral Movement Rule → remote logon activity

This becomes a Critical SIEM Alert via correlation.

Intel Dump

  • Detection rules define suspicious behavior to generate alerts.

  • Rules use fields, thresholds, patterns, time windows, and event sequences.

  • MITRE ATT&CK provides structure for building behavior-based rules.

  • Examples include brute force, PowerShell abuse, credential dumping, lateral movement, and exfiltration.

  • Good rules avoid noise, use correlation, and rely on clear attacker techniques.

  • Detection rule testing validates accuracy and reduces false positives.

HOME LEARN COMMUNITY DASHBOARD