Applied Purple Teaming Threat Optics Lab – Azure TerraForm
Purple Teaming Attack & Hunt Lab – TerraForm
Defensive Origins uses a highly verbose threat optics lab to isolate adversarial techniques to more easily attribute IOC (indicators of compromise). These labs have routinely been time consuming to build and manage. The platform included here automates much of the threat-optic lab environment built on the Azure cloud network.
This process requires Python3.
- Edit LabBuilder.py and add in your Token info at the top of the file.
Default credentials are set in LabBuilder.py.
- Windows & Linux systems:
The credentials can be changed within the locals variable:
resource_group_name = "class-resources"
The password for Kibana can be changed by editing the HELK install line:
./helk_install.sh -p hunting -i 10.10.98.20 -b 'helk-kibana-analysis-alert'
This file is located at:
Please note the following regarding access:
- Only the Windows client is accessible externally
- Kibana is accessed internally, use a browser on one of the Windows machines to access.
- An SSH client will need to be installed on the Windows machines in order to SSH to the Linux system.
- You can also update the Region variable to desired region. This is updated LabBuilder.py.
- List of regions can be found here that offer the B-series we use in this lab environment.
git clone https://github.com/DefensiveOrigins/APT-Lab-Terraform.git
Run the builder and deploy your systems.
python .\LabBuilder.py -m YOURPUBLICIP
- If this script errors, or there are missing dependencies ensure it is being executed with Python 3.X. As such, attempt to execute with Python3 directly:
python3 .\LabBuilder.py -m YOURPUBLICIP
The -m flag will accept a single IP Address or Subnet as input. This adds the IP as a SRC IP address filter on the lab environment.
To confirm successful deployment the following 3 virtual machines will be found within Azure:
Deployment, include all the post-installation scripts, may take twenty minutes or more. Setup of the Linux node, with its ELK stack, will take the longest.
If LabBuilder.py errors during execution. Delete the LABS folder, found at
The error (shown at the top of script execution) is:
Directory not copied. Error: [Errno 17] File exists: './LABS'.
Errors referencing a ‘duplicate’ are also solved by this. Examples include:
Error: Duplicate module call
Error: Duplicate resource "azurerm_resource_group" configuration
If LabBuilder.py gives you an error as follows:
TypeError: replace() argument 2 must be str, not tuple
… it means that you copy-pasted configuration data for your Azure Cloud authentication, without removing the trailing comma (,). Definitions such as “client_id” should not end with a comma.
If LabBuilder.py creates only one or two out of the three VMs it will likely also throw an error including the following text:
Operation could not be completed as it results in exceeding approved Total Regional Cores quota.
This occurs when you have a free/trial Azure Cloud subscription, which is limited to 4 active CPU cores. You may edit the VM definitions for the Active Directory server and the Windows client, to change the VM sizing. This is done in the files named “2-virtual-machine.tf”, by replacing the “vm_size” field. The files include an example line to use as replacement.
python .\LabBuilder.py -destroy
The ‘-d’ or ‘-destroy’ flag will execute theTerraform destroy command. This will remove the Lab in Azure. CAUTION: All data within the VMs will be deleted.
Please confirm within the Azure portal that everything has been deleted.
The various components of this build process are defined below.
|Various TerraForm modules
|Python script that uses TerraForm and AzureCLI to build the Applied Purple Teaming to specifications using the modules in /master/modules and additional resources.
|Additional resources to configure lab environment.
This module creates a Network with 2 x Subnets:
- Domain Controllers
- Domain Clients
This module shouldn’t be used as-is in a Production Environment – where you’d probably have Network Security Rules configured – it’s designed to be a simplified configuration for the purposes of this example.
|Setup Primary Network
|Grab and Set Network ID
- This module is designed to quickly spin up an Active Directory Forest on a single node, this is by no means best practice and we’d highly recommend not using this approach in Production.
- This module was based on / heavily inspired by: https://github.com/bobalob/Terraform-AzureRM-Example/tree/winrm-https
|Setup interface of Domain Controller
|Specify Domain Controller VM Attributes
|Initial Domain Configuration
|Quietly wait for Domain to finish provisioning
|Domain Controller Services and Software Configuration
|Run first commands
|Enable WinRM, grab Lab resources
- This module configures a Ubuntu image with the necessary tooling to be used as a hunters-SIEM (HELK)
|Setup interface for Linux system
|Specify VM configuration for Linux System
|Setup and configure software
- This module provisions a Windows Client which will be bound to the Active Directory Domain created in the other module.
- There’s a few hacks in here as we have to wait for Active Directory to become available, but this takes advantage of the azurerm_virtual_machine_extension resource. It’s worth noting that the keys in this resource are case sensitive.
|Setup network interface for Windows client
|Specify client VM configuration
|Politely wait for the Domain to be provisioned
|Join Windows client to domain.
|Procure and configure the various tools.
|Grab the associated VM IP.
- Gave us a head start on setting up the necessary configuration to use WinRM for deployment.