Home About Labs Projects Contact Email Me ↗
Case Study · Published

Authentication log analysis with Splunk.

An end-to-end lab covering brute-force credential detection: SPL alert logic, a structured triage method, and a response workflow designed to be run again by someone who was not there the first time.

4625
Windows Event ID
80+
Failed Logons Isolated
04
Workflow Phases
SPL
Query Language
Objective

Turn authentication noise into analyst-ready signal.

Failed logons are constant in any Windows estate. Most are a mistyped credential; a few are not. The goal of this lab was to find the difference reliably — identify anomalous authentication patterns, cut alert fatigue through threshold tuning, and turn raw event data into a structured, repeatable response workflow.

It is deliberately unglamorous work. The value is in the write-up: anyone picking this up later should be able to rebuild the query, understand why the threshold sits where it does, and follow the same triage path.

Parameters

The setup.

FocusAuthentication anomalies and brute-force behaviour
TelemetryWindows Security Event Logs in Splunk Enterprise
SignalEvent ID 4625, grouped by source and account
Result80+ failed logons in a defined window
StatusPublished, write-up complete
Splunk Enterprise SPL Windows Security Logs Case Documentation
Workflow

Four steps,
in order.

Nothing skipped and nothing assumed. Each step produced an artefact the next step depended on.

01
Data

Ingestion and normalisation

Windows Security Event Logs — specifically Event ID 4625, failed logon — ingested into Splunk Enterprise and normalised so that source host, account name, and timestamp could be queried consistently rather than parsed by hand each time.

Artefact
Queryable index of authentication events
02
Detection

SPL query logic

SPL queries written to correlate failed logon volume across source IP, user account, and time window — the combination that separates one frustrated user from a single host hammering many accounts.

Artefact
Reusable SPL search with documented fields
03
Triage

Validation and threshold tuning

Correlated events reviewed, thresholds adjusted to cut false positives without losing the signal, and the analyst decision points written down — including what was ruled out and why.

Artefact
Tuned threshold with a stated false-positive boundary
04
Response

Repeatable response framework

Analyst actions, escalation criteria, and reusable case notes defined so the next occurrence follows a known path instead of restarting the investigation from scratch.

Artefact
Response notes and escalation criteria
Stack & Skills

What it took,
what it proved.

A small toolset used properly, and the competencies the lab was built to exercise.

Stack
  • Splunk Enterprise
  • SPL query language
  • Windows Security Event Logs
  • Structured case documentation
Skills Demonstrated
  • Detection logic and query design
  • Log analysis and event correlation
  • Triage methodology
  • Technical documentation
Outcome

A lab that behaves like real work.

The result is a self-contained use case demonstrating credential-attack detection, a structured triage method, and a documented analyst workflow that would transfer to a real operations environment without rewriting.

The write-up and queries live in the repository. The two staged labs that follow this one are indexed in the case files.

If the next person cannot repeat it from the notes, the lab is not finished.

Related

Keep reading.

Next

Questions about how it was built?