Introducing Splunk Attack Range v2.0

The Splunk Threat Research Team (STRT) has continued focusing development on the Splunk Attack Range project and is thrilled to announce its v2.0 release with a host of new features. Since the v1.0 release 6 months ago the team has been focused on developments to make the attack range a more fully-featured development testbed out of the box. This blog post will share these additions as well as some of the project’s future directions.

What is the Splunk Attack Range?

The Splunk Attack Range is an open-source project maintained by the STRT. It builds instrumented cloud and local environments, simulates attacks, and forwards the data into a Splunk instance. This environment can then be used to develop and test the effectiveness of detections. With the release of v2.0 responses can now be tested more easily using Splunk SOAR.

If you haven’t read the v1.0 release, you should start here to understand both the motivation and current Splunk utilization of the attack range. Today, the Attack Range:

• Remains the most-starred Splunk GitHub repository



• Has been featured in over 30+ talks at Splunk .conf, RSA Conference, Black Hat, DEF CON, Purple Team Summit, and more
• Has been published on hakin9, KitPloit, tl;dr sec and many others
• Is used to test 90+% of our detections

What makes this v2.0?

After a year of development focused on out of the box utilization features v2.0 brings a host of notable changes. The most notable of these is the addition of a CI job that allows a commit to be tagged in develop and a corresponding release package produced. This comprises a key set of added features which make this a more complete detection development platform, including:

Above is an updated image from the new attack range configuration showing the new features

• Updated Docker install
• PurpleSharp integration
• Nginx plus 
• Linux sysmon 
• Splunk SOAR out-of-the-box support
• Pre-populated Active Directory using BadBlood
• Prelude support, replacing Caldera
• Red Team Tools pre-installed out-of-the-box

To summarize this, and updated architecture diagram is included below which better visualizes how the supported components have changed:

Each of these new features is described in detail below.

Docker Install

Under the hood, the Attack Range is comprised of python scripts that rely on the installation of 90+ third-party libraries that include ansible, terraform, bcrypt, and many others. While virtual environments are a great way of insulating python library sets, the attack range was updated to provide users with other ways of using the platform.

Thus for attack range v2.0 a Docker version of the Attack Range was created. Using this Docker installation allows for the benefits of containerization and allows for easy deployment of multiple lab environments for adversary simulation & detection engineering. A thorough guideline on how to use the Docker container may be found here.

PurpleSharp Simulations

PurpleSharp is an open-source adversary simulation tool written in C# that executes adversary techniques within Windows Active Directory environments. The resulting telemetry may be leveraged to measure and improve the efficacy of detection engineering efforts. Attack Range v2.0 integrates PurpleSharp and allows the execution of complex multi-step attack simulations directly from the command line.

In the following example, a single ATT&CK technique against a Windows host within the range is executed using PurpleSharp.

python attack_range.py simulate -e PurpleSharp -st T1003.001 -t ar-win-dc

Attack Range users can also leverage PurpleSharp’s ability to execute complex multi-technique attack playbooks described with a JSON file. 

python attack_range.py simulate -e PurpleSharp -sp AD_Discovery.json -t ar-win-dc

Nginx

As part of our Log4j analysis and research, STRT recognized the need for Attack Range to support the collection and analysis of Web-based logging. This drove the v2.0 feature which incorporates an Nginx web proxy configured out-of-the-box with Splunk logging through a new configuration stanza. This new feature allows Attack Range users to stand up custom web applications behind the Nginx proxy and research, build or test security content for web-based attacks.

Linux Sysmon Support

Sysmon is a very popular tool among detection developers and blue teamers as it provides extensive endpoint activity details. On the 25th anniversary of Sysinternals, Sysmon for Linux was released. Linux administrators can now leverage these new monitoring and detection capabilities previously only available in Windows environments.

The Splunk Add-On released by Cedric Hien and available for download on Splunkbase allows Splunk administrators to ingest events generated by Sysmon installations and investigate attacks on Linux endpoints. A new configuration stanza provides Attack Range users the ability to test the capabilities provided by Sysmon for Linux. As an example, Rod Soto wrote a blog post where he released detections for common post-exploitation tools used against Linux hosts.

Splunk SOAR

Splunk SOAR has been part of the Attack Range project for some time. Since the last release, STRT added a Bring-Your-Own feature to Attack_Range, allowing a long-running instance of Splunk SOAR to connect to an Attack Range so that work can be continued across multiple ranges and the effort of standing up a SOAR instance from scratch does not necessarily have to be completed for each build.

Additionally, STRT reconfigured the default apps for SOAR. Now, the AD LDAP app is pre-installed and preconfigured with the Windows Domain Controller built-in Attack Range. The same work has been done for the Splunk app, the WinRM app, the DNS app, the MaxMind app, and the WhoIs RDAP app. These apps should all now be pre-configured out of the box when a new SOAR instance is included in the Attack Range config.

BadBlood Integration

The first version of the Attack Range built a Windows Active Directory environment as part of the provisioning process. However, a clean install without pre-populated directory objects that include users, computers, service principal names, etc., limits the options available for simulating and researching active directory attacks like Password Spraying or Kerberoasting. 

BadBlood is a great tool released by David Rowe which consists of a set of PowerShell scripts that fill Active Directory with a structure and thousands of objects. Each time this tool runs, it produces different results: the domain, users, groups, computers, and permissions are always different. The newest release of Attack Range runs BadBlood with a simple configuration stanza. This allows users to research, build and test detection opportunities for complex active directory attacks.

Prelude Support

Prelude Operator is a popular and extremely useful purple teaming tool. The Attack Range v2.0 replaces Caldera with Prelude and thus provides users with a clear UI to run simulations and attack chains against an Attack Range environment. We have added the ability to build a redirector on the same machine as the Splunk server and deploy Pneuma agents to Windows and Linux machines which connect back to the redirector on TCP 2323. An architectural description of this feature addition is below:

Further details can be found on the wiki page here.

Red Team Tools

A new configuration stanza has been added to automatically download a long list of Windows-based red team tools that include Mimikatz, PowerSploit, UACMe, SharpGPOAbuse, and others. This enables Attack Range users to execute attack scenarios and analyze the resulting logging.

To request additional tools be added, submit a request here.

Looking to the Future 

Even as the release for Attack Range v2.0 is being prepared and packaged, STRT is already preparing for Attack Range v3.0. STRT is committed to evolving and improving the Attack Range as a tool that helps Splunk customers and the broader community build better detections. With that mission in mind, some items have been identified to make Attack Range more accessible and useful to a larger audience which will be our focus for v3.0.

One of the most common requests the team has heard from users and Splunk customers is the ability to add additional/different logs from EDR (Aurora, Sysmon), network collection tools (Zeek, Suricata, Bro), and or applications (AD, Tools) to test detections. Today, this entails modifying many pieces of the code (1, 2, 3 for example) and usually is NOT a trivial process. For version 3.0, the intent is to include other collection agents, and prebuilt images with them, to improve build times across different provider types (running environments).

The request to add additional collection points is usually followed by the ability to “bring my own golden image,” quoting a user and large Splunk customer. This opens the opportunity to easily test exactly what logging will be available given a specific attack and iterate on detections based on production data. This is something we plan on tackling in future Attack Range releases.

Finally, a year ago STRT decided to make Attack Range scale by focusing on supporting cloud providers like Azure and AWS. Moving away from VirtualBox the Attack Range project was forked and Attack Range Local was created to keep the ability to run a deployment locally available. As part of the decision, we intended to NOT backport features to this fork and deprecate it in the future. However, after receiving much feedback on the value of local detection development the next version will contain the ability to deploy to docker and ESXI as providers. The hope is this will be a suitable replacement for Attack Range Local and allow us to set a deprecation date.

In the same spirit, the Attack Range Cloud project will also be deprecated and all its features ported directly to the Splunk Attack Range as part of version v3.0. I hope this gives you a glimpse into the future and you get as excited as we are!

A final note: STRT did look at adding MacOS endpoints but ran into pitfalls. You can read about them in detail on this personal blog. This does NOT mean no – just not yet! 

Huge thanks to every single one of our users and everyone who has found value from this project and given the project a star on GitHub. We will continue to improve and keep this project free for the benefit of Splunk customers as well as the broader industry and community.

This blog post was co-authored by Mauricio Velazco, Lou Stella, Jose Hernandez