Threat Detection Made Simple: Splunk Attack Range Basics
文章介绍了如何使用Splunk Attack Range快速搭建威胁检测环境,通过Docker和AWS实现低成本配置,并模拟攻击进行检测。 2025-9-22 17:23:12 Author: redsiege.com(查看原文) 阅读量:1 收藏

by Ian Briley

Let’s be honest, when starting a new skill or interest, one of the largest hurdles is setting up an environment//playground//attack range for your learning activities. Sometimes it feels like you spend 95% of the time setting up the environment, troubleshooting why some tool isn’t talking to another tool, dealing with finding and using licenses, etc. These are all valuable lessons learned, but not when you’re trying to at least get your feet wet.

My preferred method is finding a way to get my feet into the water as quickly as possible, and later on discover why wet feet are important to the process. This is how I’m approaching starting my learning journey with Threat Detection. I think, “I may like this, let’s find a (mostly) frictionless way to dip my feet into threat detection.”

Please welcome to the stage:

Splunk Attack Range

After passing through the dead remains of DetectionLab, finding old setup guides, dead links, references to other projects using software stacks that require more tinkering for set up. I finally found the Splunk Attack Range. This checks ALL of the boxes.

  • Uses a well-known SIEM (Actually useful resume candy)
  • Splunk has a TON of tutorials (most of which are free)
  • Uses AWS/Cloud Technology (costs less than $0.50 an hour, no Frankenstein PCs on my network)
  • Everything is contained in Docker (Mess something up? Destroy the range and restart docker)
  • Has range guides, and a fairly large community support.
  • Written mostly in Python so I can actually fix things if need be (although I didn’t need it)

Spoiler Alert: I was able to set this range up in about 45 minutes, and only about 5 minutes of that was hands on keyboard configuration setup.

So, let’s get our feet into the water!

Three Simple Commands

Just use Docker. Docker is and probably will always remain magic to me, good news is you just need to run these three commands to start our lab journey.

This command will pull the latest and greatest Splunk Attack Range.
docker pull splunk/attack_range

Download the Docker container

Now we’ll use the next command to run the docker instance to create our environment.
docker run -it splunk/attack_range

Run the Docker container

Finally, we will configure AWS inside of the Docker instance. (I find AWS easier to use then the other cloud platforms) You’ll need to create a key pair in the AWS console for this. There’s tons of guides how to get this. The big thing you want to pay attention to is the zone you choose here NEEDS to match the zone you configure the range for. I use us-east-1 because I’m on the east coast.
aws configure

Configure AWS

Now we’re ready to actually setup and build the range. This next command will be the bulk of the hands on keyboard time for the setup.
python attack_range.py configure

Starting our setup

You’ll run through a list of choices in the screenshot below is what I ended up doing that worked the best out of the box for me. For starting out all we really need is a Windows Server feeding Sysmon logs to a Splunk Server.

As shown in the screenshot below, I chose AWS as my cloud provider, because, as I said before, I think it’s the easiest to work with, and I also kept the randomly-created range password.

Use the password given

Create an SSH key, the program should pull your region from the AWS configuration automatically. Only allow your home IP to connect to it. Again the program should pull this automatically for you and throw it into a CIDR /32 as shown below.

Make sure your IP can access

Give it a name, it doesn’t matter these environments at most live only 8 hours. Say “Yes” to building a windows server, select 2022, say “Yes” to making it a DC, and installing “red team tools” on to it. This will help us simulate attacks later on.

Then say “No” to everything after the “red team tools”. It’s VERY tempting to want to use badblood right off the bat to populate our testing domain with AD objects and configurations.

Say NO to BadBlood

But when I tried to do the badblood module, I would get an error like the one shown in the screenshot below. I’m sure this is normal but for just starting out I want to make sure everything can be logged into and checked manually if need be. This will be useful later on down the road, for doing things like making detections for someone accessing an admin account outside of business hours, but it’s not necessary for just getting our feet wet.

Can’t RDP to Admin User when BadBlood was enabled

Let’s Build Us an Empire

Having configured our Splunk Attack Range, we’ll run the following command and wait for it to finish (took about 40ish minutes for me.) You’ll see a bunch of lines of text showing what’s being installed and set up. The way we have it configured currently it’ll set up a DC, a Splunk server, red team attacker tools, and will have a Guacamole session manager installed.
python attack_range.py build

Build Start

Verbose Output

You won’t really need to pay attention to anything in this until the very end (assuming everything is set up correctly). You can also pull this information up by running the following command after the setup is complete.
python attack_range.py show

Got our connection information

We can use this information to check on the servers. But for the purposes for brevity, I used Guacamole to check in on the DC and then the web interface for Splunk.

Guacamole Login Screen

Splunk Login Screen

Once you log in to each you should see screens like below. Guacamole provides a web-based RDP connection to your boxes, and the web interface for Splunk provides a GUI for us to use the tool as seen below.

Things are looking good

Let’s talk about cost really quick

Like all cloud computing adventures if you don’t pay attention now, the huge bill for sure will capture your attention later. With our current configuration we have two EC2 instances, a t3.xlarge and a t3.2xlarge. A t3.xlarge runs (at the time of writing this) about $0.1664 an hour, and a t3.2xlarge runs at $0.3328 an hour. For a grand total of $0.4922, or as said earlier about fifty cents an hour. At the end of the day destroy the range and double check your AWS EC2 instance list to make sure you don’t have any surprises. (The attack range has a command that makes this easy.)

Our basic setup

Let’s simulate our first attack!

Simulating attacks is very simple for our detection needs. Using the command below will start the Atomic Red Teams (ART) technique (te) T1003.001. This is attempting to dump passwords using Mimikatz. We’ll want to replace <target> with our EC2 host “ar-win-root-22561-redsiege-0”
python attack_range.py simulate -e ART -te T1003.001 -t <target>

Start of simulated attack

While the attack is setting up and executing, if we go back to the Splunk GUI we can click on the dashboard tab. We can see in the screenshots below that Splunk fresh out of the Docker box hasn’t seen anything yet.

Splunk Dashboard

No detections found yet

You will see some verbose text in your Docker container window. Take some time to read through it as this text can give you an idea of what simulation and its variants worked or didn’t work, things you could search for later, etc. Once the attack is finished, you’ll see an update in the Docker container stating how many tests were done, how many were skipped, etc.

Halfway through the simulation

Simulation finished

If we switch back to our Splunk Dashboard we can see it has captured several events as shown in the image below. This is great but the goal of this series is to get good enough we can write our own detections.

Dashboard found stuff

We start our journey by using the Splunk App “Search & Reporting” on the left side column.

Let’s manually find this

This will bring us to the dreaded regex search bar as shown below. But fear not, for starting out we can look at already created Splunk Queries using Google.

Woe be the search bar

Tons of search queries

At first glance, these queries look near impossible to translate, and eventually we’ll get to the point where we can write very elaborate queries. But for our purposes to get started we’ll use a much simpler method. We can look through these queries and look for really specific elements such as pulling the CommandLine = and searching for mimikatz.exe.

I know from watching the Simulation verbose text that in the logs it literally uses mimikatz.exe several times. So, let’s search in the logs for any command line that had mimikatz.exe in it. At first Splunk will look like it can’t find anything but give it a few more seconds to parse though the logs.
CommandLine="*mimikatz.exe*"

Fear not, let it think

Eventually, it will find events of our criminal misdoings as shown below. There’s a ton of information to look at in this screen. You can look for selected fields such as host, users, process ID’s, etc. Feel free to click around and get familiar we’ll cover all this in great detail later in the series.

Results at last

There’s even hidden functionality to help you parse through the logs more organically. If I want to narrow my search even further all I have to do is hover near the string of interest in the event viewer, left click, and Splunk brings up additional means to add to the search, remove results, etc. using that string.

TONS of functionality

You can even search for raw simple strings. In the example below I typed in “mimikatz” and Splunk parsed through the logs searching for any raw string matches. (Obviously this isn’t super time consuming now because Splunk is only chewing through a handful of events, but the more events it records, the longer it’ll take to get results for vague search terms.) Either way we have successfully detected our first attacker! Rejoice and cherish this moment forever!

Simple string searches work as well

The result of the simple string search

Keep the AWS Boogie Man Bill Away

Splunk Attack Range makes it easy to keep your AWS bill small, just run the following command in docker. You should run this command when you are done with the lab at the end of each session.
python attack_range.py destroy

Start the destroy process

Attack range taken down

Big Recommendation

When you are officially done, exit the Docker container. If you want to build the lab again, start from the step after we downloaded the Docker container. I’ve found every time I tried to build and destroy the lab from the same Docker container, more and more things went astray, SSH keys got mangled, services wouldn’t install correctly, certain hosts wouldn’t spin up properly, etc. It’s just better to restart the container for a fresh start for each adventure in Splunk land.

What’s next?

This laid the groundwork for an ongoing blog/video web series I’m planning. Where we cover how to detect basic things like password spraying using the attack range, up to really specific circumstances like user ‘Joe’ from Sales using SSH, and even covering detections for some of our own (Red Siege) tools! Stay tuned, have fun, learn something new, and stay curious!


About Ian Briley, Security Consultant

Ian Briley has over 10 years of experience in information security consisting of The United States Armed Forces, the Healthcare industry, Security Operation Centers, and Security Consulting. Ian is an experienced presenter, trainer, developer, maker, and researcher. Ian enjoys attending local security focused groups and learning more about cloud-based environments and solutions

Certifications:
CRTO, GWAPT, eJPT, CySA+, SSCP, SEC+

Red Siege at Wild West Hackin’ Fest 2025: What to Expect

By Red Siege | October 2, 2025

As proud sponsors of Wild West Hackin’ Fest, Red Siege is excited to return to Deadwood for another year of cutting-edge training, engaging talks, and unique experiences. The event is […]

Learn More

Red Siege at Wild West Hackin’ Fest 2025: What to Expect

Kerberoasting, Microsoft, and a Senator

By Tim Medin | September 11, 2025

Kerberoasting, Microsoft, and a Senator When I came up with Kerberoasting in 2014, I never thought it would live for more than a year or two. I (erroneously) thought that […]

Learn More

Kerberoasting, Microsoft, and a Senator

Stupid Simple: Windows Data Exfiltration

By Red Siege | September 8, 2025

by Ian Briley To get around a DLP (Data Loss Prevention) implementation, you don’t need a fancy C2 setup to exfil your treasures. In fact, it’s incredibly easy using native […]

Learn More

Stupid Simple: Windows Data Exfiltration


文章来源: https://redsiege.com/blog/2025/09/threat-detection-made-simple-splunk-attack-range-basics/
如有侵权请联系:admin#unsafe.sh