Build a Splunk SOC Project: Detect a Brute-Force Login
A free, step-by-step build guide — no prior Splunk experience required. By the end, you’ll have a real detection, an alert, and a dashboard to show for it.
What you’ll build
By the end of this guide, you’ll have ingested sample authentication log data into Splunk, written a search that identifies a burst of failed login attempts from a single source, saved that search as an alert, and built a dashboard panel that visualizes it — the same basic workflow a real SOC analyst uses to catch a brute-force attempt in progress.
This project maps to MITRE ATT&CK Technique T1110 (Brute Force) — a real, catalogued attack technique, not a made-up scenario. Naming that connection explicitly in your portfolio write-up is exactly the kind of detail that signals you understand the threat landscape, not just the tool.
Setup: get Splunk running
Splunk offers a genuinely free tier, but the path to it isn’t instant — worth knowing upfront so it doesn’t feel like a bait-and-switch.
How Splunk Free actually works: You install a 60-day Enterprise Trial from Splunk’s official download page, then switch to the Free license before the trial ends. The Free license has no expiration date, but caps indexing at 500 MB per day and removes multi-user login — neither limitation matters for a portfolio project.
For this guide, you don’t need a virtual machine or real Windows Event Logs — Splunk ships with its own built-in tutorial dataset, which is enough to practice the detection logic below. If you want to level up later, generating logs from a real Windows VM with Sysmon is the natural next step, but it’s not a prerequisite here.
Step-by-step build
Load the sample data
Inside Splunk Web, go to Settings → Add Data → Upload, and load the built-in tutorial dataset (Splunk’s own onboarding walks you through this the first time you log in). This gives you real, structured log events to search against immediately.
Run a basic search first
Before writing a detection, get a feel for the data. In the Search & Reporting app, run a broad search to see what fields are available:
index=* EventCode=4625
| EventCode 4625 = a failed Windows logon attempt
Confirm you’re seeing results before moving on — if the search returns nothing, double-check the dataset actually loaded in Step 1.
Write the detection search
This is the core of the project — a search that flags a source IP with 5 or more failed logins inside a 2-minute window, a classic brute-force pattern:
index=* EventCode=4625 | bin _time span=2m | stats count by src_ip, _time | where count >= 5 | sort -count
Adjust the threshold (5) and window (2m) if your dataset doesn’t naturally produce a match — the exact numbers matter less than understanding why this logic catches a brute-force pattern specifically.
Save it as an alert
Once the search reliably returns results, click Save As → Alert. Set it to run on a schedule (every 5 minutes is reasonable for a demo), and configure a trigger condition of “number of results is greater than 0.” This turns a one-off search into something that actually monitors.
Build a dashboard panel
From the same search results, click Save As → Dashboard Panel, and choose a column or bar chart visualizing failed-login count by source IP. This is what turns a technical search into something a non-technical reviewer (or an interviewer) can understand at a glance.
Capture your results
Screenshot the dashboard panel and the alert configuration — you’ll need both for documentation. Note the specific numbers your detection actually caught (e.g. “47 failed attempts from one IP in 90 seconds”) rather than describing it generically.
Document the project
Turn this into a README a recruiter can actually skim in 30 seconds.
Get the README Template →Write it up like a real incident
Go further — document the detection the way a real SOC analyst writes up a case.
Get the Incident Report Template →What this proves to an employer
A SOC Analyst job posting rarely says “build a brute-force detection in Splunk” outright — but it almost always lists the underlying skills this project actually demonstrates:
Frequently asked questions
Do I need a virtual machine to do this project?
No — Splunk’s own built-in tutorial dataset is enough to complete this guide with no VM setup. A VM with real Windows Event Logs is a good next-level upgrade once you’re comfortable, but it isn’t required to build a legitimate first project.
Is Splunk Free actually free forever?
Yes, with limits. You install a 60-day Enterprise Trial, then switch to the Free license, which has no expiration but caps indexing at 500 MB per day and removes multi-user features — both are non-issues for a portfolio project.
What if my computer can’t run Splunk locally?
Splunk Enterprise needs a reasonably capable machine. If yours can’t handle it, the Microsoft Sentinel project is a cloud-based alternative that runs entirely in a browser.
Documented this project? Build a second one.
One project proves you can follow instructions. Two or three, covering different skills, is what actually builds a portfolio.
Back to the Portfolio Hub →