Over the last few years, many teams and organisations have moved to automated deployment of their red team infrastructure. It's not exactly something new or groundbreaking. If you're a small security team considering the implementation of automated red team infrastructure, you might be trying to identify some of the pros and cons of putting in the effort to develop said infrastructure.

At SilentGrid, we looked at the many approaches to automating infrastructure and the benefits of implementing the project far exceeded the effort levels required to spin up this infrastructure manually each time. Here are just some of the benefits we identified when implementing the project:

  • Predictability & Consistency - Infrastructure-as-Code provides an operator with a recipe for each deployment, making the environment consistent and predictable. This increases the the effectiveness of debugging and reliability.
  • Isolation - With automated infrastructure we can tune the environment each time it is deployed and ensure that any data within the environment is protected and isolated.
  • Easy to Destroy - What goes up, must come down. One of the great features of Infrastructure-as-Code is the ability to destroy the infrastructure with a few clicks. This provides a clean way to manage infrastructure.
  • Saves Loads of Time - The system was designed to be efficient and effective, and thus the ability to spin full environments up and down with minimal configuration is a huge benefit, which allows our technical team to focus on the good stuff.

Now that we can see the benefits of automating the infrastructure, how do we develop a system which is easy to use and and maintain? When deciding on how we wanted to approach this, we looked at what tooling would best suit our team.

We had experience with using tools like Terraform and it seemed like an obvious choice when deciding on the workhorse, however we did not want every operator to be required to know Terraform, and soon realised that Terraform on its own was not enough. The downfall of the tool was not in its ability, but its usage in an environment based around projects and multiple team members looking after the same infrastructure.

To combat this, we decided to utilise Gitlab and its Terraform features to manage the Terraform state. Our approach is as follows:

  1. Terraform tooling stored in a repository
  2. Create a new branch of the repository with the project name
  3. Modify the terraform.tfvars variables to suit the project

Pipeline & Configuration

When a new branch is created under the repository, this kicks off a Continuous Integration/Continuous Delivery (CI/CD) pipeline. The CI/CD pipeline has 5 stages. The first three are automatically run.

Pipeline of a project
  • Prepare -> Prepares all tooling for the Terraform pipeline
  • Validate -> Confirm that the configuration file is valid
  • Build -> Creates a Terraform build plan
  • Deploy -> Deploy the Build plan created in the previous step (Manual)
  • Cleanup -> Destroy all the infrastructure created from the Terraform state (Manual)

It is possible to have a project per branch, run multiple environments simultaneously, and allow all members of the Gitlab group to manage the environment and state using this method.

The terraform.tfvars file controls which services are deployed, and all instances, DNS records, firewall rules, certificates and networks are configured by changing this file.

terraform.tfvars snippets can be used to in the Gitlab wiki to deploy GoPhish instances

Once deployed, changes can be made to the terraform.tfvars file to add/change/delete services from the state. For example, an operator can set up phishing infrastructure, then as the project developed, deploy command & control infrastructure.

Finally, at the end of engagements, once the data has been collected for reporting, operators can run the 'Cleanup' phase of the CI/CD pipeline. This will destroy all resources within the environment.

Destruction of the environment is as easy as running the final pipeline phase

Building Blocks

In order to create a customised environment, we utilised Terraform Modules for each service and/or function of the infrastructure. For example, a phishing module may be pre-configured for specific Simple Mail Transfer Protocol (SMTP) services, but can be customised with a custom domain. The operator is not required to understand Terraform, but simply modify the 'domain' variable.

Terraform Modules make repository organisation easier to navigate and extend

Terraform Modules provide the building blocks to every environment and make it very easy for an operator to get a complex environment up and running within minutes. They also provide a blueprint for extending the capability of the automated infrastructure.

Conclusion

There are many ways to deploy automated red team infrastructure, and there's no one 'right way' to do things. There are countless combinations of tools which can be used with each other.

At SilentGrid, we reviewed how to operate these types of assessments, and developed infrastructure in a way which fits our team using readily available tooling from Gitlab and Terraform.

The ease of configuration combined with an easy to manage solution allowed us to minimise the effort to build the solution and get a proof of concept faster without reinventing the wheel. By streamlining our simulated attack infrastructure, we have optimised our use of time during engagements, and allowed our operators to keep focused on the objective.

In the next installment of this series we dive a little deeper into how SilentGrid designs and develops modules to extend the capabilities of the infrastructure.