Detect a Brute Force Attack with Splunk

Build a Splunk detection and dashboard for Windows failed-login attacks.

Introduction

30 Second Summary

Several failed sign-ins can look harmless until one computer hammers the same account within minutes. Security teams need a fast way to separate that burst from ordinary sign-in mistakes.

In this project, you will build a security investigation in Splunk Cloud Platform using safe Windows Event ID 4625 data. You will use SPL to separate a concentrated brute-force burst from slow background failures.

What You'll Build

You'll open a SOC-style dashboard where a concentrated attack burst stands out within the surrounding failed-logon activity.

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

  • A searchable failed-logon investigation that exposes the context behind each failed sign-in.
  • A five-minute brute-force alert that singles out the rapid failures against Administrator. The slower svc-backup failures stay out of the results.
  • A SOC dashboard that turns the full investigation into one view you can demonstrate.
  • Secret Mission: Add a dashboard table that catches one source attempting several accounts within five minutes.

Are there any prerequisites?

You need a Windows device with internet access. You do not need an existing Splunk account because the setup includes a 14-day trial with no credit card required.

Before We Start

Before any setup begins, lock in the purpose of the SOC-style failed-login dashboard you are about to build. Your goal is to help an analyst decide whether a brute-force match needs investigation.

Set Up the Splunk Lab

A SOC investigation needs a working search environment. Unconfirmed access can stop the project before the first failed-login event becomes searchable.

In this step, you will confirm that Microsoft Edge can reach the web. You will also confirm that Windows Notepad is available for creating the dataset later.

You will then activate Splunk Cloud Platform. A successful internal search proves that your lab is ready.

In this step, get ready to:
  • Verify the required Windows apps.
  • Activate a Splunk Cloud Platform trial.
  • Prove that Search & Reporting returns internal events.
Verify the Windows tools

Microsoft Edge gives you access to the Splunk web interface. Windows Notepad gives you a simple place to create the fixture used in the next step.

  • Press the Windows key to open Windows search.
  • Type Microsoft Edge.
  • Press Enter.

✔️ Microsoft Edge opens

Microsoft Edge opens successfully. Your browser requirement is complete.

ⓧ Microsoft Edge is unavailable

Running the installer may trigger a Windows permission prompt. Approving that request allows Microsoft Edge to install.

  • Open the official Microsoft Edge download page from another browser on your Windows device.
  • Download the Windows installer from the page.
  • Run the installer from your Downloads folder.
  • Approve the installation request if Windows shows one.
  • Press the Windows key after installation.
  • Type Microsoft Edge.
  • Press Enter.
  • Select Start from the Windows taskbar.
  • Type Notepad.
  • Select Notepad from the results.

✔️ Notepad opens

Notepad opens to a blank document. Your text editor requirement is complete.

ⓧ Notepad is unavailable

  • Open the official Windows Notepad listing in Microsoft Store.
  • Install the free Windows app from the listing.
  • Select Start after installation.
  • Type Notepad.
  • Select Notepad from the results.

Notepad opens to a blank document when the installation succeeds.

Your two local tools are ready for the Splunk lab.

Having trouble opening an app?

  • Check whether Windows is waiting for administrator approval.
  • Restart Windows search if the newly installed app does not appear.

Help me troubleshoot an app installation on my Windows device.

Activate the Splunk Cloud trial

Splunk Cloud Platform keeps the lab in your browser. This lets you focus on searches instead of local server installation.

The free trial lasts 14 days. It supports ingestion up to 5 GB/day without requiring a credit card.

A Splunk.com account connects the trial to you. Your next screen depends on whether you already have an account.

✔️ I have a Splunk.com account

  • Sign in with your existing Splunk.com account.

ⓧ I need a Splunk.com account

  • Select the registration option on the account page.
  • Enter the account details requested on the registration page.
  • Finish creating your Splunk.com account.
  • Return to the Splunk Cloud Platform trial page in Microsoft Edge.
  • Select the free trial option on the trial page.
  • Complete the trial details shown on the page.
  • Submit your trial request.
  • Wait until your Splunk Cloud Platform instance is provisioned.
  • Open the provisioned Splunk instance.

You will see Splunk Home after the instance opens. The Apps panel gives you access to the search interface.

That clears the biggest setup hurdle. Your cloud lab is active.

Can't reach your Splunk instance?

  • Confirm that you activated the trial through the official trial page.
  • Refresh the trial page after signing in if the instance link does not appear.
  • Confirm that the trial request finished provisioning before opening the instance.

Help me access my Splunk Cloud Platform trial.

Verify Search & Reporting

An SPL search can confirm that the instance accepts queries. The internal index already contains events generated by Splunk.

  • From Splunk Home, select Search & Reporting in the Apps panel.
  • Keep the time range picker on its default recent range.

Before you run the search, do you expect a new trial to already contain events?

  • Enter this SPL search in the Search bar:
index=_internal

What does this search do?

  • The index=_internal filter limits the results to internal Splunk events.
  • The returned events prove that your trial can execute searches before you upload the lab dataset.
  • Submit the search by pressing Enter.

You will see Splunk internal events under the Events tab. The search interface remains available above the results.

You have cleared the setup step. Splunk can now search its own internal activity.

Don't see internal events?

  • Re-enter index=_internal exactly as shown.
  • Confirm that you opened Search & Reporting from your provisioned trial instance.
  • Confirm that the search results are displayed on the Events tab.

Help me debug my Splunk internal search.

Your Splunk lab can search its own events. Next, you will load the safe failed-login dataset that powers the investigation.

Load the Failed-Login Dataset

Your Splunk Cloud Platform trial can now search internal events. It still needs authentication data before you can investigate failed logons.

Exported .evtx files do not work with Splunk Web Upload. A synthetic CSV preserves searchable Windows Event ID 4625 fields while keeping this lab focused on the evidence.

In this step, get ready to:
  • Create the failed-login CSV fixture in Windows Notepad.
  • Upload the fixture with a custom source type in the default index.
  • Verify that all 20 historical events are searchable with the expected fields.
Create the CSV fixture

Each CSV row becomes one searchable event. The header row gives Splunk the field names used throughout the investigation.

Why Use a CSV?

Live Windows collection adds forwarder setup before you can investigate anything. This fixture gives you safe authentication data with the fields needed for the detection workflow.

  • Press the Windows key to open the Windows search bar.
  • Type Notepad and press Enter to open Windows Notepad.
  • Paste the exact dataset below into the blank document:
timestamp,EventCode,TargetUserName,IpAddress,LogonType,WorkstationName,Computer
2026-10-16T08:00:00Z,4625,svc-backup,10.20.30.50,3,APP01,FILE01
2026-10-16T08:10:00Z,4625,svc-backup,10.20.30.50,3,APP01,FILE01
2026-10-16T08:15:00Z,4625,jsmith,10.20.30.21,3,LAPTOP21,FILE01
2026-10-16T08:16:00Z,4625,jsmith,10.20.30.21,3,LAPTOP21,FILE01
2026-10-16T08:20:00Z,4625,svc-backup,10.20.30.50,3,APP01,FILE01
2026-10-16T08:30:00Z,4625,svc-backup,10.20.30.50,3,APP01,FILE01
2026-10-16T08:40:00Z,4625,svc-backup,10.20.30.50,3,APP01,FILE01
2026-10-16T08:50:00Z,4625,svc-backup,10.20.30.50,3,APP01,FILE01
2026-10-16T09:00:05Z,4625,Administrator,10.20.30.40,3,UNKNOWN,SERVER01
2026-10-16T09:00:40Z,4625,Administrator,10.20.30.40,3,UNKNOWN,SERVER01
2026-10-16T09:01:15Z,4625,Administrator,10.20.30.40,3,UNKNOWN,SERVER01
2026-10-16T09:02:05Z,4625,Administrator,10.20.30.40,3,UNKNOWN,SERVER01
2026-10-16T09:03:20Z,4625,Administrator,10.20.30.40,3,UNKNOWN,SERVER01
2026-10-16T09:04:10Z,4625,Administrator,10.20.30.40,3,UNKNOWN,SERVER01
2026-10-16T10:00:00Z,4625,a.nguyen,10.20.30.60,3,KIOSK01,DC01
2026-10-16T10:00:30Z,4625,b.smith,10.20.30.60,3,KIOSK01,DC01
2026-10-16T10:01:00Z,4625,c.patel,10.20.30.60,3,KIOSK01,DC01
2026-10-16T10:01:30Z,4625,d.garcia,10.20.30.60,3,KIOSK01,DC01
2026-10-16T10:02:00Z,4625,e.brown,10.20.30.60,3,KIOSK01,DC01
2026-10-16T10:02:30Z,4625,f.wilson,10.20.30.60,3,KIOSK01,DC01

How Is This Dataset Structured?

  • The first row defines the timestamp plus six Windows authentication fields.
  • The next 20 rows represent synthetic failed-logon events with EventCode set to 4625.
  • The fixed timestamps let every learner investigate the same historical evidence.
  • Select File in Notepad.
  • Select Save As.
  • Choose your Desktop as the save location.
  • Enter windows_failed_logins_lab.csv in the File name box.
  • Select All Files (*.*) in the Save as type box.
  • Select UTF-8 in the Encoding box.
  • Select Save.

You should see windows_failed_logins_lab.csv in the Notepad title bar. This confirms that the fixture now exists on your Desktop.

Did Notepad Add .txt?

Return to Save As if the filename ends with .csv.txt. Select All Files (*.*) before saving the exact windows_failed_logins_lab.csv filename again.

Help me save the CSV fixture with the exact filename in Windows Notepad.

✔️ Awesome, I've got everything!

Your CSV fixture is saved with the exact filename needed for the upload.

ⓧ I'd like to double check the full code

timestamp,EventCode,TargetUserName,IpAddress,LogonType,WorkstationName,Computer
2026-10-16T08:00:00Z,4625,svc-backup,10.20.30.50,3,APP01,FILE01
2026-10-16T08:10:00Z,4625,svc-backup,10.20.30.50,3,APP01,FILE01
2026-10-16T08:15:00Z,4625,jsmith,10.20.30.21,3,LAPTOP21,FILE01
2026-10-16T08:16:00Z,4625,jsmith,10.20.30.21,3,LAPTOP21,FILE01
2026-10-16T08:20:00Z,4625,svc-backup,10.20.30.50,3,APP01,FILE01
2026-10-16T08:30:00Z,4625,svc-backup,10.20.30.50,3,APP01,FILE01
2026-10-16T08:40:00Z,4625,svc-backup,10.20.30.50,3,APP01,FILE01
2026-10-16T08:50:00Z,4625,svc-backup,10.20.30.50,3,APP01,FILE01
2026-10-16T09:00:05Z,4625,Administrator,10.20.30.40,3,UNKNOWN,SERVER01
2026-10-16T09:00:40Z,4625,Administrator,10.20.30.40,3,UNKNOWN,SERVER01
2026-10-16T09:01:15Z,4625,Administrator,10.20.30.40,3,UNKNOWN,SERVER01
2026-10-16T09:02:05Z,4625,Administrator,10.20.30.40,3,UNKNOWN,SERVER01
2026-10-16T09:03:20Z,4625,Administrator,10.20.30.40,3,UNKNOWN,SERVER01
2026-10-16T09:04:10Z,4625,Administrator,10.20.30.40,3,UNKNOWN,SERVER01
2026-10-16T10:00:00Z,4625,a.nguyen,10.20.30.60,3,KIOSK01,DC01
2026-10-16T10:00:30Z,4625,b.smith,10.20.30.60,3,KIOSK01,DC01
2026-10-16T10:01:00Z,4625,c.patel,10.20.30.60,3,KIOSK01,DC01
2026-10-16T10:01:30Z,4625,d.garcia,10.20.30.60,3,KIOSK01,DC01
2026-10-16T10:02:00Z,4625,e.brown,10.20.30.60,3,KIOSK01,DC01
2026-10-16T10:02:30Z,4625,f.wilson,10.20.30.60,3,KIOSK01,DC01

How to Compare the Fixture

Check that your header and all 20 data rows match this reference. Even one missing comma can change how Splunk extracts the fields.

Upload the CSV to Splunk

A source type tells Splunk how to parse incoming data. Saving the automatic csv selection as windows_failed_logins_lab gives this fixture a project-specific identity.

  • Switch back to Microsoft Edge with your active Splunk Cloud Platform trial.
  • Select Settings in the Splunk navigation.
  • Select Add Data.
  • Select Upload.
  • Use the file picker to select windows_failed_logins_lab.csv from your Desktop.
  • Select Next.

The Set Source type preview opens with csv selected automatically. The preview lets you check how Splunk separates events before indexing them.

  • Confirm that the source type is set to csv.
  • Confirm that each data row appears as one event.
  • Confirm that the first row supplies the field names.
  • Confirm that the timestamp values are extracted automatically.
  • Select Save As.
  • Enter windows_failed_logins_lab as the new source type name.
  • Select Save.
  • Select Next to continue to Input Settings.

Why Save a Custom Source Type?

The custom source type becomes a reusable search filter for this lab. It keeps these events separate from unrelated CSV uploads.

  • Keep the default index selected in Input Settings.
  • Select Review.
  • Select Submit.
  • Select Start Searching.

Splunk opens Search & Reporting with the uploaded data ready to query. Your CSV rows are now indexed events.

Does the Preview Look Wrong?

Check that the uploaded file ends with .csv instead of .csv.txt. Return to Notepad if the header or data rows do not match the full-file reference.

Help me troubleshoot the CSV preview or upload in Splunk Cloud Platform.

Verify all 20 events

The fixture uses fixed historical timestamps from October 2026. The default recent time range can hide those events, so this verification searches across All time.

  • Select the time range picker in Search & Reporting.
  • Select All time.
  • Predict whether Splunk should return every data row from the CSV before running the search.
  • Search the uploaded fixture by running this query:
sourcetype=windows_failed_logins_lab EventCode=4625

What Does This Search Do?

  • The sourcetype filter limits the search to your uploaded fixture.
  • The EventCode=4625 filter keeps failed Windows logon events.

You should see 20 events in the results. This matches the 20 data rows in windows_failed_logins_lab.csv.

  • Select the Events tab if another results tab is active.
  • Open one returned event to inspect its extracted fields.

You should see timestamp, EventCode, TargetUserName, IpAddress, LogonType, WorkstationName, and Computer with the event.

Strong start. Your 20 failed-logon records are now indexed with the investigation fields intact.

Do You See Fewer Than 20 Events?

Confirm that the time range is All time. Check that the query uses the exact windows_failed_logins_lab source type.

Help me find why my Splunk search does not return all 20 failed-login events.

Your authentication dataset is searchable. Next, you will inspect the failed logons and compare the activity linked to each source.

Investigate the Failed Logons

Your failed-login dataset is now searchable in Splunk Cloud Platform. You can begin investigating the authentication activity.

A raw total can make a slow misconfiguration look identical to a rapid attack. You will expose that weakness with an all-time SPL rule.

In this step, get ready to:
  • Inspect raw Windows Event ID 4625 activity.
  • Run a naive all-time aggregation with a five-failure threshold.
  • Compare the timestamps behind both flagged patterns.
Inspect the failed logon events

Windows Event ID 4625 records a failed logon on the computer where the attempt occurred. The event fields supply the context for your investigation.

  • Switch back to Search & Reporting in Splunk Cloud Platform.
  • Set the time range picker to All time.
  • Inspect the event fields by running this search:
sourcetype=windows_failed_logins_lab EventCode=4625
| table _time EventCode TargetUserName IpAddress LogonType WorkstationName Computer

What does this search reveal?

  • The first line selects events from the windows_failed_logins_lab source type with EventCode=4625.
  • The table command limits the results to investigation fields.
  • The _time field shows when each failed logon occurred.
  • The remaining fields identify the attempted account plus the systems involved.
  • Open the Statistics tab.
  • Confirm that the table contains 20 rows.

You should see a timestamp for every failed logon. Each row also shows its account plus its source and destination context.

Missing events or fields?

  • Set the time range to All time if fewer than 20 rows appear.
  • Check the capitalization of each field if a table column is missing.
  • Compare the source type in your search with windows_failed_logins_lab if zero events appear.

Help me diagnose missing events or fields in this Splunk search.

Test an all-time threshold

A threshold converts event volume into a detection signal. This first version counts failures across the full historical range.

Before you run this search, which account and source pairs do you think will meet five failures?

  • Test the five-failure threshold by running this search:
sourcetype=windows_failed_logins_lab EventCode=4625
| stats count AS failed_attempts BY IpAddress TargetUserName
| where failed_attempts >= 5
| sort - failed_attempts

How does the aggregation work?

  • The stats command counts events for each unique source IP and target account pair.
  • The AS clause names the count failed_attempts.
  • The where command keeps pairs with at least five failures.
  • The sort command orders larger counts before smaller counts.
  • Open the Statistics tab.
  • Compare the account and source pairs in the results.

You will see Administrator from 10.20.30.40. You will also see svc-backup from 10.20.30.50.

Each row has a failed_attempts value of 6. The rule gives both patterns the same severity.

You found the blind spot. The all-time count has discarded the speed of each pattern.

Only seeing one result?

  • Keep All time selected if either expected row is missing.
  • Check that the threshold uses failed_attempts >= 5.
  • Confirm that the grouping fields are IpAddress and TargetUserName.

Help me troubleshoot why my naive Splunk aggregation does not return both expected pairs.

Compare the failure timing

Equal totals can occupy very different time windows. Returning to event-level timestamps reveals the concentration of each pattern.

Before you return to the timestamps, which six-event pattern do you expect to occupy the shorter window?

  • Restore the event-level detail by running this search:
sourcetype=windows_failed_logins_lab EventCode=4625
| table _time EventCode TargetUserName IpAddress LogonType WorkstationName Computer

Why return to event-level results?

  • This search displays one row per event so that _time is visible again.
  • The account and source fields let you match each timestamp to one of the flagged pairs.
  • Open the Statistics tab.
  • Review the six Administrator rows from 10.20.30.40.
  • Compare the earliest and latest timestamps for those rows.
  • Review the six svc-backup rows from 10.20.30.50.
  • Compare the earliest and latest timestamps for those rows.

The Administrator attempts occupy four minutes and five seconds. The svc-backup attempts occupy fifty minutes.

The naive aggregation flags both pairs despite this timing difference. Your timestamp comparison proves that only the Administrator pattern is concentrated.

That is the investigation complete. You have shown why attack speed matters when a total count looks suspicious.

Having trouble comparing the timestamps?

  • Confirm that All time remains selected if any comparison rows are missing.
  • Match rows using both TargetUserName and IpAddress.
  • Use the earliest and latest _time values for each pair.

Help me compare the failed-logon timestamps and explain the difference between the two patterns.

Your investigation has exposed the weakness in an all-time threshold. Next up, you will preserve attack speed with a five-minute brute-force detection.

Build the Brute-Force Detection

Your earlier search in Splunk Cloud Platform exposed a blind spot. It treated a rapid attack like a slow stream of background failures.

A five-minute SPL pipeline preserves the speed of each pattern. You will turn the focused result into a scheduled alert for repeat checks.

In this step, get ready to:
  • Group failed logons into five-minute windows.
  • Save the focused detection as an hourly scheduled alert.
  • Confirm the detection search plus alert are ready.
Build the five-minute detection

The _time field lets Splunk place failures into fixed windows. Each result now represents one source targeting one account during one five-minute period.

  • Return to the search from the previous step in Search & Reporting.
  • Set the time range picker to All time.
  • Replace the naive search with the finished detection by pasting this query:
sourcetype=windows_failed_logins_lab EventCode=4625
| bin _time span=5m
| stats count AS failed_attempts values(LogonType) AS logon_types values(Computer) AS destinations BY _time IpAddress TargetUserName
| where failed_attempts >= 5
| sort - failed_attempts

How Does the Detection Work?

  • The base search selects failed Windows Event ID 4625 activity from the lab dataset.
  • The bin _time span=5m command places events into five-minute windows.
  • The stats command counts failures for each time window.
  • The same aggregation groups results by IpAddress plus TargetUserName.
  • The values(LogonType) expression preserves the observed logon types.
  • The values(Computer) expression preserves the destination computers.
  • The where failed_attempts >= 5 command keeps windows that meet the lab threshold.
  • The sort - failed_attempts command places the largest count first.

Five failures in five minutes is a threshold for this compact lab dataset. Production teams should measure their normal failed-logon rate before choosing a threshold.

Why Five-Minute Buckets?

The all-time rule merged failures from fifty minutes into one total. Five-minute buckets keep concentrated activity together while separating slow background failures.

Before you run the search, consider whether both earlier results will survive the five-minute bucket.

  • Select the Search icon.

You will see one row for 10.20.30.40 targeting Administrator. The slower svc-backup pattern no longer meets the threshold inside one bucket.

That is the key detection win. The rapid burst remains visible without elevating the slow background failures.

No Detection Row?

  • Confirm the time range picker still shows All time.
  • Compare each line of your search with the full reference below.
  • Select the Statistics tab to view the transformed result.

Help me troubleshoot why my five-minute Splunk detection returns no rows.

✔️ Awesome, I've got everything!

Great. Your detection now separates the concentrated attack from the slow failure pattern.

ⓧ I'd like to double check the full code

sourcetype=windows_failed_logins_lab EventCode=4625
| bin _time span=5m
| stats count AS failed_attempts values(LogonType) AS logon_types values(Computer) AS destinations BY _time IpAddress TargetUserName
| where failed_attempts >= 5
| sort - failed_attempts

How to Use This Reference

Compare this complete search with the query in your Search bar. Every command should appear in the same order.

Save the scheduled alert

A scheduled alert reruns a search automatically. This alert checks the historical fixture every hour because the lab events have fixed timestamps.

  • Select Save As above the search results.
  • Select Alert.
  • Enter Windows Brute Force Lab in the Title field.
  • Set Alert type to Scheduled.
  • Set Schedule to hourly.
  • Set Time range to All time.

Why Use All Time Here?

The compact fixture contains historical events. An all-time range keeps those events available to every scheduled lab run.

A live detection should use a recent search window aligned with its schedule. That keeps each run focused on newly ingested activity.

  • Set Trigger condition to Number of Results.
  • Set Trigger when number of results to is greater than.
  • Enter 0 in the threshold field.
  • Open Add Actions.
  • Select Add to triggered alerts.
  • Keep Severity set to Medium.
  • Select Save.

Good progress. Splunk now reruns your focused search every hour.

The alert action records triggered matches in Triggered Alerts.

Alert Not Saving?

  • Confirm the Title field contains Windows Brute Force Lab.
  • Confirm the search currently returns a result before reopening the alert form.
  • Check that the result threshold contains 0.

Help me troubleshoot why my scheduled Splunk alert will not save.

Verify the saved alert

Saving the alert creates a reusable detection object. The Alerts page gives you a visible record that the schedule exists.

Before you check the list, predict which exact alert title should appear.

  • In Search & Reporting, select Alerts.
  • Locate Windows Brute Force Lab in the alert list.
  • Select Windows Brute Force Lab to review its saved settings.
  • Confirm the schedule is set to hourly.
  • Confirm the trigger condition is greater than 0 results.
  • Confirm Add to triggered alerts is configured.

You will see Windows Brute Force Lab on the Alerts page. This confirms that your five-minute detection has been saved with its hourly schedule.

Your detection now separates attack speed from background noise. Next up, you will place the trend data plus detection match into a SOC dashboard.

Build the SOC Dashboard

Your scheduled Splunk Cloud Platform detection now isolates the concentrated brute-force burst. Analysts still need to rerun separate searches to understand the activity around that match.

In this step, you will bring those searches into a private SOC dashboard built with Dashboard Studio. Four SPL data sources will place the detection beside its investigation context.

In this step, get ready to:
  • Create a private dashboard with an All time global time range.
  • Add visualizations for failed-logon trends plus the most targeted accounts and source IPs.
  • Add the brute-force matches table and verify the finished dashboard.
Create the dashboard canvas

A shared dashboard gives analysts one place to assess failed-logon activity. The private setting keeps this lab view limited to your account.

  • Return to the Search & Reporting app from earlier.
  • Select Dashboards.
  • Select Create New Dashboard.
  • Enter Windows Failed Login Monitoring as the dashboard title.
  • Set the permissions to Private.
  • Select Dashboard Studio.
  • Choose Absolute as the layout.
  • Select Create.

You will see an empty canvas titled Windows Failed Login Monitoring. This canvas becomes the investigation workspace for your four panels.

  • Set the Global Time Range to All time.

Why use All time?

Your lab fixture contains fixed historical timestamps. The All time range keeps those events available to every dashboard search.

Add the investigation overview

The overview separates three investigation questions. It shows when failures happened, which accounts received them, and which source IPs produced them.

  • Select Add Chart in the dashboard editing toolbar.
  • Select + Create search.
  • Enter Failed Logons Over Time as the data source name.
  • Paste this search into the SPL query field:
sourcetype=windows_failed_logins_lab EventCode=4625
| timechart span=5m count AS "Failed Logons"

What does this search do?

  • The base search selects the lab's Windows Event ID 4625 events.
  • The timechart command turns those events into a time series.
  • The span=5m option uses five-minute intervals that match your detection window.
  • The Failed Logons alias gives the series a readable label.
  • Select Apply and close.
  • Choose a line chart for the visualization.
  • Set the panel title to Failed Logons Over Time.

You will see failed-logon activity plotted in five-minute intervals. The concentrated attack period forms a visible burst in the trend.

Is the trend empty?

  • Confirm that the dashboard's global time range is set to All time.
  • Check that the source type in the search is windows_failed_logins_lab.

Ask for help with the search if the chart still has no data: Help me troubleshoot an empty Dashboard Studio timechart using my uploaded Windows failed-login data.

  • Select Add Chart in the dashboard editing toolbar.
  • Select + Create search.
  • Enter Top Targeted Accounts as the data source name.
  • Paste this search into the SPL query field:
sourcetype=windows_failed_logins_lab EventCode=4625
| top limit=5 TargetUserName

What does this search do?

  • The top command ranks account names by event frequency.
  • The limit=5 option keeps the panel focused on five accounts.
  • The TargetUserName field identifies the account attempted during each failed logon.
  • Select Apply and close.
  • Choose a bar or column chart for the visualization.
  • Set the panel title to Top Targeted Accounts.

You will see the most frequently targeted accounts ranked by failed-logon volume. The panel makes repeated targeting easy to compare.

Are the account names missing?

  • Confirm that the search ends with TargetUserName.
  • Check that the dashboard still uses the All time range.

Ask for help if the ranking does not display: Help me troubleshoot my Top Targeted Accounts panel in Splunk Dashboard Studio.

  • Select Add Chart in the dashboard editing toolbar.
  • Select + Create search.
  • Enter Top Source IPs as the data source name.
  • Paste this search into the SPL query field:
sourcetype=windows_failed_logins_lab EventCode=4625
| top limit=5 IpAddress

What does this search do?

  • The top command ranks source addresses by failed-logon frequency.
  • The limit=5 option keeps the five most active addresses.
  • The IpAddress field identifies the source associated with each attempt.
  • Select Apply and close.
  • Choose a bar or column chart for the visualization.
  • Set the panel title to Top Source IPs.

You will see the most active source IPs ranked by failed-logon volume. This view helps an analyst identify which systems deserve attention first.

Is the IP ranking empty?

  • Confirm that the search ends with IpAddress.
  • Check that the uploaded events expose the IpAddress field.

Ask for help if the addresses remain hidden: Help me troubleshoot my Top Source IPs panel in Splunk Dashboard Studio.

Complete the detection view

The overview panels describe the wider failed-logon activity. The final table places confirmed detection matches in the same investigation view.

  • Select Add Chart in the dashboard editing toolbar.
  • Select + Create search.
  • Enter Brute Force Detection Matches as the data source name.
  • Paste your completed detection search into the SPL query field:
sourcetype=windows_failed_logins_lab EventCode=4625
| bin _time span=5m
| stats count AS failed_attempts values(LogonType) AS logon_types values(Computer) AS destinations BY _time IpAddress TargetUserName
| where failed_attempts >= 5
| sort - failed_attempts

What does this search do?

  • The bin command places events into five-minute windows.
  • The stats command counts failures for each source IP and target account group.
  • The values functions preserve the observed logon types and destination computers.
  • The where command keeps groups with at least five failures.
  • Select Apply and close.
  • Choose a table for the visualization.
  • Set the panel title to Brute Force Detection Matches.

You will see one match for 10.20.30.40 targeting Administrator. The slow svc-backup failures remain outside the table.

Does the table show the wrong matches?

  • Confirm that the search includes bin _time span=5m.
  • Check that the stats grouping includes _time, IpAddress, and TargetUserName.
  • Confirm that the threshold is failed_attempts >= 5.

Ask for help if the table still includes the slow failures: Help me compare my dashboard detection search with the expected five-minute brute-force logic.

This checkpoint lets you compare every cumulative project artifact with the source of truth. The three new overview searches should sit beside the unchanged fixture and brute-force detection.

✔️ Awesome, I've got everything!

Your four dashboard searches are in place. Continue to arrange the panels and verify the complete dashboard.

ⓧ I'd like to double check the full code

  • Compare each artifact below with your project.
sourcetype=windows_failed_logins_lab EventCode=4625
| bin _time span=5m
| stats count AS failed_attempts values(LogonType) AS logon_types values(Computer) AS destinations BY _time IpAddress TargetUserName
| where failed_attempts >= 5
| sort - failed_attempts

Brute-force detection check

This search should return only the concentrated burst from 10.20.30.40 against Administrator.

sourcetype=windows_failed_logins_lab EventCode=4625
| timechart span=5m count AS "Failed Logons"

Failed-logon trend check

This search supplies five-minute failed-logon totals to the line chart.

sourcetype=windows_failed_logins_lab EventCode=4625
| top limit=5 IpAddress

Source IP ranking check

This search supplies the five most common source IP values to the source ranking panel.

sourcetype=windows_failed_logins_lab EventCode=4625
| top limit=5 TargetUserName

Target account ranking check

This search supplies the five most common target account values to the account ranking panel.

timestamp,EventCode,TargetUserName,IpAddress,LogonType,WorkstationName,Computer
2026-10-16T08:00:00Z,4625,svc-backup,10.20.30.50,3,APP01,FILE01
2026-10-16T08:10:00Z,4625,svc-backup,10.20.30.50,3,APP01,FILE01
2026-10-16T08:15:00Z,4625,jsmith,10.20.30.21,3,LAPTOP21,FILE01
2026-10-16T08:16:00Z,4625,jsmith,10.20.30.21,3,LAPTOP21,FILE01
2026-10-16T08:20:00Z,4625,svc-backup,10.20.30.50,3,APP01,FILE01
2026-10-16T08:30:00Z,4625,svc-backup,10.20.30.50,3,APP01,FILE01
2026-10-16T08:40:00Z,4625,svc-backup,10.20.30.50,3,APP01,FILE01
2026-10-16T08:50:00Z,4625,svc-backup,10.20.30.50,3,APP01,FILE01
2026-10-16T09:00:05Z,4625,Administrator,10.20.30.40,3,UNKNOWN,SERVER01
2026-10-16T09:00:40Z,4625,Administrator,10.20.30.40,3,UNKNOWN,SERVER01
2026-10-16T09:01:15Z,4625,Administrator,10.20.30.40,3,UNKNOWN,SERVER01
2026-10-16T09:02:05Z,4625,Administrator,10.20.30.40,3,UNKNOWN,SERVER01
2026-10-16T09:03:20Z,4625,Administrator,10.20.30.40,3,UNKNOWN,SERVER01
2026-10-16T09:04:10Z,4625,Administrator,10.20.30.40,3,UNKNOWN,SERVER01
2026-10-16T10:00:00Z,4625,a.nguyen,10.20.30.60,3,KIOSK01,DC01
2026-10-16T10:00:30Z,4625,b.smith,10.20.30.60,3,KIOSK01,DC01
2026-10-16T10:01:00Z,4625,c.patel,10.20.30.60,3,KIOSK01,DC01
2026-10-16T10:01:30Z,4625,d.garcia,10.20.30.60,3,KIOSK01,DC01
2026-10-16T10:02:00Z,4625,e.brown,10.20.30.60,3,KIOSK01,DC01
2026-10-16T10:02:30Z,4625,f.wilson,10.20.30.60,3,KIOSK01,DC01

Fixture check

The fixture should still contain all 20 historical failed-logon events. Its field names and timestamps remain unchanged.

  • Arrange the panels so the failed-logon trend sits above the three investigation summaries.
  • Select Save.

Before you reload the dashboard, which panels do you expect to show ranked entities versus activity over time?

  • Reload the Windows Failed Login Monitoring dashboard.

You will see the five-minute trend, the top targeted accounts, the top source IPs, and one brute-force detection row. Each panel uses the dashboard's All time range.

That brings the investigation together. Your dashboard now gives an analyst the trend, the leading entities, and the confirmed detection from one view.

Is a panel missing after reload?

  • Return to edit mode and confirm that the missing panel still has its data source.
  • Check that each panel has the exact title shown in this step.
  • Select Save after restoring the panel.

Ask for help if the saved layout remains incomplete: Help me troubleshoot a missing panel in my saved Splunk Dashboard Studio dashboard.

Secret mission

Detect Password Spraying

Repeated guesses against one account are only one attack shape. Extend your SPL to catch one source touching several accounts within five minutes. Add the match to your SOC dashboard.

Clean Up Your Resources

Clean Up Your Resources

Choose whether to keep your security lab available, pause its scheduled activity, or remove its project resources. The 14-day Splunk Cloud Platform trial is free with no credit card required.

Resources you used:

  • One local CSV fixture named windows_failed_logins_lab.csv.
  • Twenty historical failed-logon events uploaded with the windows_failed_logins_lab sourcetype in the default index.
  • One scheduled hourly alert named Windows Brute Force Lab with Medium severity and the Add to triggered alerts action.
  • One private Dashboard Studio dashboard named Windows Failed Login Monitoring with five investigation panels.

Keep everything running

No action is needed. Choose this if you want to keep investigating the sample events during the remainder of your trial.

  • Leave the Windows Brute Force Lab alert enabled so its hourly schedule remains active.
  • Keep the Windows Failed Login Monitoring dashboard available for future demonstrations.
  • Retain windows_failed_logins_lab.csv if you want to upload the fixture again.
  • Continue using the 20 indexed events for SPL experiments during the trial.

Pause - I'll come back to this later

Disable the scheduled alert to pause its hourly activity. Your indexed events and dashboard stay available for later review.

  • Return to Search & Reporting in your Splunk Cloud Platform trial.
  • Select Alerts from the app navigation.
  • Select Windows Brute Force Lab from the alert list.
  • Select Disable from the alert controls.
  • Confirm that the alert details show its schedule as disabled.
  • Leave the Windows Failed Login Monitoring dashboard in place.
  • Retain windows_failed_logins_lab.csv for your next session.

Delete - I don't want to use this again

Remove the scheduled alert, the dashboard, and the local CSV fixture. Stop using the temporary trial instance after you finish the cleanup.

  • Return to Search & Reporting in your Splunk Cloud Platform trial.
  • Select Alerts from the app navigation.
  • Locate Windows Brute Force Lab in the alert list.
  • Open the alert row's actions menu.
  • Select Delete.
  • Confirm the alert deletion.

That's the active automation handled: the hourly search can no longer create new triggered records.

  • Select Dashboards from the app navigation.
  • Locate Windows Failed Login Monitoring in the dashboard list.
  • Open the dashboard row's actions menu.
  • Select Delete.
  • Confirm the dashboard deletion.

The five-panel SOC view is now removed from your trial.

  • Press the Windows key to open Windows search.
  • Type windows_failed_logins_lab.csv into the search field.
  • Use the result's location option to reveal the file in File Explorer.
  • Right-click windows_failed_logins_lab.csv.
  • Select Delete.
  • Stop using the temporary Splunk Cloud Platform trial instance after removing these project resources.

The trial requires no credit card. This project does not create an automatic paid subscription.

Nice Work!

Nice Work!

Outstanding work! Your Splunk Cloud Platform workflow now turns failed Windows logons into focused security detections that an analyst can review from one dashboard.

What you learned:

  • Used SPL to investigate Windows Event ID 4625 records. Proved that an all-time count can flag slow background failures alongside a rapid attack.
  • Built a five-minute brute-force detection grouped by source IP and target account. Saved it as the scheduled alert named Windows Brute Force Lab so future matches can reach Triggered Alerts.
  • Created the private Windows Failed Login Monitoring dashboard with Dashboard Studio. Its panels show failed-logon trends, targeted accounts, source IPs, and brute-force detection matches in one investigation view.
  • Secret Mission: Extended the logic to detect password spraying by counting distinct accounts per source in five-minute windows. Added the Password Spray Detection Matches table after identifying 10.20.30.60 across six accounts.

Ready to quiz yourself?