Defend the Flag
Want to test out Microsoft Security products (and others) but don't have the environment to thoroughly test? Want to simulate Active Directory, privileged users, to learn more about credential exposure and credential abuse? Want to learn more about attack tools so you can become a better computer and network defender?
This project aims at lowering the friction to get started. By leveraging Azure Resource Manager (ARM;
Nested) and Desired State Configuration (DSC;
DSC), we can build this entire environment within 40 minutes--the majority of that time is performing a DC promo.
This project also includes code to then take the VMs and snapshot their disks (
Stage). This allows you to later have deployment tasks on those disks which take roughly 2 minutes.
DISCLAIMER These VMs should not be placed in production environments or used in production workloads. The settings of the VMs have antivirus purposefully disabled, updates disabled (after provisioning), and attack tools stagged.
||Nested ARM scripts for ARM deployment. Extends azuredeploy.json|
||Scripts to help snapshot resources. Convert them to images for easy deployment|
||Helper scripts to help troubleshoot and build-out ARM and DSC environment|
||Desired State Configuration which configure the resources after ARM provisioning|
||Changelog for each version, plus current dev efforts (vNext)|
Primer for PowerShell Az cmdlets: here
About the environment
This creates VMs, one of those VMs being a Domain Controller which hydrates users in an AD environment. Those users are also configured appropriately on the respective VMs to simulate management and administrative activities.
For more information refer to
Phase 0 (build from absolute scratch)
To build from scratch (Phase 0):
New-AzResourceGroup -Name <<resource-group-name>>
New-AzResourceGroupDeployment -ResourceGroupName <<resource-group-name>> -TemplateFile .\azuredeploy.json
The first command creates the resource group (in your respective Tenant). The second line hydrates the new resource group with the provided ARM tempalte file. The
azuredeploy.json wraps in the Desired State Configuration policys to build out the Domain Controller, VictimPC, AdminPC and Client01.
You can make modifications to these VMs, but again, we recommend any change is made at the ARM and DSC level.
If you wish to remove the DSC from a resource, use the
Remove-AzVmExtension command. Make the desired configurations to the DSC, re-compile the DSC (
Publish-AzVmDscConfiguratoin) and repeat the above steps, although you do not need to re-create another resource-group. You can target the same one and Azure is smart enough to know what ARM to apply, and same with DSC, thanks to them being idempotent.
Once you have what you want, you can use the scripts in
Stage folder to help capture the VMs and move them into Azure Storage Containers. This allows us to then deploy these VMs in minutes vs seconds.
Phase 1: Stagging Changes
Stage has what you need. Use
New-BackupVmsToDisk.ps1, point to the right resource group, and the disks will be snapshotted to the resource-group. Then,
New-MoveDisksToStorageAccountContainer.ps1 will take those snapshots and move them into the respective Azure Storage Account container.
Once this is done, you can do Phase 2.
Phase 2: Deploying from Stagged Changes
Like before, but with different parameters, we can deploy VMs.
New-AzResourceGroup -Name <<other-resource-group-name>>
New-AzResourceGroupDeployment -ResourceGroupName <<other-resource-group-name>> -Templatefile .\template.json
template.json will need to be updated so it points to the right location of the VMs earlier captured. This can be done very quickly once you realize the variables use specific names (i.e.
DcVhdUri is the Domain Controller's VHD URI). Also note the other changes that can be made in the
template.json including the VMs names.
The most critical part of this is knowing the Domain Controller becomes the vNet's DNS server, which can only happen after the DC VM exists. For this reason, we have a nested ARM template, similar to what we do in Phase 0. Without this, VMs would not always be able to resolve each other consistently and a race-condition would exist between the vNet DNS settings taking effect before the other VMs are built.
Access your VMs
Regardless of if your in Phase 0 or Phase 2, you eventually will want to access your VMs. You can of course do this from the Azure Portal, but we also created a quick script,
Get-VmsInfo.ps1 -ResourceGroupName <ResourceGroupName>. This will tell you the VMs IPs. You can then
mstsc /v:<<ip>> or,
ssh <<ip>> to quickly RDP into that machine, depending on the VM type and its authentication service.
Skip straight to Phase 2
Want to skip Phase 0? Feel free to grab our VHDs from an open Azure Storage account.
- ContosoDC: https://publicdefendtheflag.blob.core.windows.net/public-v1/ContosoDcd.vhd
- VictimPC: https://publicdefendtheflag.blob.core.windows.net/public-v1/VictimPcd.vhd
- AdminPC: https://publicdefendtheflag.blob.core.windows.net/public-v1/AdminPcd.vhd
- Client01: https://publicdefendtheflag.blob.core.windows.net/public-v1/Client01d.vhd
- Ubuntu-Katoolin: https://publicdefendtheflag.blob.core.windows.net/public-v1/Ubuntu-Katoolind.vhd
NOTE: Ubuntu-Katoolin is leveraging cloud-init which is pulling the DSC
ProvisionKatoolin.yamlconfiguration. For more about the configuration is detailed within the
Don't want to download them? See guidance on
Phase 2; those commands automatically pull from these public Azure Storage Containers; total deployment time is usually ~2 minutes.
Once you have your lab, that is just when the fun begins. Now its time to actually use the lab to learn, grow and practice.
Here is some content that builds on top of these labs:
|Azure ATP||Attack Simulation Playbook||Learn about the various attacks|
|Azure ATP||Ciberesponce: Kali Pass the Ticket||Learn to use harvested tickets from Windows, on Kali|
About the author
The maintainer is a Principal PM/Architect at Microsoft for the Cloud and Artificial Intelligence (C+AI) Security team. You can find more of his work and thoughts at Ciberesponce.com.
This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.
When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact email@example.com with any additional questions or comments.
For full view of whats new and comprehensive changelog, here here.