Using Terraform to Automate a Red Team Infrastructure Build
Inside a Cloud Based Virtual Machine
We will be using Terraform, an infrastructure as a code service, directly
from the command line (cmd on Windows 10 in my case) on our local machine (host or VM),
to to automate our red team infrastructure build in an Amazon
Web Services (AWS) Linux virtual machine. This infrastructure can be easily built and
destroyed from the command line using Terraform. In our AWS virtual private cloud (VPC),
we will create a Linux EC2 virtual machine instance,
which will host our entire infrastructure (Caldera-C2, Evilginx2, Gophish, and Socat
redirector). This is achieved by utilizing a Hashicorp Configuration Language (HCL)
file, that is run directly from our command line (the
Terraform CLI has to be installed from the Terraform website). Using this method we can
simplify our infrastructure build, saving us time, streamlining the process, and setting
ourselves up for version control of our code
as necessary. The HCL file can be edited using the code editor of your choice, and
tracked for version control using the version control system (VCS) of your choice. Using
infrastructure as a code in this way is an elegant
and efficient way of managing your red team infrastructure.
I have created a local folder for each of my phishing domains that I have
registered in AWS using Route-53, with the zone-id variable in the HCL file set to the
zone-id that has been assigned to that domain in AWS Route-53. These
HCL files will can be managed using a version control system (GitHub in my case), which
makes it easy to keep track of changes to the infrastructure, as well as to branch and
modify the file for use in different phishing
domains.
What Is Terraform?
Terraform is an open-source, infrastructure as code software tool, that provides a
consistent command line interface workflow to manage multiple cloud services. Terraform
codifies cloud APIs into declarative configuration files. You use it directly
from your command line on your machine to automate your cloud infrastructure builds.
Terraform
Why Use The Cloud?
The cloud provides us with the optimal platform in terms of reliability for hosting our
command and control server, along with the rest of our infrastructure. All the
infrastructure required for registering domains and configuration of DNS records for
our use is readily available using AWS Route-53. The cloud provider IP addresses
associated with the red team infrastructure VM are trusted because they are associated
with AWS, and are not likely to raise suspicion. If
internal IDS/IPS (Intrusion Detection System / Intrusion Prevention System), or an
actual human performs a DNS lookup, an AWS IP address range will be returned. It is
common for most modern enterprises to utilise a cloud
service provider to host services and applications, as well as for databases. The
services and applications that we interact with on a daily basis are hosted mostly, if
not completely, on one of the available cloud service
providers (this may be a hybrid cloud - combination of site based and cloud based
services). As a red team service provider, we are no different, and using the cloud to
host our infrastructure in this manner is a best practice.
Using a cloud service provider ensures that our command and control server is ready at
all times to receive a connection when a target is successfully exploited and begins
beaconing. Public IP addresses associated with
the VPC instance are re-created every time the VM is destroyed and re-created (the
process is straightforward using Terraform), meaning that if the target becomes
suspicious, the machine can be easily destroyed using the
"terraform destroy" command, and rebuilt immediately using the "terraform plan" and
"terraform apply" commands, thereby changing the public IP addresses associated with the
VPC instance. The cloud also gives flexibility
in terms of multiple IP addresses, and multiple machines for a bigger infrastructure. We
are using AWS, but there are many other options available.
Configuring AWS
The process begins by creating an AWS account. In AWS, the infrastructure as
a service virtual machine and VPC service is called EC2. here you can create a new EC2
instance, and configure it to run the command and control server.
We have chosen an AWS linux VM (t4g.micro) that is available on free tier, and we set up
our VPC. Our Terraform HCL file will create this infrastructure when we run it from our
command line. For two factor authentication
of my AWS account I use a FIDO U2F zero trust security key.
After the EC2 VPC and Linux VM have been set up, we can use the AWS Route-53
service to check for available domains for registration as our phishing domains. I have
registered a fake LinkedIn domain, as well as a yourcreditInvoice.com
domain for use as phishing domains in a red team engagement.
Modifying The HCL File Using The Hashicorp Configuration Language
As soon as your organization and workspace have been created inside
Terraform, they will need to be added to the HCL file, as seen in the code below:
The
phishing_zone_id variable , and c2_zone_id variable are set to
the
zone-id configured in AWS,
as a domain chosen and set up as a phishing domain,
as
seen in the code
snippet below.
We set up our c2 domain automatically when we run the Terraform build
after
having set the necessary variables in the HCL file, as seen in the code snippet
below.
Using GitHub as Version Control for the HCL File
I have made a private repository on GitHub for version control of my HCL
files. When I register a phishing domain, that domain gets its own folder on my
machine,
I then create a branch from the main "red-team-infrastructure"
repository on GitHub, and assign that branch the name of the newly registered
domain. In
this way, I have a corresponding branch that contains a modified HCL file for each
domain that I register, and the main branch of
the red-team-infrastructure repository contains the original HCL file with default
values, ready for configuration and branching according to my needs.
Grant Knoetze
IT Support Specialist Cybersecurity Analyst Software Developer
Useful Code for Red Teaming
This is code that I wrote to help me with red teaming, and includes a step by step
how-to on developing a fully undetectable trojan. Disclaimer - Nothing
on this page is intended for malicious purposes, anything that you do with any code is
your own
responsibility, never engage a target without written permission in the form of
a signed contract.