Skip to content

Latest commit

 

History

History
203 lines (150 loc) · 11.4 KB

README.md

File metadata and controls

203 lines (150 loc) · 11.4 KB

Splunk Attack Range

branch build status
develop develop status
master master status

Purpose

The Attack Range is a detection development platform, which solves three main challenges in detection engineering. First, the user is able to build quickly a small lab infrastructure as close as possible to a production environment. Second, the Attack Range performs attack simulation using different engines such as Atomic Red Team or Caldera in order to generate real attack data. Third, it integrates seamlessly into any Continuous Integration / Continuous Delivery (CI/CD) pipeline to automate the detection rule testing process.

The lab infrastructure contains a Windows Domain Controller, Windows Server, Windows Workstation and a Kali Machine, which comes pre-configured with multiple security tools and logging configuration. Furthermore, a Splunk server and a Phantom server completes the lab infrastructure. The lab infrastructure can be deployed locally or in the cloud. The building process is completely automated and can be executed with a single command.

The Attack Range incorporates different simulation engines such as Atomic Red Team from Red Canary and Caldera from Mitre. Attacks can be executed with a single command allowing the user to attack the lab infrastructure. These data can be used to develop new detections or test existing detection rules.

The differentiation to existing open source tools such as Detection Lab is that the Attack Range exposes all actions over the command line. This allows the user to integrate the Attack Range into a CI/CD pipeline and automating the detection testing/development process. For example, after writing a new detection for credential dumping, the Attack Range can automatically test it by performing the following steps: build Attack Range, perform attack T1103 (credential dumping), run detection, destroy Attack Range.

Demo

📺 A short demo (< 6 min) which shows the basic functions of the attack range. It builds a testing enviroment using terraform, walks through the data collected by Splunk. Then attacks it using MITRE ATT&CK Technique T1003 and finally showcases how ESCU searches are used to detect the attack.

Attack Range Demo

Deployment

Attack Range can be built in three different ways:

  • local using vagrant and virtualbox
  • in the cloud using terraform and AWS
  • cloud optimized using terraform, packer and AWS

Logical Diagram

Architecture

Attack Range consists of:

  • Windows Domain Controller
  • Windows Server
  • Windows Workstation
  • A Kali Machine
  • Splunk Server
  • Phantom Server

Which can be added/removed/configured using attack_range.conf. More machines such as Phantom, Linux server, Linux client, MacOS clients are currently under development.

Logical Diagram

An approxiamte cost estimate for running attack_range using --mode terraform on AWS can be found here.

Configuration

Running

Attack Range supports different actions:

  • Build Attack Range
  • Perform Attack Simulation
  • Search with Attack Range
  • Destroy Attack Range
  • Stop Attack Range
  • Resume Attack Range

Build Attack Range

  • Build Attack Range
python attack_range.py -m terraform/vagrant -a build

Perform Attack Simulation

  • Perform Attack Simulation
python attack_range.py -m terraform/vagrant -a simulate -st T1117,T1003 -t attack-range-windows-domain-controller

Search with Attack Range

  • Run a savedsearch and return the results
python attack_range.py -m terraform/vagrant -a search -sn search_name

Destroy Attack Range

  • Destroy Attack Range
python attack_range.py -m terraform/vagrant -a destroy

Stop Attack Range

  • Stop Attack Range
python attack_range.py -m terraform/vagrant -a stop

Resume Attack Range

  • Resume Attack Range
python attack_range.py -m terraform/vagrant -a resume

Cloud Optimized

Using the Attack Range for automated detection testing in a Continuous Integration (CI) pipeline, needs the ability to build it quickly. Therefore we introduced the mode cloud optimized by combining packer and terraform. In this mode you need to build the AMIs with packer and then use terraform with the prebuilt AMIs:

  • Build AMIs with packer
python attack_range.py -m packer -a build_amis
  • Build Attack Range with terraform and -ami flag:
python attack_range.py -m terraform -a build -ami
  • Deregister AMIs with packer
python attack_range.py -m packer -a destroy_amis

Features

  • Splunk Server

    • Indexing of Microsoft Event Logs, PowerShell Logs, Sysmon Logs, DNS Logs, ...
    • Preconfigured with multiple TAs for field extractions
    • Out of the box Splunk detections with Enterprise Security Content Update (ESCU) App
    • Preinstalled Machine Learning Toolkit (MLTK)
    • Splunk UI available through port 8000 with user admin
    • ssh connection over configured ssh key
  • Splunk Enterprise Security

  • Splunk Phantom

  • Splunk Mission Control (BETA)

    • Splunk Mission Control is a unified experience that modernizes and optimizes your team’s security operations. The cloud-based software-as-a-service (SaaS) allows you to detect, manage, investigate, hunt, contain, and remediate threats and other high-priority security issues across the entire event lifecycle—all from the common work surface it provides.
    • Instructions on how to configure mission control and run a demo can be found here.
  • Splunk Data Stream Processor

    • Splunk Data Stream Processor is a scalable stream processing solution built to guarantee delivery of high-volume, high-velocity data across the enterprise. As events occur, DSP continuously collects, formats, and organizes high-velocity, high-volume data based on specified conditions, masks sensitive or private information, detects abnormal data patterns, and then distributes results to Splunk or other destinations in milliseconds
    • Instructions on how to configure Splunk DSP can be found here.
  • Windows Domain Controller & Window Server & Windows 10 Client

    • Can be enabled, disabled and configured over attack_range.conf
    • Collecting of Microsoft Event Logs, PowerShell Logs, Sysmon Logs, DNS Logs, ...
    • Sysmon log collection with customizable Sysmon configuration
    • RDP connection over port 3389 with user Administrator
  • Atomic Red Team

    • Attack Simulation with Atomic Red Team
    • Will be automatically installed on target during first execution of simulate
  • Caldera

    • Adversary Emulation with Caldera
    • Installed on the Splunk Server and available over port 8888 with user admin
    • Preinstalled Caldera agents on windows machines
  • Kali Linux

    • Preconfigured Kali Linux machine for penetration testing
    • ssh connection over configured ssh key

Demo Mode

We are using Attack Range to test and demo specific attack scenarios. We want to share them with the community. The attack_range.conf has an option run_demo and demo_scenario. We currently support the following demo scenario:

  • demo_scenario: mission_control_malicious_putty. In this scenario, the windows server contains a backdoored version of putty.exe called puttyX.exe located in the C drive. When the user clicks on it a reverse meterpreter shell is established to the kali linux. Then, kali linux will perform enumeration and credential dumping with hashdump and mimikatz. These credentials are used by kali linux to copy the malicious puttyX.exe from the windows domain controller to the windows server.

Planned features

  • Linux Server
  • Linux Client
  • macOS Client

Support

Please use the GitHub issue tracker to submit bugs or request features.

If you have questions or need support, you can:

Author

Contributors

Contributing

We welcome feedback and contributions from the community! Please see our contribution guidelines for more information on how to get involved.