Top 10 SIEM Use Cases Every Security Team Should Implement

A SIEM without detection rules is a very expensive log storage system. The value of a SIEM is in the correlation rules and alerts that turn raw log data into actionable security intelligence. This guide covers the 10 most impactful detection use cases — with actual rules for Wazuh and Splunk/KQL examples.

Use Case 1: Brute Force Detection

# Alert: 10+ failed logins in 5 minutes from same source IP

# Wazuh rule (local_rules.xml):
# <rule id="100001" level="10" frequency="10" timeframe="300">
#   <if_matched_sid>18100</if_matched_sid>
#   <description>Brute force attack - 10 failures in 5 minutes</description>
# </rule>

# Splunk SPL:
index=windows EventCode=4625
| bucket _time span=5m
| stats count by src_ip, _time
| where count >= 10
| table _time, src_ip, count

Use Case 2: Impossible Travel

# Alert: Same user logged in from two countries within 1 hour

# Microsoft Sentinel KQL:
SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType == "0"  // Successful logins only
| project TimeGenerated, UserPrincipalName, IPAddress, Location
| summarize Locations=makeset(Location), IPs=makeset(IPAddress), Times=makeset(TimeGenerated)
  by UserPrincipalName
| where array_length(Locations) > 1
| mv-expand Location=Locations
| where Location !contains "Unknown"

Use Case 3: Lateral Movement Detection

# Alert: Single source accessing many internal hosts rapidly

# Splunk SPL (SMB lateral movement):
index=windows EventCode=4624 LogonType=3
| bucket _time span=10m
| stats dc(dest) as unique_targets by src, _time
| where unique_targets > 10
| table _time, src, unique_targets

# Wazuh: Rule chain
# Multiple successful network logons (4624) from same source = lateral movement indicator

Use Case 4: Data Exfiltration Detection

# Alert: Large outbound data transfer to external IP

# NetFlow-based detection (Splunk):
index=netflow dest!="10.0.0.0/8" dest!="192.168.0.0/16" dest!="172.16.0.0/12"
| stats sum(bytes) as total_bytes by src, dest
| where total_bytes > 104857600  // 100 MB
| table src, dest, total_bytes

# DNS-based exfiltration (query length anomaly):
index=dns
| eval query_length=len(query)
| where query_length > 50 AND query_length < 200
| stats count dc(query) as unique_queries by src, dest_domain
| where unique_queries > 100

Use Case 5: Ransomware Behavior Detection

# Alert: Mass file extension changes (ransomware encrypting files)

# Sysmon Event ID 11 (FileCreate) - detect bulk file renaming:
# Wazuh + Sysmon rule:
# Alert when: 100+ files renamed/created in 60 seconds by same process

# Splunk SPL:
index=sysmon EventCode=11
| rex field=TargetFilename ".(?P[^.]+)$"
| where extension IN ("encrypted","locked","enc","ransomware","crypted")
| bucket _time span=1m
| stats count by _time, Image, User
| where count > 10

Use Case 6: New Admin Account Creation

# Alert: Administrator account created outside of change window

# Windows Event 4728 (member added to security-enabled global group):
# Splunk:
index=windows (EventCode=4720 OR EventCode=4728)
| where group_name IN ("Administrators","Domain Admins","Enterprise Admins")
| eval day_of_week=strftime(_time, "%A")
| eval hour=strftime(_time, "%H")
| where NOT (day_of_week IN ("Monday","Tuesday","Wednesday","Thursday","Friday") AND hour >= "09" AND hour <= "17")
| table _time, src_user, dest_user, group_name

Use Cases 7-10: Quick Reference

# 7: Credential dumping (LSASS access):
# Event 4656 - handle to lsass.exe from non-SYSTEM process
# Wazuh rule 100060: lsass.exe opened by suspicious process

# 8: Persistence mechanism detection:
# New scheduled task (Event 4698) or service (Event 7045)
# New Run registry key (Sysmon Event 13)
# Alert: Outside of change windows

# 9: Living-off-the-land binaries:
# certutil.exe, mshta.exe, wscript.exe downloading files
# regsvr32.exe loading from network share
# Sysmon Event 3 (network connection) from these processes = alert

# 10: Certificate-based authentication anomaly:
# Service account authenticating from unexpected hostname
# Machine account authenticating interactively
# Event 4768/4769 from unusual source hosts

SIEM Alert Tuning

# Alert fatigue kills SIEM programs:
# Tuning process:
# Week 1: Enable rule, review ALL alerts, identify false positives
# Week 2: Add exclusions for known-good behavior
# Week 3: Reduce threshold or add additional conditions
# Week 4: Rule is tuned - add to production alerting

# Exclusion examples:
# Brute force rule: Exclude IP addresses of your vulnerability scanners
# Lateral movement rule: Exclude your backup agents (they access many hosts)
# Admin account creation rule: Exclude your automated provisioning accounts

Wrap Up

These 10 use cases cover the most common attack patterns seen in real breaches. Start with brute force and impossible travel (quick wins), then add lateral movement and ransomware detection. Each rule needs tuning for your environment — plan two weeks per rule to reduce false positives to an acceptable level. A well-tuned SIEM with 10 good rules is more valuable than a noisy SIEM with 500 untouched rules.