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:
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.
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!
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
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
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
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
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
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.
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!
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+
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
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
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