Analyze Web Logs with Splunk

Set up a local SIEM, ingest web logs, and build a security dashboard.

Introduction

30 Second Summary

Every time you visit a website, a log entry is created. Security teams analyze millions of these entries daily to detect hackers, failed logins, and suspicious activity before damage is done.

In this project, you will install Splunk Enterprise on your Windows machine, ingest web server and authentication logs, write search queries to hunt for threats, and build a security monitoring dashboard.

What You'll Build

A local SIEM deployment that analyzes Apache web access logs and SSH authentication logs from Splunk's official Buttercup Games sample dataset.

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

  • A running Splunk Enterprise instance with indexed sample data including web access logs, authentication logs, and vendor sales logs.
  • A set of SPL queries that filter events, aggregate statistics, and identify security-relevant patterns like failed logins and brute-force attempts.
  • A custom dashboard visualizing failed login attempts, top client IPs, and HTTP error rates.
  • Secret Mission: Create an automated alert that detects brute-force login attempts when they exceed a threshold.

Are there any prerequisites?

No prior security or Splunk experience is needed. You do need a Windows 10 (or newer) machine with a 2-core 64-bit CPU at 2 GHz or greater and at least 4 GB of RAM.

The Splunk Enterprise installer is approximately 1 GB, so a stable internet connection helps during the download step.

Install Splunk Enterprise on Windows

Before you can analyze any logs, you need a place to send them. Splunk Enterprise is a SIEM platform that collects, indexes, and searches machine data from any source.

In this step, you'll install Splunk Enterprise locally on your Windows machine. This gives you a full-featured security analytics platform running at http://localhost:8000 with a 60-day trial license.

In this step, get ready to:
  • Create a free Splunk account and download the installer.
  • Run the MSI installer and configure admin credentials.
  • Verify Splunk is running in your browser.
Create a Splunk account and download the installer

Splunk offers a free 60-day Enterprise trial with no credit card required. You need an account to access the download page.

  • Open your web browser and navigate to the Splunk Enterprise download page.
  • Click Free Trial.
  • Create a new Splunk account with your email address and a password. No credit card is required.
  • After signing in, you'll see the download page. Make sure Windows is selected as the operating system.
  • Download the 64-bit .msi installer. The file is named splunk-10.4.0-f798d4d49089-windows-x64.msi and is approximately 1 GB.
  • Wait for the download to complete before continuing.

What is Splunk Enterprise?

Splunk Enterprise is the industry-standard SIEM platform used by Security Operations Center (SOC) teams worldwide. It ingests log data from servers, applications, and network devices, then lets analysts search and visualize that data to detect threats.

The 60-day trial gives you full access to every feature. After it expires, Splunk converts to a perpetual Free license with a 500 MB per day indexing limit.

System requirements

You need a 64-bit Windows 10 (or newer) machine with at least a 2-core CPU at 2 GHz and 4 GB of RAM. The installer itself is about 1 GB, and you'll need additional disk space for indexed data.

Download not starting?

Some browsers block large downloads. Check your browser's download bar or notification area for a blocked download prompt and allow it.

If the page asks for a work email, make sure you selected Splunk Enterprise (not Splunk Cloud). The Enterprise trial accepts any email address.

help me download Splunk Enterprise on Windows

Run the MSI installer with default settings

The installer is a standard Windows MSI file that walks you through setup with a GUI wizard. You'll accept the license, choose how Splunk runs, and create your admin credentials.

  • Navigate to your Downloads folder in File Explorer.
  • Double-click the splunk-10.4.0-f798d4d49089-windows-x64.msi file to launch the installer.
  • The installer displays the Splunk Enterprise Installer panel. Check the Check this box to accept the License Agreement checkbox.
  • Click Next to install with default settings.
  • The installer prompts you to create an administrator password. Enter a username (e.g. admin) and a strong password you'll remember.
  • Click Next again to begin installation. This may take a few minutes.

What do the default settings do?

With default settings, the installer places Splunk Enterprise at C:\Program Files\Splunk and runs it as the Local System user. It also installs two Windows services: splunkd (the core engine) and splunkweb (the web interface).

You do not need to customize anything for this project. The defaults are perfect for a local learning environment.

  • When the installation completes, the Installation Complete panel appears.
  • Check the Launch browser with Splunk Enterprise checkbox.
  • Click Finish.

Write down your credentials

Keep your admin username and password somewhere safe. You'll use these credentials every time you log into Splunk Web throughout this project.

Installation taking too long?

The installation typically takes 2-5 minutes depending on your machine. If it seems stuck, do not close the installer. Let it finish processing.

If you see a Windows User Account Control (UAC) prompt asking for permission, click Yes to allow the installer to make changes.

help me troubleshoot my Splunk Enterprise installation on Windows

Verify Splunk is running

If you checked the launch option, your browser should open automatically. If it didn't, you can navigate there manually.

  • Open your web browser and go to http://localhost:8000.
  • You should see the Splunk Web login page.
  • Enter the admin username and password you created during installation.
  • Click Sign In.

You should now see the Splunk Home page with the Search & Reporting app listed. This confirms Splunk Enterprise is installed and running successfully.

What is the Search & Reporting app?

Search & Reporting is the default app included with every Splunk installation. It provides the search bar, timeline visualization, and field explorer that you'll use throughout this project to analyze log data.

Can't reach localhost:8000?

Splunk services may need a moment to start after installation. Wait 30 seconds and refresh the page.

If the page still won't load, open Windows Services by pressing the Windows key, typing services.msc, and pressing Enter. Look for Splunkd Service in the list and confirm its status is Running. If it says Stopped, right-click it and select Start.

help me get Splunk Web running at localhost:8000

Your Splunk Enterprise instance is live and ready to ingest data. Next up, you'll feed it real web server logs and authentication data to start hunting for security events.

Ingest the Buttercup Games Sample Data

Splunk is installed and running, but it has no data to analyze yet. A SIEM without data is like a security camera with no footage.

In this step, you will download Splunk's official sample dataset and feed it into your instance. This gives Splunk real log events to index, search, and visualize in the steps ahead.

In this step, get ready to:
  • Download the Buttercup Games tutorial data from Splunk's documentation.
  • Upload the data using Splunk's Add Data wizard.
  • Confirm that all three log types are indexed and searchable.
Download the tutorial data files

Splunk provides a sample dataset called "Buttercup Games" specifically for learning. It contains web server access logs, SSH authentication logs, and vendor sales logs for a fictitious online store.

What is inside this dataset?

The tutorialdata.zip file contains three types of log files from a fictitious online store called Buttercup Games:

  • access.log contains Apache web server access logs with fields like clientip, status, and productid.
  • secure.log contains SSH authentication events, including failed login attempts.
  • vendor_sales.log contains purchase transaction records.

The data is timestamped for the previous seven days from your download date, so it always appears fresh.

File downloaded as a folder instead of a .zip?

Some browsers (especially Safari) automatically uncompress ZIP files after downloading. If you see a folder instead of a .zip file, re-compress the folder before uploading.

In Chrome or Firefox, this usually does not happen. If you are using Safari, uncheck Open "safe" files after downloading in Preferences > General before downloading again.

Help me fix my tutorialdata.zip file

Upload the data using the Add Data wizard

Splunk's Add Data wizard walks you through importing files into an index. Once data is indexed, it becomes searchable through SPL.

  • Switch back to your Splunk Web tab at http://localhost:8000.
  • Click Settings in the top navigation bar.
  • Click Add Data.
  • At the bottom of the page, click Upload.
  • Click Select File and choose the tutorialdata.zip file from your Downloads folder.
  • Click Next to continue to Input Settings.

Why did Splunk skip Set Source Type?

Because you uploaded a compressed file, Splunk automatically recognizes the data source type. If you were uploading an uncompressed file, Splunk would ask you to identify the format manually.

  • Under Host, change the dropdown to Segment in path.
  • In the segment number field, type 1.
  • Click Review.
  • Review your settings, then click Submit.

Why set Host to Segment in path?

The ZIP file contains logs from different hosts (servers). Setting the host to a path segment tells Splunk to extract the host name from each file's path inside the archive. This means each log source gets its own host value, which is useful for filtering later.

You should see a success message confirming the data has been uploaded and indexed.

Seeing an error during upload?

Make sure you selected the tutorialdata.zip file itself, not an unzipped folder. Splunk requires the compressed archive for this upload method.

If you see a file size error, confirm you downloaded the correct file from the tutorial page (not a different dataset).

Help me fix my Splunk data upload error

Confirm data is indexed

Now that the upload is complete, you need to verify Splunk actually processed and indexed all three log types.

  • Click Start Searching on the success page.
  • The Search app opens and automatically runs a search on your uploaded data. You should see events listed below the search bar.
  • In the time range picker (to the right of the search bar), select Last 7 days.
  • Clear the search bar and type the following search, then press Enter:
source="tutorialdata.zip:*"

What does this search do?

The source field in Splunk identifies where each event came from. The wildcard * matches all files inside the ZIP archive. This search returns every event from all three log files at once.

You should see events from all three log types: access log entries with HTTP status codes, secure log entries with authentication messages, and vendor sales entries.

Not seeing any results?

The most common cause is the time range. The tutorial data contains events from the previous seven days relative to when you downloaded it. If you waited more than a day between downloading and uploading, expand the time range to All time and try again.

Also confirm the search is typed exactly as shown. The quotes around tutorialdata.zip:* are required.

Help me troubleshoot my Splunk search results

Your Splunk instance now has real log data to work with. Next up, you will write SPL queries to search through these logs and hunt for security-relevant patterns like failed logins and suspicious IP addresses.

Search and Explore with SPL

Your Buttercup Games data is indexed and ready to explore. Now you need a way to sift through thousands of log events to find the ones that matter.

Splunk's Search Processing Language (SPL) lets you filter, transform, and aggregate events using simple commands piped together. In this step, you'll start with keyword searches and build up to multi-command pipelines that reveal security patterns hiding in your logs.

In this step, get ready to:
  • Run keyword searches to filter events by text and field values.
  • Use SPL pipe commands to aggregate and sort data.
  • Investigate security events to identify potential brute-force attacks.
Run basic keyword searches

The simplest way to find events in Splunk is to type a keyword into the search bar. Splunk scans every indexed event and returns matches, highlighting the terms it found.

  • Return to the Search & Reporting app in Splunk Web.
  • Click the time range picker to the right of the search bar and select Last 7 days under Presets.
  • Type the following into the search bar and press Enter (or click the green search icon):
fail*

What does this search do?

The * is a wildcard. Searching fail* matches any word starting with "fail" across all your indexed data. This catches "failed", "failure", "failing", and similar variations in a single search.

You should see events appear in the Events tab, with matching terms highlighted in orange. The timeline at the top shows when these events occurred over the past 7 days.

  • Now clear the search bar and type this search to find web pages that returned "Not Found" errors:
status=404

What is a field search?

Instead of searching for raw text, status=404 searches a specific field. Splunk automatically extracts fields like status, clientip, and _time from your log data. Field searches are faster and more precise than keyword searches.

You should see events where web requests returned a 404 HTTP status code. These represent pages or resources that visitors tried to access but could not find.

Not seeing any results?

Check your time range picker. The tutorial data contains events from the 7 days before you downloaded it. If you see zero results, click the time range picker and select Last 7 days or All time.

Also confirm you uploaded tutorialdata.zip in the previous step. Run source="tutorialdata.zip:*" to check if any data exists.

Help me troubleshoot why my Splunk search returns no results.

Use SPL commands to aggregate data

Keyword searches find individual events, but real analysis requires aggregation. SPL uses the pipe character (|) to chain commands together, passing the output of one command into the next.

  • Clear the search bar and run this query to see a breakdown of HTTP status codes in your web access logs:
source="tutorialdata.zip:*/access.log" | stats count by status

What does this query do?

This query has two parts joined by a pipe. The first part (source="tutorialdata.zip:*/access.log") filters to only Apache access log events. The second part (stats count by status) counts how many events exist for each unique HTTP status code value.

The stats command is one of SPL's most powerful aggregation tools. It groups events by a field and calculates values like count, sum, average, or max.

Click the Statistics tab to see your results as a table. You should see status codes like 200, 404, and others with their counts.

  • Now run this query to identify the top 10 IP addresses generating the most requests:
source="tutorialdata.zip:*/access.log" | stats count by clientip | sort -count | head 10

What do sort and head do?

After stats count by clientip groups requests by IP address, sort -count arranges the results in descending order (the minus sign means descending). Then head 10 keeps only the first 10 rows.

In security operations, identifying "top talkers" helps you spot scanners, bots, or compromised hosts generating unusual traffic volume.

Click the Statistics tab. You should see a table of 10 IP addresses sorted from most to fewest requests.

Seeing an error about the source field?

Make sure the quotes around the source value are straight double quotes, not curly/smart quotes. Copy the query directly from above if needed.

Also confirm the path includes the wildcard: tutorialdata.zip:*/access.log. The * matches the directory structure inside the zip file.

Help me fix my SPL source path query.

Investigate security events

Your indexed data also contains SSH authentication logs from a Linux server. These logs record every login attempt, including failed ones. A cluster of failed password attempts from a single IP address is a classic indicator of a brute-force attack.

  • Run this query to find all failed SSH login attempts in the secure log:
source="tutorialdata.zip:*/secure.log" "Failed password"

Why the quotes around Failed password?

Wrapping "Failed password" in double quotes tells Splunk to search for that exact phrase. Without quotes, Splunk would search for events containing both words anywhere in the event, not necessarily together.

You should see events in the Events tab showing failed SSH login attempts. Each event includes details like the username attempted and the source IP address.

  • Now pipe those results into a stats command to count failed attempts by source IP address:
source="tutorialdata.zip:*/secure.log" "Failed password" | stats count by src_ip

What does this tell a security analyst?

This query groups failed login attempts by their source IP. If one IP has significantly more failed attempts than others, it is likely running an automated brute-force attack against your server.

This is exactly the kind of query a SOC analyst writes when investigating suspicious authentication activity. The pattern of "filter, then aggregate" is the foundation of threat hunting in any SIEM.

Click the Statistics tab. You should see IP addresses with their failed login counts, revealing which addresses are attempting the most logins.

Seeing zero results for the secure log search?

Double-check that your source path is tutorialdata.zip:*/secure.log (not access.log). The phrase "Failed password" is case-sensitive in Splunk searches. Make sure the F in Failed and the p in password match exactly.

Help me find failed login events in Splunk.

✔️ Awesome, I've got everything!

Great. You've run all six SPL queries and can see how keyword searches, field searches, and piped aggregations work together to surface security-relevant patterns.

ⓧ I'd like to double check the full queries

Here are all six queries you should have run in this step:

fail*

status=404

source="tutorialdata.zip:*/access.log" | stats count by status

source="tutorialdata.zip:*/access.log" | stats count by clientip | sort -count | head 10

source="tutorialdata.zip:*/secure.log" "Failed password"

source="tutorialdata.zip:*/secure.log" "Failed password" | stats count by src_ip

You now have hands-on experience writing SPL queries that filter, aggregate, and correlate log data. Next up, you'll turn these queries into a visual security monitoring dashboard that makes patterns instantly recognizable.

Build a Security Monitoring Dashboard

You now have a set of SPL queries that surface security-relevant patterns from your log data.

Queries are powerful, but a SOC analyst needs to monitor multiple signals at once. A dashboard puts your key searches into visual panels that update together on a single screen. In this step, you will build a Security Monitor dashboard with three panels that track failed logins, top client IPs, and HTTP errors.

In this step, get ready to:
  • Create a new Classic Dashboard in the Search & Reporting app.
  • Add panels for failed login counts and top client IPs.
  • Add a pie chart panel for HTTP error codes and save the dashboard.
Create a new dashboard

Before you can add panels, you need an empty dashboard to hold them.

  • In the Search & Reporting app, click Dashboards in the top navigation bar.
  • Click Create New Dashboard.
  • For Dashboard Title, type Security Monitor.
  • For Dashboard Permissions, keep the default Private setting.
  • Select Classic Dashboards as the dashboard type.
  • Click Create.

You should see an empty dashboard in edit mode with the title "Security Monitor" at the top.

Why Classic Dashboards?

Splunk Enterprise offers two dashboard frameworks: Classic Dashboards (built on Simple XML) and Dashboard Studio. Classic Dashboards are simpler to build through the UI and are what the official Splunk tutorials teach.

Add panels for failed logins and top talkers

Each panel on a dashboard runs its own SPL search and displays the results as a specific visualization type. You will add two panels here: one showing total failed login attempts, and one showing which IP addresses generate the most traffic.

  • Click Add Panel in the dashboard editor.
  • Expand the New category and select Single Value as the visualization type.
  • In the search field, paste the following SPL query:
source="tutorialdata.zip:*/secure.log" "Failed password" | stats count AS "Failed Logins"
  • Set the time range to Last 7 days.
  • For the panel title, type Failed Logins.
  • Click Add to Dashboard.

What does this panel show?

This query searches your SSH authentication logs for entries containing "Failed password" and counts the total. The Single Value visualization displays that number as one large figure, giving you an instant read on how many failed login attempts exist in the dataset.

You should see a single large number appear on your dashboard. Now add the second panel.

  • Click Add Panel again.
  • Expand New and select Bar Chart as the visualization type.
  • In the search field, paste this SPL query:
source="tutorialdata.zip:*/access.log" | stats count by clientip | sort -count | head 10
  • Set the time range to Last 7 days.
  • For the panel title, type Top 10 Client IPs.
  • Click Add to Dashboard.

What does this panel show?

This query counts how many requests each client IP made in your web access logs, sorts them in descending order, and shows only the top 10. In a real environment, an IP generating far more traffic than others could indicate a scanner, a bot, or an attacker probing your site.

You should now see two panels on your dashboard: a single number for failed logins and a bar chart showing IP addresses ranked by request volume.

Panel shows no results?

Make sure the time range is set to Last 7 days. The tutorial data is timestamped for the seven days before you downloaded it. If you downloaded the file more than a day ago, try All time instead.

Also check for typos in the source path. The query must use source="tutorialdata.zip:* with the quotes and wildcard exactly as shown.

Still stuck? Help me troubleshoot why my dashboard panel shows no results.

Add an HTTP error rate panel

The final panel visualizes which HTTP error codes your web server is returning. A spike in 4xx or 5xx codes can signal an attack or a misconfiguration.

  • Click Add Panel one more time.
  • Expand New and select Pie Chart as the visualization type.
  • In the search field, paste this SPL query:
source="tutorialdata.zip:*/access.log" status>=400 | stats count by status
  • Set the time range to Last 7 days.
  • For the panel title, type HTTP Errors by Status Code.
  • Click Add to Dashboard.

What does this panel show?

The status>=400 filter catches all HTTP error responses (400 Bad Request, 403 Forbidden, 404 Not Found, 500 Internal Server Error, and so on). The pie chart breaks down the proportion of each error code, so you can quickly see which errors dominate.

  • Click Done Editing at the top of the dashboard to save it.

Your Security Monitor dashboard is now saved with three panels: a Single Value showing failed logins, a Bar Chart of top client IPs, and a Pie Chart of HTTP error codes.

Don't see all three panels?

If a panel is missing, click Edit at the top of the dashboard to re-enter edit mode. Then click Add Panel and repeat the steps for the missing panel.

If a panel shows an error icon, click the panel and check the SPL query for typos. Common mistakes include missing quotes around the source path or using a lowercase as instead of uppercase AS in the stats command.

Need more help? Help me fix my Splunk dashboard panels.

✔️ Awesome, I've got all three panels!

Great work. Your Security Monitor dashboard is complete and saved. Make sure you clicked Done Editing so the dashboard is no longer in edit mode.

ⓧ I'd like to double check my SPL queries

Here are the three SPL queries you should have used, one per panel:

Panel 1 (Single Value, titled "Failed Logins"):

source="tutorialdata.zip:*/secure.log" "Failed password" | stats count AS "Failed Logins"

Panel 2 (Bar Chart, titled "Top 10 Client IPs"):

source="tutorialdata.zip:*/access.log" | stats count by clientip | sort -count | head 10

Panel 3 (Pie Chart, titled "HTTP Errors by Status Code"):

source="tutorialdata.zip:*/access.log" status>=400 | stats count by status

Your Security Monitor dashboard is ready. This is exactly the kind of view a SOC analyst uses to keep an eye on their environment at a glance. Next up, you will take this further with a Secret Mission that adds automated alerting to detect brute-force attacks in real time.

Secret mission

Create a Failed Login Alert

Your dashboard shows security data, but what if you could detect brute-force attacks automatically? In this secret mission, you'll create a scheduled alert that fires when failed SSH login attempts exceed a threshold. This is exactly how SOC teams catch attacks in real time.

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 locally on your Windows machine, so there are no ongoing cloud costs.

The 60-day Enterprise Trial license is free and requires no credit card. After 60 days it converts to a perpetual Free license with 500 MB/day indexing.

Resources you used:

  • Splunk Enterprise installed at C:\Program Files\Splunk (includes all indexed data, dashboards, saved searches, and alerts).
  • Two Windows services: splunkd and splunkweb running in the background.

Keep everything running

No action needed. Choose this if you are still actively building or want to explore more data sources.

  • Splunk continues running as Windows services in the background.
  • You can keep learning by indexing more data sources (like your own Windows Event Logs).
  • The trial license remains active for 60 days. After that, it converts to a perpetual Free license (500 MB/day indexing, alerting disabled).
  • Your splunk.com account remains active. It is free and does not incur charges.

Pause - I'll come back to this later

Stop the Splunk services to free up system resources. Your data and configuration stay on disk.

  • Press the Windows key, type services.msc, and press Enter to open Windows Services.
  • Find Splunkd Service in the list, right-click it, and select Stop.
  • When you want to continue, return to Windows Services and right-click Splunkd Service, then select Start.
  • Splunk Web will be available again at http://localhost:8000 once the service restarts.

Delete - I don't want to use this again

Remove all project resources from your machine. This is irreversible.

  • Press the Windows key, type Add or remove programs, and press Enter.
  • Find Splunk Enterprise in the list, click it, and select Uninstall.
  • If the installer prompts for a reboot, you can safely ignore the request.
  • After uninstall completes, check whether the folder C:\Program Files\Splunk still exists. If it does, delete it manually to remove any residual configuration and index files.

What about my splunk.com account?

Your splunk.com account is free and does not store any of your local indexed data. You can leave it as-is with no cost or security concern. If you want to delete it in the future, you would need to contact Splunk Support directly.

Nice Work!

Nice Work!

You just built your first SIEM deployment and security monitoring dashboard using Splunk Enterprise. This is the exact workflow Security Operations Center analysts perform every day to detect and investigate threats.

Here's what you learned:

  • Installed Splunk Enterprise as a local SIEM and ingested multi-format log data including Apache access logs, SSH authentication logs, and vendor sales logs.
  • Wrote SPL queries to filter events, aggregate statistics, and identify security threats like brute-force login attempts.
  • Built a security monitoring dashboard with panels visualizing failed logins, top client IPs, and HTTP error patterns.
  • Created an automated alert that detects brute-force login attempts when failed SSH logins exceed a threshold.

Ready to quiz yourself?