SIEM Use Cases: 10 Every SOC Runs (With Detection Logic)
SIEM use cases explained with detection logic sketches, data sources, and tuning notes for the 10 detections every SOC team operates.
SIEM use cases are the core detection units of any Security Operations Center: each one defines a threat behavior, the log sources that expose it, and the logic that fires an alert when it appears. SIEM use cases span several categories (threat detection, compliance and audit, cloud monitoring, and insider threat), but this guide focuses on the detection scenarios an analyst actually triages. The ten use cases below cover the detections that virtually every SOC team runs on day one, with illustrative logic sketches and the false positive sources that will consume your tuning time.
The ten use cases covered here:
- Brute Force and Password Spray
- Impossible Travel
- Privilege Escalation
- Log Source Went Silent
- Malware Beaconing and C2 Traffic
- Data Exfiltration Volume Anomaly
- Lateral Movement via SMB and RDP
- Suspicious PowerShell and LOLBins
- Account Created Then Immediately Privileged
- Off-Hours Admin Activity
The Reference Table
Before the deep-dives, here is a summary view of all ten use cases for quick reference:
| Use Case | Primary Data Sources | Difficulty to Tune |
|---|---|---|
| Brute Force / Password Spray | Windows Security (4625, 4648), Linux auth logs, LDAP | Medium — volume thresholds vary widely by environment |
| Impossible Travel | Identity provider, VPN, SSO logs | Medium — VPN/proxy users generate constant noise |
| Privilege Escalation | Windows Security (4672, 4728, 4732), Linux sudo logs | Low to Medium — service accounts add FP volume |
| Log Source Went Silent | SIEM health metrics, heartbeat events | Low to write, Medium to operationalize |
| Malware Beaconing / C2 | DNS, Proxy/Web gateway, Firewall, NDR | High — legitimate software uses similar intervals |
| Data Exfiltration Volume | DLP, Proxy, Cloud CASB, Email gateway | High — backup jobs, cloud sync, dev uploads dominate |
| Lateral Movement (SMB/RDP) | Windows Security (4624, 4648), NetFlow, XDR telemetry | Medium — IT ops tools create constant noise |
| Suspicious PowerShell / LOLBins | Windows Sysmon (Event 1, 7, 10), Script Block Logging | Medium — admin scripts and automation trigger constantly |
| Account Created Then Privileged | Windows Security (4720, 4728, 4732), Azure AD audit | Low — easy to write, easy to tune with change window filters |
| Off-Hours Admin Activity | Windows Security, VPN, Privileged Access Management logs | High — global teams, on-call engineers, overnight jobs |
1. Brute Force and Password Spray
What it detects: A high volume of authentication failures against one or many accounts, indicating an attacker testing credentials at scale.
Brute force targets a single account with many passwords. Password spray inverts this: one password tested across many accounts. SIEM detection logic typically differentiates the two by grouping failure counts by username (brute force) or by source IP across multiple usernames (password spray).
The canonical Windows events are Event ID 4625 (failed login) and Event ID 4648 (explicit credential use). Linux logs the equivalent in /var/log/auth.log via sshd or PAM. For cloud identity, you need Azure AD Sign-in logs or Okta System Log.
Below is a Sigma-style detection sketch for password spray. This is an illustrative example — adapt field names and thresholds to your environment:
# Illustrative Sigma-style sketch — not production-ready as-is
title: "Multiple Failed Logons Followed by Success"
status: experimental
logsource:
product: windows
service: security
detection:
selection:
EventID: 4625
LogonType: 3
condition: selection
timeframe: 10m
groupby:
- SubjectUserName
having:
distinct_count_TargetUserName: '>= 10'
falsepositives:
- Vulnerability scanners
- Misconfigured service accounts
level: mediumTuning pain points: Vulnerability scanners (Nessus, Qualys, Tenable) generate authentication noise that looks identical to a password spray. Backup agents and monitoring services that store credentials also fire this rule repeatedly. Scope the rule to sensitive targets (domain controllers, VPN gateways, mail servers) and add exclusions for known scanner source IPs from day one.
2. Impossible Travel
What it detects: A user authenticating from two geographically distant locations within a time window too short to physically travel between them.
A login from London at 09:00 UTC followed by a login from São Paulo at 09:45 UTC is physically impossible. This pattern is a strong indicator of stolen credentials, session token theft, or account sharing.
The data source is your identity provider's authentication log: Azure AD, Okta, PingFederate, or on-premises AD with geographic enrichment. Raw auth logs rarely include geolocation, so you need IP-to-geo enrichment either in a SIEM lookup table or via a threat intelligence feed.
Tuning pain points: This is the rule that VPN kills. When your users authenticate through a corporate VPN exit node in a different country from their physical location, every login appears to originate from that exit node's geography. Cloud-hosted desktops (Azure Virtual Desktop, Citrix) cause the same pattern. Before you can tune this rule meaningfully, you need a list of every VPN egress IP and proxy exit node in your environment mapped to its geographic label, then add those as exclusion entries or normalize the IP before the geo-lookup.
Note
Impossible travel is one of the clearest examples of why detection logic that works on paper fails in production without environment context. The rule is simple. The enrichment and the exclusion set are where the real work lives.
Practicing alert triage on impossible-travel alerts is one of the fastest ways to internalize how SIEM enrichment affects your verdict. The same raw event looks entirely different when you have the VPN egress context versus when you do not.
3. Privilege Escalation
What it detects: A user or process gaining elevated privileges, either through legitimate means at an unusual time, or through unauthorized changes to group membership or token manipulation.
The Windows audit trail for privilege escalation centers on three event IDs: 4672 (special privileges assigned at logon), 4728 (member added to security-enabled global group), and 4732 (member added to security-enabled local group). On Linux, sudo escalation is captured in /var/log/auth.log and journald.
Tuning pain points: Service accounts assigned privileged roles for legitimate purposes fire this rule continuously. Software deployment pipelines, patch management agents, and IT automation tools add accounts to admin groups as part of normal operation. The most effective tuning strategy is to baseline which accounts are expected to generate 4672 events regularly and exclude them by account name or SID, then alert on anything outside that expected set.
4. Log Source Went Silent
What it detects: A log source (firewall, endpoint agent, domain controller, server) that stops sending events to the SIEM, which may indicate a logging failure, a disabled agent, or an attacker disabling logging as part of an intrusion.
This is a meta-detection: it monitors the health of your visibility layer rather than monitoring user or network activity. A silent log source means blind spots you may not know you have until an incident is already underway.
Most SIEMs implement this through a heartbeat or summary event that each agent sends on a regular interval. The detection fires when a source that previously sent events goes quiet for longer than the expected interval plus a tolerance window.
Tuning pain points: Server maintenance windows, planned agent upgrades, and cloud-instance shutdowns all cause expected log silence. Without a change-management integration that communicates planned downtime to the SIEM, this rule fires constantly during routine operations. Integration with your ITSM (ServiceNow, Jira) to suppress alerts during approved change windows dramatically reduces noise.
5. Malware Beaconing and C2 Traffic
What it detects: An endpoint making periodic, low-volume outbound connections to an external destination at regular intervals, which is the signature pattern of malware maintaining contact with a command-and-control server.
Beaconing is characterized by regularity: the same destination, the same approximate byte count, at the same time interval, whether that interval is every 30 seconds or every 12 hours. DNS-based C2 adds another pattern: unusually long or encoded subdomain strings. The MITRE ATT&CK technique T1071 documents the full spectrum of C2 communication protocols.
Here is a KQL-style sketch for detecting regular outbound HTTP beaconing in a Sentinel-style environment. This is an illustrative example:
// Illustrative KQL sketch — not production-ready as-is
// Detect regularity in outbound connections to external IPs
let lookback = 24h;
let min_connections = 10;
let jitter_tolerance = 30s;
NetworkCommunicationEvents
| where TimeGenerated >= ago(lookback)
| where Direction == "Outbound"
| where not(RemoteIPType == "Private")
| summarize
ConnectionCount = count(),
IntervalStdDev = stdev(TimeGenerated),
DestinationPorts = make_set(RemotePort)
by DeviceName, RemoteIP, RemoteUrl
| where ConnectionCount >= min_connections
| where IntervalStdDev <= totimespan(jitter_tolerance)
| sort by ConnectionCount descTuning pain points: Legitimate software beacons constantly. Update checkers, telemetry agents, monitoring daemons, cloud backup clients, and anti-virus heartbeat processes all connect to external destinations at regular intervals. Building a whitelist of known-good destinations from your software inventory before you turn on this rule is not optional — it is the first tuning step.
6. Data Exfiltration Volume Anomaly
What it detects: An unusually large outbound data transfer from an endpoint or user account, indicating potential data theft.
Volume-based exfiltration detection compares current outbound transfer rates against a historical baseline for the same user, host, or network segment. A developer who routinely uploads large build artifacts to an external CI/CD pipeline has a very different baseline from an HR analyst whose job involves spreadsheets.
Tuning pain points: This is among the highest false-positive use cases in enterprise environments. Cloud storage synchronization (OneDrive, Google Drive, Dropbox), CI/CD pipelines, database backup jobs, and media encoding workloads all generate large outbound transfers that look identical to data theft at the network layer. User and Entity Behavior Analytics (UEBA) engines that build per-entity baselines are more effective than flat thresholds here, but even UEBA systems generate significant noise until they have accumulated enough behavioral history (typically 30 days of clean data).
7. Lateral Movement via SMB and RDP
What it detects: A user or system account accessing multiple internal systems via SMB or RDP in a short time window, indicating an attacker moving through the network after an initial compromise.
Lateral movement leaves distinct Windows event traces: Event ID 4624 (successful logon) with Logon Type 3 (network) or Type 10 (remote interactive) across multiple destination hosts from the same source in a compressed time window. NetFlow data from network devices adds network-layer corroboration.
Here is an SPL-style sketch for Splunk to detect a single source account authenticating to multiple hosts within a window. This is an illustrative example:
index=wineventlog EventCode=4624 Logon_Type IN (3, 10)
| bucket _time span=30m
| stats
dc(ComputerName) AS distinct_hosts,
values(ComputerName) AS target_hosts
by _time, Account_Name, Source_Network_Address
| where distinct_hosts >= 5
| sort -distinct_hostsCorrelating SIEM authentication events with XDR process telemetry is the combination that separates IT admin activity from actual attacker pivoting — neither data source alone closes the verdict.
Tuning pain points: IT administration is lateral movement with authorization. Patch management agents, configuration management tools (SCCM, Ansible, Chef), and monitoring systems (Nagios, Zabbix) all connect to many hosts in short windows. Scoping this rule to non-service-account identities and to hosts outside the known management subnet reduces noise substantially.
8. Suspicious PowerShell and LOLBins
What it detects: PowerShell execution with encoded commands, bypass flags, or download cradles; or the use of legitimate Windows binaries (certutil, mshta, regsvr32, wscript) to execute malicious code, collectively known as Living-Off-the-Land Binaries (LOLBins).
The best data source for this use case is Sysmon with a well-tuned configuration, supplemented by PowerShell Script Block Logging (Event ID 4104). Without Sysmon, you are limited to process creation events from the Windows Security log, which lacks command-line arguments by default. The LOLBAS Project catalogs every Windows binary that attackers abuse and the expected command patterns for each.
Tuning pain points: Administrators, automation frameworks, and legitimate software use PowerShell with the same flags that attackers use. Base64-encoded commands appear in IT automation pipelines (DSC configurations, Azure automation runbooks). certutil is used by legitimate certificate management tools. The most reliable filter is combining the suspicious binary with an unusual parent process: certutil launched by cmd.exe launched by excel.exe is interesting. certutil launched by a scheduled task service on a server is noise.
Warning
Script Block Logging and Sysmon generate high log volume. Before enabling them across your fleet, confirm your SIEM indexing capacity and your license cost — the data quality gain is significant, but so is the infrastructure cost.
9. Account Created Then Immediately Privileged
What it detects: A new user account that receives administrative or elevated group membership within a short window of its creation, a pattern consistent with attacker persistence (creating a backdoor admin account).
This is a two-event correlation: Event ID 4720 (user account created) followed within a configurable window by Event ID 4728 or 4732 (member added to privileged group), for the same account name, on the same domain controller.
Tuning pain points: This rule has relatively low false positive volume compared to the others on this list, which makes it one of the better use cases to start with when building a new detection program. The primary noise sources are automated provisioning scripts that create and configure accounts in the same workflow, and help desk procedures that provision accounts with a role template. Filtering on accounts created by known provisioning service accounts and during approved change windows covers most legitimate cases.
10. Off-Hours Admin Activity
What it detects: Administrative actions (privileged logins, policy changes, account modifications) occurring outside of expected business hours, which may indicate an attacker or a compromised account acting when monitoring attention is low.
Business hours vary by organization and by role. A global enterprise has IT staff in every timezone; "off-hours" means different things in different segments. Effective off-hours detection requires either a per-user schedule model (which few SIEMs support natively) or a per-geography segmentation that defines expected hours by source IP block or identity provider attribute.
Tuning pain points: This is one of the highest-noise use cases in any organization with on-call infrastructure, global teams, or overnight automation. Patch deployment jobs, scheduled maintenance scripts, and remote workers in non-headquarters timezones all generate legitimate off-hours administrative events. Rather than a binary hours threshold, the more reliable approach is combining time anomaly with other signals: off-hours login from an unusual source IP with no matching change ticket is meaningful. Off-hours login from a known admin's home IP during a scheduled maintenance window is not.
Off-hours admin activity is most useful as a corroborating signal, not as the sole basis for escalation — the tuning discipline is learning to weight it alongside source IP, change ticket status, and the criticality of the affected asset.
Detection Logic Is the Starting Point, Not the Finish Line
Writing a detection rule is the beginning of the work, not the end. Every use case above requires three additional investments before it generates actionable signal at reasonable volume.
The first is baseline documentation. Before you tune a single threshold, you need to know what normal looks like for your environment. How many authentication failures per hour is expected from your vulnerability scanner? What is the typical outbound transfer volume from your backup servers? Without a documented baseline, every threshold you set is a guess.
The second is exclusion management. Every rule above has at least one category of legitimate activity that mimics the attack pattern it is designed to detect. The exclusion set is not an afterthought to be added when alerts fire. It is a first-class artifact of every use case, maintained alongside the detection logic.
The third is feedback loops. Every false positive that reaches an analyst and gets closed should generate a tuning ticket. The only sustainable way to manage false positive rates is a systematic process that converts analyst verdicts into rule adjustments. Without that loop, alert fatigue is structurally guaranteed regardless of how carefully you wrote the initial logic.
The ten use cases above are the detection foundation. Practicing your verdict on these alert types under realistic conditions is the fastest way to close the gap between knowing a rule and triaging it correctly — training operations provides a queue of realistic SIEM alerts built around exactly these use cases. As your triage instincts sharpen, the natural next step is proactive hunting: turning uncovered ATT&CK techniques into new searches before an attacker triggers them. The threat hunting tools guide covers the query languages, endpoint visibility platforms, and network analysis tools that hunting workflows require.
For a deeper look at how to evaluate the alerts these use cases generate, the alert triage guide covers the full verdict framework from queue intake to escalation. The Windows Event IDs cheat sheet gives you the quick-reference event table you will return to every time you write a new Windows-based detection rule.
If you are studying for an interview, the SOC analyst interview questions guide includes questions specifically about SIEM use case design and alert triage methodology that interviewers return to consistently.
And if you want to understand how the best SIEM tools differ in how they implement these use cases natively, that guide covers the major platforms and their detection engineering approaches.
Free forever · No credit card
Train on real alerts, with zero consequences
Practice triage on realistic alert volume in a live SOC console. Free forever — no credit card.
Frequently Asked Questions
- What are SIEM use cases?
- SIEM use cases are the specific detection scenarios that a security team configures their SIEM to monitor for. Each use case defines what data sources to ingest, what pattern or threshold to alert on, and what severity to assign. Common examples include brute force login attempts, impossible travel logins, privilege escalation, and data exfiltration volume anomalies. A mature SOC typically runs dozens to hundreds of use cases simultaneously.
- What are the most common SIEM detections?
- The most common SIEM detections in enterprise SOCs include brute force and password spray attacks, impossible travel (logins from geographically impossible locations), privilege escalation events, malware beaconing to command-and-control infrastructure, data exfiltration by volume, lateral movement via SMB or RDP, suspicious PowerShell execution, log source silence alerts, off-hours admin activity, and newly created accounts that immediately receive elevated privileges.
- How do you write a SIEM use case?
- Writing a SIEM use case starts with defining the threat behavior you want to detect, then identifying which log sources generate evidence of that behavior. Next you write the detection logic as a query or correlation rule, set thresholds and time windows, assign a severity, and define the expected false positive sources so you can tune the rule from day one. Every use case should be documented with its intent, data requirements, detection logic, and known exclusion patterns.
- What causes SIEM false positives?
- SIEM false positives are caused by detection logic that is too broad for the specific environment. The most common sources are authorized tools that mimic attack patterns (vulnerability scanners triggering port scan rules, backup jobs triggering brute force rules), legitimate users working outside normal hours, cloud and SaaS authentication flows that appear anomalous to on-premises-tuned rules, and misconfigured assets generating noisy logs. Reducing false positives requires environment-specific tuning: adding exclusions for known-good behavior, raising thresholds to match actual baselines, and scoping rules to asset groups where the detection is meaningful.
- What is a use case in SIEM?
- In SIEM, a use case is a specific security scenario the platform is configured to detect, together with everything needed to detect it: the threat behavior, the log sources that expose it, the detection logic (a query or correlation rule), the thresholds and time window, the severity, and the known false positive sources. A use case is broader than a single rule. It is the full package of intent, data requirements, detection logic, and tuning notes that turns a raw stream of events into an actionable alert.
- What are SIEM use cases used for beyond threat detection?
- Beyond threat detection, SIEM use cases support compliance and audit (generating the evidence and retention required for PCI DSS, HIPAA, SOC 2, and similar frameworks), cloud and multi-cloud security monitoring, insider threat and user behavior analytics, and incident response and forensics. The ten use cases in this guide focus on the detection scenarios an analyst triages day to day, but a mature SOC also runs use cases whose primary purpose is audit readiness and visibility rather than alerting.
Field notes
New walkthroughs and detections, in your inbox
A short email when we publish something worth your time. No spam, unsubscribe in one click.
Community
Continue the conversation
Discuss this with analysts who are actively training and working in the field.
Related Articles
Cyber Threat Hunting Tools: 13 SOC Analysts Use (2026)
Cyber threat hunting tools every SOC analyst needs: Sigma, YARA, KQL, Velociraptor, Wireshark, Zeek, MISP and more — grouped by layer with code examples.
Best SIEM Tools in 2026: 10 Platforms Ranked
Best SIEM tools ranked for 2026: Splunk, Microsoft Sentinel, IBM QRadar, Elastic Security, and more — reviewed from a SOC analyst training perspective.
Open Source SIEM Tools: 7 for Your Home Lab (2026)
Open source SIEM tools let you build real detection skills at zero cost. Here are 7 worth running in a home lab, ranked by what they actually teach.