Introducing Splunk Attack Range v1.0

The Splunk Attack Range project has officially reached the v1.0 release. By achieving this milestone, we wanted to reflect on how we got here, what features we’ve built for v1.0 and what the future looks like for Splunk Attack Range.

What is the Splunk Attack Range? 🧐

About 2 years ago, the Splunk Threat Research Team was just starting to ship detections as code to Splunk Enterprise Security in the form of the Splunk ES Content Update (ESCU) app. During this time we would author these detections by analyzing and furiously reading through any open research papers, blogs or articles on the threat we were hoping to detect or running the attack ourselves. In many cases, the detections were incorrect or would break after certain updates to the product (a TA or some other required underlying Splunk component would change). Our professional service team usually learned of the broken detections during customer engagements and, needless to say, it was painful to experience. To further accentuate the pain, when professional services asked questions as to why a specific detection was not working, often the researcher had already either wiped the environment built to write and test the detection or got rid of the actual data that powered it. From this pain, the Splunk Attack Range was born.

The Attack Range is a detection development platform that solves three main challenges in detection engineering. First, the user can quickly build a small lab infrastructure as close as possible to a production environment. Second, the Attack Range performs attack simulations using different engines, such as Atomic Red Team or Caldera, to generate real attack data. Third, since it is built as a CLI, it integrates seamlessly into any continuous integration/continuous delivery (CI/CD) pipeline to automate the detection rule testing process.”
— Splunk Attack Range Repo Purpose

Having a replicable environment close to production that could be built in a few minutes allowed us to repeat and test many attacks easily. Adding simulation tools like Atomic Red Team easily allowed us to codify not only the detections (which we moved from the open source project to Splunk Security Content) but also the attack itself. Finally, by building the project with a focus on automation (CLI instead for interactions instead of a UI) allowed us to build the automated detection testing service which lets us know if any detection fails to work:

  1. If any underlying component is changed.
  2. If any detection logic is changed.
  3. If any attack logic is changed.

Here is the latest logical diagram of its architecture:

Today, the Attack Range:

What Makes This v1.0 💁‍♀️

The most direct answer to that was the fact that we added a CI job that allows us to tag a commit in develop and produce a release package. But it’s much simpler than that. It comes down to a key set of features we have slowly added to make this a more complete detection development platform, including:

  • A new configure action with a wizard 🧙‍♂️ to make configurations easier. 
  • A CI job that allows us to tag a commit in develop and produce a release package. 
  • New installation scripts for macOS and Linux platforms.
  • A dump action so users can easily capture the log data generated by an attack. Today it is what powers a lot of the datasets in the Splunk Attack Data repository.   

The `replay` action to easily replay datasets into a range.

Looking Into the Future 🚅

Phil Royer and Rod Soto presented the original version of the Attack Range at Splunk .conf®18 (SEC1671) and it has evolved 🌻 since then. This initial proof of concept version is closer to what we call the Attack Range Local project. Since then, Patrick Bareiss has rewritten its code base and added the ability to build these environments in cloud providers like AWS and Azure. This is what we call the Splunk Attack Range today, but we’re just getting started. In the short term, we plan to:

  1. Use Docker containers to increase portability and ease of installation in platforms like Windows.
  2. Add macOS endpoint.
  3. Pre-populate the Microsoft Active directory server with a full organization using scripts like BadBlood by David Rowe or similar projects.
  4. Incorporate pre-configured integration between Splunk Enterprise and Splunk Phantom.

We would like to thank contributors Bhavin Patel, Rod Soto, Russ Nolen, Phil Royer, Joseph Zadeh, Rico Valdez, Dimitris Lambrou, Dave Herrald, Ignacio Bermudez Corrales, Peter Gael, Josef Kuepker, Stanislav Miskovic, Shannon Davis and Mauricio Velazco
, who have made this happen. We’re also indebted to everyone else in the community that supports the project and helps us continually evolve it, including David Hunt, Jose Nazario, Michael Haag and Olaf Hartong. Finally, thank you to Chris Long, the author of DetectionLabs and the inspiration for the Attack Range and Red Canary team, for open sourcing the Atomic Red Team project — which we rely so much on for simulations.


About the Splunk Threat Research Team

The Splunk Threat Research Team is devoted to understanding actor behavior and researching known threats to build detections that the entire Splunk community can benefit from. The Splunk Threat Research Team does this by building and open sourcing tools that analyze threats and actors like the Splunk Attack Range and using these tools to create attack datasets. From these datasets, new detections are built and shared with the Splunk community under Splunk Security Content. Various Splunk products like Enterprise Security, Splunk Security Essentials and Mission Control then consume these products to help customers quickly and effectively find known threats.


The Splunk Threat Research Team is an active part of a customer’s overall defense strategy by enhancing Splunk security offerings with verified research and security content such as use cases, detection searches, and playbooks. We help security teams around the globe strengthen operations by providing tactical guidance and insights to detect, investigate and respond against the latest threats. The Splunk Threat Research Team focuses on understanding how threats, actors, and vulnerabilities work, and the team replicates attacks which are stored as datasets in the Attack Data repository

Our goal is to provide security teams with research they can leverage in their day to day operations and to become the industry standard for SIEM detections. We are a team of industry-recognized experts who are encouraged to improve the security industry by sharing our work with the community via conference talks, open-sourcing projects, and writing white papers or blogs. You will also find us presenting our research at conferences such as Defcon, Blackhat, RSA, and many more.

Read more Splunk Security Content

Show All Tags
Show Less Tags