Splunk Detection and Incident Response Course

Why this course exists

Splunk is one of the two dominant enterprise SIEMs, and for a large share of SOC and DFIR practitioners it is the tool they sit in front of every day. The search bar is where they triage alerts, build detections, run hunts, and reconstruct incidents. Yet detection training, including most of this platform's own, is written for the Microsoft stack: KQL against Sentinel and Defender, Graph for identity, Defender XDR for endpoint.

If you work in Splunk, you have been translating that material in your head, and translation is where detections quietly break.

They break because the two platforms do not share a model. KQL runs over tables with a known schema. SPL runs as a pipeline over raw events, extracts most fields at search time, layers the Common Information Model on top to normalize them, and accelerates detection with tstats against data models, which has no direct KQL equivalent.

Port a KQL detection field for field into SPL and you usually get one of two failures: it scans raw events and times out at scale, or it matches a field name that means something different in Splunk and returns the wrong rows. The fix is not a cleaner translation. It is writing the detection the way Splunk wants it written, and that is what this course teaches.

There is also a level problem. The beginner end of Splunk is saturated: the vendor's own free eLearning, the Core Certified User track, and an endless supply of "intro to SPL" rooms all teach search, stats, and eval. The advanced end is thin.

A practitioner who can write a stats aggregation but cannot yet write a tstats-accelerated detection over a CIM data model, cut false positives with a lookup-driven allowlist, or reconstruct a multi-sourcetype incident with transaction and subsearches has nowhere obvious to go at subscription price. That gap, competent to advanced and in the defender's seat, is where this course lives.

It does one thing deliberately: it teaches Splunk detection engineering, hunting, and incident response against real data. Not Splunk administration. Not deployment or indexer architecture. Not certification cramming. The work here is what you do with a Splunk environment once someone else has stood it up, and you do all of it on the page, against a live dataset.

You are handed a Splunk environment with data already in it; this course is what you type into the search bar and how you read what comes back. The dashboards, the app configuration, the admin console are another job, or another course.

Who this course is for

This is an intermediate-to-advanced course, and it is open about that. It assumes you can already:

• write a search with stats, eval, and rex, and extract the fields you need;
• read a result set and reason about what it does and does not prove;
• work from a SOC or DFIR background where "investigate this lead" is a familiar instruction.

Here is that line in concrete terms. You can almost certainly write index=azuread sourcetype=azure:monitor:aad | stats count by user.

What this course adds is why the production form of that detection is | tstats count from datamodel=Authentication by Authentication.user, when the accelerated data model is the right tool and when it is not, and how to wrap the result in a lookup so a known-good service account stops paging you at 3am. The first query you already own. The second is the job this course is about.

It is a deliberate departure from the platform's usual "no minimum experience" principle, made because the target reader is specific and the market below them is already well served. The universal rule, that every concept is explained when it is first used, still holds inside the advanced frame: when a tstats idiom or a data-model acceleration assumption appears, it is explained at that point.

What is not re-taught is the SPL you are assumed to bring. SPL0.2 draws that line precisely, so you can see what is assumed and what is taught before you commit.

If you are newer to SPL, the KQL course (SEC201) and the free Splunk material are the on-ramp. Come back when stats by is muscle memory.

What this course covers

Thirteen modules: a free two-module preview, then five phases. Each phase is a precondition for the next.

Phase 1 builds the platform fluency the course runs on: the data model underneath Splunk, the CIM that normalizes it, and the advanced commands (tstats, eventstats, streamstats, transaction, lookup) that everything afterward assumes. Phase 2 turns that into detections, the engineering discipline first and then the identity and endpoint detections, each built against a real attack in the data.

Phase 3 covers network, web, and DNS detection and steps off the alert to hunt across sourcetypes. Phase 4 runs the incident from search alone: triage, investigation, response, reporting. Phase 5 puts all of it under pressure against one full chain.

The attack chains that run through it

This course is not a tour of disconnected example searches. The NE environment carries seven embedded attack chains, and the detection, hunting, and IR modules investigate the same seven in Splunk. Each one teaches something specific:

• Password spray is your first real detection: many failed authentications from one source across many users, the aggregate signal that a single rejection hides.
• AiTM token replay is the identity case the industry fights now, where MFA succeeded and the session token was stolen and replayed anyway.
• Endpoint compromise is process ancestry and persistence: a foothold that spawns the wrong child process and installs a service.
• Ransomware pre-encryption is the window before damage, when shadow copies are deleted and backups are tampered with.
• The hybrid pivot crosses the on-prem and cloud identity boundary, where a directory change in one plane becomes access in the other.
• The edge-to-identity intrusion starts at an internet-facing service and ends in a compromised account.
• The full-span chain ties these together and is the capstone.

By Module 5 you are detecting the spray that actually happened in the data. By Module 10 you are reconstructing how the edge intrusion became an identity compromise and then cloud access. The same adversaries reappear across sourcetypes because real incidents do not stay in one log, and learning to follow them across the estate is the skill the course is built to produce.

Why the course is shaped this way

The order is not arbitrary. You cannot write a scaled detection before you understand the data model it accelerates over, so the platform and the advanced surface come first. You cannot tune a detection before you can write one, so engineering precedes the detection library.

You cannot hunt without the detection vocabulary, and you cannot run an incident without being able to hunt and correlate, so response sits last, where it draws on everything before it. The capstone exists because real incidents do not announce their type at the start. A student who has worked the chains individually should be able to take one they have never seen and run it to a report.

Module 2 is the spine. tstats over an accelerated data model is the single technique that separates a Splunk user from a Splunk detection engineer, and almost every later module leans on it. If you take one thing from the course, make it the ability to write detection and hunting logic that runs across the whole estate in seconds instead of timing out on raw events.

SPL0.2 covers how to get the most from the course, and exactly which SPL it assumes you already know.