Detect a Brute Force Attack with Splunk

Build a SIEM that detects brute force login attacks on your Windows machine.

Introduction

30 Second Summary

Every time a password attempt fails on your computer, the operating system quietly logs it. An attacker trying thousands of passwords generates a mountain of these logs, but without the right tool watching, nobody notices until it is too late.

In this project, you will set up Splunk Enterprise on your Windows machine and feed it your real security logs. You will simulate a brute force login attack, write queries that detect it, and build a dashboard that makes the threat visible.

What You'll Build

By the time you finish, you will have a working SIEM (Security Information and Event Management) system on your own machine where a spike of failed logins lights up the moment an attack hits, ready to show anyone exactly what happened and when.

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

  • Your own security monitoring system running on your machine, ingesting real Windows security events as they happen.
  • A single SPL (Search Processing Language) query that cuts through thousands of raw log events to surface every failed login attempt instantly.
  • A multi-panel security dashboard that shows failed login trends over time and exactly which accounts are being targeted.
  • Secret Mission: A Splunk alert that automatically fires when failed logins spike, making your SIEM work even when you are not watching.

Do I need a Windows machine for this project?

Yes. This project uses Windows Security Event Logs, which are only available on Windows. You need a Windows machine to follow along.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters.

Install and Launch Splunk Enterprise

Every step in this project depends on having a working SIEM platform running on your machine. Without one, there are no logs to search, no queries to write, and no dashboards to build.

In this step, you'll install Splunk Enterprise on your Windows machine and open Splunk Web in your browser. This is the foundation everything else builds on.

In this step, get ready to:
  • Create a free Splunk account and download the installer.
  • Install Splunk Enterprise on your Windows machine.
  • Launch Splunk Web and log in for the first time.
Create a free Splunk account and download the installer
  • Open the Splunk Enterprise download page in your browser.
  • Create a free splunk.com account. No credit card is required.
  • Once signed in, find the Windows 64-bit .msi installer for Splunk Enterprise 10.4.2 and click the download button.
  • The installer is about 1 GB. While it downloads, continue reading ahead.

What is Splunk Enterprise?

Splunk Enterprise is one of the most widely used SIEM platforms in the industry. SOC analyst and SIEM engineer job listings consistently name Splunk as a required skill.

You'll use the free 60-day Enterprise Trial, which gives you full access to all features including dashboards, alerts, and search. After 60 days, you can switch to the perpetual Free license (500 MB/day indexing, no expiration).

Run the installer
  • Open your Downloads folder and double-click the downloaded .msi file to start the installer.
  • Check the box labeled Check this box to accept the License Agreement to enable the Next button.
  • Click Next to accept the default installation settings.
  • When prompted, create an administrator password. The password must be at least 8 characters. Write it down. You will need it in a moment.
  • Click Install and wait for the installation to complete.

What did the installer set up?

The installer placed Splunk Enterprise at C:\Program Files\Splunk and created two Windows services: splunkd and splunkweb.

The splunkd service handles all Splunk Enterprise operations, including search, indexing, and the web interface. These services start automatically so Splunk is ready whenever your machine boots.

Launch Splunk Web and log in
  • On the Installation Complete screen, check the box labeled Launch browser with Splunk Enterprise.
  • Click Finish.

Splunk Enterprise starts in the background. After a moment, your browser opens automatically to http://localhost:8000.

  • Log in with the username admin and the password you created during installation.

Before you look around, take a guess. What do you think a SIEM's home page shows you?

You should see the Splunk Enterprise home page with the Search & Reporting app listed on the left side. This is where you'll spend most of your time in the upcoming steps.

Splunk Web not loading?

  • If your browser did not open automatically, open it manually and go to http://localhost:8000.
  • If you see a blank page or a connection error, Splunk may still be starting up. Wait 30 seconds and refresh the page.
  • If you see a "Not Found" or 404 error, another application may be using port 8000. Splunk may have moved to port 8001 instead. Try http://localhost:8001 in your browser.
  • If you forgot your admin password, you will need to uninstall and reinstall Splunk Enterprise to reset it.

help me troubleshoot Splunk Web not loading on my Windows machine

Splunk is installed and running on your machine. Next up, you'll feed it your Windows Security logs and watch real security events start flowing in.

Feed Splunk Your Windows Security Logs

Splunk is installed and ready to go. But a SIEM without data is like a security camera with no feed.

Your Windows machine is already generating security events every minute. In this step, you will connect Splunk to those events so it has real data to search through.

In this step, get ready to:
  • Configure Splunk to monitor your Windows Security Event Log.
  • Verify that real security events are flowing into Splunk.
Open the Add Data wizard
  • On the Splunk Enterprise home page, click Add Data.
  • Click Monitor to monitor data on this local machine.
  • In the left sidebar, click Local Event Logs.

You should see a list of available Windows event logs with checkboxes next to each one.

What are Windows Security Event Logs?

Every Windows machine keeps a dedicated log of security-related activities. Logins, logoffs, permission changes, and failed access attempts all generate entries in this log.

These events are the raw material that a SIEM analyzes to detect threats. By connecting Splunk to this log, you give it a live feed of everything security-related happening on your machine.

Select the Security log and start ingesting
  • Check the box next to Security.
  • Click Next to move to the input settings.
  • Leave all settings at their defaults.
  • Click Review.
  • Click Submit.

Splunk displays a success page confirming that indexing has begun. You should see a Start Searching option on this page.

What just happened?

You told Splunk to start reading from the Windows Security Event Log on your machine. Splunk is now continuously pulling new events from that log and indexing them so they become searchable.

The index is set to default and the source type is automatically assigned as WinEventLog:Security. You will use that source type to find these events in searches.

Verify events are flowing
  • Click Start Searching on the success page.
  • Set the time picker dropdown to Last 24 hours.
  • Type this query into the search bar:
sourcetype="WinEventLog:Security"

Before you run the search, what do you think your Windows machine has been logging over the last 24 hours? Do you expect a handful of events or hundreds?

  • Click the Search icon on the right side of the search bar, or press Enter.

You should see security events from your Windows machine appearing in the results. Each row is a real security log entry from your machine, not sample data.

What am I looking at?

Each event in the list is something Windows recorded: a user login, a service starting, a permission check. The sourcetype value WinEventLog:Security tells Splunk to show only events from the Windows Security log.

Most machines generate hundreds of these events in a single day. That volume is exactly why you need a SIEM to make sense of it.

Not seeing any events?

  • Make sure the time picker is set to Last 24 hours. A shorter window might not have captured enough events yet.
  • Confirm you selected the Security checkbox in the Add Data wizard. If you missed it, click Add Data on the home page and walk through the wizard again.
  • Check that the search query matches exactly: sourcetype="WinEventLog:Security". The quotes and capitalization matter.

Help me troubleshoot why my Splunk search for Windows Security events returns no results.

Your Splunk instance is now connected to a live stream of security data from your own machine. Next up, you will dig into that data and discover why raw events are harder to make sense of than they look.

Search Your Security Data (and Hit a Wall)

Your Splunk instance is now pulling in real security events from your Windows machine. Every login, privilege change, and system activity flows into your default index.

The challenge is that your machine generates hundreds or thousands of these events every day. In this step, you will try to find something suspicious in that flood and discover why raw logs alone are not enough.

In this step, get ready to:
  • Browse raw security events and experience the sheer volume of data a SIEM ingests.
  • Use SPL queries to organize events by type and frequency.
  • Discover why manual threat detection does not scale.
See the wall of raw events

Your Windows machine has been generating security events the entire time Splunk has been running. Let's see what that looks like.

Before you run this search, take a guess. How many security events do you think your machine has generated in the last 24 hours?

  • In the search bar in the Search & Reporting app, type the following SPL query and press Enter:
sourcetype="WinEventLog:Security"
  • Make sure the time picker in the top right of the search bar is set to Last 24 hours.
  • Scroll through the results that appear below the search bar.

You should see hundreds or even thousands of events listed. Try reading through a few and spotting anything that looks suspicious.

It is nearly impossible to tell what is normal and what might be a threat. This is the exact problem every SOC analyst faces on day one.

Why are there so many events?

Windows generates a security event for almost everything. A user logs in, a service starts, a privilege is assigned, a process accesses a protected resource. Each one creates a log entry.

This is great for forensics (nothing gets missed) but terrible for real-time detection. The signal is buried in noise.

Not seeing any events?

  • Check that the time picker is set to Last 24 hours, not a shorter window like Last 15 minutes.
  • Make sure you typed sourcetype="WinEventLog:Security" exactly, including the quotes around the sourcetype value.
  • If you still see zero results, go back to Step 2 and confirm the Security log monitor was set up correctly.

Why aren't my Splunk security events showing up?

Use SPL to make sense of the data

Scrolling through raw events is not going to cut it. SPL (Search Processing Language) lets you transform those raw events into structured tables and summaries.

Before you run the next query, what do you think the most common type of security event on your machine will be? A login? A permission check? Something else entirely?

  • Run the following query in the search bar:
sourcetype="WinEventLog:Security" | stats count by EventCode | sort -count

What does this query do?

  • sourcetype="WinEventLog:Security" pulls all your Windows Security events, just like the previous search.
  • stats count by EventCode groups every event by its EventCode and counts how many of each type exist.
  • sort -count sorts the table so the most frequent event types appear at the top.

Instead of thousands of individual events, you now have a compact table showing exactly what your machine is doing.

You should see a table with EventCode values ranked by how often they occur. Compare what you see to your prediction.

What are these EventCodes?

Every Windows Security event has a numeric EventCode that identifies what happened. Here are a few common ones you will likely see in your results:

  • 4624 = successful logon.
  • 4672 = special privileges assigned to a new logon.
  • 4625 = failed logon attempt. You may or may not see this one yet. That is about to change.
Try to find threats manually

The EventCode table is a big improvement over raw logs. But can you actually spot a threat from it? Let's try one more angle.

  • Run the following query in the search bar:
sourcetype="WinEventLog:Security" | stats count by Keywords

What does this query do?

The Keywords field is a built-in category that Windows assigns to each event. It groups events into high-level buckets like Audit Success and Audit Failure.

You should see a small table showing categories like Audit Success and Audit Failure with counts next to each.

  • If you see Audit Failure in the results, click on that value to filter down to just the failure events.

Even after filtering, you are still scrolling through individual events looking for patterns. You can see that failures exist, but you cannot tell if they are routine (a mistyped password) or a coordinated attack (hundreds of attempts in a row).

Why does filtering still fall short?

Filtering narrows your view, but it does not detect patterns. A brute force attack looks like a burst of failed logins in a short window. Spotting that requires a query that targets a specific EventCode and groups by time. That is exactly what you will build next.

You have seen what thousands of raw security events look like and discovered that even organized tables and filters cannot surface a real attack pattern. In the next step, you will create a real threat by simulating a brute force attack and write the SPL query that catches it.

Simulate and Detect a Brute Force Attack

In the last step, you scrolled through thousands of raw security events and saw firsthand how impossible it is to spot a threat by reading logs line by line. That wall of noise is the exact problem every SOC analyst faces on day one.

Now you are going to flip the script. You will create a real threat on your own machine by simulating a brute force attack, then write targeted SPL queries that cut through the noise and catch the attack instantly.

In this step, get ready to:
  • Simulate a brute force attack by generating failed login events on your machine.
  • Write targeted SPL queries that detect the exact attack signature.
  • Build a timeline chart that visualizes the attack as a spike.
Simulate a brute force attack

A brute force attack is when an attacker tries many username and password combinations in rapid succession, hoping one will work. You are going to simulate this by deliberately failing 10 login attempts against your own machine.

  • Press the Windows key to open your search bar.
  • Type cmd and press Enter to open Command Prompt.
  • Run this command to attempt a failed login against your local machine:
net use \\127.0.0.1\IPC$ /user:attacker wrongpassword

You will see an error message saying the user name or password is incorrect. This is exactly what you want.

  • Press the Up Arrow key and then press Enter to repeat the command.
  • Do this 9 more times, for a total of 10 failed attempts.

After 10 runs, your Command Prompt should show 10 error messages. Each one planted a failed logon event into the Windows Security log that Splunk is actively ingesting.

What does this command do?

The net use command attempts to connect to a network share. By targeting \\127.0.0.1\IPC$ with a fake username and wrong password, you force a failed network logon on your own machine.

Each failed attempt generates an EventCode 4625 in the Windows Security log. This is the same event that fires when a real attacker hammers a login page with bad credentials.

Not seeing error messages?

Make sure you typed the command exactly as shown, including the double backslashes before 127.0.0.1 and the single backslash before IPC$.

If you see a different error or an access denied message, try opening Command Prompt as a regular user (not as Administrator). The command still generates the failed logon event either way.

Help me troubleshoot my net use command

Detect the attack with a targeted SPL query

Your simulated attack events are now sitting in Splunk, mixed in with all the other security events your machine generates. Time to write a query that pulls them out.

  • Switch back to Splunk Web in your browser.
  • In the Search & Reporting app search bar, type the following query:
sourcetype="WinEventLog:Security" EventCode=4625
  • Set the time picker to Last 15 minutes.
  • Click the green search button or press Enter.

You should see your simulated failed login events in the results. Each one represents one of the net use commands you just ran.

What does this query do?

This query filters all security events down to just EventCode 4625, which Windows logs whenever a logon attempt fails. Instead of scrolling through thousands of events, you now see only the ones that matter for detecting brute force attacks.

  • Add stats to reveal the attacker pattern by running this query in the search bar:
sourcetype="WinEventLog:Security" EventCode=4625 | stats count by Account_Name, Source_Network_Address

This groups all matching events by account name and source address, then counts them. You should see the account name attacker and the source address 127.0.0.1 listed with a count of 10.

What does the stats command do?

The stats count by command groups all matching events and counts how many came from each unique combination of account name and source address. This is the brute force pattern: many failed attempts from the same source, targeting the same account.

A SOC analyst seeing this table in production would immediately know someone is hammering a specific account with bad passwords.

No EventCode 4625 results?

Make sure your time picker is set to Last 15 minutes, not Last 24 hours. If too much time has passed since you ran the net use commands, widen the time window or run the commands again.

If you still see no results, your Windows audit policy may not be logging failed logon attempts. Open Command Prompt as Administrator and run:

auditpol /set /subcategory:"Logon" /failure:enable

Then repeat the 10 net use commands from the previous substep and search again.

Help me find my failed login events in Splunk

Build a timeline of the attack

You have identified the attacker and the source. The final piece is seeing when the attack happened, because brute force attacks leave a distinctive spike pattern in a timeline.

Before you run the next query, think about what you expect the chart to look like. You ran 10 failed logins within a short window. What shape do you predict the timeline will show?

  • Run this query in the search bar:
sourcetype="WinEventLog:Security" EventCode=4625 | timechart span=1m count

What does timechart do?

The timechart command groups events into time buckets and plots them as a chart. The span=1m part sets each bucket to one minute.

Splunk renders this as a line chart, so you can see the volume of failed logins over time at a glance.

You should see a sharp spike during the minute you ran the net use commands. That spike is your simulated brute force attack, clearly visible against the flat baseline of normal activity.

Chart looks flat with no spike?

Make sure the time picker covers the window when you ran the net use commands. Try setting it to Last 60 minutes so the spike is not cut off.

If events exist but the chart is still flat, check that span=1m is typed correctly. A larger span like span=1h would flatten 10 events into a single bar.

Help me see the brute force spike in my timechart

You have gone from drowning in raw logs to pinpointing an attack in seconds. Next up, you will turn these queries into a persistent dashboard so threats are visible the moment you open Splunk.

Build a Security Dashboard

In the last step, you wrote SPL queries that detected your simulated brute force attack. You went from a wall of raw events to targeted detections showing exactly which accounts were under attack and when.

Typing those searches every time you want to check for threats is not sustainable. In this step, you will build a dashboard that gives you a persistent, at-a-glance view of brute force activity so threats are visible the moment you open Splunk.

In this step, get ready to:
  • Create a dashboard by saving your timeline search as the first panel.
  • Add panels for top targeted accounts and recent failed login events.
  • View a complete security dashboard populated with your attack data.
Create the dashboard and add the timeline panel

Splunk lets you save any search as a panel on a dashboard. Instead of retyping your timeline query every time, you can pin it as a permanent chart that refreshes whenever you open the dashboard.

  • In the Search & Reporting app, re-run your timeline search by pasting this into the search bar:
sourcetype="WinEventLog:Security" EventCode=4625 | timechart span=1m count
  • Set the time picker to Last 24 hours.
  • Press Enter to run the search.

Why re-run this search?

This is the same timechart query from the last step. By running it in the search bar first, Splunk lets you save the results directly as a dashboard panel.

  • Click Save As in the top right.
  • Select Dashboard Panel.
  • In the Dashboard Title field, type Brute Force Monitor.
  • In the Panel Title field, type Failed Login Timeline.
  • Click Save.
  • Click View Dashboard.

You should see your new Brute Force Monitor dashboard with a single panel showing the Failed Login Timeline chart. The chart displays a spike during the time you ran your simulated attack.

Don't see your dashboard?

If clicking View Dashboard did not open the dashboard, click the Splunk logo in the top left to go home, then look for Brute Force Monitor under the Dashboards section.

If the panel shows no results, make sure the time picker on the dashboard is set to Last 24 hours. Your simulated attack events may fall outside a shorter time range.

Still stuck? Help me troubleshoot my Splunk dashboard not showing data.

Add a top targeted accounts panel

Your timeline shows when attacks happen. The next panel will show who is being targeted by ranking accounts with the most failed login attempts.

  • From the dashboard, click Edit in the top right.
  • Click + Add Panel.
  • Click New.
  • Select Bar Chart.
  • Set up the panel's search by entering this query in the search field:
sourcetype="WinEventLog:Security" EventCode=4625 | top limit=10 Account_Name
  • Set the time range to Last 24 hours.
  • In the Panel Title field, type Top Targeted Accounts.
  • Click Add to Dashboard.

What does this search do?

The top command counts how many times each Account_Name appears in the failed login events and ranks them by frequency.

limit=10 keeps the chart focused on the ten most-targeted accounts. This reveals which accounts attackers are going after the hardest.

You should now see a second panel on your dashboard showing a bar chart of targeted accounts. The attacker account from your simulation should be at the top.

Panel showing no results?

Double-check that you set the time range to Last 24 hours in the panel configuration. A shorter time range may exclude your simulated events.

Also verify the search query matches exactly, including the double quotes around WinEventLog:Security. A missing quote will cause a syntax error.

Help me figure out why my Splunk panel is empty.

Add a recent events table panel

The timeline shows when attacks happen. The bar chart shows who is targeted. The final panel will show the raw details of each failed login so you can investigate specific events.

  • Click + Add Panel again (you should still be in edit mode).
  • Click New.
  • Select Statistics Table.
  • Set up the panel's search by entering this query in the search field:
sourcetype="WinEventLog:Security" EventCode=4625 | table _time, Account_Name, Source_Network_Address, Logon_Type | head 20
  • In the Panel Title field, type Recent Failed Login Events.
  • Click Add to Dashboard.

What does this search do?

table extracts specific fields into clean columns, giving you a spreadsheet-like view of each event. The four fields (_time, Account_Name, Source_Network_Address, Logon_Type) are the key details a security analyst would check first when investigating a brute force alert.

head 20 limits the output to the 20 most recent events so the panel stays readable.

All three panels are now in place. Before you save the dashboard, think about what you expect each panel to show based on the searches you entered.

  • Click Save to exit edit mode.

Your Brute Force Monitor dashboard now has three panels populated with data:

  • Failed Login Timeline shows a chart with the spike from your simulated attack.
  • Top Targeted Accounts shows the attacker account at the top of the list.
  • Recent Failed Login Events shows a table with timestamps, account names, and source addresses for each failed login.

Why a dashboard instead of saved searches?

A SOC analyst checking for threats does not want to run three separate searches every morning. A dashboard combines multiple views into a single screen so patterns jump out immediately.

The better your panels are designed, the faster you can spot anomalies. That timeline spike you see is exactly the kind of signal that separates noise from a real incident.

A panel is missing or empty?

Click Edit on the dashboard to re-enter edit mode. Click the pencil icon on the empty panel to check its search query for typos. Make sure EventCode=4625 is present and the sourcetype value is wrapped in double quotes.

If you only see one or two panels, you may have accidentally closed the + Add Panel dialog before clicking Add to Dashboard. Re-enter edit mode and add the missing panel using the same steps above.

Help me troubleshoot my Splunk dashboard panels.

Secret mission

Create a Brute Force Alert

Your dashboard shows brute force attacks, but only when you are looking at it. What about attacks that happen at 3 AM? In this secret mission, you will create a Splunk alert that automatically fires when failed logins spike. Your SIEM will watch for threats even when you are not.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely on your local machine, so there are no cloud resources or ongoing costs.

Resources you used:

  • Splunk Enterprise 10.4.2 installed at C:\Program Files\Splunk (indexed data grows over time, approximately 7 GB per month at the 500 MB/day free license limit).
  • The Splunkd Service Windows service (consumes RAM while running).
  • A splunk.com account (created during installation).

Keep everything running

No action needed. Choose this if you are still actively building or want to keep experimenting with SPL and dashboards.

  • Splunk continues running and ingesting Windows Security logs in the background.
  • Your 60-day Enterprise Trial gives you full features including alerts, dashboards, and multi-user management.
  • After 60 days, you can switch to the perpetual Free license (500 MB/day indexing, no expiration) by going to Settings > Licensing > Change License Group > Free license > Save, then restart Splunk.
  • Your splunk.com account remains active. There is no documented self-service deletion path, so it stays on your account.

Pause - I'll come back to this later

Stop the Splunk service to free up RAM while keeping all your data, dashboards, and configuration intact. Start it again anytime.

  • Press the Windows key, type services, and press Enter to open the Services control panel.
  • Find Splunkd Service in the list.
  • Right-click it and select Stop.

Starting Splunk again

To resume, open Services again, right-click Splunkd Service, and select Start. Then open http://localhost:8000 in your browser to access Splunk Web.

Delete - I don't want to use this again

Remove Splunk Enterprise and all indexed data from your machine. This cannot be undone.

  • Press the Windows key, type Add or remove programs, and press Enter.
  • Search for Splunk Enterprise in the apps list.
  • Click Uninstall and follow the prompts to remove it.

What about leftover files?

The uninstaller may leave behind configuration and index files in C:\Program Files\Splunk. If you want a completely clean removal, delete that folder manually after the uninstall finishes.

If you see a reboot prompt during the uninstall, you can safely ignore it.

Nice Work!

Nice Work!

Nice work! You just built a working SIEM that detects brute force login attacks on your own Windows machine. You can now ingest logs, write detection queries, and build dashboards. This is the foundational skill behind every SOC analyst role.

What you learned:

  • Installed Splunk Enterprise and connected it to real Windows Security Event Logs flowing from your own machine, giving you a live security monitoring setup with authentic data.
  • Wrote targeted SPL queries to cut through thousands of raw events, simulated a brute force attack, and detected it using EventCode 4625.
  • Built a multi-panel security dashboard that visualizes failed login trends and targeted accounts at a glance.
  • Secret Mission: Created a scheduled Splunk alert that automatically detects brute force attacks, making your SIEM work for you even when you are not watching.

Ready to quiz yourself?