Splunk is one of the most common SIEMs you'll encounter in a SOC role. It can look overwhelming when you first open it — the interface is dense, the query language has its own syntax, and nobody explains the defaults.
This is the quick-start version. By the end you'll know how to run a basic search, read what comes back, and start digging into a real alert.
What Splunk actually does
Splunk ingests log data from across your environment — Windows event logs, firewall traffic, EDR telemetry, proxy logs — indexes it, and makes it searchable in near real-time. As an L1 analyst, you're not building the indexes. You're searching them.
Everything in Splunk is time-indexed. Every event has a _time field. That matters because the first thing you should always do when you open a search is set your time range correctly. The default is "Last 24 hours," which is usually fine for alert investigation, but leave it too wide and your searches will be slow and noisy.
The search bar and SPL basics
Splunk uses SPL — Search Processing Language. It reads left to right, with each step piped into the next using |.
A basic search looks like this:
index=windows EventCode=4625
That pulls all failed logon events (Windows Event ID 4625) from your Windows log index. That's it — just field=value pairs. To get useful insight from that, pipe it through a stats command:
index=windows EventCode=4625 | stats count by src_ip | sort -count
Now you're counting failed logons by source IP and sorting highest-first. That immediately shows you if one IP is hammering accounts. Brute-force candidate.
Reading the results panel
When a search returns results you get two views: the Events tab (raw log lines) and the fields panel on the left.
The fields panel lists every field Splunk has extracted from your results. The ones you'll use constantly as a SOC analyst:
src_ip/dest_ip— source and destination addressesuserorAccount_Name— who the action relates toEventCode— the Windows Event IDhost— the machine that generated the logsource— the log file pathsourcetype— what type of data this is (WinEventLog, syslog, etc.)
Click any field in the left panel and Splunk shows you the top values. Click a value to filter to it. This is the fastest way to drill into an alert without writing SPL from scratch.
A real workflow: investigating a failed logon alert
Say you get an alert: "Multiple failed logons for domain admin account." Here's what you'd actually do.
1. Find the events
index=windows EventCode=4625 Account_Name="administrator"
| sort _time
2. Get the shape. How many events? Over what time period? From how many source IPs?
3. Check for a success after the failures
index=windows (EventCode=4625 OR EventCode=4624) Account_Name="administrator"
| sort _time
If you see 4625s followed by a 4624 from the same src_ip, that's a potential successful brute force. Escalate.
4. Pivot on the source IP
index=* src_ip="10.2.4.87" earliest=-24h
What else has this IP done? Is it internal or external? Is it on a threat intelligence watchlist?
The time picker matters more than you think
Every slow Splunk search comes down to the time range. If you're investigating an alert from 9am, set your window to a few hours either side. Running "All Time" on a busy index will time out or return millions of events that bury your signal.
Habit: always set the time range before you click Search.
What you don't need to know yet
You don't need to know lookups, data models, dashboards, or correlation searches to be useful as an L1. Those come later. What you need is: how to search an index, how to filter by field, how to use stats count by to aggregate, and how to sort results. Everything else builds on that.
The best way to actually learn SPL is repetition on real data — which is exactly what the SOCentre simulator gives you: log data you have to query and interpret, not just read about.
Practice what you've read. The SOCentre simulator puts you in front of real-looking log data with live scenarios to work through. Start training free — no card required.