Building a Red Team Infrastructure in 2023

Intro

The infrastructure of a red team engagement might be poetically described as the beating heart of an engagement. It is the central point where everything is connected and runs together. All the data is stored here and when it crashes (or is crashed), it might as well end the whole engagement. This leads to several requirements that have to be met, rooting from different perspectives like functionality, stability, but also security and deception of the blue team.

The topic of building a red team infrastructure is not a new one and although several blog posts on this topic exist [1], I tried to let my insights and struggle flow into this post, which will hopefully help you to make better decisions and avoid potential pitfalls.

The following questions are drawing the outline for this blog post:

• What requirements have to be met?
• What are the components a red team infrastructure consists of?
• What software can be used?
• How are these components set up?

In order to answer these, I will first lay out the requirements for the infrastructure, then give an overview of the whole system and zoom in on the different components to give my opinion on these as well as a quick look on the setup of each.

Requirements

For a red team exercise not only the requirements of a common infrastructure, like the actual functionality, reliability as well as stability apply, but also another layer of security and obfuscation has to be added to prevent the blue team from detecting the infrastructure on the first day of the phishing campaign. An overview of these requirements can be seen in the graphic below.

These requirements constitute the baseline of the necessary infrastructure components. Of course, you can customize these towards your own needs, but instead of stripping away points, I would rather add more requirements.

Overview of Components

So, what are the components that are necessary to satisfy the aforementioned requirements? In the graphic below, the network, including components and connections, is depicted.

The following components are part the infrastructure:

• Phishing/Payload Server: used to create and execute phishing campaigns and store payload code for attacks.
• C2-Team-Server: central communication and steering centre for red team operators.
• Redirectors: for mail, https and dns traffic. Serve as proxies for the traffic and protect core assets.
• [Optional] Vaultwarden: represents a secure data storage solution for the duration of the engagement, e.g. for secrets or gathered credentials.
• [Optional] Red ELK: basically a SOC for red teams, helps to monitor your infrastructure and detect the blue team snooping around your assets.

A detailed explanation of each component is given in later paragraphs.

Network Segregation

The image also shows the distinction between the internal network and the public internet. As the redirectors have to be accessible via the public internet and camouflage as legit web, dns or mail servers, these of course should have a public IP address.

The core assets like the C2-team-server or the phishing and the payload server should be spun up in a protected or internal network. If that is not possible, it should be at least ensured that the open ports of these machines are only accessible by legitimate users. This can be done via connections restricted to specific IP-addresses or certificates. Furthermore, only necessary ports, e.g. SSH- or VPN-ports should be externally accessible.

Cloud Providers

Regarding cloud providers, just go with your preferred one. Personally, for the redirectors we use AWS and as Azure makes the implementation of their apps pretty easy, we used Azure for the Outlook instance. But also CloudFront or Digital Ocean are fine for spinning up instances. More important is to let the provider know that you are operating a professional red team operation otherwise any cloud provider will deactivate your machines without further notice.

C2-Infrastructure

I will start the deep dive into individual components with the C2-infrastructure, which consists of one or more C2-instances and several traffic redirectors.

C2 Team Server

The C2-instance serves as the central communication and steering point for red team operators. Implant traffic is controlled from this point and can also be changed from the way it communicates, up to single commands sent to be executed on the target's computer. C2-frameworks also offer a wide range of integrated tools, that help to execute a successful attack.

A critical decision to be made is whether you want to (or rather can) afford a paid C2 or not. For many years Cobalt Strike was the industry-standard for red teams, but during the recent years many other alternatives arose. Open-source frameworks get a more and more popular, especially with threat actors. The reason they were used by threat actors is simple: these C2s are not as widespread as Cobalt Strike or other paid industry standard C2-frameworks and defensive mechanisms often do not catch them as easily, as their behaviour has not been fingerprinted as well. This even went so far, that the first implants generated by Havoc last year were not even caught by Windows Defender.

The following questions might help you with choosing the best solution:

• Do I want to pay for a C2?
• What communication channels do I want?
• Do I want a GUI?
• Do I need several operators to connect to the C2?
• What operating system does the C2 have to run on?
• What evasion features do I want?

You can also have a look at the C2 Matrix but pay attention as some of the information might be not perfectly up to date. Nevertheless, it gives a good overview on the existing C2 frameworks. When deciding for an open-source framework, always check the latest releases and commits to make sure these are not seriously outdated. And most important, it should go without saying, test and play around with your C2 of choice. If you cannot decide, there is always the option to implement two or more C2s and use these in parallel.

Personally, I decided to give Sliver a go, especially as it is really well maintained, but honestly also as it got hyped a bit at the time I started this experiment. Nevertheless, Sliver did not disappoint. Below I listed my personal advantages and disadvantages for Sliver:

Some of the disadvantages could be easy to solve as it is open-source and everyone can help to improve it.

C2-Redirectors

These can be divided into different kinds based on the traffic they redirect, which will be in this blog post: mail traffic (phishing), HTTPS traffic (short term), DNS traffic (long term). An overview of the redirectors relevant for the C2-traffic can be found below. The mail redirector will be covered in a later paragraph.

The main tasks of a redirector is to protect the respective core assets and to proxy all the traffic destined for and sent by those instances (here: the C2-team server(s)). If a beacon's traffic is discovered by the target's blue team, only the IP or domain of the redirector is lost. In that case just the redirector has to be exchanged, maybe there is even a backup redirector in place. Consequently, only the traffic has to be rerouted to another redirector instead of having to set up the whole infrastructure again. The two different traffic channels for the C2 exist for reasons of redundancy. Should the HTTPS-channel be discovered, there still is the DNS-channel available. DNS traffic is not monitored in many companies and therefore often flies under the radar.

Please note, that if another kind of protocol for the implant communication is used, another redirector is necessary.

HTTPS Redirector

Two kinds of approaches exist for a redirector for HTTPS traffic. Traffic can be redirected via a simple pipe or via a reverse web proxy. The first option, achieved via socat or an IP tables rule, blindly forwards traffic arriving at a certain port. This basically describes the functionality one would expect from a redirector. In contrast, a reverse web proxy adds the possibility to filter out unwanted visitors based on factors like geolocation or user agent. It enables you to route the implant traffic to your C2-server and show all other visitors a common web site. This principle is also shown in the picture below.

It can be seen that a marker on every request reaching the redirector is evaluated. Based on the outcome of that evaluation, if the request is categorized as a valid request coming from the implant, it is forwarded to the C2 server. Otherwise, the request is forwarded to a web server containing an ordinary web page or an error code.

Software Options

Regarding the proxy software, three main options exist: Apache, Nginx or Caddy. All of these are open-source applications. Of course, you can also use another web server if it fulfils the previously mentioned criteria.

Apache and Nginx are well-known options and lots of tutorials for the setup are available. They function almost out of the box and have lots of modules to block unwanted guests or IPs based on the regarding geolocation. Also, as these are widely used, they do not stand out in terms of the product itself.

A lesser known and used option is Caddy. I have not tried it yet, but it promises an easy setup with automated HTTPS support (via ZeroSSL or Let's Encrypt) for public domains. A big plus is also that you only need a single file called "Caddyfile", which handles all settings. It is written in Go and does not have any further dependencies. It has also been demonstrated that Caddy can be specifically used as a redirector for C2-traffic [2].

Setup/Hardening Process

The correct setup and hardening of the redirectors are crucial processes. If done correctly the redirector will look like a common web site. If not, the blue team will catch you sooner than you think.

First of all, all traffic to and from the redirector should be encrypted via HTTPS. Otherwise, the SOC will easily pick up your implant, as all transmitted data can be read. From an OPSEC-perspective you do not want to have an unencrypted connection into a client's network, as anyone could eavesdrop on the traffic. Plus, unencrypted traffic always stands out as it could be an indicator for suspicious activity.

Which leads to the next point: do not use self-signed certificates. An easy way to generate valid certificates is using Let's Encrypt and getting automatically generated certificates for your domain. You can either generate the certificate yourself or use Certbot, which opens a web server on port 80 of your IP (to make sure you legally own the domain) and does all the work. If you are running another service (e.g. Nginx) on port 80, this service should be stopped for the time Certbot is running. As the certificates from Let's Encrypt are free, a lot of people use them - this includes loads of suspicious actors and scammers. Consequently, if you have the budget available, buy some certificates from any other certificate authority (honestly, it does not matter from which one).

Speaking of issuing certificates to a domain: your redirector should have a domain, as connections to IP-addresses are pretty suspicious. Choose a domain name based on your OSINT-results. Ideas would be anything infrastructure related, campaigns/promotions related to special events like Christmas or even a domain with the target's name and a well-hidden typo in it.

If you have the time, you should definitely create a simple, but convincing web site. This will critically add to the site's credibility and help to conceal the real purpose of the web server (to tunnel implant traffic).

Off to more specific settings to block unwanted visitors. As scanner bots often use specific user agents, it is rather simple to map unwanted strings in user agents to a rule that either responds with an error code or forwards the visitor to another website (like google.com).

The most crucial part is to hide the implant traffic to the C2. This is commonly done by making the implant query a specific directory or file on the webserver. The webserver then forwards all traffic to the C2 server.

To only get desired traffic reaching the C2 server, a restriction-layer based on multiple factors (like user agent, IP address or domain if available) and responding with an error code for queries not matching the required pattern is implemented.

In this example I chose Nginx as a redirector, so the following paragraphs are tailored towards it. Nevertheless, similar functions do exist in Apache or Caddy.

For Nginx you can set the proxy_pass attribute when a certain location is requested. As a restriction, based on the requested location could be detected easily, another factor is needed. In this example, it will be the user agent. The following snippet is from Nginx's default.conf.

# map useragents to proxypasses
map $http_user_agent $goodagent {                                                                                                                                        
    default 0;           
    "Supersecretuseragent" 1;
}

[...]

server {

[...]

# C2 route
  location /supersecretlocation/ {
      proxy_ssl_certificate /etc/nginx/https-cert.pem;
      proxy_ssl_certificate_key /etc/nginx/https-key.pem;
      proxy_ssl_verify off;
      proxy_ssl_server_name      on;
      proxy_set_header Host $host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_pass https://localhost:5443;
      if ($goodagent = 0) {
      return 404;
	}
  }
 } 

In a first step, different user agents have to be categorized. As you can see, the variable $goodagent is set to false for any user agent apart from Supersecretuseragent. In the server-block, the proxy_pass for the route supersecretlocation is defined. That is the route, the beacon will request with the user agent Supersecretuseragent. The proxy-connection itself forwards to https://localhost:5443. The reason for this is, as you will see later on, that the connection from C2 to the redirector is solved through ssh and remote port forwarding. If the request comes with a user agent, not categorized as $goodagent a 404-error will be thrown.

Another restriction can be implemented, based on geolocations. Therefore, the MaxMind database is used, which maps IP addresses to countries. In the Nginx configuration these countries can be referenced and assigned to different server responses [3]. The restriction process is similar to the restriction of user agents.

Last, of course, the web server itself has to be hardened. This consists of the following points:

• make sure the implemented version is up to date
• strip out all instances of the version number
• change default credentials (if applicable)
• remove all unnecessary files (like Changelogs, Publisher Notes, etc.)
• remove all metadata from files and media
• remove comments in code
• check and clean all certificate data

After this step go and scan your redirector server, to see whether you can gain information or hack it. Specifically, do port scans or wordlist enumeration. The aim should be to check whether you forgot something to clean. It might also help to let a fresh pair of eyes do this.

DNS Redirector

For a DNS redirector no specific DNS service on the redirector itself is necessary. As the traffic is only forwarded and not processed two main options do exist: socat or iptables. Iptables might offer slightly more options, as you can specify the IP-ranges of incoming traffic and implement forwarding rules for IPs not coming from that range. On the other hand, socat is a bit easier and faster to set up [4].

It also pays off to have a look at how your C2-server handles DNS requests and if it could be fingerprinted through that [5].

To make the redirector work properly, a few more steps have to be taken. These steps differ based on the respective C2. Basically, you need to register an A record as well as an NS record for the (sub)domain of your redirector. For Sliver a comprehensive tutorial exists in the official Wiki [6].

Phishing/Payload Infrastructure

This part of the infrastructure consists of three components: the actual phishing/payload server, a Postfix redirector and an instance of Outlook in the Azure cloud. The phishing/payload server contains the actual phishing software and functions as storage for stage-1-payloads (staged payloads consist of a small piece of code, the stage-0, which is executed by the target and loads the actual payload, the so-called stage-1). The Postfix redirector is used for changing or stripping out suspicious mail headers and the Outlook instance is necessary to make the mails look more trustworthy. Additionally, if a response to the mails is sent from the target, the communication can be carried onwards from the Outlook inbox.

The diagram below gives an overview this part of the infrastructure and the respective functions described before.

Phishing/Payload Server

In terms of phishing software Gophish is the go-to-standard for years. It helps in the creation of fake websites, can monitor clicks or personalize links with IDs to identify the behaviour of certain users. Gophish also comes with a web server for your fake websites or stage-1-payloads. So, if a HTTPS-redirector is placed in front of the Gophish instance it can be used as a combined phishing and payload service. Aside from that, GoPhish does its job pretty well. Some small OPSEC-customizations have to be done, but that's because GoPhish is tailored towards phishing engagements only and implements not-so-stealthy headers containing the value "gophish" to distinct these from real phishing mails. As that is a clear indicator for defensive mechanisms, these headers have to be stripped out (this will be done by the Postfix redirector).

Setup Process

First of all, you should register your domain with a DNS service and afterwards set up all necessary DNS records. In this case I used Route 53 as it allows an easy setup with Terraform, but also any other DNS Service is absolutely fine (like SSE's very own deSEC). The following records have to be set: A, MX, SPF, DMARC, DKIM. If not already happened by now, also purchase an MS Office365 or Outlook license. Then spin up the Outlook instance in Azure and follow the steps below to connect the components.

The process to use Office365 as an SMTP relay is already described step by step in this blogpost. In the following paragraphs, I will briefly sum the process up and add some information relevant for phishing. First, the MS365 host is implemented. Therefore, you need to set up an Azure box with MS Office365 and enable SMTP-authentication for a single user account (the one you plan to use for the forwarding).

Then you have to set up the Postfix instance on an internal server. After installing it (for Ubuntu it is just apt-get), some configuration files have to be created and hashed. If you follow the aforementioned blog post this is quite simple. By now, Gophish does not know that a redirector is used. This can be changed with so "Sending Profiles", which can be created via the Gophish UI and where you just need to add your Postfix server values [7].

Afterwards, the headers Gophish sends along with an email have to be removed, otherwise the phishing mail will be instantly recognized and blocked by mail servers. The cleaning of the mail headers is mainly done by integrating a file called "header_checks" in Postfix. This file tells Postfix how to handle certain headers. In our case, this means to find certain headers and either strip these out or overwrite the values. Apart from headers containing your IP and hostname or domain, the file should also handle the header "X-Mailer", as it is specific to Gophish and a clear indicator for phishing. Additionally, in Postfix's main configuration file (main.cf) the variable myhostname should be set to something unsuspicious like a subdomain of your phishing domain (e.g. something like mail.domain.com)

The following is an example of how Postfix's header_checks.cf file can look like:

      /^Received:/ IGNORE
      /^X-Mailer:/ IGNORE
      /^Message-ID:/ IGNORE
      /^User-Agent:/ IGNORE
      /^X-Originating-IP:/    IGNORE
      /^Mime-Version:/        IGNORE
      /^In-Reply-To:/ IGNORE
      /^References:/ IGNORE

After setting up the Gophish server, send some test mails and analyse custom or suspicious headers. It might help to grep for the used hostname, expressions like "phish" and anything related to the Gophish server's IP address or hostname.

Connections

Now that the single components have been depicted, also the collaboration between the elements has to be defined.

In the present infrastructure three connections between servers are needed:

• C2-team-server to HTTPS-redirector (implant communication)
• C2-team-server to DNS-redirector (implant communication)
• Payload-server to HTTPS-redirector (stage-1-payload)

The connections from the internal network to the redirectors can be handled via ssh and remote port forwarding. In that way traffic can be forwarded in a comfortable and fast way. For this use case I implemented Autossh as a service. Autossh makes sure that the connection is held up and if it is lost reconnects automatically.

It makes sense to establish Autossh as a service, as it is more stable. In the snippet below the service for a connection to the DNS-redirector is depicted:

[Unit]
Description=AutoSSH tunnel to DNS-Redirector
After=network.target
[Service]
Environment="AUTOSSH_GATETIME=0"
ExecStart=/usr/bin/autossh -M 0 -q -N -o "ServerAliveInterval 60" -o "ServerAliveCountMax 3" -R 5353:localhost:53 -i <SSH-KEY> <USER>@<DNS_Redirector_IP>
[Install]
WantedBy=multi-user.target

Of course, also other services or methods can be used, as long as these offers a stable connection and offers an automatic reconnection. An example for this would be Wireguard [8].

Automate Setup Process

As you do not want to set up every host by hand, automation is almost a must . This reduces mistakes and if done correctly it also saves a lot of time in case parts of the infrastructure have to be changed (which almost happens for every engagement). For this reason, a mixture between Terraform, Vagrant and Ansible can be used.

I used these in the following way: Terraform for the setup of the AWS boxes, Vagrant for the setup of the boxes on the internal network and Ansible for automating the installation of software and everything else following after an installation of a machine's operation system. This included web servers, ssh connections, certificates, movement of files and more. Additionally, the three tools can be intertwined seamlessly and work together like a charm. Depending on the size of the infrastructure, it makes sense to create automation scripts in a modular way, for example with Ansible roles for each host. An example for automating a red team setup with Terraform and Digital Ocean can be found under this blogpost.

Summary

As you can see the topic is a very broad one, with lots of branches and paths to go down. I tried to trim these to a minimum to keep the path clear and give an overview without diving too deep into the rabbit holes of different components. I hope I could answer the following questions.

What requirements have to be met?

The requirements can be divided into requirements related to functionality & performance, security & obfuscation and additional requirements not fitting the other two categories. The infrastructure should be able to send and receive phishing mails, host files and allow C2 communication. All of this functionality should be protected from the target's blue team or other defensive tools (like Antivirus software) and has to work proper and stable.

What are the components a red team infrastructure consists of?

The main infrastructure can be divided into the phishing infrastructure and the C2-infrastructure. Each of these contains the main component (phishing/payload server or C2 server) and several redirectors.

For the C2-infrastructure, these are redirectors used to forward beacon traffic and protect the main C2 server. A minimum of two different redirectors are recommended, one for the main beacon traffic using a fast protocol like HTTPS and one backup channel using a more subtle protocol like DNS.

The mail infrastructure uses two redirectors in a row, one Postfix redirector to clean outgoing mail traffic and afterwards an MS Office365 instance to make the mail traffic look more trustworthy as well as to provide an inbox for potential responses.

What software can be used?

This question does not have a definitive answer, as it comes down to individual preferences and budget. Regarding the mail infrastructure there is more or less a definitive answer as Gophish is the de-facto industry standard nowadays. Paired with a Postfix redirector and a Microsoft Outlook instance as a mail relay it is in my opinion the best choice.

The choice of a C2-framework offers much more possibilities, as a decision has to be made between paid and open-source frameworks. For paid frameworks I would choose between Cobalt Strike, Brute Ratel or Nighthawk. In terms of free frameworks, at the current point in time, I would go with Sliver, Havoc or Mythic.

For redirectors for C2 traffic there would be the choice between Apache, Nginx or Caddy for the HTTPS redirector and Socat or IPtables for the DNS redirector.

Conclusion

This blog post serves as a base to create your own red team infrastructure and hopefully helps to give an overview on the different branches. Each branch can be explored deeper, which I might do in future blog posts focusing on single elements, but this should be enough for today. If you have questions or just want to chat about what you just read, do not hesitate and hit me up.

Links

[1]: https://github.com/bluscreenofjeff/Red-Team-Infrastructure-Wiki [2]: https://medium.com/geekculture/an-nginx-apache-alternative-for-c2-redirecting-61e92a917101 [3]: https://medium.com/@maxime.durand.54/add-the-geoip2-module-to-nginx-f0b56e015763 [4]: https://www.cobaltstrike.com/blog/simple-dns-redirectors-for-cobalt-strike/ [5]: https://labs.withsecure.com/publications/detecting-exposed-cobalt-strike-dns-redirectors [6]: https://github.com/BishopFox/sliver/wiki/DNS-C2 [7]: https://docs.getgophish.com/user-guide/documentation/sending-profiles [8]: https://www.wireguard.com/