Investigate Brute Force in Splunk

Use Splunk Cloud to investigate a simulated brute-force account compromise.

Introduction

30 Second Summary

A burst of failed sign-ins can come from a mistyped password, a broken service task, or someone forcing their way into an account. The count alone cannot tell you which story is real.

In this project, you will investigate a synthetic Windows authentication incident as a junior SOC analyst using Splunk Cloud Platform. You will use SPL searches to separate noisy login activity from a likely brute-force account compromise.

What You'll Build

You will open a private dashboard where an ordered timeline reveals why only one of two suspicious login candidates points to a likely account compromise.

By the end of this project, you'll have:

A searchable incident dataset where you can inspect 15 synthetic Windows authentication events in Splunk.
Repeatable triage searches that surface high-failure candidates before correlating each candidate with successful logons.
Portfolio evidence that shows the suspicious login sequence in a private dashboard and documents your decision in an incident report.
An optional Secret Mission to push your skills further.

Are there any prerequisites?

You need a Windows PC with internet access. You also need an email address for your free Splunk account.

The project uses Microsoft Edge and Windows Notepad. The 14-day trial does not require a credit card.

Before We Start

Before the hands-on investigation begins, commit to treating this synthetic brute-force account-compromise case like a real analyst case. Your decision depends on correlating failed Windows event ID 4625 logons with successful event ID 4624 logons so noisy failures do not become false alarms.

Set Up the SOC Case

A safe SOC investigation needs evidence you can query without touching a live system. A synthetic dataset lets you practise a SIEM workflow without risking real accounts.

You'll use Microsoft Edge to start a free Splunk Cloud Platform trial. Windows Notepad supplies the controlled CSV that Splunk ingests for your case.

In this step, get ready to:

Access a free Splunk Cloud Platform trial in Splunk Web.
Create the synthetic Windows authentication CSV in Notepad.
Prove Splunk can search all 15 uploaded events.

Start your Splunk Cloud trial

The browser-based trial gives you a purpose-built environment for searching security events. The 14-day trial requires no credit card, so starting it does not create a billing commitment.

Press the Windows key to open the Windows search bar.
Type Microsoft Edge and press Enter to open it.
Go to the Splunk Cloud Platform trial page.
Create a Splunk account with your email address if you do not already have one.
Sign in to your Splunk account.
Start the free Splunk Cloud Platform trial from the product page.
Go to the Instances page in your Splunk account.
Open your free trial instance when it becomes available.

You'll see Splunk Web in Microsoft Edge. The Settings menu confirms that you are inside the trial instance.

Can't open your trial instance?

Confirm that Microsoft Edge is signed in to the same Splunk account that started the trial.
Refresh the Instances page if the trial is still being prepared.
Use the deployment URL and credentials supplied by Splunk if the instance opens on a separate sign-in page.

Still stuck? Why can't I open my Splunk Cloud trial instance? You can also ask the Splunk Community about an account-specific provisioning issue.

Create the authentication dataset

Each row in the case file represents one synthetic authentication event. The fixed timestamps preserve the event order you need for the later investigation.

Press the Windows key to open the Windows search bar.
Type Notepad and press Enter to open it.
Paste the synthetic authentication events below into the blank Notepad document:

timestamp,event_id,user,source_ip,status,logon_type,destination,context
2026-08-30T08:55:00Z,4625,priya,198.51.100.25,failure,3,FILE-SRV-01,user_typo
2026-08-30T08:55:15Z,4624,priya,198.51.100.25,success,3,FILE-SRV-01,normal_vpn
2026-08-30T08:57:00Z,4625,backup_svc,192.0.2.10,failure,3,FILE-SRV-01,approved_backup_service
2026-08-30T08:57:10Z,4625,backup_svc,192.0.2.10,failure,3,FILE-SRV-01,approved_backup_service
2026-08-30T08:57:20Z,4625,backup_svc,192.0.2.10,failure,3,FILE-SRV-01,approved_backup_service
2026-08-30T08:57:30Z,4625,backup_svc,192.0.2.10,failure,3,FILE-SRV-01,approved_backup_service
2026-08-30T08:57:40Z,4625,backup_svc,192.0.2.10,failure,3,FILE-SRV-01,approved_backup_service
2026-08-30T09:00:00Z,4625,alex,203.0.113.77,failure,3,FILE-SRV-01,external_unknown
2026-08-30T09:00:30Z,4625,alex,203.0.113.77,failure,3,FILE-SRV-01,external_unknown
2026-08-30T09:01:00Z,4625,alex,203.0.113.77,failure,3,FILE-SRV-01,external_unknown
2026-08-30T09:01:30Z,4625,alex,203.0.113.77,failure,3,FILE-SRV-01,external_unknown
2026-08-30T09:02:00Z,4625,alex,203.0.113.77,failure,3,FILE-SRV-01,external_unknown
2026-08-30T09:02:30Z,4625,alex,203.0.113.77,failure,3,FILE-SRV-01,external_unknown
2026-08-30T09:03:00Z,4624,alex,203.0.113.77,success,3,FILE-SRV-01,external_unknown
2026-08-30T09:05:00Z,4624,morgan,198.51.100.44,success,3,FILE-SRV-01,normal_vpn

What is in this dataset?

Each line after the header represents one synthetic authentication event.
Windows event 4625 records a failed logon. Windows event 4624 records a successful logon.
The user field identifies the account involved in each event.
The source_ip field identifies the source associated with each logon.
The context field gives this synthetic case enough background for later classification.

Click File in the top-left corner of Notepad.
Select Save As.
Choose Desktop as the destination.
Enter soc_windows_auth.csv in the File name field.
Set Save as type to All files (*.*).
Select Save.
Confirm that the Notepad title bar shows soc_windows_auth.csv.

✔️ Awesome, I've got everything!

The full filename in the title bar confirms that Notepad preserved the .csv extension. Your 15-event case file is ready for upload.

ⓧ I'd like to double check the full code

Compare your Notepad document with this complete file:

timestamp,event_id,user,source_ip,status,logon_type,destination,context
2026-08-30T08:55:00Z,4625,priya,198.51.100.25,failure,3,FILE-SRV-01,user_typo
2026-08-30T08:55:15Z,4624,priya,198.51.100.25,success,3,FILE-SRV-01,normal_vpn
2026-08-30T08:57:00Z,4625,backup_svc,192.0.2.10,failure,3,FILE-SRV-01,approved_backup_service
2026-08-30T08:57:10Z,4625,backup_svc,192.0.2.10,failure,3,FILE-SRV-01,approved_backup_service
2026-08-30T08:57:20Z,4625,backup_svc,192.0.2.10,failure,3,FILE-SRV-01,approved_backup_service
2026-08-30T08:57:30Z,4625,backup_svc,192.0.2.10,failure,3,FILE-SRV-01,approved_backup_service
2026-08-30T08:57:40Z,4625,backup_svc,192.0.2.10,failure,3,FILE-SRV-01,approved_backup_service
2026-08-30T09:00:00Z,4625,alex,203.0.113.77,failure,3,FILE-SRV-01,external_unknown
2026-08-30T09:00:30Z,4625,alex,203.0.113.77,failure,3,FILE-SRV-01,external_unknown
2026-08-30T09:01:00Z,4625,alex,203.0.113.77,failure,3,FILE-SRV-01,external_unknown
2026-08-30T09:01:30Z,4625,alex,203.0.113.77,failure,3,FILE-SRV-01,external_unknown
2026-08-30T09:02:00Z,4625,alex,203.0.113.77,failure,3,FILE-SRV-01,external_unknown
2026-08-30T09:02:30Z,4625,alex,203.0.113.77,failure,3,FILE-SRV-01,external_unknown
2026-08-30T09:03:00Z,4624,alex,203.0.113.77,success,3,FILE-SRV-01,external_unknown
2026-08-30T09:05:00Z,4624,morgan,198.51.100.44,success,3,FILE-SRV-01,normal_vpn

Did Notepad add a text extension?

Return to Save As if the title bar ends with .txt.
Set Save as type to All files (*.*) before saving again.
Confirm that the first row begins with timestamp,event_id,user.
Confirm that the final row contains the morgan event.

Still stuck? Why did Notepad save my CSV as a text file?

Upload and verify the dataset

SIEM ingestion turns the CSV rows into searchable events. The header gives Splunk the field names you use throughout the investigation.

Switch back to the Splunk Web tab in Microsoft Edge.
Select Settings in the top navigation.
Select Add Data.
Select Upload.
Select Select File.
Choose soc_windows_auth.csv from your Desktop.
Select Open.

You'll see soc_windows_auth.csv listed as the selected upload file.

Select Next.
Confirm that the Set Source Type page identifies the source type as csv.
Select Next.
Leave the Index option on the Input Settings page set to Default.
Select Review.
Select Submit.
Select Start searching.

You'll land in Splunk Web Search with the uploaded authentication events available as results.

Set the time range picker to All time.
Select one uploaded event to view its extracted fields.
Confirm that the field list includes timestamp, event_id, user, source_ip, status, logon_type, destination, and context.

A short SPL search can prove that Splunk indexed every data row. Before you run it, do you expect the total to match the 15 events in the file?

Count the uploaded events by running this search:

source="soc_windows_auth.csv" | stats count

What does this search prove?

The source="soc_windows_auth.csv" filter limits the search to events uploaded from your case file.
The pipe sends those events to the next search command.
The stats count command reduces the matching events to one total.

Select the Statistics tab.

You'll see one row with a count of 15. That result proves the complete case file is searchable.

Don't see a count of 15?

Confirm that the time range picker is set to All time.
Confirm that the source filename in the search is exactly soc_windows_auth.csv.
Return to the uploaded event results if the fields are missing. Confirm that the source type is csv.
Compare the local file with the full-code tab if the count is lower than 15.

Still stuck? Why is my Splunk CSV upload returning the wrong event count? You can also ask the Splunk Community about an environment-specific ingestion issue.

Case setup complete. Your SIEM can search all 15 authentication events.

Next, you'll run a failure threshold that surfaces two noisy login candidates.

Find the Noisy Login Candidates

Your 15 synthetic authentication events are now searchable in Splunk Cloud Platform. That controlled dataset gives your SOC case a safe evidence set.

Now you'll use SPL to turn individual events into a triage shortlist. The threshold produces quick leads without enough evidence for classification.

In this step, get ready to:

Inspect the available authentication fields in a baseline table.
Count failed logons for each user and source IP.
Keep every threshold match unresolved until more evidence is available.

Review the authentication events

A baseline table lets you confirm which fields are available before you aggregate the events. The table command keeps the evidence in a consistent column order.

In the Splunk Web Search tab from earlier, confirm All time remains selected.
Display the eight authentication fields by running this search:

source="soc_windows_auth.csv"
| table timestamp event_id user source_ip status logon_type destination context

What Does This Search Show?

The source="soc_windows_auth.csv" filter limits the results to your uploaded dataset.
The table command displays only the eight fields used throughout the investigation.
The field order makes each authentication event easier to scan.

Select the Statistics tab.

You'll see 15 rows with timestamp, event_id, user, source_ip, status, logon_type, destination, and context columns. The rows include failed logons plus successful logons.

Missing a Field From the Table?

Confirm that All time remains selected in the time range control.
Check that the source filter uses the exact file name soc_windows_auth.csv.
Compare every field name in the table command with the search above.

Help me find the missing fields in my baseline Splunk table.

Run the failure threshold

A threshold detector condenses repeated failures into a candidate list. Windows event 4625 records a failed account logon.

Before you run this search, do you expect one clear suspect or more than one candidate?

Select the existing query in the Splunk Web search bar.
Build the candidate shortlist by running this search:

source="soc_windows_auth.csv" event_id=4625
| stats count AS failed_logons BY user source_ip
| where failed_logons>=5
| sort - failed_logons

How Does the Threshold Work?

The event_id=4625 filter keeps failed logon events.
The stats count command totals records for each user and source_ip pair.
The AS failed_logons clause gives each total a clear column name.
The where failed_logons>=5 condition keeps candidates with at least five failures.
The sort - failed_logons command places the largest count first.

Select the Statistics tab.

You'll see alex at 203.0.113.77 with 6 failed logons. You'll also see backup_svc at 192.0.2.10 with 5 failed logons.

You now have your first triage shortlist. Both candidates remain unresolved because this query measures failures only.

Missing One of the Candidates?

Confirm that the time range still shows All time.
Check that the first line filters for event_id=4625.
Check that the threshold line uses failed_logons>=5.

Help me troubleshoot my high-failure candidate search.

Keep both candidates unresolved

A threshold match is an unresolved triage lead. Event correlation can later test whether these failures are followed by a successful logon.

Record alex from 203.0.113.77 with 6 failed logons as unresolved in the checkpoint below.
Record backup_svc from 192.0.2.10 with 5 failed logons as unresolved in the checkpoint below.

Before you rerun the search, which candidate do you expect to appear at the top of the table?

Confirm the unresolved shortlist by running the threshold search again:

source="soc_windows_auth.csv" event_id=4625
| stats count AS failed_logons BY user source_ip
| where failed_logons>=5
| sort - failed_logons

What Does This Final Check Prove?

The search consistently returns the same threshold-based shortlist while All time is selected. Its output contains no successful-logon count, so both rows stay unresolved.

Select the Statistics tab.

You should see alex first with 6 failed logons. The second row should show backup_svc with 5 failed logons.

Results Changed After the Rerun?

Restore the time range to All time.
Replace the search bar contents with the exact threshold query above.

Help me restore the expected two-row threshold result.

Your threshold has surfaced two candidates without forcing an early verdict. Next, you'll compare event order with login outcomes to decide which sequence needs escalation.

Correlate the Evidence

The threshold search in Splunk Cloud Platform found two unresolved candidates. Each candidate crossed the same failed-logon threshold.

Now you'll use SPL timeline searches for event correlation. Event order reveals whether repeated failures ended in successful access.

In this step, get ready to:

Inspect the backup-service timeline for a later successful logon.
Trace the alex activity in timestamp order.
Classify each candidate from its full event sequence.

Inspect the backup-service timeline

A threshold count removes event order. A timeline search puts the backup-service events back into sequence.

Replace the high-failure query in the Splunk search bar with this backup-service timeline query:

source="soc_windows_auth.csv" source_ip="192.0.2.10" user="backup_svc" (event_id=4624 OR event_id=4625)
| sort 0 timestamp
| table timestamp event_id user source_ip status logon_type destination context

How Does the Timeline Search Work?

The first line limits the evidence to backup_svc at 192.0.2.10.
The event filter keeps 4624 successes plus 4625 failures.
The sort 0 timestamp command orders every matching event by the synthetic timestamp.
The table command keeps the evidence fields in a consistent column order.

Before you run this search, form a quick expectation about whether the backup-service failures end in a successful logon.

Run the query from the Splunk search bar.
Select the Statistics tab.

You'll see five 4625 failures. Every row shows approved_backup_service context for backup_svc at 192.0.2.10.

No 4624 success appears after those failures. You now have the missing outcome evidence for this candidate.

Missing the Backup-Service Rows?

Confirm that All time remains selected.
Check that the source value is exactly soc_windows_auth.csv.
Check that the query uses backup_svc with 192.0.2.10.

Still stuck? Help me troubleshoot a missing backup-service timeline in Splunk.

Trace the suspicious source

The same timeline method now focuses on alex at 203.0.113.77. This view keeps failures plus successes from one source in a single sequence.

Replace the current query in the Splunk search bar with this suspicious-source timeline query:

source="soc_windows_auth.csv" source_ip="203.0.113.77" user="alex" (event_id=4624 OR event_id=4625)
| sort 0 timestamp
| table timestamp event_id user source_ip status logon_type destination context

How Does This Search Reveal the Sequence?

The first line isolates the alex activity from 203.0.113.77.
The event filter includes failed logons plus successful logons.
The timestamp sort exposes the order in which the authentication attempts occurred.
The final table preserves the destination plus context needed for triage.

Before you run this search, form a quick expectation about which event type appears last.

Run the query from the Splunk search bar.
Select the Statistics tab.

You'll see seven rows in timestamp order. The first six rows are 4625 failures from 2026-08-30T09:00:00Z through 2026-08-30T09:02:30Z.

The final row is a 4624 success at 2026-08-30T09:03:00Z. Every event uses logon type 3 for FILE-SRV-01 with external_unknown context.

You found the sequence the threshold hid. The same user-source pair moves from repeated failures to successful access.

Missing the Alex Success?

Confirm that All time remains selected.
Check that the query includes both event_id=4624 plus event_id=4625.
Check that the source pair is alex with 203.0.113.77.

Still stuck? Help me find the missing successful logon in my Splunk timeline.

Reach the incident verdicts

Correlation compares each candidate's event order with its outcome. Logon type 3 confirms that these records represent network logons.

Classify backup_svc from 192.0.2.10 as an expected-service false positive that requires tuning.
Classify alex from 203.0.113.77 as a likely true positive for suspected brute-force account compromise.

Why Do the Verdicts Differ?

The backup-service candidate contains failures with approved-service context. No successful access follows the failures.

The alex candidate contains six failures followed by a success from the same source. That sequence supports escalation as a suspected account compromise.

Before you verify the verdict, predict which event should appear last if the likely compromise classification holds.

Run the current suspicious-source timeline query again from the Splunk search bar.
Select the Statistics tab.

You'll see six 4625 failures for alex followed by one 4624 success from 203.0.113.77.

Your evidence now separates expected service noise from a likely compromise. Next, you'll turn the two searches into an investigation dashboard that makes the case easy to review.

Build the Investigation Dashboard

Your threshold search identifies the noisy candidates. Your timeline search isolates the likely compromise.

Raw searches help during triage. A dashboard in Splunk Cloud Platform turns those results into a clear investigation story.

In this step, get ready to:

Save the high-failure search as the first panel in a private dashboard.
Add the suspicious login timeline as the second panel.
Arrange the two panels into investigation order.

Create the candidate dashboard panel

Each dashboard panel is powered by a search. The first panel preserves the broad threshold result that began your triage.

Replace the current search by pasting this SPL query into the search bar:

source="soc_windows_auth.csv" event_id=4625
| stats count AS failed_logons BY user source_ip
| where failed_logons>=5
| sort - failed_logons

What does this search preserve?

The first line retrieves failed event 4625 records from soc_windows_auth.csv.
The stats command groups failures by user plus source_ip. It stores each total in failed_logons.
The where condition keeps candidates with at least five failures.
The final line places the largest failure count first.

Run the search by selecting Search.
Select the Statistics tab.

You should see alex at 203.0.113.77 with 6 failed logons. You should also see backup_svc at 192.0.2.10 with 5.

Select Save As above the search results.
Select Dashboard panel.
Select New for the dashboard.
Enter SOC Authentication Investigation as the dashboard name.
Keep the dashboard permissions set to Private.
Enter High-Failure Candidates as the Panel title.
Select Save.

Your first panel is saved. It now keeps the noisy candidate list ready for review.

Missing a candidate or the save option?

Confirm that All time remains selected before rerunning the search.
Compare the query with the block above if the result does not contain two rows.
Confirm that you are viewing search results if Save As is unavailable.

Still stuck? Help me save my high-failure SPL results as a private Splunk dashboard panel.

Add the suspicious timeline panel

The second panel captures the evidence that changed your classification. Its ordered events show the transition from repeated failures to successful access.

Return to Splunk Web Search by selecting Search in the Apps bar.
Replace the current search by pasting this timeline query into the search bar:

source="soc_windows_auth.csv" source_ip="203.0.113.77" user="alex" (event_id=4624 OR event_id=4625)
| sort 0 timestamp
| table timestamp event_id user source_ip status logon_type destination context

What does this timeline show?

The first filter isolates alex at 203.0.113.77.
The event expression keeps event IDs 4624 plus 4625.
The sort 0 timestamp command places every matching event in timestamp order.
The table command keeps the fields needed for evidence review.

Run the timeline search by selecting Search.
Select the Statistics tab.

You should see seven rows. The six 4625 failures appear before the 4624 success.

Select Save As above the search results.
Select Dashboard panel.
Select Existing for the dashboard.
Choose SOC Authentication Investigation from the dashboard list.
Enter Suspicious Login Timeline as the Panel title.
Select Save.

The evidence timeline now has a permanent place beside the candidate summary. Your investigation can be reviewed without rerunning either search.

Timeline saved to the wrong dashboard?

Confirm that Existing is selected in the dashboard options.
Confirm that the selected dashboard is SOC Authentication Investigation.
Rerun the exact timeline query above if the panel does not show seven ordered events.

Need a hand? Help me add my suspicious login timeline to the existing Splunk dashboard.

Arrange and verify the dashboard

A dashboard should lead with the broad signal. The ordered event sequence then supplies the evidence behind the classification.

Select View Dashboard from the save confirmation.
Select Edit at the top of the dashboard.
Drag the High-Failure Candidates panel by its drag-and-drop bar until it appears above Suspicious Login Timeline.

Before you save the layout, which panel should a reviewer encounter first?

Select Save in the dashboard editor.

Dashboard Checkpoint

The dashboard title is SOC Authentication Investigation. Its permissions remain Private.

The High-Failure Candidates panel appears first. It shows alex at 203.0.113.77 with 6 failures. It also shows backup_svc at 192.0.2.10 with 5 failures.

The Suspicious Login Timeline panel appears second. It presents six 4625 failures followed by one 4624 success for alex.

Your dashboard now presents the noisy threshold beside the evidence that resolves it. Next, you'll turn that investigation into a portfolio incident report.

Write the Portfolio Incident Report

Your Splunk Cloud Platform dashboard now puts the two threshold candidates beside the ordered login sequence. You have enough evidence to make a clear incident decision.

Analysts need to turn technical evidence into guidance that another person can act on. You'll preserve your SPL searches in a Markdown file before writing the case assessment.

In this step, get ready to:

Save the four investigation searches as a local query file.
Write an incident report with evidence and response recommendations.
Reopen both files to verify the completed investigation package.

Save the investigation searches

A query file makes your investigation repeatable after the cloud trial ends. It also shows how each conclusion connects to a specific search.

Select Start on the Windows taskbar.
Type Notepad into the search bar.
Select Windows Notepad from the results.
Build the first half of soc_investigation_queries.md by pasting the code below into the blank document:

# SOC Authentication Investigation Queries

## 1. Baseline event table

```spl
source="soc_windows_auth.csv"
| table timestamp event_id user source_ip status logon_type destination context
```

## 2. High-failure candidates

```spl
source="soc_windows_auth.csv" event_id=4625
| stats count AS failed_logons BY user source_ip
| where failed_logons>=5
| sort - failed_logons
```

What do these searches preserve?

The baseline search displays the fields used throughout the investigation.
The high-failure search groups failed logons by account and source.
The threshold keeps candidates with at least five failures for further analysis.

Select File in the Notepad menu bar.
Select Save As.
Choose the folder that contains soc_windows_auth.csv.
Enter soc_investigation_queries.md as the file name.
Set Save as type to All files (*.*).
Select Save.

You should see soc_investigation_queries.md as the saved document name in Windows Notepad.

Did Notepad add a text extension?

Repeat the save process if the file ends in .txt. Make sure Save as type is set to All files (*.*).

Still stuck? Help me save a Markdown file in Windows Notepad without adding a .txt extension.

Place the cursor after the final code fence in soc_investigation_queries.md.
Add the two timeline searches by pasting the code below:

## 3. Backup-service timeline

```spl
source="soc_windows_auth.csv" source_ip="192.0.2.10" user="backup_svc" (event_id=4624 OR event_id=4625)
| sort 0 timestamp
| table timestamp event_id user source_ip status logon_type destination context
```

## 4. Suspicious-source timeline

```spl
source="soc_windows_auth.csv" source_ip="203.0.113.77" user="alex" (event_id=4624 OR event_id=4625)
| sort 0 timestamp
| table timestamp event_id user source_ip status logon_type destination context
```

What do the timelines preserve?

The backup-service timeline preserves the five failures that had no later success.
The suspicious-source timeline preserves the six failures followed by one success.
Sorting by timestamp keeps each event sequence in chronological order.

Save soc_investigation_queries.md in Windows Notepad.
Scroll through the saved file to confirm it contains headings numbered 1 through 4.

You should see one baseline search and three investigation searches. Together they reproduce the path from raw events to the suspicious login sequence.

Missing one of the searches?

Check that the backup-service timeline begins after the closing fence for the high-failure search. A missing fence can make two searches look like one block.

Need a second pair of eyes? Help me compare my investigation query file with the four required searches.

✔️ Awesome, I've got everything!

Great. Your saved query file now preserves all four searches used in the investigation.

ⓧ I'd like to double check the full code

Compare the complete contents of soc_investigation_queries.md with this reference:

# SOC Authentication Investigation Queries

## 1. Baseline event table

```spl
source="soc_windows_auth.csv"
| table timestamp event_id user source_ip status logon_type destination context
```

## 2. High-failure candidates

```spl
source="soc_windows_auth.csv" event_id=4625
| stats count AS failed_logons BY user source_ip
| where failed_logons>=5
| sort - failed_logons
```

## 3. Backup-service timeline

```spl
source="soc_windows_auth.csv" source_ip="192.0.2.10" user="backup_svc" (event_id=4624 OR event_id=4625)
| sort 0 timestamp
| table timestamp event_id user source_ip status logon_type destination context
```

## 4. Suspicious-source timeline

```spl
source="soc_windows_auth.csv" source_ip="203.0.113.77" user="alex" (event_id=4624 OR event_id=4625)
| sort 0 timestamp
| table timestamp event_id user source_ip status logon_type destination context
```

Write the incident report

An incident report connects evidence to an operational decision. The first half records the case status and the authentication timeline.

Create a blank document from the File menu in Windows Notepad.
Add the case details and evidence by pasting the code below:

# Incident Report: SOC-001

Analyst: Your Name
Date investigated: 2026-08-30
Status: Escalate for containment and deeper investigation
Classification: Likely true positive - suspected brute-force account compromise
Severity: High

## Executive Summary

Splunk analysis identified six failed network logons for the account `alex` from `203.0.113.77`, followed by one successful network logon from the same source. The sequence is consistent with a likely brute-force attempt that obtained valid access. A second high-failure candidate, `backup_svc` from `192.0.2.10`, had five failures but no successful logon and was classified as an expected-service false positive for this exercise.

## Evidence

- Destination: `FILE-SRV-01`
- Account: `alex`
- Source: `203.0.113.77`
- Window: `2026-08-30T09:00:00Z` to `2026-08-30T09:03:00Z`
- Failed logons: `6` events with event ID `4625`
- Successful logons: `1` event with event ID `4624`
- Logon type: `3`, network logon

How does this establish the case?

The opening lines record the incident identifier and escalation status.
The executive summary distinguishes the likely compromise from the expected service activity.
The evidence section records the account and source involved in the suspicious sequence.
The event counts establish six failed logons followed by one successful logon.

Select File in the Notepad menu bar.
Select Save As.
Choose the folder that contains soc_windows_auth.csv.
Enter incident_report.md as the file name.
Set Save as type to All files (*.*).
Select Save.

You should see incident_report.md as the saved document name. The report now contains the case summary and supporting evidence.

Does the report look incomplete?

Confirm that the evidence list ends with logon type 3. The assessment and response sections belong directly below it.

Need help checking the structure? Help me verify the first half of my SOC incident report.

Place the cursor after the network logon evidence item in incident_report.md.
Complete the assessment and response by pasting the code below:

## Analyst Assessment

The failed-logon threshold initially returned two candidates, which showed that failure counts alone were not sufficient for classification. Timeline correlation isolated the stronger risk pattern for `alex`: repeated failures followed by a success from the same source. The backup-service activity lacked a successful logon and had approved-service context, so it should be tuned rather than escalated.

## Recommended Response

1. Contain access by disabling or resetting the affected account according to organizational procedure.
2. Preserve the authentication evidence and collect relevant endpoint and server logs around the incident window.
3. Investigate activity performed by `alex` after the successful logon and search for the same source across other accounts.
4. Block or monitor the source according to organizational policy and validate recovery before restoring normal access.

## Portfolio Summary

This investigation demonstrates SIEM ingestion, SPL searching, threshold detection, event correlation, false-positive analysis, dashboard creation, and incident reporting.

How does the report support action?

The assessment explains why timeline correlation supports the true-positive classification.
The response starts with containment of the affected account.
The next actions preserve evidence and investigate activity after the successful logon.
The final action covers source monitoring and recovery validation.

Save incident_report.md in Windows Notepad.
Scroll through the file to confirm it ends with the Portfolio Summary section.

You should now see a complete report that moves from evidence to assessment. Its response section gives another analyst a practical next move.

Are any response sections missing?

Check below the evidence list for the analyst assessment and four numbered response actions. The portfolio summary should appear last.

Still unsure? Help me check whether my incident report includes every required assessment and response section.

✔️ Awesome, I've got everything!

Your report structure is complete. The remaining edit makes the analyst line your own.

ⓧ I'd like to double check the full code

Compare the complete report structure with this reference:

# Incident Report: SOC-001

Analyst: Your Name
Date investigated: 2026-08-30
Status: Escalate for containment and deeper investigation
Classification: Likely true positive - suspected brute-force account compromise
Severity: High

## Executive Summary

Splunk analysis identified six failed network logons for the account `alex` from `203.0.113.77`, followed by one successful network logon from the same source. The sequence is consistent with a likely brute-force attempt that obtained valid access. A second high-failure candidate, `backup_svc` from `192.0.2.10`, had five failures but no successful logon and was classified as an expected-service false positive for this exercise.

## Evidence

- Destination: `FILE-SRV-01`
- Account: `alex`
- Source: `203.0.113.77`
- Window: `2026-08-30T09:00:00Z` to `2026-08-30T09:03:00Z`
- Failed logons: `6` events with event ID `4625`
- Successful logons: `1` event with event ID `4624`
- Logon type: `3`, network logon

## Analyst Assessment

The failed-logon threshold initially returned two candidates, which showed that failure counts alone were not sufficient for classification. Timeline correlation isolated the stronger risk pattern for `alex`: repeated failures followed by a success from the same source. The backup-service activity lacked a successful logon and had approved-service context, so it should be tuned rather than escalated.

## Recommended Response

1. Contain access by disabling or resetting the affected account according to organizational procedure.
2. Preserve the authentication evidence and collect relevant endpoint and server logs around the incident window.
3. Investigate activity performed by `alex` after the successful logon and search for the same source across other accounts.
4. Block or monitor the source according to organizational policy and validate recovery before restoring normal access.

## Portfolio Summary

This investigation demonstrates SIEM ingestion, SPL searching, threshold detection, event correlation, false-positive analysis, dashboard creation, and incident reporting.

Find Analyst: Your Name near the top of incident_report.md.
Replace Your Name with your own name.
Save incident_report.md.

Your analyst line now identifies you as the person who completed the investigation.

Review the final case files

The final check proves that your local portfolio files can stand on their own. Each conclusion should remain traceable to the dashboard evidence.

Before you reopen the files, which details should prove that the investigation is reproducible and ready for another analyst?

Close the open soc_investigation_queries.md document in Windows Notepad.
Close the open incident_report.md document in Windows Notepad.
Use the File menu to reopen soc_investigation_queries.md from the folder containing soc_windows_auth.csv.
Use the same menu to reopen incident_report.md.
Confirm that the query file contains headings numbered 1 through 4.
Confirm that the report timeline covers 2026-08-30T09:00:00Z to 2026-08-30T09:03:00Z.
Confirm that the report classifies the incident as a likely true positive with High severity.
Confirm that the response section covers containment, evidence preservation, investigation, source monitoring, and recovery.

What should you see?

The query file contains the baseline table and three investigation searches.
The report identifies incident SOC-001 as a likely true positive involving alex.
The evidence records six event ID 4625 failures followed by one event ID 4624 success from 203.0.113.77.
The report gives another analyst clear containment and recovery actions.

Strong finish. You have turned raw authentication events into a documented case that another analyst can review and act on.

Secret mission

Automate the Correlation Rule

Your manual triage found the pattern that separates a likely compromise from expected service noise. Turn that reasoning into a reusable SPL correlation rule that keeps the confirmed compromise while suppressing the backup-service false positive.

Clean Up Your Resources

Choose whether to keep your trial available, pause your investigation, or remove the resources you control. The 14-day Splunk Cloud Platform trial costs $0 with no credit card required.

Resources you used:

Temporary Splunk Cloud Platform trial instance containing the uploaded soc_windows_auth.csv source.
Private SOC Authentication Investigation dashboard with three panels.
Local soc_windows_auth.csv dataset.
Local soc_investigation_queries.md query file.
Local incident_report.md case report.

Keep everything running

No action is needed. Choose this option while you are still reviewing the investigation during the trial.

Continue using the SOC Authentication Investigation dashboard until the trial expires.
Keep soc_windows_auth.csv as the reusable synthetic dataset.
Keep soc_investigation_queries.md as the record of all five searches.
Keep incident_report.md as the completed case record.

Splunk removes the trial instance when the 14-day period ends. Your local files remain available on your Windows PC.

Those local copies preserve the evidence after the cloud data disappears.

Pause - I'll come back to this later

A pause leaves your local evidence untouched. No process continues running on your Windows PC.

Switch back to the Splunk Cloud Platform trial in Microsoft Edge.
Sign out of Splunk Cloud Platform.
Leave soc_windows_auth.csv where you saved it.
Leave soc_investigation_queries.md where you saved it.
Leave incident_report.md where you saved it.

Your trial keeps counting down while you are signed out. Splunk deletes the instance when the 14-day period ends.

All cloud data is deleted with it.

Delete - I don't want to use this again

Deleting your local copies is permanent. The remaining cloud cleanup follows the trial expiry process.

Disable the private dashboard:

In the Splunk Web session from earlier, select Settings.
Select User interface.
Select Views.
Find the dashboard ID associated with SOC Authentication Investigation.
Select Disable for that dashboard.

You have now taken the three-panel dashboard out of active use.

Finish the cloud cleanup:

Leave the trial to reach its expiry date.

Splunk deletes the trial instance when the 14-day period ends. The searchable soc_windows_auth.csv upload disappears with it.

The disabled dashboard data is deleted at the same time.

Delete the local files:

Use Windows File Explorer to locate soc_windows_auth.csv where you saved it.
Delete soc_windows_auth.csv.
Use Windows File Explorer to locate soc_investigation_queries.md where you saved it.
Delete soc_investigation_queries.md.
Use Windows File Explorer to locate incident_report.md where you saved it.
Delete incident_report.md.

You have cleared the investigation files from your PC. Splunk completes the remaining cloud deletion when the trial expires.

Nice Work!

Investigation complete! You turned 15 synthetic Windows authentication events into a high-severity likely compromise finding in Splunk Cloud Platform.

You've learned how to:

Built a searchable SIEM dataset from synthetic Windows authentication events. Used SPL searches to identify two high-failure candidates.
Applied event correlation to connect event 4625 failures with an event 4624 success. Classified alex as a likely true positive while treating backup_svc as a false positive.
Built a three-panel investigation dashboard that presents the candidate summary and evidence timeline. Wrote a portfolio incident report in incident_report.md with the classification and recommended response.
Completed the optional Secret Mission by encoding a tuned correlation rule. The rule keeps alex while suppressing backup_svc.

Ready to quiz yourself?