Going Phishing with Terraform

Let's talk about Terraform for a minute.  Terraform is a tool for building, changing, and versioning cloud or local infrastructure safely and efficiently.  This allows system administrators to construct infrastructure as code, which means you can create customized scripts to spin up entire environments in AWS, Google Cloud Console, Azure, and Digital Ocean.  

This is very helpful for pentesting or red teaming exercises because it allows infrastructure to be stood up and torn down within matter of minutes in the instance an IP address or domain is burned on an engagement.  The term burned would be defined here as a blue team or incident response team that has categorized and/or blocked a particular IP deemed a threat to the company.  With Terraform we can quickly acquire new dynamic IP addresses and continue our attack vectors.  

There is a particular open source project that has been developed by byt3bl33d3r known as Red-Baron.  Red-Baron attempts to automate resilient, disposable, secure, and agile infrastructure for Red Teams.  The code on GitHub is a set of modules and custom/third-party providers for Terraform.  The examples developed by byt3bl33d3r provides the ability to stand up command and control servers, and basic phishing sites on the more popular cloud services.  However, I decided to take this one step further and write a custom script that would allow the automated deployment of a GoPhish server in AWS.  This would allow for rapid deployment of GoPhish in AWS which would significantly cut down the amount of time required for the setup phase of a Social Engineering assessment.  Additionally, it would limit the connections to the administrative portal of the GoPhish server to the external IP where the server was deployed.  

Terraform, unfortunately is not cloud agnostic, and all scripts must be tailored to the environment you want to deploy in.  For this blog post, and all of my current GitHub projects revolve around AWS.  In order to run through the examples detailed in this blog post you will need a basic free-tier AWS account with an IAM account in order to deploy the necessary resources.  


First step is to make sure that Terraform is installed on our host platform.  The software developers make it very easy to get this setup.  

#~ wget https://releases.hashicorp.com/terraform/0.11.13/terraform_0.11.13_linux_amd64.zip
#~ unzip terraform_0.11.13_linux_amd64.zip
#~ mv terraform /usr/local/bin/

That's all it takes to setup Terraform on Kali or any other Linux x64 distro.  In order to deploy the GoPhish server the code base provided on my GitHub account will help assist with that process. The following steps detail how you can pull the code down, and export the AWS keys to your $PATH.

#~ git clone https://github.com/ryanvillarreal/TerraformFun && cd TerraformFun
#~ cp examples/gophish.tf .
#~ export AWS_ACCESS_KEY_ID="accesskey"
#~ export AWS_SECRET_ACCESS_KEY="secretkey"
#~ export AWS_DEFAULT_REGION="us-east-1"

Stand Up

Terraform has three main stages or commands which it has to go through in order to deploy cloud resources.  The terraform init command is used to initialize a working directory containing Terraform configuration files. This is the first command that should be run after writing a new Terraform configuration or cloning an existing one from version control. Also, it is safe to run this command multiple times.  The second phase is the terraform plan command.  This command is a convenient way to check whether the execution plan for a set of changes matches your expectations without making any changes to real resources or to the state.  Finally, the apply phase.  The terraform apply command is used to apply the changes required to reach the desired state of the configuration, or the predetermined set of actions generated by a terraform plan execution plan.

#~ terraform init
#~ terraform plan
#~ terraform apply

The screenshot below shows Terraform performing the init phase and pulling down the required configuration files.

For demonstration purposes I have no included any screenshots for the plan phase, because it was not beneficial to the post.  The screenshot below shows the beginning stages of the apply phase.  Terraform lists out all of the actions that will be performed, along with all the information that is returned from AWS.  

The screenshot below is apart of my custom GoPhish setup script that will automatically change the password for the default admin account on the GoPhish server.  This password will be randomly created every time the setup script is run, therefore storing it some where safe is imperative.   This helps ensure that our tools are safe.  We do not want to get owned while trying to own others.  In the future I would like to write this out to a file or somewhere that is more accessible than just dumping to the logs.  

Now if we navigate to the external IP address on port 3333, as long as all of the AWS routes and firewall rules were implemented correctly you should be prompted with the GoPhish administrative login page.

Using our randomly created password with the username admin we successfully login.  

To demonstrate the power of the Terraform tool, I have logged into my AWS dashboard to verify all of the running instances. As you can see in the screenshot below, in fact we have the phishing-server instance up and running.  

By browsing to the Security Group page, we can see the firewall security group that was setup during terraform apply phase.  

Tear Down

Now that the engagement is over, or your IP address has been burned we need to quickly tear down everything we created.  Well Terraform makes that simplistic as well. To tear down the Terraform environment that you have stood up, make sure you are in the root TerraformFun directory and run the following:

#~ terraform destroy

Once the terraform destroy command is run it should report back that all Resources have been removed.  I will say from experience though if for some reason your ssh keys or .terraform.state files have been corrupted or deleted it will be impossible for Terraform to know which resources to destroy, and will require the user to login to the AWS portal to destroy the created resources.  

To verify once more, I have logged into the AWS portal and determined that all resources have successfully been destroyed.  

Hopefully this blog post and the code base hosted on GitHub will help in your next phishing or red-teaming exercise.  Future plans for this GitHub project is to add in Ansible support for more advanced management over all nodes, and utilization of AWS' Route53 to deploy Domain names to the GoPhish server.  Until next time, keep on hacking!