Splunk SPL Cheat Sheet: 15 Queries Every SOC Analyst Should Bookmark
Stop Googling basic SPL syntax. Here are 15 essential Splunk queries every SOC analyst needs for threat hunting, incident investigation, and daily security monitoring—with real examples you can use immediately.
EpicDetect Team
12 min read
Splunk SPL Cheat Sheet: 15 Queries Every SOC Analyst Should Bookmark
You're staring at Splunk. Again.
You know you need to hunt for suspicious activity, investigate that weird alert, or pull some logs for an incident report. But you can't quite remember the exact SPL syntax.
So you Google it. Again.
Here's the thing: there are a handful of SPL queries that show up in like 80% of SOC work. If you memorize these 15 patterns, you'll dramatically speed up your daily workflow.
Let's get into it.
Why SPL Matters for SOC Analysts
Splunk Search Processing Language (SPL) is how you actually use Splunk. It's how you find the needle in the haystack of millions of logs.
What you'll use SPL for:
- Investigating security alerts
- Threat hunting for suspicious patterns
- Creating detection rules
- Generating reports for incidents
- Baseline analysis and anomaly detection
The faster you can write queries, the faster you can respond to threats. These 15 queries are your foundation.
---
Query 1: Basic Search with Time Range
What it does: Search for specific events within a time window
``spl
index=main sourcetype=windows:security EventCode=4625
earliest=-24h latest=now
`
When to use it:
- Starting point for most investigations
- Limiting results to relevant timeframe
- Reducing search load on Splunk
Real scenario: "Show me all failed login attempts in the last 24 hours"
Tips:
- Always specify index and sourcetype (faster searches)
- Use earliest and latest to narrow timeframe
- Common time modifiers: -1h, -24h, -7d, -30d
---
Query 2: Count Events by Field
What it does: Aggregate and count occurrences of a field
`spl
index=security sourcetype=firewall action=blocked
| stats count by src_ip
| sort - count
`
When to use it:
- Finding the most active IPs, users, or hosts
- Identifying potential scanning or brute force activity
- Baseline establishment
Real scenario: "Which IPs are getting blocked by the firewall most?"
Tips:
- stats count by [field] is your friend
- sort - count shows highest counts first (descending)
- Can count by multiple fields: stats count by src_ip, dest_port
---
Query 3: Search with Wildcards
What it does: Pattern matching with wildcards
`spl
index=web sourcetype=access_combined
| search user_agent="bot" OR user_agent="crawler"
`
When to use it:
- Partial string matching
- Finding variations of the same thing
- Broad initial searches
Real scenario: "Find all web requests from bots or crawlers"
Tips:
- * matches any number of characters
- Use quotes for multi-word patterns
- Wildcards at the beginning slow searches (avoid "*admin" if possible)
---
Query 4: Filter with WHERE
What it does: Filter results based on conditions
`spl
index=authentication sourcetype=radius
| stats count by username
| where count > 10
`
When to use it:
- Filtering aggregated results
- Finding anomalies based on thresholds
- Post-processing after stats/calculations
Real scenario: "Show users who authenticated more than 10 times"
Tips:
- where comes after aggregation (stats, timechart, etc.)
- Can use comparison operators: >, <, >=, <=, !=, =
- Combine conditions: where count > 10 AND count < 100
---
Query 5: Field Extraction with REX
What it does: Extract fields from raw logs using regex
`spl
index=web sourcetype=apache
| rex field=_raw "status=(?
| stats count by http_status
`
When to use it:
- When Splunk doesn't auto-extract fields
- Custom parsing of log formats
- Extracting specific patterns from text
Real scenario: "Extract HTTP status codes from custom web logs"
Tips:
- Named capture groups: (?
- Test regex patterns before using in production
- Use rex mode=sed for string replacement
---
Query 6: Dedup (Remove Duplicates)
What it does: Remove duplicate events based on field values
`spl
index=security EventCode=4624
| dedup username
| table _time, username, src_ip
`
When to use it:
- Getting unique values
- Cleaning up repetitive results
- First/last occurrence analysis
Real scenario: "Show me unique users who logged in (one entry per user)"
Tips:
- dedup [field] keeps first occurrence by default
- dedup username sortby -_time keeps most recent
- Can dedup by multiple fields: dedup username, src_ip
---
Query 7: Timechart for Time-Series Analysis
What it does: Create time-based aggregations
`spl
index=security EventCode=4625
| timechart span=1h count by username
`
When to use it:
- Visualizing trends over time
- Identifying spikes or anomalies
- Creating dashboards
Real scenario: "Show failed logins per hour for each user"
Tips:
- span=1h sets time buckets (1m, 5m, 1h, 1d, etc.)
- Great for charts and visualizations
- Limit results: timechart span=1h count by username limit=10
---
Query 8: Eval (Create Calculated Fields)
What it does: Create new fields or modify existing ones
`spl
index=security EventCode=4625
| eval failed_login_time=strftime(_time, "%Y-%m-%d %H:%M:%S")
| eval status=if(Account_Name="admin", "CRITICAL", "normal")
| table failed_login_time, Account_Name, status
`
When to use it:
- Formatting fields
- Conditional logic
- Math calculations
Real scenario: "Flag admin login failures as critical"
Tips:
- if(condition, true_value, false_value) for conditionals
- case() for multiple conditions
- Math: eval total=value1 + value2
---
Query 9: Join Data from Multiple Indexes
What it does: Combine results from different searches
`spl
index=firewall action=blocked
| stats count by src_ip
| join src_ip
[search index=threat_intel | table src_ip, threat_score]
| where threat_score > 50
`
When to use it:
- Correlating data from different sources
- Enriching events with additional context
- Threat intelligence lookups
Real scenario: "Find blocked IPs that match threat intel feeds"
Tips:
- Use join sparingly (can be slow on large datasets)
- Consider lookup for static reference data
- Subsearches go in [ ] brackets
---
Query 10: Transaction (Group Related Events)
What it does: Group events that are related into transactions
`spl
index=web sourcetype=access_combined
| transaction session_id maxpause=30m
| where duration > 3600
| table session_id, duration, eventcount
`
When to use it:
- Tracking user sessions
- Analyzing multi-step processes
- Finding long-running activities
Real scenario: "Find web sessions lasting over 1 hour"
Tips:
- maxpause defines max time between events in transaction
- duration field automatically created (in seconds)
- eventcount shows number of events in transaction
---
Query 11: Subsearch (Search Within a Search)
What it does: Use results from one search as input to another
`spl
index=authentication action=failure
[search index=threat_intel category=malicious | fields src_ip]
| stats count by username, src_ip
`
When to use it:
- Dynamic filtering based on search results
- Correlating across indexes
- Complex threat hunting
Real scenario: "Find login failures from IPs in threat intel database"
Tips:
- Subsearches run first, then pass results to main search
- Limit subsearch results (max 50k events by default)
- Can be resource-intensive
---
Query 12: Top Command (Quick Stats)
What it does: Show most/least common values for a field
`spl
index=dns
| top limit=20 query
`
When to use it:
- Quick frequency analysis
- Finding outliers
- Dashboard building
Real scenario: "What are the top 20 DNS queries?"
Tips:
- top shows most common by default
- rare shows least common
- Add showperc=true to show percentages
- limit=X controls number of results
---
Query 13: Lookup (Enrich with Reference Data)
What it does: Add fields from lookup tables
`spl
index=firewall
| lookup geo_ip_lookup ip as src_ip OUTPUT country, city
| stats count by country
`
When to use it:
- GeoIP lookups
- Asset inventory enrichment
- Threat intelligence matching
- User/host information
Real scenario: "Show firewall blocks by country"
Tips:
- Faster than joins for static reference data
- Create lookup files via CSV upload
- Automatic lookups can be configured in Splunk
---
Query 14: Regex (Advanced Filtering)
What it does: Use regular expressions for complex pattern matching
`spl
index=web sourcetype=access_combined
| regex user_agent="(?i)(nikto|sqlmap|nmap|metasploit)"
`
When to use it:
- Complex pattern matching beyond wildcards
- Case-insensitive searches
- Multi-pattern detection
Real scenario: "Find web requests from known hacking tools"
Tips:
- (?i) makes regex case-insensitive
- Test patterns at regex101.com first
- Can be slower than simple searches
---
Query 15: Streamstats (Running Calculations)
What it does: Calculate running totals or moving averages
`spl
index=authentication action=success
| streamstats count by username reset_on_change=true
| where count > 5
`
When to use it:
- Detecting rapid successive events
- Baseline comparison
- Identifying suspicious patterns
Real scenario: "Find users with 5+ rapid successive logins"
Tips:
- streamstats maintains order (unlike stats)
- reset_on_change=true resets count when field value changes
- Good for time-based anomaly detection
---
Pro Tips for Writing Better SPL
Now that you've got 15 essential queries, here are some tips to level up your SPL game:
1. Index and Sourcetype First
Always start with index= and sourcetype= to make searches faster.
Slow:
`spl
EventCode=4625
`
Fast:
`spl
index=windows sourcetype=windows:security EventCode=4625
`
2. Use Fields Command to Reduce Data
Only keep fields you need to speed up searches.
`spl
index=web | fields src_ip, url, status
`
3. Avoid Leading Wildcards
Searches starting with * are slow. Be specific.
Slow:
`spl
"admin"
`
Faster:
`spl
"admin" OR "admin"
`
4. Use Head to Limit Results During Testing
When building queries, limit results to test faster.
`spl
index=firewall | head 100
`
5. Pipe Efficiency Matters
Put filtering commands early in the pipeline.
Less efficient:
`spl
index=web | stats count by status | where status=404
`
More efficient:
`spl
index=web status=404 | stats count by status
`
---
Common SOC Use Cases
Here's how these queries apply to real SOC work:
Failed Login Investigation
`spl
index=authentication action=failure
| stats count by username, src_ip
| where count > 5
| sort - count
`
Suspicious PowerShell Execution
`spl
index=windows EventCode=4688
| search CommandLine="powershell" AND CommandLine="-enc"
| table _time, ComputerName, User, CommandLine
`
Outbound Traffic to Rare Destinations
`spl
index=firewall action=allowed direction=outbound
| stats count by dest_ip
| where count < 5
`
User Login from Multiple IPs
`spl
index=authentication action=success
| stats dc(src_ip) as unique_ips by username
| where unique_ips > 3
`
Malware Callback Detection
`spl
index=proxy
| lookup threat_intel_domains domain as dest_domain OUTPUT threat_category
| where threat_category="malware"
| stats count by src_ip, dest_domain
``
---
Practice Makes Perfect
Reading SPL is one thing. Writing it from muscle memory is another.
How to actually get good at SPL:
1. Practice daily – Even 15 minutes a day writing queries
2. Start simple – Master basic searches before advanced stuff
3. Build a personal cheat sheet – Add queries you use often
4. Learn from others – Read Splunk dashboards and saved searches at work
5. Do hands-on labs – Practice with real datasets (like on EpicDetect)
The SOC analysts who are fastest at investigating incidents? They're not Googling SPL syntax—they've got these patterns memorized.
---
TL;DR – Bookmark These 15 Queries
Master these 15 SPL patterns and you'll handle 80% of SOC analyst work: basic search with time range, count by field, wildcards, where filtering, regex extraction, dedup, timechart, eval, joins, transactions, subsearches, top/rare, lookups, regex, and streamstats. Always start with index/sourcetype, filter early in the pipeline, and practice daily to build muscle memory.
---
FAQs
Do I need to memorize all of these?
Not necessarily, but the first 10 will show up constantly in SOC work. Bookmark this page and reference it until they become second nature.
What if my logs don't have the fields in these examples?
Adjust the field names to match your environment. The query patterns stay the same—just swap out the field names.
Is Splunk the only SIEM I should learn?
Nope, but it's one of the most common. The concepts transfer to other SIEMs (Sentinel uses KQL, Elastic uses their own query language). Learn SPL first, then others become easier.
How long does it take to get good at SPL?
With daily practice, you'll be comfortable in 1-2 months. Mastery takes 6-12 months of real SOC work.
Can I use these queries in Splunk Free?
Yep, these all work in Splunk Free. The only limitations are around alerting and clustering, not search functionality.
---
Sources & References:
---
> Copy these 15 queries into a text file or OneNote. Next time you're in Splunk and can't remember the syntax, you'll have it ready. Eventually you won't need the cheat sheet—it'll just be muscle memory.
How EpicDetect Can Help
Reading SPL is one thing. Actually writing it under pressure during an investigation is different.
EpicDetect gives you hands-on practice with real SOC scenarios where you need to write SPL queries to investigate incidents, hunt for threats, and analyze logs. You'll practice these exact query patterns (and more) in context.
Instead of just copying examples, you'll build the muscle memory that makes you fast when it actually matters—during an active investigation.
Check it out: EpicDetect Pricing — 7-day free trial, cancel anytime.