Introduction

My team is constantly building out infrastructure for various engagements. One of the most difficult to stand up is a proper Red Team Infrastructure. The concept was to build out a fully working base model complete with Redirectors and basic domain fronting.

Planning and Research

Hours upon hours of research went into this project. Initially, I needed to learn Ansible. Having only used it once before on a small project, I was about to venture out on building a stable infrastructure from scratch on AWS, a platform I was also unfamiliar with, other than basic knowledge.

Initially, I wanted to build out on multiple platforms, such as Digital Ocean, AWS, Azure, Linode, etc. but this wasn’t going to be practical for the current engagement this tool was needed for.

One key point of a Red Team infrastructure is they should have a new IP address, right? Well, Ansible generally likes to have a nice, neat set of inventory items to use for builds and since I had no idea what IP AWS intended to assign to the new EC2 instances, we would have to build our inventory on the fly.

Another issue that I faced was customization. No Red Team infrastructure should ever use defaults, so I needed to find a way to ensure that my tool used as few defaults as possible, or had the capability to remove defaults from the build if desired.

Some Assembly Required

C2 Servers

I started with building out the C2 servers. I knew that we needed to create some Cobalt Strike servers for this engagement. Best practice states to have the TeamServers on different hosts in case of compromise. We want one for Short Haul, HTTPS communication, and one for Long Haul, DNS communication. Even though Cobalt Strike has the capability of running multiple listeners on one TeamServer, I feel more comfortable knowing that if for some reason, my Short Haul C2 gets discovered, my DNS Long Haul server should survive.

Customization

I also wanted to make this as customizable as possible. I integrated C2Concealer to automatically build out a random profile for your engagement, then this script would run on both TeamServers. Alternatively, I added an option for using your own profile that you created. Simply drop your profile (named evasive.profile) into files/custom/<TYPE>/evasive.profile, where “TYPE” is the type of C2 server you were using that profile on (DNS or HTTPS). You are also able to do the same for a KeyStore. If files/custom/<TYPE>/keystore.store is not present, it will generate a LetsEncrypt certificate for the domain associated with the C2 server. It is HIGHLY recommended you do not use the generated KeyStore as a code signing certificate.

Further, we use a custom version of Cobalt Strike, with different parameters, certificates, ports, etc. Since I am sure that other teams do similar things, if files/cobaltstrike.zip is present, Red Commander will use that “custom” version instead.

Web Redirectors

The next step required me to build out the Web Redirectors. We needed to ensure that these sites were functional, so I decided to use Joomla as the CMS for the front-end decoy website. Also, to ensure that we could build up as many Web Redirectors as desired, the tool will also allow you to configure new Web Redirectors after you’ve initially built the infrastructure. Simply add more domains to the `domains` list, and rerun the playbook.

The tool also installs Apache so that “mod_rewrite” can be used for redirecting traffic. The initial configuration of the Web Redirectors does not install Joomla though, that comes later. Here, we are installing the required modules and dependencies, generating a LetsEncrypt certificate for the domain associated with the instance, and enabling the necessary services.

To get the right redirector profiles, it was necessary to temporarily copy the created profiles to the Ansible Control Node. We then copied the profile to the Web Redirectors. I’m fully aware that the synchronize module exists, but without changing SSH features in each instance, it would not work the way I intended.

At this point, the playbook will use C2ModRewrite.py and create a set of rewrite rules for that profile. There are some known limitations in the script provided, which can be found in the repository.

Finally, the playbook will add a list of known bad IP addresses to the Apache2 Config using a file called redirect.rules. Please update and/or modify this file as needed, as the goal is to help weed out sandboxes from investigating your C2. The file is nowhere near perfect, but it is a great starting point.

DNS Redirector

Currently, I only employed one DNS redirector. Since the purpose of the DNS beacon in this build is Long Haul communication (1 time per three days or so), multiple redirectors would be unnecessary for the purposes of this engagement. The redirector was created by using socat, which is a multipurpose relay tool for linux. 

To learn more about socat visit https://linux.die.net/man/1/socat.

RedELK

Now for the fun part. RedELK was obviously mandatory for this engagement, and I wanted to automate as much as I could. For this reason, I downloaded a current version (1.0.2) and made a few modifications:

• Added GPS VPN IP Addresses to iplist_redteam.conf;
• Changed CobaltStrike Folder Paths;
• Modified Timezones to America/New_York;
• Added our own logo instead of the RedELK logo; and
• Modified custom.styles.css to work with our logo.

I zipped up the RedELK folder and stored it at files/RedELK.zip. The playbook creates a t2.large instance in AWS and copies it over.

The RedELK playbook also makes a few changes to the configuration files, other than auto-setting the cron jobs based on domains. It will also add your Red Team domains to elkserver/etc/redelk/redteamdomains.conf, update the information used to generate the TLS certificate, and adds config data from variables to the elkserver/etc/redelk/alarms.json.conf file. Note that all certificate generation is done on the RedELK server. Next, the playbook fetches the teamserver.tgz and redirs.tgz files, and stores them in tmp/ on the control node. From here, the playbook executes the elkserver installer to install RedLK on the server.

The next playbook that runs is the redirector playbook for RedELK. It simply copies the redirector package over, extracts and executes the install-redir.sh script. This is to install FileBeat and other RedELK required modules.

The final playbook does the same for the C2 servers. 

After all of this, you’re ready to go! 

**One notable change that wasn’t mentioned before, I did modify Nginx to run Kibana on port 443 with a LetsEncrypt certificate.

To read more about RedELK, visit https://github.com/outflanknl/RedELK/wiki 

Final Thoughts and Getting Started

I’m really excited to release tools that help keep organizations secure by exercising their defensive responses, and hopefully, this has explained clearly the intent and capabilities of this tool. I highly recommend reading the README.md file in the repository to understand every prerequisite. Additionally, the vars/main.yml file holds all of the required variables for this tool to function properly. Each one is mandatory, except certain API keys (IBM, Hybrid Analysis, VirusTotal). It is recommended to use Ansible Vault to encrypt your sensitive variables such as API keys and licenses.

Run Ansible from your control node and (hopefully) everything goes smoothly on the first try! If you need a new redirector, add a domain name, but right now subdomains for redirectors are not supported. 

To access RedCommander and for additional information, check out our GitHub repository: https://github.com/GuidePointSecurity/RedCommander

About GuidePoint Security

GuidePoint Security provides trusted cybersecurity expertise, solutions and services that help organizations make better decisions and minimize risk. By taking a three-tiered, holistic approach for evaluating security posture and ecosystems, GuidePoint enables some of the nation’s top organizations, such as Fortune 500 companies and U.S. government agencies, to identify threats, optimize resources and integrate best-fit solutions that mitigate risk.

To learn more, please visit us at: www.guidepointsecurity.com/

Contributing Author

Alex Williams is a Senior Security Consultant at GuidePoint Security with previous experience in Systems Engineering. He has been professionally involved with information technology for seven years and has worked four years in information security, focused on both offensive and defensive perspectives. Alex furthers his learning by building labs for various local information security groups and schools. Alex has several industry certifications including Offensive Security Certified Professional (OSCP), GIAC Exploit Researcher and Advanced Penetration Tester (GXPN), GIAC Web Application Penetration Tester (GWAPT), Offensive Security Wireless Professional (OSWP), and Microsoft Certified Solutions Expert (MCSE Windows Server 2012: Server Infrastructure).