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:

• Is the most-starred Github repository for Splunk.

• Has been visited by more than 400 unique users this month and counting.

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.