Investigate a Security Breach with Splunk

Use SPL to hunt threats and build a SOC dashboard in Splunk.

Introduction

30 Second Summary

Every day, companies face cyberattacks that leave traces scattered across system logs. Security Operations Center (SOC) analysts are the people who dig through those logs to figure out what happened, who did it, and how to prevent it next time.

In this project, you will install Splunk Enterprise on your machine, load a realistic attack dataset, and write SPL queries to investigate a simulated security breach from start to finish.

What You'll Build

A local SIEM environment powered by Splunk, loaded with realistic attack data from a simulated breach of a fictitious company.

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

  • A working Splunk Enterprise instance with the Boss of the SOC (BOTS) security dataset loaded and searchable.
  • SPL queries that detect failed login attempts, suspicious network traffic, and attacker IP addresses from realistic attack data.
  • A security monitoring dashboard that visualizes attack patterns across multiple data sources.
  • Secret Mission: Enrich your investigation with a threat intelligence lookup table and build a brute-force detection alert.

Are there any prerequisites?

You need a Windows machine with at least 8 GB of RAM. No prior Splunk experience is required. This guide walks you through installing every tool from scratch.

Install Splunk Enterprise and Load Security Data

Before you can investigate a security breach, you need a SIEM platform to ingest and search through security logs. Splunk Enterprise is one of the most widely used SIEM tools in Security Operations Centers (SOCs) worldwide.

In this step, you will install Splunk Enterprise locally on your Windows machine and load a realistic attack dataset called Boss of the SOC (BOTS) v1. This dataset contains pre-recorded security events from a simulated breach, giving you real attack data to investigate.

In this step, get ready to:
  • Install Splunk Enterprise 10.4.0 on Windows using the MSI installer.
  • Download and load the BOTS v1 attack-only dataset into Splunk.
  • Verify the dataset is searchable across multiple security-relevant sourcetypes.
Download and install Splunk Enterprise

Splunk Enterprise requires a free account to download. The 60-day trial gives you full Enterprise features with no credit card required.

  • Open your web browser and navigate to the Splunk Enterprise download page:
  • https://www.splunk.com/en_us/download/splunk-enterprise.html
  • Click Create your account if you do not have one already.
  • Fill in your name, email, and a password to create your Splunk account.
  • Once logged in, find the Windows section under Choose Your Installation Package.
  • Select the 64-bit .msi option for Windows 10.
  • Click Download and wait for the file to finish downloading (approximately 1 GB).

Why Splunk Enterprise over Splunk Cloud?

A local install teaches the full SIEM administration workflow: install, configure, ingest, and search. The Cloud trial is only 14 days with a 5 GB/day limit, and all data is deleted when it expires.

The Enterprise trial runs for 60 days. After that, it converts to a perpetual free license with a 500 MB/day indexing limit.

Now run the installer to get Splunk set up on your machine.

  • Double-click the downloaded .msi file to launch the installer.
  • Check the Check this box to accept the License Agreement checkbox.
  • Click Next to proceed with default settings.

What do the default settings do?

The default installation installs Splunk to C:\Program Files\Splunk, uses the standard web port (8000), and configures Splunk to run as the Local System user.

  • The installer prompts you to create a Splunk administrator password. Enter a password you will remember. The username defaults to admin.
  • Click Next, then click Install to begin the installation.
  • Wait for the installation to complete.
  • On the final screen, check the box for Launch browser with Splunk Enterprise.
  • Click Finish.

Your browser opens to http://localhost:8000 with the Splunk Web login page.

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

You should see the Splunk Enterprise home screen with the Search & Reporting app listed.

Splunk Web not loading?

Splunk takes 30-60 seconds to fully start after installation. If you see a connection error, wait a minute and refresh your browser.

Make sure no other application is using port 8000 on your machine. Help me troubleshoot why Splunk Web isn't loading at http://localhost:8000

Download and extract the BOTS v1 dataset

The Boss of the SOC (BOTS) v1 dataset contains realistic attack data from a simulated breach of a fictitious company called Wayne Corp. The attack-only version is 135 MB and contains just the malicious activity, making it perfect for a focused investigation.

  • Open the BOTS v1 GitHub repository in your browser:
  • https://github.com/splunk/botsv1
  • Scroll down to the Retrieving the BOTS v1 Dataset section.
  • Under Splunk Indexed, find the link for botsv1-attack-only.tgz (135 MB compressed).
  • Click the link to download the file. Save it somewhere easy to find, like your Downloads folder.

Why the attack-only dataset?

The full BOTS v1 dataset is 6.1 GB. The attack-only version is just 135 MB and contains only the malicious activity. In the words of the dataset creators, it is "just the needles, no haystack."

Because the data is distributed in a pre-indexed format, there are no volume-based licensing limits to worry about.

Now extract the dataset into Splunk's apps directory. You will need to use an Administrator PowerShell window because the Splunk install directory is in a protected location.

  • Press the Windows key to open your search bar.
  • Type PowerShell and right-click Windows PowerShell in the results.
  • Select Run as administrator.
  • Click Yes on the User Account Control prompt.
  • Extract the dataset into Splunk's apps folder by running this command:
tar -xzf "$HOME\Downloads\botsv1-attack-only.tgz" -C "C:\Program Files\Splunk\etc\apps"

What does this command do?

The tar command extracts compressed archive files. The -xzf flags tell it to extract (x), decompress gzip (z), and use the specified file (f).

The -C flag specifies the target directory. The dataset extracts as a Splunk app directly into the apps folder where Splunk can detect it.

Downloaded to a different folder?

If you saved botsv1-attack-only.tgz somewhere other than your Downloads folder, update the path in the command to match the actual location of the file.

After extraction, restart Splunk so it recognizes the new dataset.

  • Restart Splunk by running this command in the same Administrator PowerShell window:
cd "C:\Program Files\Splunk\bin"
.\splunk restart

What does this do?

The splunk restart command stops all Splunk services and starts them again. This forces Splunk to scan the apps directory and load any new datasets it finds.

  • Wait for the restart to complete. You will see a message confirming that Splunk has started.

Seeing a permission error?

Make sure you opened PowerShell as an Administrator. The Splunk directory at C:\Program Files\Splunk requires elevated permissions for both extraction and service control.

Help me fix permission errors when extracting the BOTS dataset or restarting Splunk on Windows

Verify the dataset is loaded

With Splunk restarted, you can confirm the BOTS v1 data is available by running a search query that counts events by sourcetype.

  • Return to Splunk Web at http://localhost:8000 in your browser. Log in again if prompted.
  • Click Search & Reporting on the left sidebar or home screen.
  • In the search bar at the top, enter the following SPL query and press Enter:
index=botsv1 earliest=0 | stats count by sourcetype

What does this SPL query do?

  • index=botsv1 tells Splunk to search only the BOTS v1 dataset index.
  • earliest=0 searches all time (the dataset contains historical events, not recent ones).
  • | stats count by sourcetype groups the results and counts how many events exist in each data source type.

You should see a table listing multiple sourcetypes with their event counts. Look for sourcetypes including WinEventLog:Security, suricata, stream:http, stream:dns, and others.

What are these sourcetypes?

Each sourcetype represents a different security data source that was captured during the simulated attack.

  • WinEventLog:Security contains Windows login attempts, privilege changes, and other security events.
  • suricata contains network intrusion detection alerts.
  • stream:http and stream:dns contain captured network traffic for web requests and DNS lookups.

No results returned?

Make sure you restarted Splunk after extracting the dataset. Splunk needs a restart to detect new apps in the etc/apps directory.

Also verify that earliest=0 is included in your query. Without it, Splunk defaults to searching the last 24 hours, and the BOTS dataset contains historical events that fall outside that window.

Help me figure out why my BOTS v1 dataset search returns no results in Splunk

Your SIEM environment is ready with real attack data loaded and searchable. Next up, you will explore this data and start identifying the attackers behind the breach.

Explore the Data and Identify Attack Sources

Your Splunk instance is live and loaded with realistic attack data. Now it is time to start investigating.

In a real Security Operations Center, analysts receive thousands of events per minute from dozens of sources. The first challenge is understanding what data you have and where to look. In this step, you will survey the data landscape using SPL (Search Processing Language) and narrow down which IP addresses are responsible for suspicious activity.

In this step, get ready to:
  • Survey all available sourcetypes to understand the scope of the security data.
  • Identify which IP addresses are generating the most HTTP traffic to the target servers.
  • Narrow down to attacker IPs by filtering for error-heavy traffic patterns.
Survey available sourcetypes with the metadata command

Before hunting for attackers, you need to understand what data sources exist in the dataset. The metadata command gives you a bird's-eye view of all sourcetypes and how many events each one contains.

  • Switch back to the Search and Reporting app in Splunk Web.
  • Click the time range picker (to the left of the search button) and select All time from the Presets list.
  • Enter this search in the Search bar and click the search icon (or press Enter):
| metadata type=sourcetypes index=botsv1 | sort - totalCount

What does this search do?

  • The leading pipe | tells Splunk this is a generating command that produces its own results (rather than filtering existing events).
  • metadata type=sourcetypes index=botsv1 retrieves summary information about every sourcetype in the botsv1 index.
  • sort - totalCount orders the results by event count in descending order, so the busiest data sources appear first.
  • Check the Statistics tab. You should see a table listing sourcetypes such as stream:http, suricata, WinEventLog:Security, and others, ranked by total event count.

What do these sourcetypes mean?

  • stream:http and stream:dns are captured network traffic (HTTP requests, DNS queries).
  • WinEventLog:Security contains Windows authentication events like logins and failures.
  • suricata holds alerts from the Suricata intrusion detection system (IDS).
  • XmlWinEventLog:Microsoft-Windows-Sysmon/Operational records detailed process and file activity from Sysmon.

Not seeing any results?

  • Make sure the time range picker is set to All time. The default is Last 24 hours, which will miss the historical BOTS data entirely.
  • Double-check that you typed index=botsv1 exactly. The index name is case-sensitive.

Help me troubleshoot why my metadata search returns no results.

Identify top HTTP traffic sources

HTTP traffic is often the first place to look for web-based attacks. Attackers perform reconnaissance by making many requests to a web server, probing for vulnerabilities.

  • Clear the previous search, then enter this search and press Enter:
index=botsv1 sourcetype=stream:http | stats count by src_ip dest_ip | sort - count | head 20

What does this search do?

  • index=botsv1 sourcetype=stream:http filters events to only HTTP network traffic captured in the dataset.
  • stats count by src_ip dest_ip counts how many HTTP events each source IP sent to each destination IP.
  • sort - count | head 20 shows only the top 20 busiest source-destination pairs, ranked by volume.

A legitimate user generates moderate, spread-out traffic. An attacker scanning a web server generates thousands of requests in a short period.

  • Check the Statistics tab. Look for any source IP that has a dramatically higher count than the others.
  • Note down any IP address that appears at the top with a disproportionately large event count. This is likely an attacker performing reconnaissance.

All counts look similar?

  • Confirm you set the time range to All time before running the search.
  • Check that sourcetype=stream:http is typed exactly with no extra spaces.

Help me understand my HTTP traffic results in Splunk.

Filter for error responses to confirm attacker IPs

High traffic volume alone does not prove malicious intent. Attackers performing scans and brute-force attempts generate many HTTP error responses (status codes 400 and above) because they are hitting pages that do not exist or submitting invalid credentials.

  • Clear the previous search, then enter this search and press Enter:
index=botsv1 sourcetype=stream:http status_code>=400 | stats count by src_ip status_code | sort - count

What does this search do?

  • status_code>=400 filters to only error responses. Status codes in the 400 range mean client errors (like 404 Not Found). Status codes in the 500 range mean server errors triggered by the request.
  • stats count by src_ip status_code groups results by both the source IP and the specific error code, so you can see what types of errors each IP is generating.
  • An IP that appears at the top generating hundreds or thousands of 404 and 403 errors is almost certainly scanning the web server for vulnerabilities.
  • Check the Statistics tab. You should see one or two IPs dominating the error count, generating far more errors than any other source.
  • Confirm that these IPs match the high-traffic IPs you identified in the previous search. This cross-reference proves the traffic is malicious, not just busy.
  • Write down the top attacker IP address(es). You will use them in the next steps to trace the full attack chain.

Keep your attacker IPs handy

Copy the top 1-2 suspicious IP addresses into a text file or sticky note. You will reference them repeatedly in Step 3 and Step 4 to correlate activity across different data sources.

Search returns no events?

  • Make sure you typed status_code>=400 with no spaces around the >= operator. SPL requires the field comparison to be a single token.
  • Verify the time range is still set to All time. Splunk does not persist the time range picker selection between searches if you navigate away.

Help me debug my HTTP error search in Splunk.

You have pinpointed the attacker's IP address using two independent signals: traffic volume and error rate. Next up, you will use these IPs to hunt for authentication attacks and trace the full breach timeline.

Hunt for Authentication Attacks

You've pinpointed suspicious IP addresses hammering the web servers with HTTP requests. Those IPs are your primary suspects.

Now it's time to check whether those same attackers tried to break into user accounts. You'll search Windows Event Logs for failed login attempts, visualize the timing of those attempts, and then correlate the results with your earlier HTTP findings.

In this step, get ready to:
  • Search Windows Security logs for failed login attempts targeting specific accounts.
  • Visualize brute-force attack timing using a timechart.
  • Correlate attacker IPs across authentication and HTTP data sources.
Search for failed login events

Every failed login attempt on a Windows machine generates EventCode 4625 in the Security Event Log. SOC analysts look for clusters of these events to detect brute-force password attacks.

  • In the Search and Reporting app, clear your previous search and paste the following SPL query:
index=botsv1 sourcetype="WinEventLog:Security" EventCode=4625 | stats count by src_ip Account_Name | sort - count
  • Click the green search button (or press Enter) to run the query.

What does this query do?

  • index=botsv1 sourcetype="WinEventLog:Security" EventCode=4625 filters the dataset to only failed logon events from Windows Security logs.
  • stats count by src_ip Account_Name groups the results by the attacker's source IP and the targeted account name, counting how many failed attempts each combination produced.
  • sort - count puts the most-targeted combinations at the top so you can immediately spot who is being attacked and from where.
  • Look at the results table. You should see one or two source IPs with a high count of failed login attempts against specific account names.
  • Note which accounts are being targeted and which IPs are attempting the logins.

Why does EventCode 4625 matter?

EventCode 4625 is the standard Windows event ID for a failed logon attempt. When an attacker tries thousands of password combinations, each failure generates one of these events.

A normal user might trigger a handful of 4625 events (mistyped password). An attacker generates hundreds or thousands in a short window. That volume difference is what makes brute-force attacks detectable.

Not seeing any results?

  • Make sure you have earliest=0 set in your time picker (or select All time from the time range dropdown). The BOTS dataset uses historical timestamps, so a default 24-hour window will return nothing.
  • Double-check the sourcetype is exactly "WinEventLog:Security" with the capital letters and colon.

Ask NextWork AI for help: My EventCode 4625 search in Splunk returns no results from the BOTS v1 dataset

Visualize the attack timeline

Seeing raw counts is useful, but a timeline reveals patterns that numbers alone cannot. Spikes in the chart indicate concentrated bursts of login attempts.

  • Clear the search bar and paste this timechart query:
index=botsv1 sourcetype="WinEventLog:Security" EventCode=4625 | timechart span=1h count by src_ip
  • Run the search.
  • Once results appear, click the Visualization tab above the results area.

What does this query do?

  • timechart span=1h count by src_ip groups failed login events into one-hour buckets, split by source IP.
  • The Visualization tab renders this data as a line chart where the X-axis is time and the Y-axis is the number of failed logins per hour.
  • Tall spikes in the chart represent concentrated brute-force bursts. Short, flat lines represent background noise.
  • Look for one or more obvious spikes in the chart. These spikes correspond to the attacker's brute-force windows.
  • Hover over a spike to see which IP address generated it and the exact hour the burst occurred.

Adjust the chart type

If the default chart type doesn't show the spikes clearly, click the chart type selector (bar, line, area icons) in the Visualization tab toolbar. A line chart or area chart works well for time-series attack data.

Visualization tab is grayed out?

  • The Visualization tab only becomes active after the search completes and produces results. Wait for the search to finish (the green progress bar completes).
  • If your search returns zero events, check the time range picker. Select All time to cover the full historical BOTS dataset.

Ask NextWork AI for help: My timechart visualization is not showing in Splunk after running a search on BOTS v1 data

Correlate activity across data sources

Event correlation is one of the most powerful SIEM techniques. By combining data from different log sources in a single query, you can prove that the same attacker is conducting multiple types of attacks.

  • Clear the search bar and paste this correlation query:
index=botsv1 (sourcetype="WinEventLog:Security" EventCode=4625) OR (sourcetype=stream:http status_code>=400) | stats count by src_ip sourcetype | sort - count
  • Run the search.

What does this query do?

  • The OR operator pulls events from two completely different data sources into one search: failed logins from Windows logs and HTTP errors from web traffic.
  • stats count by src_ip sourcetype groups results by both the source IP and which log produced the event.
  • If the same IP appears in both WinEventLog:Security and stream:http rows, that IP is conducting coordinated attacks across multiple protocols.
  • Examine the results table. Look for IP addresses that appear in both the WinEventLog:Security and stream:http sourcetype rows.
  • Confirm that the suspicious IPs you identified in Step 2 also appear in the failed login results. This proves the attacker performed both web reconnaissance and brute-force login attempts.

Why is cross-source correlation important?

An attacker rarely uses just one technique. Seeing the same IP in both web scanning logs and authentication failure logs proves coordinated behavior. It elevates a suspicious IP from "maybe a noisy scanner" to "confirmed threat actor."

This is exactly how SOC analysts build cases during incident response. Each additional data source that confirms the same IP strengthens the evidence.

Don't see the same IPs in both sourcetypes?

  • Make sure both parenthetical groups in your query are correct. The first group filters on EventCode=4625 and the second filters on status_code>=400. A typo in either condition will skew results.
  • Verify the time range is set to All time. A narrow time window might exclude one set of events.

Ask NextWork AI for help: My Splunk correlation query is not showing the same IPs in both WinEventLog and stream:http sourcetypes

You've now traced the attacker across multiple data sources and proven coordinated attack behavior. Next up, you'll analyze network traffic for signs of command-and-control communication and data exfiltration.

Analyze Network Traffic for Command and Control

You have confirmed the attacker IP(s) across both web scanning and authentication attacks. Now it is time to follow their trail deeper into the network.

Attackers rarely stop at logging in. Once inside, they establish command and control (C2) channels to communicate with compromised hosts, exfiltrate data, and maintain persistence. In this step, you will analyze DNS queries, data transfer volumes, and IDS alerts to map the full extent of the attacker's activity.

In this step, get ready to:
  • Examine DNS queries for suspicious patterns that indicate C2 activity.
  • Calculate data transfer volumes between the attacker and internal hosts.
  • Review Suricata IDS alerts to cross-reference with your investigation findings.
Examine DNS queries for C2 indicators

Attackers often use DNS to communicate with their infrastructure. A compromised machine might repeatedly query a domain controlled by the attacker, creating a pattern of unusually frequent lookups.

  • In the Search and Reporting app, clear any existing search and set the time picker to All time.
  • Search for the top DNS queries across the entire dataset by running this SPL query:
index=botsv1 sourcetype=stream:dns | stats count by query | sort - count | head 30

What does this query do?

This query pulls all DNS resolution events from the stream:dns sourcetype.

  • stats count by query counts how many times each domain was queried.
  • sort - count | head 30 returns only the 30 most-queried domains, sorted from highest to lowest.

Domains with unusually high query counts or suspicious-looking names (random characters, uncommon TLDs) could be C2 beacons phoning home at regular intervals.

  • Review the results table. Look for domains with disproportionately high counts or names that look randomly generated.
  • Note any suspicious domain names. These are potential C2 indicators you will cross-reference later.

Not seeing any DNS results?

Make sure your time picker is set to All time. The BOTS dataset contains historical events, so a relative time range like "Last 24 hours" returns nothing.

Double-check that you typed sourcetype=stream:dns exactly. A typo in the sourcetype name returns zero events.

Still stuck? Why is my DNS search returning no results in Splunk?

Calculate data transfer volumes for potential exfiltration

Once an attacker gains access, they often download tools or exfiltrate stolen data. Large outbound data transfers from internal hosts to the attacker IP are a strong indicator of data theft.

  • Run the following SPL query, replacing the attacker IP placeholder with the IP address you identified in Step 2:
index=botsv1 sourcetype=stream:http src_ip="[[ATTACKER_IP="the attacker IP you identified in Step 2"]]" | stats sum(bytes_in) as total_in sum(bytes_out) as total_out by dest_ip | eval mb_in=round(total_in/1024/1024,2) | eval mb_out=round(total_out/1024/1024,2) | table dest_ip mb_in mb_out

What does this query do?

This query calculates how much data flowed between the attacker and each internal host they communicated with.

  • stats sum(bytes_in) as total_in sum(bytes_out) as total_out by dest_ip totals all bytes transferred in each direction, grouped by destination IP.
  • eval mb_in=round(total_in/1024/1024,2) converts raw bytes into megabytes for readability.
  • table dest_ip mb_in mb_out formats the output as a clean table showing only the columns you need.

A destination IP with a high mb_out value means the attacker sent a lot of data to that host (potentially uploading malware). A high mb_in means data flowed back to the attacker (potential exfiltration).

  • Review the results table. Identify which internal hosts received the most data from the attacker and which sent data back.
  • Note the destination IPs with the highest transfer volumes. These are the hosts most impacted by the breach.

Query returning no results?

The most common cause is a typo in the attacker IP address. Make sure you replaced the placeholder with the exact IP from your Step 2 investigation, wrapped in quotes.

If you are unsure which IP to use, re-run your earlier query: index=botsv1 sourcetype=stream:http status_code>=400 | stats count by src_ip | sort - count. The top result is your attacker IP.

Need help? My data transfer query returns zero results even with the correct attacker IP.

Review Suricata IDS alerts

A network Intrusion Detection System (IDS) like Suricata watches network traffic and fires alerts when it matches known attack signatures. The BOTS dataset includes Suricata alerts that were generated during the simulated breach.

  • Search for the top Suricata alert signatures and categories by running this query:
index=botsv1 sourcetype=suricata | stats count by alert.signature alert.category | sort - count | head 20

What does this query do?

This query summarizes all Suricata IDS alerts by their signature name and category.

  • alert.signature is the human-readable name of the threat detected (e.g., "ET SCAN" for scanning activity).
  • alert.category groups alerts into broader threat types (e.g., "Attempted Information Leak", "Web Application Attack").

Cross-reference the alert signatures with the attacker activity you have already identified. If you see scanning or brute-force signatures associated with the same timeframe and targets, the IDS independently confirms your investigation findings.

  • Review the results. Look for alert signatures that correlate with the reconnaissance and brute-force activity you found in Steps 2 and 3.
  • Note the top alert categories. These confirm which types of attacks the IDS flagged independently of your manual investigation.

Seeing zero Suricata events?

Verify the sourcetype is spelled exactly as sourcetype=suricata (all lowercase, no colon prefix).

If the query runs but returns no alert fields, try expanding a raw event first: index=botsv1 sourcetype=suricata | head 5. Check whether the field names match alert.signature and alert.category in the event data.

Still stuck? Why am I not seeing Suricata alert fields in my Splunk search results?

You have now mapped the attacker's full kill chain: reconnaissance, brute-force authentication, and potential data movement, confirmed across multiple independent data sources. Next up, you will turn these findings into a polished security monitoring dashboard.

Build a Security Monitoring Dashboard

In the previous step, you mapped the attacker's full kill chain across DNS, HTTP, Windows Event Logs, and Suricata IDS data. That investigation lives only in your search history right now.

In this step, you will turn your key findings into a permanent, shareable dashboard. Dashboards are how SOC analysts communicate investigation results to their team and management.

In this step, get ready to:
  • Save key SPL searches as reusable reports.
  • Create a security monitoring dashboard with multiple visualization panels.
  • Add a summary metric panel for at-a-glance monitoring.
Save key searches as reports

A report in Splunk is a saved search you can run again, share with your team, or use as a data source for dashboard panels. You will save two of your investigation searches as reports.

  • In the Search and Reporting app, paste the following search into the search bar and run it:
index=botsv1 sourcetype="WinEventLog:Security" EventCode=4625 | timechart span=1h count by src_ip

What does this search do?

This is the authentication attack timechart from your earlier investigation. It counts failed login attempts (EventCode 4625) per hour, broken down by source IP. Saving it as a report means you can rerun it or add it to a dashboard without retyping.

  • Once the search completes, click Save As in the toolbar above the search bar.
  • Select Report.
  • In the Title field, type Failed Login Attempts Over Time.
  • Click Save.

A confirmation dialog appears. You can close it for now.

  • Now run your combined attacker correlation search by pasting this into the search bar:
index=botsv1 (sourcetype="WinEventLog:Security" EventCode=4625) OR (sourcetype=stream:http status_code>=400) | stats count by src_ip sourcetype | sort - count

What does this search do?

This query pulls events from both the Windows Security log (failed logins) and the HTTP stream (error codes 400+), then counts them by source IP and sourcetype. It surfaces the IPs that appear in both attack vectors, proving coordinated behavior.

  • Once the search completes, click Save As in the toolbar.
  • Select Report.
  • In the Title field, type Top Attacker Source IPs.
  • Click Save.

You now have two saved reports ready to use as dashboard panel data sources.

Don't see Save As in the toolbar?

The Save As button only appears after the search has completed or is running. Make sure you clicked the search button (or pressed Enter) and that results have loaded before trying to save.

help me find the Save As button in the Search and Reporting app

Create a security monitoring dashboard

Dashboards combine multiple visualizations on a single page, giving you an at-a-glance view of attack activity. You will create a new Classic Dashboard and populate it with panels from your saved reports.

  • In the navigation bar at the top of Splunk Web, click Dashboards.
  • Click Create New Dashboard.
  • In the Dashboard Title field, type Security Investigation Dashboard.
  • Leave Dashboard Permissions set to Private.
  • Click Create Dashboard.

Splunk opens your new empty dashboard in edit mode.

  • Click Add Panel.
  • In the panel sidebar, expand New from Report.
  • Select Failed Login Attempts Over Time from the list.
  • Click Add to Dashboard.

What visualization type will this panel use?

Because the underlying search uses the timechart command, Splunk automatically renders it as a line chart. The panel shows failed login spikes over time, broken out by attacker IP.

  • Click Add Panel again.
  • Under New from Report, select Top Attacker Source IPs.
  • Click Add to Dashboard.

This panel displays as a table showing the count of events per source IP and sourcetype.

  • Click Add Panel one more time.
  • Expand the New category to create a panel with an inline search.
  • Paste the following search into the search field:
index=botsv1 sourcetype=suricata | stats count by alert.signature alert.category | sort - count | head 20
  • Set the visualization type to Bar Chart.
  • Click Add to Dashboard.

Why a bar chart for Suricata alerts?

Bar charts are ideal for comparing discrete categories. Each bar represents a different Suricata IDS alert signature, so you can instantly see which alert types fired most often during the attack.

Your dashboard now has three panels: a line chart of failed logins over time, a table of top attacker IPs, and a bar chart of IDS alerts.

Add a summary metric panel and save the dashboard

A single-value panel provides an at-a-glance indicator. You will add one that shows the total count of failed login events across the entire dataset.

  • Click Add Panel.
  • Expand the New category.
  • Paste the following inline search:
index=botsv1 sourcetype="WinEventLog:Security" EventCode=4625 | stats count
  • Set the visualization type to Single Value.
  • Click Add to Dashboard.
  • Click Save at the top of the dashboard editor to save all changes.

What does this panel show?

The single-value panel displays one number: the total count of all EventCode 4625 (failed login) events in the dataset. In a real SOC environment, this metric would update in near-real-time as new logs arrive, giving analysts an instant sense of authentication attack volume.

Your completed dashboard now loads with four panels: the authentication attack timeline, top attacker IPs, Suricata IDS alerts, and a total failed login count.

Dashboard panels show no results?

Make sure the time range picker at the top of the dashboard is set to All time. The BOTS v1 dataset uses historical timestamps, so a default range like "Last 24 hours" will return zero events.

If a report-based panel is blank but the inline search panels work, confirm that you saved both reports successfully by navigating to Reports in the app bar and checking they appear in the list.

help me troubleshoot why my Splunk dashboard panels are showing no results

Secret mission

Enrich with Threat Intelligence and Build an Alert

You have identified the attacker and mapped their kill chain. Now take your investigation from reactive analysis to proactive detection by enriching your searches with threat intelligence and building a scheduled alert that catches brute-force attacks automatically.

Clean Up Your Resources

Clean Up Your Resources

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

Resources you used:

  • Splunk Enterprise installation at C:\Program Files\Splunk (local, no cloud costs).
  • BOTS v1 attack-only dataset stored inside C:\Program Files\Splunk\etc\apps (approximately 135 MB compressed, expands to a few hundred MB on disk).
  • Saved reports, dashboard, lookup file, and scheduled alert stored within the Splunk installation.

Keep everything running

No action needed. Choose this if you are still actively building or want to continue exploring the BOTS dataset.

  • Your 60-day Splunk Enterprise trial gives you full Enterprise features. After 60 days it converts to a perpetual free license with a 500 MB/day indexing limit.
  • Since the BOTS v1 data is pre-indexed, no additional indexing volume is consumed when you search it.
  • Your saved reports, dashboard, lookup file, and scheduled alert remain available at http://localhost:8000 whenever the Splunkd service is running.

Pause - I'll come back to this later

Stop the Splunk service to free up memory and CPU. Your data, searches, dashboards, and alerts are preserved on disk.

  • Open an administrative Command Prompt and stop the service by running:
  • To restart Splunk later, run NET START splunkd from an administrative Command Prompt. Then open http://localhost:8000 in your browser.
NET STOP splunkd

All your configuration, indexed data, reports, and dashboards remain intact on disk.

Delete - I don't want to use this again

Remove Splunk and all project data from your machine entirely.

  • Stop the Splunk service first. Open an administrative Command Prompt and run:
NET STOP splunkd
  • Open the Control Panel.
  • Select Programs and Features (or Apps & features in Windows Settings).
  • Find Splunk Enterprise in the list, select it, and click Uninstall.
  • If you see a reboot prompt from the installer, you can safely ignore it.
  • The MSI uninstaller may leave configuration and index files behind. Delete the remaining installation directory by running this in an administrative Command Prompt:
rmdir /s /q "C:\Program Files\Splunk"

This removes all Splunk data including the BOTS v1 dataset, your saved reports, dashboard, lookup file, and scheduled alert.

What about my Splunk account?

The Splunk.com account you created to download the installer is free and has no associated costs. You can leave it active for future downloads or community access.

Nice Work!

Nice Work!

You just investigated a realistic security breach using Splunk Enterprise as your SIEM. From raw security logs to a polished dashboard, you followed the same threat-hunting workflow that SOC analysts perform every day.

You've learned how to:

  • Write SPL queries using stats, eval, timechart, and metadata to investigate attacker activity across Windows Event Logs, HTTP streams, DNS, and Suricata IDS.
  • Correlate events across multiple data sources to map an attacker's full kill chain, from reconnaissance and brute-force authentication to potential data exfiltration.
  • Build a security monitoring dashboard with visualization panels showing attack timelines, top attacker IPs, IDS alert signatures, and summary metrics.
  • Secret Mission: Created a threat intelligence lookup table to enrich search results with threat categories and configured a scheduled alert that detects brute-force login patterns.

Ready to quiz yourself?