Splunk SIEM for Beginners: Hands-On Lab Walkthrough

Splunk is one of the most widely deployed SIEM platforms in enterprise environments. If you walk into a SOC analyst interview and cannot speak to Splunk, you are at a disadvantage. The good news: Splunk offers a free tier that is more than enough to build real, demonstrable skills.

This walkthrough covers what I learned from the Vandalay Industries lab scenario — a guided simulation where you investigate a fictitious company's network for signs of compromise.

Setting Up Splunk Free

Splunk Enterprise has a free licence limited to 500MB of data ingestion per day — plenty for a homelab. Download from splunk.com, install on a Windows or Linux VM, and start it with:

./splunk start --accept-license

The web UI runs on http://localhost:8000. Add data by uploading log files or configuring a Universal Forwarder on another VM to ship logs in real time.

Understanding SPL — Splunk's Query Language

SPL (Search Processing Language) is what you will spend most of your time writing. The basic structure is a pipeline — each command feeds into the next using |.

index=main sourcetype=syslog "failed password"
| stats count by src_ip
| sort -count
| head 10

This query finds all syslog events containing "failed password", counts them by source IP, sorts descending, and returns the top 10. In a real SOC this is one of the first queries you run when investigating a brute-force alert.

Key SPL Commands to Learn First

• stats count by field — aggregate and group events
• timechart count — plot events over time (great for spotting spikes)
• rex field=_raw — extract fields with regex on the fly
• transaction — group related events into a single session
• eval — create calculated fields

The Vandalay Industries Scenario

This is a guided lab available through various cybersecurity bootcamps and the Splunk training platform. The scenario gives you pre-loaded logs and asks you to investigate a series of incidents. Here is what I investigated:

Investigation 1 — Brute Force Attack

The task: find which IP was brute-forcing the company's FTP server and determine if they succeeded. My query:

index=main sourcetype="ftp" action=failure
| stats count as failures by src_ip
| where failures > 20
| join src_ip [search index=main sourcetype="ftp" action=success
  | stats count as successes by src_ip]

Result: one IP had 346 failures followed by a successful login. That is your attacker, and that is also how you write it up in an incident report.

Investigation 2 — Data Exfiltration

Using the timechart command to plot outbound traffic volume, I found a spike of unusual upload activity at 2:37 AM — outside business hours, to an IP with no prior connection history. Classic data exfiltration pattern.

Creating Alerts

Knowing how to write a query is half the job. Turning it into a persistent alert is the other half. In Splunk:

1. Run your SPL query and confirm it catches what you want
2. Click Save As > Alert
3. Set a schedule (e.g., every 15 minutes) and a trigger condition (e.g., number of results > 0)
4. Configure an action: email, webhook to Slack, or log to a summary index

Dashboards and Visualisation

Build a dashboard that any analyst on shift can read at a glance. Mine had four panels: failed logins over time, top talkers by bytes, geographic map of source IPs, and open alerts by severity. Use the Dashboard Studio (newer UI) — it is cleaner than the Classic builder.

What This Teaches You for a Real SOC

Every real SOC uses some form of SIEM. The specific platform varies — it might be Splunk, Microsoft Sentinel, IBM QRadar, or Elastic SIEM — but the concepts are transferable: ingest logs, write detection queries, triage alerts, escalate confirmed incidents. Splunk teaches you the mental model.

After completing this project I could confidently discuss log correlation, alert tuning (reducing false positives), and incident timeline reconstruction in interviews. That is exactly what tier-1 SOC analysts do every day.