The need to automate the creation of disposable red-team infrastructure is key to providing effective adversary simulations. As Coalfire Labs continued to grow, our team needed a system to quickly configure and spin up C2 and/or phishing infrastructure, run multiple campaigns at the same time, and recreate infrastructure if some parts got detected and/or blacklisted.

With a little bit of Googling, it doesn’t take long to stumble across Terraform by HashiCorp. Creating red-team infrastructure with Terraform is by no means a new concept, and it has been used by the security community to do exactly this. Terraform is a fantastic and easy tool to use, and all their code is open source. However, here at Coalfire Labs we are really picky and needed a lot of features that a single Terraform configuration file couldn’t provide. Additionally, we needed to streamline the whole process so that everyone in the team could create infrastructure without the overhead of making everyone learn the ins and outs of Terraform or HCL (Hashicorp Configuration Language).

Today, the Coalfire Labs R&D team is open-sourcing Red Baron and making it publicly available on Github. Red Baron is a set of modules and custom/third-party providers for Terraform that automates the creation of resilient, disposable, secure, and agile infrastructure for Red Teams while at the same time reducing the amount of code required to do so and making it as accessible as possible.

Each Red Baron module creates a defined resource and abstracts most of the code necessary to configure the underlying Terraform provider.

First let’s get everything set up: Red Baron requires Terraform version >= 0.10.0, which can be installed using your distros package manager.

After that just clone the repository:

git clone https://github.com/Coalfire-Research/Red-Baron && cd Red-Baron



Since we are only going to be using Linode for this example, we need to export the Linode API key to an environment variable, which will then get picked up by Red Baron on run time:

export LINODE_API_KEY="apikey"



We’re ready to start creating our infrastructure. The following example (which was taken from one of the example config files), should give you an idea of how simple Red Baron makes creating and configuring your infrastructure. We’re going to be creating a C2 server and a redirector.

module "http_c2" { source = "./modules/linode/http-c2" install = [“./scripts/empire.sh”] } module "http_rdir" { source = "./modules/linode/http-rdir" redirect_to = "${module.http_c2.ips}" }



We define the name of the module “http_c2” and give it the source, which in this case is the folder located at “./modules/linode/http-c2”. As the name implies, this module will create a HTTP C2 server in Linode. If you take a look at the linode/http-c2 module documentation you will see that it doesn't have any required arguments so we don't really need to specify anything else, but in this case we also want to install Empire on the C2 server as well, so we specify the location of the install script. (You can install multiple post-exploitation frameworks by just adding the path of the install scripts to the array. Red Barron already comes with a few install scripts for the most popular frameworks.)

We now want an HTTP redirector to obfuscate our C2 server. We define the

“http_rdir” module and give it the appropriate module source location. Looking at the linode/http-rdir module docs we see the only required argument is a list of IPs to redirect HTTP traffic to. Luckily the output of the http_c2 module gives us exactly that!

All we need to do now is feed the output of the “http_c2” module to the “redirect_to” argument. This also creates an implicit dependency, meaning that Terraform will first create the HTTP C2 before the HTTP redirector since we need its IP.

All modules generate unique SSH keys for each instance and are outputted to the “ssh_keys” directory once the resource has been successfully created.

Save the above code to the root directory of the repository and run:

Done! That was easy!

Obviously, Red Baron does a lot more than this: you can mix and match instances on different CSPs, auto-magically create Let’s-Encrypt certs, configure DNS records, setup domain fronting and more!

I strongly encourage you to check out the project’s wiki, which contains all the modules documentation and the example configuration folder, which contains more advanced infrastructure setups.

I’m hopeful this will prove useful to the security community (it already has saved us an enormous amount of time), and that eventually more modules will be contributed to it.