Investigate a Cyber Attack with Splunk

Hunt threats in real enterprise attack data using Splunk SPL queries.

Introduction

30 Second Summary

Every day, security operations teams sift through millions of log events looking for the one signal that says "someone is inside our network." The tools and techniques they use are exactly what employers test for when hiring SOC analysts.

In this project, you will install Splunk on your machine, load a real-world attack dataset, and investigate a multi-stage cyber attack against a fictional company. You will write queries that uncover hidden malware, map your findings to a professional framework, and publish the whole investigation to GitHub as a portfolio piece.

What You'll Build

You will run your own SIEM loaded with real enterprise attack data, hunt down a compromised endpoint, and present the investigation in a format that proves to any hiring manager you can do the job of a SOC analyst.

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

A complete threat investigation where you trace an attacker from their first suspicious login through confirmed PowerShell Empire C2 malware on a compromised endpoint.
Your own SPL queries that detect authentication anomalies, identify compromised hosts, and uncover hidden malware across 80+ data source types.
A public GitHub repository presenting your findings with MITRE ATT&CK technique mappings, ready to show employers as proof of your investigation skills.
Secret Mission: Build a detection alert rule that automatically catches the attack pattern you uncovered.

Are there any prerequisites?

No prior security or Splunk experience is needed. You will need a Windows machine with at least 8GB of RAM and around 4GB of free disk space. This guide walks you through installing everything from scratch.

Before We Start

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

This project proves a specific skill that SOC analyst employers look for: the ability to use a SIEM tool to investigate a real attack, document your findings, and map them to an industry framework.

Install Splunk and Load the Attack Data

Every threat investigation starts with data. Before you can hunt for attackers hiding in a network, you need a SIEM loaded with logs to search through.

In this step, you will install Splunk Enterprise on your Windows machine and load 320MB of real enterprise attack data from Splunk's Boss of the SOC competition. By the end, you will have a working SIEM with thousands of searchable events ready for investigation.

In this step, get ready to:

Download and install Splunk Enterprise.
Load the BOTS v3 attack dataset into Splunk.
Run your first SPL queries to confirm the data is searchable.

Download and install Splunk Enterprise

Splunk Enterprise is the SIEM platform you will use for your entire investigation. It runs as a local web application on your machine.

Open your web browser and navigate to splunk.com.
Click Free Splunk at the top of the page.
Create a free Splunk account using your email address.
After signing in, find the Splunk Enterprise section and click Download Free Trial.
Select the Windows tab and download the .msi installer (about 1GB).

Why is the download so large?

Splunk Enterprise is a full data analytics platform. The 1GB package includes its search engine, web server, data indexing pipeline, and all the built-in apps. This is the same software used by enterprise SOC teams worldwide.

Once the download completes, double-click the .msi file to launch the installer.
Check the box to accept the license agreement.
Click Next to accept the default installation path (C:\Program Files\Splunk).
When prompted, create an admin username and password. Write these down somewhere safe.
Click Install and wait for the installation to finish.

Remember your credentials

You will use this admin username and password every time you open Splunk. Store them somewhere you can easily find again.

Splunk starts automatically after installation. It runs as a Windows service in the background.

Open your browser and go to http://localhost:8000.
Log in with the admin username and password you just created.

✔️ I see the Splunk dashboard

You are logged into Splunk Enterprise. You should see the Splunk Home page with options like Search & Reporting and Settings.

ⓧ The page won't load

The Splunk service may not have started yet. Give it 30-60 seconds after installation before trying again.

If it still does not load, check that the Splunk service is running:

Press Win+R to open the Run dialog.
Type services.msc and press Enter.
Find Splunkd Service in the list.
If it shows Stopped, right-click it and select Start.
Wait 30 seconds, then try http://localhost:8000 again.

Download and install the BOTS v3 dataset

The BOTS v3 dataset is a 320MB collection of real enterprise security logs from Splunk's Boss of the SOC competition. It contains evidence of a multi-stage cyber attack against a fictional beer company called Frothly.

Download the BOTS v3 dataset by navigating to this URL in your browser:

https://botsdataset.s3.amazonaws.com/botsv3/botsv3_data_set.tgz

What is this dataset?

This is a pre-indexed Splunk dataset released under a Creative Commons Zero (CC0) license. Because the data is pre-indexed, it bypasses Splunk's 500 MB/day indexing limit on the free license. You can search the full 320MB without restrictions.

The downloaded file is a .tgz archive (a compressed tar file). You need to extract it in two steps using 7-Zip.

Need 7-Zip?

If you do not have 7-Zip installed, download it for free from https://www.7-zip.org/download.html. Install it before continuing.

Right-click the downloaded botsv3_data_set.tgz file.
Select 7-Zip then Extract Here. This produces a .tar file.
Right-click the resulting .tar file.
Select 7-Zip then Extract files....
In the Extract to field, enter this path:

C:\Program Files\Splunk\etc\apps\

Click OK and wait for extraction to complete.

What just happened?

You extracted the BOTS v3 dataset into Splunk's apps directory. Splunk loads data from this folder at startup. The extraction creates a botsv3 folder inside C:\Program Files\Splunk\etc\apps\.

Splunk needs to restart before it can see the new dataset.

Go back to your Splunk browser tab at http://localhost:8000.
Click Settings in the top navigation bar.
Click Server controls.
Click Restart Splunk.
Confirm the restart when prompted. Wait 30-60 seconds for Splunk to come back online.
Log back in when the login page reappears.

Now verify that the BOTS v3 data is loaded and searchable.

Click Search & Reporting on the Splunk Home page.
In the time range picker on the right side of the search bar, select All time.
Type the following query into the search bar and press Enter:

index=botsv3 earliest=0

What does this query do?

This is your first SPL (Search Processing Language) query. It tells Splunk to retrieve all events from the botsv3 index. The earliest=0 parameter means "go back to the beginning of time" so no events are excluded by the time filter.

✔️ I see thousands of events

Your BOTS v3 dataset is loaded and working. You should see a large number of events in the results panel. The event count will appear above the results.

ⓧ I see zero results

If the search returns no events, check these common causes:

Make sure the time range picker is set to All time, not a recent window like "Last 24 hours".
Confirm you extracted the dataset to the correct path: C:\Program Files\Splunk\etc\apps\botsv3. Open that folder in File Explorer and check that it contains subfolders.
Restart Splunk again via Settings then Server controls then Restart Splunk.
After restarting, try the search again.

Explore the data landscape

A SOC analyst's first job on any new environment is reconnaissance. You need to understand what kinds of data exist before you can hunt for threats in them.

In the Search & Reporting search bar, clear your previous query.
Make sure All time is still selected in the time range picker.
Run this query to see every data source in the BOTS v3 dataset:

| tstats count where index=botsv3 by sourcetype | sort -count

What does this query do?

The tstats command is a high-performance way to count events. This query counts how many events exist for each sourcetype (data source) and sorts them from most to least common.

The leading | (pipe) tells Splunk this is a generating command that creates data rather than filtering existing results.

Before you run this, what do you think you will see? How many different source types do you expect a real enterprise environment to have?

You should see a table with 80+ source types ranked by event count. Look for these key sources that you will use throughout your investigation:

wineventlog for Windows security events (logons, process creation, privilege changes).
stream:http for captured network HTTP traffic.
aws:cloudtrail for AWS API activity.
linux_secure for Linux authentication logs.
xmlwineventlog:microsoft-windows-sysmon/operational for detailed Windows process monitoring.

Why does this matter?

This is a hybrid enterprise environment with Windows endpoints, Linux servers, AWS cloud infrastructure, network traffic captures, and endpoint protection logs. Real SOC environments look exactly like this. Your investigation will cross multiple source types to piece together the attacker's story.

Only seeing a few source types?

If you see far fewer than 80 source types, the dataset may not have fully extracted. Open C:\Program Files\Splunk\etc\apps\botsv3 in File Explorer and confirm it contains multiple subfolders with data. If it looks empty or only has a few files, re-extract the .tar file and restart Splunk again.

Help me troubleshoot my BOTS v3 data extraction in Splunk.

Your SIEM is loaded and ready. You have a real enterprise environment to investigate, complete with Windows endpoints, Linux servers, cloud infrastructure, and network traffic. Next up, you will learn the SPL query language by profiling this environment and understanding what "normal" looks like.

Learn SPL by Exploring the Frothly Environment

Your Splunk instance is running and loaded with 320MB of real attack data from the Frothly enterprise. Now you need to learn how to actually search through it.

Before hunting threats, a SOC analyst's first job on any new environment is reconnaissance. You need to understand what data sources exist and what "normal" looks like. Running blind searches wastes time and misses context, so you will start by exploring the Frothly environment with SPL (Search Processing Language).

In this step, get ready to:

Run basic SPL queries to understand the Frothly data landscape.
Profile the Windows endpoints and identify key Event Codes.
Profile the Linux and cloud sources to map the full hybrid environment.

Run basic SPL queries to understand the environment

SPL queries run in Splunk's search bar and return results instantly. You will start with the simplest possible query and build up from there.

In the Search & Reporting app, make sure the time range picker (next to the search bar) is set to All time.
Type this query into the search bar and click the green search button (or press Enter):

index=botsv3 earliest=0

You should see thousands of events appear in the results panel. Each event is a log entry from the Frothly enterprise environment.

Seeing zero results?

Make sure the time range picker is set to All time, not the default "Last 24 hours". The BOTS v3 data is historical, so a recent time window will find nothing.

Also confirm that earliest=0 is in your query. This overrides the time picker and searches from the beginning of time.

Help me troubleshoot why my Splunk BOTS v3 search returns no results.

Filter to only Windows events by running this query:

index=botsv3 sourcetype=wineventlog

The results now show only Windows Event Log entries. The sourcetype filter narrows your search to a specific type of data.

Count events by host to see which machines generated the most logs by running this query:

index=botsv3 | stats count by host | sort -count

Click the Statistics tab below the search bar to see a clean table of hosts ranked by event count.

What is the pipe operator?

The | character passes results from one command to the next, like a Unix pipeline. In the query above, index=botsv3 finds all events, then stats count by host groups and counts them, then sort -count orders the table from highest to lowest.

Explore the network traffic data by running this query:

index=botsv3 sourcetype="stream:http" | stats count by src_ip | sort -count

In the Statistics tab, you should see a table of source IP addresses ranked by how many HTTP requests they made. This is network-level data captured from Frothly's environment.

Profile the Windows endpoints

Windows Event Logs are the bread and butter of security monitoring. You need to know which hosts exist and which Event Codes appear most frequently.

Identify the main Windows hosts by running this query:

index=botsv3 sourcetype=wineventlog | stats count by host | sort -count

Click the Statistics tab. You should see the Windows hosts in the Frothly environment listed with their event counts.

Before you run the next query, think about this: which Windows Event Codes do you expect to see the most in an enterprise environment? Process creation? Logons? Something else?

Find the most common Event Codes by running this query:

index=botsv3 sourcetype=wineventlog | stats count by EventCode | sort -count

In the Statistics tab, you should see a table of Windows Event Codes ranked by frequency. The top codes tell you what kind of activity dominates this environment.

What do these Event Codes mean?

The three most important Event Codes for security monitoring are:

4688 means a new process was created (someone ran a program).
4624 means a successful account logon.
4625 means a failed account logon (wrong password or unauthorized access attempt).

These three codes will be your primary hunting tools in the next step when you search for signs of attack.

Profile the Linux and cloud sources

Frothly is not just a Windows shop. Real enterprise environments are hybrid, spanning on-premises servers and cloud infrastructure. You need to profile the full picture.

Identify the Linux hosts by running this query:

index=botsv3 sourcetype=linux_secure | stats count by host

In the Statistics tab, you should see Linux hosts that generate authentication logs. These are servers in Frothly's environment running Linux.

Explore the AWS CloudTrail activity by running this query:

index=botsv3 sourcetype="aws:cloudtrail" | stats count by eventName | sort -count

In the Statistics tab, you should see a ranked list of AWS API calls. These show what actions were taken in Frothly's cloud infrastructure.

Why does this matter for threat hunting?

You have now confirmed that Frothly runs a hybrid environment: Windows endpoints, Linux servers, and AWS cloud infrastructure. An attacker who compromises one layer can pivot to another.

Real SOC environments look exactly like this. Knowing which data sources exist before you start hunting means you will not miss evidence hiding in a source type you forgot to check.

AWS CloudTrail query returning no results?

Make sure you include the quotes around "aws:cloudtrail" in the sourcetype filter. The colon in the name requires quotes. Also confirm your time range is still set to All time.

Help me troubleshoot why my AWS CloudTrail query returns no results in Splunk.

You now have a mental map of the Frothly environment. Windows endpoints generating process and logon events. Linux servers with authentication logs. AWS cloud activity tracked by CloudTrail. Next up, you will use this knowledge to hunt for the actual attack hidden in the data.

Hunt for the Initial Compromise

You have explored the Frothly environment and understand what data sources exist across the 80+ source types. Now it is time to shift from reconnaissance to active threat hunting.

Real SOC analysts begin every investigation the same way. They start with authentication logs and look for what does not belong. In this step, you will examine Windows logon events to find anomalies, then follow the evidence wherever it leads.

In this step, get ready to:

Analyze Windows authentication events for unusual patterns.
Identify the host with the highest process creation activity.
Document a primary investigation target based on combined evidence.

Examine Windows authentication patterns

Authentication logs tell you who is trying to access what. Two Windows Event Codes matter most here: 4625 (failed logon) and 4624 (successful logon).

Search for failed logons across the environment by pasting this query into the Search bar and clicking the search icon:

index=botsv3 sourcetype=wineventlog EventCode=4625 | stats count by Account_Name, host | sort -count

What does this query do?

index=botsv3 sourcetype=wineventlog EventCode=4625 filters to only failed logon events in Windows Event Log.
stats count by Account_Name, host groups the results by who tried to log in and where.
sort -count puts the accounts with the most failures at the top.

Click the Statistics tab to see your results as a table. Notice that the failed logon count is surprisingly low.

Now search for successful logons by running this query:

index=botsv3 sourcetype=wineventlog EventCode=4624 | stats count by Account_Name, host | sort -count

Click the Statistics tab again. You should see hundreds of successful logon events spread across multiple hosts and accounts.

Why is this pattern unusual?

In most compromised environments, you would expect a spike in failed logons from brute force attempts. Here, the failed logon count is very low compared to the volume of successful logons.

This could mean the attacker already had valid credentials, or used a method that bypassed normal authentication. Either way, authentication logs alone will not reveal the full picture.

Not seeing any results?

Make sure your time range picker (to the right of the Search bar) is set to All time. The default is Last 24 hours, which will return nothing for this historical dataset.
Check that the query uses EventCode=4625 (capital E, capital C) exactly as shown. SPL field names are case-sensitive.
help me troubleshoot why my Splunk search returns no results for Windows Event Log data

Pivot to process creation activity

Authentication logs showed an oddly quiet picture. Process creation events (EventCode=4688) reveal what programs actually ran on each machine. A host that launches far more processes than its peers is worth investigating.

Count process creation events by host to find outliers:

index=botsv3 sourcetype=wineventlog EventCode=4688 | stats count by host | sort -count

Click the Statistics tab. Look at which host sits at the top of the list with the highest process creation count.

Before you drill into that host, what do you expect to find when you inspect its individual processes?

Drill into the top host by running this query to see what processes it launched:

index=botsv3 sourcetype=wineventlog EventCode=4688 host="BSTOLL-L*" | stats count by New_Process_Name | sort -count

You should see cmd.exe and powershell.exe near the top of the results with abnormally high counts. This is a red flag. Normal workstations do not launch hundreds of command-line processes.

Why are cmd.exe and powershell.exe suspicious?

On a typical employee workstation, cmd.exe and powershell.exe launch occasionally for system tasks. Hundreds of executions mean something is programmatically running commands on this machine.

Attackers use PowerShell and cmd.exe extensively for post-exploitation because they are legitimate system tools. Security products are less likely to flag them compared to unknown executables.

BSTOLL-L not appearing at the top?

Confirm you are searching index=botsv3 with the time range set to All time.
Double-check that EventCode=4688 is typed exactly (no spaces around the equals sign).
help me understand why my process creation search is not showing expected results in BOTS v3

Identify the suspicious endpoint

You now have two signals pointing at BSTOLL-L: it has the highest process creation volume, and those processes are dominated by command-line tools. One final check will strengthen the case.

Examine the account names that logged into BSTOLL-L by running:

index=botsv3 sourcetype=wineventlog EventCode=4624 host="BSTOLL-L*" | stats count by Account_Name

Click the Statistics tab. Look at the account names in the results. Notice any unusual account formats that differ from the standard naming pattern used by other hosts.

What counts as an unusual account format?

Most Windows environments use a consistent naming convention like DOMAIN\username or just a short username. If you see email-style names, service accounts with odd prefixes, or accounts that do not match the pattern of other hosts, that is additional evidence of compromise.

You have now combined three pieces of evidence pointing at BSTOLL-L as your primary investigation target:

Highest process creation count in the environment.
Abnormally high cmd.exe and powershell.exe activity.
Unusual account formats in logon events.

Document this finding: BSTOLL-L is your primary target for deeper investigation.

You have narrowed down a suspicious endpoint from an environment with dozens of hosts. Next up, you will dig into what those PowerShell and cmd.exe processes actually did on BSTOLL-L. That is where the investigation goes from suspicious to confirmed.

Uncover the PowerShell Empire C2 Malware

In the previous step, you flagged BSTOLL-L as the most suspicious host in the Frothly environment based on process creation volume alone. That tells you something is happening on that machine, but not what.

Counting processes found the anomaly. Now you need to inspect the actual command lines those processes ran. This is where the investigation goes from "suspicious activity" to "confirmed compromise."

In this step, get ready to:

Inspect PowerShell command lines on BSTOLL-L to find C2 malware indicators.
Correlate reconnaissance commands that prove post-exploitation activity.
Confirm the compromise by identifying the user account and attack timeline.

Inspect command lines on the suspicious host

You know BSTOLL-L has the highest process creation count. The next question is: what were those processes actually doing?

Windows Event Code 4688 logs every new process, including the full command line. By filtering for PowerShell processes on BSTOLL-L, you can see exactly what commands the attacker ran.

Before you run this search, what do you think you will find in the PowerShell command lines on a compromised host?
In Search & Reporting, make sure your time range is set to All time.
Run the following SPL query to display PowerShell process details on BSTOLL-L:

index=botsv3 sourcetype=wineventlog EventCode=4688 host="BSTOLL-L*" New_Process_Name="*powershell*" | table _time, Account_Name, New_Process_Name, Process_Command_Line

Click the Events tab to see the results table.
Scan the Process_Command_Line column for entries containing -enc.

You should see PowerShell commands with flags like -noP, -sta, -w 1, and -enc followed by a long Base64-encoded string.

What do these flags mean?

These flags are the signature of PowerShell Empire, a well-known C2 (Command and Control) framework used by attackers.

-noP bypasses the PowerShell profile so security tools that hook into the profile cannot detect the session.
-sta runs PowerShell in single-threaded mode, which is required by Empire's communication model.
-w 1 sets the window to hidden so no visible console appears on the victim's screen.
-enc tells PowerShell to decode and execute a Base64-encoded payload. This is the actual malicious code, obfuscated to evade detection.

Not seeing any results?

Make sure your time range picker is set to All time (not "Last 24 hours"). The BOTS v3 data has historical timestamps that fall outside recent time windows.
Double-check you typed index=botsv3 (not index=bots). The index name must match exactly.
Verify the host filter uses host="BSTOLL-L*" with the wildcard. The full hostname is BSTOLL-L.froth.ly so the asterisk matches the domain suffix.

Still stuck? Help me troubleshoot why my Splunk search returns no results for PowerShell on BSTOLL-L.

Correlate with other host activity

Finding the C2 implant is step one. Now you need to see what the attacker did after gaining access.

PowerShell Empire's post-exploitation modules automatically run reconnaissance commands to map the compromised system. These commands query the registry, check network connections, and poll the system clock.

Run this query to search for reconnaissance commands on BSTOLL-L:

index=botsv3 sourcetype=wineventlog EventCode=4688 host="BSTOLL-L*" (Process_Command_Line="*netstat*" OR Process_Command_Line="*reg query*" OR Process_Command_Line="*wmic*") | table _time, Process_Command_Line

Review the results in the Events tab.
Look for patterns in the Process_Command_Line column.

You should see commands like netstat checking for open ports, reg query enumerating installed software, and wmic polling the system time.

Why do attackers run these commands?

These are not random commands. Each serves a specific reconnaissance purpose in the attack chain.

netstat discovers which ports are listening, revealing other services and potential lateral movement targets.
reg query against the Uninstall key enumerates installed software, helping the attacker identify security tools to evade.
wmic os get LocalDateTime checks the system clock so the C2 beacon can synchronize its callback timing.

Seeing zero events for the recon query?

Confirm that the OR operators are capitalized. SPL requires Boolean operators in uppercase (OR not or).
Check that each Process_Command_Line filter uses the wildcard asterisks around the search term (e.g. "*netstat*").

Need more help? Help me troubleshoot my Splunk recon command search on BSTOLL-L.

Confirm the compromise

You now have two independent pieces of evidence: encoded PowerShell C2 payloads and automated reconnaissance commands. The final step is to tie them together by identifying the compromised account and establishing a timeline.

Look back at your PowerShell search results from the first query.
Note the Account_Name value associated with the encoded PowerShell commands.
Note the _time values to establish when the C2 activity began.
Compare with the timestamps on the reconnaissance commands from your second query.

What should your timeline show?

A typical PowerShell Empire compromise follows a predictable sequence. First, the encoded PowerShell payload executes (the C2 implant activating). Then, within seconds or minutes, reconnaissance commands fire automatically as Empire's modules map the host.

If your _time values show encoded PowerShell execution followed closely by netstat, reg query, and wmic commands under the same account, that confirms automated post-exploitation.

Document your findings. Your investigation has confirmed:

BSTOLL-L.froth.ly was compromised via PowerShell Empire C2.
Evidence: encoded PowerShell with -enc, -noP, -sta, -w 1 flags.
Post-exploitation reconnaissance: netstat, reg query, wmic commands executed under the compromised account.
Attack timeline documented from C2 activation through host enumeration.

You have confirmed a live compromise on a Frothly endpoint. Next up, you will map your findings to the MITRE ATT&CK framework and publish your investigation as a professional portfolio piece on GitHub.

Map to MITRE ATT&CK and Push to GitHub

You confirmed that BSTOLL-L was compromised via PowerShell Empire C2 malware. That finding is valuable, but without professional framing it stays buried in your Splunk search history.

In this step, you will map your findings to the MITRE ATT&CK framework and publish a complete investigation report to GitHub. This turns your investigation into a portfolio piece that proves your SOC analysis skills to employers.

In this step, get ready to:

Map your attack findings to MITRE ATT&CK technique IDs.
Write a professional investigation report as a README.md file.
Push your report to a public GitHub repository.

Create your MITRE ATT&CK mapping

The MITRE ATT&CK framework is a shared language that SOC teams use to classify attacker behaviour. Each technique has a unique ID that maps to a specific action an attacker takes.

Based on the evidence you found in Steps 3 and 4, your investigation maps to these six techniques:

Execution T1059.001 (Command and Scripting Interpreter: PowerShell). Evidence: encoded PowerShell commands executed on BSTOLL-L.
Defense Evasion T1027 (Obfuscated Files or Information). Evidence: Base64-encoded payloads using the -enc flag.
Defense Evasion T1562.001 (Impair Defenses: Disable or Modify Tools). Evidence: PowerShell profile bypass using the -noP flag.
Discovery T1082 (System Information Discovery). Evidence: reg query and wmic commands for host enumeration.
Discovery T1049 (System Network Connections Discovery). Evidence: netstat commands to map open ports.
Command and Control T1071.001 (Application Layer Protocol: Web Protocols). Evidence: C2 communication over HTTP/HTTPS.

What is MITRE ATT&CK?

MITRE ATT&CK is a publicly available knowledge base of adversary tactics and techniques based on real-world observations. Every SOC team uses it to standardise how they describe attacks.

When you write "T1059.001" in a report, any security professional worldwide knows exactly what you mean: PowerShell-based command execution. This shared vocabulary is what makes your report instantly readable by hiring managers.

Write your investigation report as a README.md

Now you will turn your investigation into a structured report. The report lives in a README.md file inside a project folder on your Desktop.

Press the Windows key to open your search bar.
Type PowerShell and press Enter to open it.

Move to your Desktop by running this command:

cd ~/Desktop

Create your project folder and move into it by running these commands:

mkdir splunk-bots-investigation
cd splunk-bots-investigation

Confirm the folder exists by running:

ls

You should see the empty splunk-bots-investigation folder listed on your Desktop.

Now create the README file and open it in Notepad for editing:

Create and open README.md by running:

notepad README.md

What happens when you run this?

Notepad will ask if you want to create a new file since README.md does not exist yet. Click Yes to create it.

Paste the following content as the first section of your report. This covers the title, summary, and environment overview:

Copy the following and paste it into your README.md file:

# SOC Investigation: PowerShell Empire C2 on Frothly Endpoint

## Investigation Summary

Investigated the Frothly enterprise environment using Splunk SIEM and identified a confirmed PowerShell Empire C2 compromise on endpoint BSTOLL-L.froth.ly. The attacker used encoded PowerShell commands for execution and automated host reconnaissance.

## Environment Overview

- **Dataset**: Splunk BOTS v3 (Boss of the SOC competition data)
- **Company**: Frothly (fictional beer company)
- **Threat Actor**: Taedonggang APT group
- **Data Sources**: 80+ source types including Windows Event Logs, Sysmon, network streams, AWS CloudTrail, and endpoint protection
- **SIEM**: Splunk Enterprise 10.4.1

What does this section do?

The Investigation Summary gives a reader the key finding in one paragraph. The Environment Overview sets the scene so someone reviewing your report understands the scale and variety of the data you worked with.

Add the following directly below what you just pasted. This documents your methodology and key findings:

## Investigation Steps

1. **Data Reconnaissance**: Profiled the environment using `| tstats` and `stats count by sourcetype` to understand available data sources
2. **Authentication Analysis**: Examined Windows Event Codes 4624 (successful logon) and 4625 (failed logon) to identify anomalous patterns
3. **Process Creation Analysis**: Used EventCode 4688 to identify hosts with abnormal process creation volumes
4. **Command Line Inspection**: Examined PowerShell command lines on the suspicious host to confirm C2 activity

## Key Findings

| Finding | Detail |
|---------|--------|
| Compromised Host | BSTOLL-L.froth.ly |
| Malware Type | PowerShell Empire C2 |
| Key Evidence | Encoded PowerShell with -enc, -noP, -sta, -w 1 flags |
| Reconnaissance | netstat, reg query, wmic commands executed post-compromise |

What does this section do?

The Investigation Steps show your analytical methodology. Hiring managers look for a structured approach, not random searching. The Key Findings table gives a quick-reference summary of what you proved.

Add the SPL queries section next. This shows the exact searches you used during the investigation:

## SPL Queries Used

### Failed Logon Analysis
```
index=botsv3 sourcetype=wineventlog EventCode=4625 | stats count by Account_Name, host | sort -count
```

### Process Creation by Host
```
index=botsv3 sourcetype=wineventlog EventCode=4688 | stats count by host | sort -count
```

### PowerShell Activity on BSTOLL-L
```
index=botsv3 sourcetype=wineventlog EventCode=4688 host="BSTOLL-L*" New_Process_Name="*powershell*" | table _time, Account_Name, New_Process_Name, Process_Command_Line
```

### Reconnaissance Detection
```
index=botsv3 sourcetype=wineventlog EventCode=4688 host="BSTOLL-L*" (Process_Command_Line="*netstat*" OR Process_Command_Line="*reg query*" OR Process_Command_Line="*wmic*") | table _time, Process_Command_Line
```

Why include the queries?

Listing your SPL queries shows that you can write search logic from scratch, not just click through dashboards. This is the number one skill employers test in SOC analyst interviews.

Add the final two sections. These contain your MITRE ATT&CK mapping and response recommendations:

## MITRE ATT&CK Mapping

| Tactic | Technique ID | Technique Name | Evidence |
|--------|-------------|----------------|----------|
| Execution | T1059.001 | Command and Scripting Interpreter: PowerShell | Encoded PowerShell commands executed on BSTOLL-L |
| Defense Evasion | T1027 | Obfuscated Files or Information | Base64-encoded payloads using -enc flag |
| Defense Evasion | T1562.001 | Impair Defenses: Disable or Modify Tools | PowerShell profile bypass using -noP flag |
| Discovery | T1082 | System Information Discovery | reg query and wmic commands for host enumeration |
| Discovery | T1049 | System Network Connections Discovery | netstat commands to map open ports |
| Command and Control | T1071.001 | Application Layer Protocol: Web Protocols | C2 communication over HTTP/HTTPS |

## Recommendations

1. **Immediate**: Isolate BSTOLL-L from the network to prevent further C2 communication
2. **Short-term**: Reset credentials for the compromised user account and all accounts that logged into BSTOLL-L
3. **Medium-term**: Deploy PowerShell script block logging (Event ID 4104) and constrained language mode
4. **Long-term**: Implement application whitelisting to prevent unauthorized PowerShell execution patterns

What does the Recommendations section prove?

Including actionable recommendations shows you can think beyond detection. A SOC analyst who finds a threat AND proposes containment steps demonstrates senior-level thinking.

Save the file in Notepad by pressing Ctrl+S.
Close Notepad.

Back in PowerShell, confirm your file was saved by running:

type README.md

You should see the full contents of your README printed in the terminal, starting with the title and ending with your recommendations.

✔️ Awesome, I've got everything!

Great. Confirm you saved your file and the output from type README.md shows all six sections.

ⓧ I'd like to double check the full code

Scroll up and confirm your README.md contains each of these sections in order:

Investigation Summary (one paragraph describing the compromise).
Environment Overview (bullet list of dataset, company, threat actor, data sources, SIEM).
Investigation Steps (numbered list of four methodology stages).
Key Findings (table with compromised host, malware type, evidence, reconnaissance).
SPL Queries Used (four named queries with code blocks).
MITRE ATT&CK Mapping (table with six technique rows).
Recommendations (four prioritized response actions).

Push to GitHub

Your report is written. Now you need to version-control it with Git and publish it on GitHub so anyone can view it.

Check if Git is installed by running this command in PowerShell:

git --version

✔️ I see a version number

Git is ready. Move on to the next instruction below.

ⓧ Command not found

Git is not installed yet. Install it by running this command:

winget install --id Git.Git -e --source winget

After installation completes, close and reopen PowerShell so the git command becomes available. Navigate back to your project folder:

cd ~/Desktop/splunk-bots-investigation

Run git --version again to confirm you now see a version number.

Winget not recognized?

If winget is not available, download the Git installer directly from git-scm.com/install/windows.html. Run the installer and accept all default options, then reopen PowerShell.

help me install Git on Windows

Next, you need a GitHub account to host your repository publicly.

If you do not have a GitHub account, go to github.com and click Sign up.
Follow the prompts to create a free account with your email address.
If you already have a GitHub account, sign in now.

Initialize a Git repository in your project folder by running:

git init

Stage all files for your first commit by running:

git add .

Create your commit by running:

git commit -m "SOC investigation: PowerShell Empire C2 on Frothly endpoint"

You should see output confirming one file changed with your README content.

Seeing an identity error?

If Git asks you to set your name and email before committing, run these two commands (replacing the placeholder values with your own):

git config --global user.email "your-email@example.com"
git config --global user.name "Your Name"

Then run the git commit command again.

help me configure Git identity on Windows

Now create the remote repository on GitHub to push to.

Go to github.com/new in your browser.
Enter splunk-bots-investigation as the repository name.
Select Public visibility.
Leave Add a README file unchecked (you already have one).
Click Create repository.

GitHub shows you setup commands after creating the repository. You will use the HTTPS URL it displays.

Back in PowerShell, connect your local repository to GitHub by running:

git remote add origin https://github.com/[[GITHUB_USERNAME="YOUR-USERNAME"]]/splunk-bots-investigation.git

Push your commit to GitHub by running:

git branch -M main
git push -u origin main

What do these commands do?

The git branch -M main command renames your default branch to main (matching GitHub's default). The git push -u origin main command uploads your commit to the remote repository.

Authentication prompt?

GitHub may open a browser window asking you to sign in and authorize Git. Click Authorize to allow the push. If you see a username/password prompt in the terminal, you need a personal access token instead of a password.

help me authenticate Git with GitHub on Windows

Before you check your repository, predict what you will see when you visit the GitHub URL. Do you think your README content will appear formatted, or as raw markdown text?

Open your browser and go to https://github.com/ followed by your username and /splunk-bots-investigation.

GitHub automatically renders README.md files as formatted HTML. You should see your investigation report displayed with proper headings, tables, and code blocks right on the repository's main page.

Secret mission

Build a Detection Alert Rule

Finding an attack after the fact is reactive. Building a detection rule that catches it automatically is proactive. This is the difference between a junior analyst who investigates alerts and a detection engineer who creates them. In this secret mission, you will turn your investigation finding into a Splunk alert that fires automatically whenever encoded PowerShell execution appears in the logs.

Clean Up Your Resources

This project runs entirely on your local 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 (runs as a Windows service consuming RAM and CPU).
BOTS v3 dataset stored locally in C:\Program Files\Splunk\etc\apps\botsv3 (approximately 320MB on disk).
GitHub repository (splunk-bots-investigation) hosted on your GitHub account.

Keep everything running

No action needed. Choose this if you are still actively exploring the BOTS v3 dataset or plan to continue investigating other attack scenarios.

Splunk stays running as a local Windows service. It uses approximately 2-3GB of RAM while active.
The BOTS v3 dataset remains searchable at any time via index=botsv3 earliest=0.
Your GitHub repository stays public and accessible as a portfolio piece.

Pause - I'll come back to this later

Stop the Splunk service to free up RAM while keeping all your data and configuration intact. You can start it again anytime.

Press the Windows key and type services.
Select the Services app from the results.
In the Services list, find Splunkd Service.
Right-click it and select Stop.
To start Splunk again later, return to Services and right-click Splunkd Service, then select Start.

Use the command line instead

You can also stop and start Splunk from an administrative Command Prompt:

NET STOP splunkd

To start it again later, run:

NET START splunkd

Delete - I don't want to use this again

Remove all project resources completely and free up disk space. This cannot be undone.

Uninstall Splunk Enterprise (this also removes the BOTS v3 dataset):

Stop the Splunk service first. Press the Windows key, type services, and open the Services app.
Find Splunkd Service, right-click, and select Stop.
Press the Windows key and type Add or Remove Programs. Open it from the results.
Find Splunk Enterprise in the list, click it, and select Uninstall.
If the uninstaller prompts you to reboot, you can safely ignore the reboot request.
Verify the folder C:\Program Files\Splunk has been removed. If any files remain, delete the folder manually.

Delete your GitHub repository:

Navigate to your splunk-bots-investigation repository on GitHub.
Click Settings in the repository navigation bar.
Scroll down to the Danger Zone section.
Click Delete this repository.
Follow the confirmation prompts. Type the repository name when asked, then click Delete this repository to confirm.

What about my local project folder?

If you created a local splunk-bots-investigation folder on your Desktop for the Git repository, you can delete it too. Open File Explorer, navigate to your Desktop, right-click the folder, and select Delete.

Nice Work!

You just completed a full SOC analyst threat investigation using real enterprise attack data. From installing Splunk to publishing a professional portfolio piece, you proved you can hunt threats the way security teams do every day.

You've learned how to:

Write SPL queries to hunt for authentication anomalies, identify compromised endpoints, and uncover C2 malware across 80+ source types of real enterprise security logs.
Investigate a PowerShell Empire compromise from initial anomaly detection through confirmed endpoint compromise, following the same pivot methodology real SOC analysts use.
Map attack findings to the MITRE ATT&CK framework and publish a professional investigation report to GitHub as a portfolio piece.
Secret Mission: Built a detection alert rule in Splunk that automatically catches encoded PowerShell execution, moving from reactive investigation to proactive detection engineering.

Ready to quiz yourself?