diamond_full diamond diamond_half diamond_euro search-icon menu chat-icon close-icon envelope-icon smartphone-call-icon

Blog & News


A tool for automated generation and configuration of test environments in Microsoft Azure

preview-image for topology

Hands-on practice is an efficient way for penetration testers to gain in-depth knowledge of a certain skill or technology. Providing hands-on practice requires setting up an environment for test and training purposes. Setting up a test environment manually can be time-consuming and very frustrating. This is caused by long installation processes and configuration procedures. Besides that, setting up big test environments can be expensive due to the necessary infrastructure or computational power.
Developing a solution based on local virtualization is possible, but is still limited to local resources. Instead, this problem can be solved using cloud computing.

Introducing the AzureGenerat0r

AzureGenerat0r is a framework that combines infrastructure as code with configuration management. It uses Terraform to create infrastructure such as virtual machines, subnets, NICs, or routes in Microsoft Azure and modular Ansible Playbooks to configure virtual machines. The modules can be used to specify properties of a virtual machine such as

  • running services
  • vulnerabilities
  • installed software
  • OS/application configurations

Combining Terraform and Ansible with the help of some Python code, AzureGenerat0r is able to set up readily configured test environments on demand. To map a test environment to Azure, you have to describe the environment in a specification. This specification contains the infrastructure that should be created and the modules that should be deployed to the VMs. AzureGenerat0r can then process the specification and generate the specified resources. AzureGenerat0r was released on GitHub under the GPLv3 license.

Create resources

AzureGenerat0r offers a wide range of features:

  • Use a counter to create multiple virtual machines.
  • Implemented default mechanisms for keeping a specification simple.
  • Specify parameters for modules in the specification. Thus, more powerful and flexible modules can be developed.
  • Deploy modules in two stages for handling time based dependencies. Enables delayed deployment of modules.
  • Use templates to encapsulate the description of a subnet or VM. The templates can be mounted into a specification. A template binds a subnet to its virtual machine and a virtual machine to its modules. Thus, subnets and VMs can be defined on a higher level of abstraction.
  • Let AzureGenerat0r choose random modules. These can be used in combination with vulnerability modules to create randomly vulnerable VMs.
  • Filter modules based on properties like CVE. This is provided by attaching a file with metadata to an existing module.
  • Extend AzureGenerat0r with your own modules. Thus, you can map the properties you need for your personal test environment.
  • Extend AzureGenerat0r with plugins. They can be used to generate values for a specification like IDs, names, or passwords. In combination with a counter, multiple machines can be created without having to specify the properties of each single machine. A plugin also can be used to initialize the VM counter.
  • Extend AzureGenerat0r to provide additional Azure resources. This cannot be done in a modular fashion, but the source code can be extended.

How to use AzureGenerat0r

In the following I will use an example to explain how AzureGenerat0r can be used. This example uses all the Azure resources and features that are currently implemented.
The specification creates two isolated subnets in Azure. The first subnet contains an Active Directory with a domain controller, two domain computers, and two domain users. The second subnet contains a dual homed host that serves a random vulnerable service which is accessible remotely. The specification file can be downloaded on GitHub.

Spec with comments
Spec with comments

Use the command create to create the infrastructure in Azure. AzureGenera0r starts processing the specification and creates the infrastructure as follows:

  • Every machine gets its own public IP address.
  • Every machine has an open SSH/WinRM port.
  • On every machine there is a default user that can be used to log in to the machine.
  • The access to the machines is secured by Azure Network Security Groups.

After the command has executed successfully, it returns all the public and private IP addresses of the machines. Now the command enrich can be used to deploy the modules to the virtual machines. AzureGenerat0r creates the required configuration files and starts collecting the public SSH keys from the target machines, to add them to the known_hosts file. Afterwards it starts Ansible to deploy the modules to the virtual machines. This procedure is multithreaded. The output of each thread can be observed to ensure that the playbooks have been deployed successfully.

Enrich VMs

So, with AzureGenerat0r test environments can be set up on demand. While the specification is pretty long, with the usage of templates it is possible to encapsulate these subnets and reuse them in future deployments. So this test environment can be created by a one-liner.

Use Case: Active Directory Multi Tier Environment

There are already various modules for the deployment of an Active Directory. The currently developed modules are capable of:

  • creating a domain
  • promoting a computer to a domain controller
  • adding users and computers to a domain
  • randomly creating multiple user accounts and their passwords (powered by Youzer )
  • organizing users in groups and computers in organizational units
  • importing GPOs

Combining these modules, a number of options are available to configure Active Directory as needed. Especially the ability to import GPOs is very powerful, as GPOs itself can be used to create complex Active Directories like an Active Directory Tier Model. The Active Directory administrative tier model is a concept for secure administration of an Active Directory that splits the administrative accounts into separated tiers.

The AD-Testlab specification for example realizes an Active Directory Tier Model where users and computers are separated into two logical tiers. Tier0 contains the domain controller, where only the Active Directory Administrator has access to. Tier1 represents a sales department using two domain computers, where 200 employees and one admin have access to.

As it takes its time to configure a Tier Model from scratch, if you need a tier separated AD lab for training or test purposes, you can use this specification. Besides adding computers, users, or tiers the AD can be extended with services such as Microsoft Exchange Servers which can be found in a real world company.

Future Work

Besides maintaining AzureGenerat0r related to updates from Terraform, Azure and Ansible, the plan is to extend it with more modules, plugins and cloud resources. Also, the implementation of read and write access to variables would be nice. AzureGenerat0r is an open source project, so feel free to contribute.
For questions on how to develop modules and plugins, check out the related directories on the AzureGenerat0r Github project . Additionally, code reviews and improvements are appreciated.

Credits: The elaboration and software project associated with this subject are results of a Bachelor’s thesis by Johannes Ziegler created at SCHUTZWERK in collaboration with Ulm University.


~ Johannes Ziegler