Red Team Infrastructure Setup

Disclaimer

This content is provided solely for educational and research purposes. The information presented here is intended to showcase ethical Red Team tactics for professionals working in cybersecurity and is meant for legal and authorized testing environments only.

By reading or using the content in this post, you agree to take full responsibility for any actions performed using the techniques described. The author is not liable for any illegal use or unauthorized testing of these methods. These tactics are meant to improve defenses and should only be used with proper authorization from the system owner.

1. Introduction & Overview

1.1 Objective

The objective of this post is to document the development of a Proof of concept, hybrid, OPSEC-compliant Red Team infrastructure used to simulate adversarial techniques, tactics, and procedures (TTPs), as well as its functionality through a documented attack simulation scenario. This infrastructure was designed as part of the Certified Red Team Infrastructure Developer certification, with the purpose of testing initial access, command and control (C2) setup, and other Red Team operations.

1.2 MITRE ATT&CK Tactics

The following tactics conform this infrastructure’s design objectives:

TA0042: Resource Develoment - Establishment of resources to support operations.

TA0001: Initial Access - Techniques that use various entry vectors to gain our initial foothold within the target network.

TA002: Execution - techniques that result in adversary-controlled code running on a local or remote system.

TA0005: Defense Evasion - Avoid detection after initial compromise of target systems.

TA0011: Command & Control - Communication with, and control of compromised target systems.

1.3 OPSEC Considerations & Limitations

This infrastructure was configured with multiple redirectors, valid cloud services to ensure anonymity, stealth and resilience in the face of Operational threats (Blue teams, Defensive technologies). The use of legitimate cloud services, while effective in testing, should be hardened and adapted in real-world environments to mitigate forensic tracking and ensure scalability for future engagements.

While this setup serves as a proof of concept (PoC), real-world implementations should consider using dedicated reverse proxies, implementing better credential management, and isolating the C2 from the control infrastructure for added security (Visit section “OPSEC: Alternative Infrastructure Proposal” for further information about OPSEC vulnerabilities and their countermeasures).

1.4 Attack Chain

The following diagram depicts the high-level execution of the entire attack chain as accomplished by the infrastructure design:

Figure 1. Visual Attack Chain Flow with MITRE Tactics

The specific techniques and operations are described in the next section.

2. High-Level Infrastructure Overview

This section details the high-level operational architecture of the Red Team infrastructure and documents the attack simulation with supporting evidence.

2.1 Infrastructure Overview & MITRE ATT&CK Techniques

2.1.1 Overall Flow Design

The infrastructure was designed to facilitate secure, scalable Red Team operations, utilizing cloud services and redirectors for traffic obfuscation and phishing campaigns. Each layer of the architecture ensures operational security by obfuscating traffic flows, hiding the true origin of communications, and managing payload delivery.

The following diagram shows the infrastructure deployment, data flows, and user interaction within the public cloud (AWS) environment. It depicts the C2 communications flow between the target machine and the C2 server through CloudFront, an Application Load Balancer (ALB), and finally Nginx as the traffic controller. The diagram also shows how traffic is routed through CloudFront for TLS termination, enhancing anonymity and security, before reaching the ALB and Nginx, which further redirects traffic based on predefined rules to the C2 server:

Figure 2: High-level Red Team infrastructure diagram

The following subsection shows the breakdown of infrastructure components and their purpose.

2.1.2 Components & Techniques

Development Machines

Machines utilized for the testing and deployment of the Red Team infrastructure:

OS: Debian 12 Bookworm, Desktop as the main computer to deploy the resources. Windows 11 Desktop as the computer utilized for Windows-based resources, necessary for the successful techniques testing and development.
Roles: Workstations utilized for resource development, planning and deployment of adversarial infrastructure.
MITRE: TA0042: Resource Develoment - Establishment of resources to support operations.

Cloud Infrastructure

The chosen core Public Cloud infrastructure service was Amazon Web Services due to the architect or operator’s high familiarity with its ecosystem. The following services were utilized to deploy the Red Team Infrastructure:

AWS Cloudfront: Used to provide an additional layer of anonymity by serving as a proxy for incoming connections to the infrastructure. It handles TLS termination and forwards HTTP requests to the Application Load Balancer.

Role: Traffic obfuscation and TLS termination.
MITRE: T1071 (Application Layer Protocol).

AWS Application Load Balancer (ALB): The ALB manages incoming traffic, distributing it to EC2 instances hosting Nginx and Mythic C2.

Role: Traffic distribution and load balancing.
MITRE: T1090 (Proxy).

EC2 (Nginx): The Nginx server installed on the EC2 instance acts as a redirector, forwarding traffic to the Mythic C2 server based on preset rules.

Role: Reverse proxy for C2 traffic.
MITRE: T1090 (Proxy), T1071 (Application Layer Protocol).

Mythic C2 (EC2): Command and control framework used to manage and interact with compromised machines. It serves as the central hub for receiving connections from the target machines and executing commands post-exploitation.

Role: Command and control for managing compromised hosts.
MITRE:
T1071 (Application Layer Protocol): Mythic communicates using standard protocols to blend in with normal traffic.
T1090 (Proxy): Utilizes Nginx as a redirector to hide the origin of C2 traffic.
T1573 (Encrypted Channel): Mythic C2 ensures that communications between the compromised hosts and the C2 server are encrypted.

Gophish (Built on an isolated Private cloud): Software used to conduct phishing campaigns, delivering payloads to the target machines.

Role: Initial access through phishing.
MITRE: T1566 (Phishing).

The infrastructure was designed to simulate a real-world adversarial operation by leveraging AWS services and custom-built operations leveraging Nginx, Mythic C2, Gophish and SMTP services. The primary objectives were to create a stealthy, scalable, and OPSEC-compliant environment to execute Red Team techniques.

2.2 Nginx Redirection Flow

The following image shows a sequence diagram for the Nginx redirection flow:

Sequence Diagram for Nginx Redirector

HTTPS request filepath is “/”, under a normal user agent, responds with a Blog website.
HTTPS request matches user agent “Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko", gets a redirection to Mythic C2 communication, as hardcoded into C2 Windows Agents (This is configured upon Payload generation in Mythic C2).
HTTPS request filepath is “/fetch/”, gets redirected to the file sharing service (Used to host payload files, executables, etc).

3. Attack Scenario

This section provides a detailed, step-by-step walkthrough demonstration of how the infrastructure components interact in a live attack simulation operation.

3.1 Attack Scenario Details

3.1.1 Target information:

OS: Windows Server 2022, Active Directory Domain Controller.

Network & Environment: Proxmox VE virtualized on sandbox LAN. Isolated network with internet access.

Email: Google Workspace (Gmail) web email client.

3.2 Attack Walkthrough

3.2.1 Initial Access

The sequence begins with an email sent that includes an .iso file download. The user, after receiving and interacting with the email, downloads and opens the .iso, which contains a .lnk who’s execution is disguised with a standard PDF to support the phishing pretense.

Email Delivery: The phishing email is sent using Gophish and includes a socially engineered message to trick the user into downloading the pdf (.iso) file. The .iso contains both a legitimate-looking PDF, a Javascript file (Dropper) and a specially crafted .lnk file.

Note: due to modern email security mechanisms, the initial payload (dropper) was delivered through a download link instead of an email attachment, to improve delivery success and leverage the fact that the download URL is a generic AWS Cloudfront domain, so it is unlikely to be flagged by security mechanisms both in email gateways and Windows systems (Defender, Edge browser).

Figure 3: Initial Email delivery

The download URL was obfuscated using simple HTML techniques, as shown below:

Figure 4: ISO file download URL masquerade

Upon url clicking, an ISO file is downloaded from our file server:

Figure 5: ISO file download upon URL clicking

The ISO file, when opened, shows a shortcut file showing as a PDF file. The rest of the files (Javascript, PDF) are “hidden” for windows explorer:

Figure 6: ISO file opened by user

3.2.2 Fully Undetectable (FUD) - Payload Execution

When the user clicks on the .lnk file, it simultaneously opens the legitimate PDF and executes a JavaScript payload via wscript.exe. This JavaScript file has two key roles:

Format: A malicious DLL was converted as a .NET assembly into a serialized object and was embedded in a JScript file by using “DotNettoJScript.exe”.
Dropper: This serialized DLL (JS) Downloads a remote .exe payload from our file server.
Loader: Once downloaded, the .exe is injected directly into memory using .NET techniques.

References:

https://github.com/tyranid/DotNetToJScript

Technical Details:

The JavaScript payload executes using wscript.exe, which is a living-off-the-land program allowed by many security tools because it is seen as a legitimate system process.

URL to the LOLBas project for wscript: https://lolbas-project.github.io/lolbas/Binaries/Wscript/

The .exe (Windows Binary) downloaded is a fully functional Mythic C2 agent that, when loaded into memory, communicates back with the Mythic C2 server for command-and-control purposes.

In the following image, upon opening the shortcut file (.lnk), the PDF opens (left), as well as wscript.exe executing our Javascript file (Right) as seen by using Process Explorer by Windows SysInternals:

Figure 7: Pretext PDF open (Left), Javascript process running in the background, communicating with remote C2 server (Right) under wscript.exe

FULLY UNDETECTABLE (FUD)

Note: This test was made with Microsoft Defender “up” and a modern XDR (Not disclosed in this report), and this execution resulted in no detection from either solution.

3.2.3 C2 Callback

Upon successful execution of the .exe, it initiates communication with the Mythic C2 server, which is hosted behind multiple layers of obfuscation (e.g., Cloudfront > ALB > Nginx). The callback confirms that the target machine has been compromised, and the Red Team operator can now issue commands via the C2 infrastructure.

Command and Control Flow:

The C2 server (Mythic) receives a callback from the client machine.
Communication occurs over HTTPS (port 443) through the CloudFront distribution, protecting the origin of the C2 infrastructure (As seen in Figure 7).

Figure 8: Mythic C2 Callback from client machine

3.2.4 Additional information on redirectors

As demonstrated in this subsection, an HTTP request made to the original URL provided by Cloudfront is routed by Nginx and directs the visitor to a dummy website (Kitten Blog). Only Mythic C2 agents are able to communicate with Mythic C2 server, or a specified file path to download additional files. If a specific filepath is requested, a file sharing service is accessible.

The following image shows the redirection flow made by Nginx, under normal HTTP request conditions (path “/”, normal User Agents):

Figure 9: Blog Website

5. Conclusions

The infrastructure demonstrated in this report successfully simulates Red Team operations, focusing on 1. secure C2 communication and phishing campaigns, framed under MITRE ATT&CK framework as seen on this report. While effective as a proof of concept, several recommendations for further hardening and scalability were discussed.

5.1 General Recommendations

Scalability: For real-world operations, consider using multiple C2s distributed across various cloud regions to increase redundancy.

OPSEC: Introduce more stringent logging and monitoring of redirectors to detect possible signs of forensic analysis or blue team activity.

Hardened Infrastructure: Use dedicated servers for critical infrastructure components and isolate high-value targets.

In essence, OPSEC measures like using default CloudFront domains and decoy redirects protect the operation by minimizing the likelihood of detection, attributing the operation to a threat actor, and buying time to complete the mission. These tactics are focused, mainly on deception, obfuscation, and operational resilience in a live operation scenario.

Appendix A - OPSEC: Alternative Infrastructure Proposal

The current infrastructure design complies with a proof of concept (PoC) model architecture and test environment, but it contains several OPSEC vulnerabilities as described in this section.

Adversaries for a real implementation of this Red Team infrastructure model include Blue Teams, Systems Administrators, and of course, external threat actors. By taking this threat model into account, we can start analysing the potential vulnerabilities of this Red Team infrastructure and propose a set of improvements to protect against such threats in a real scenario.

The following list condenses the information or processes that we seek to protect against such threats, to contextualize the OPSEC model of our Red Team infrastructure:

Red Team clients’ sensitive information (Targets): Red Team operations always handle sensitive or secret information regarding the target infrastructure, organization, etc. (Organizational proprietary data, Passwords, users, IP addresses, PII, PHI, etc.) and must be handled properly to avoid accidental Data leaks or even third-party attacks against our Red Team Infrastructure. As a result, instead of helping our client secure their network, we would end up helping exposing their most critical information. Such threat model is out of scope of the current analysis.
Identity, data and purpose of the Red Team Infrastructure: Such information includes C2 frameworks, IP addresses, ports, TTPs, domain names, locations, etc. and must be protected against Blue Teams (Defenders) to avoid detection and fingerprinting during Red Team operations. Note: The severity of the leakage in this cases vary dependently on the type of Red Team operation taking place; for example, often in Purple Team assessments, the Blue Team would provide valuable feedback while the engagement is taking place.

For the latter scenario, the following table shows a set of OPSEC vulnerabilities and their possible countermeasures for the current infrastructure design and implementation:

OPSEC Vulnerability	Countermeasure
Single point of failure due to the centralization of services (Nginx, Mythic C2), etc. on the same server. Lack of scalability and flexibility for bigger operations.	Segmentation of network and compute environments: EC2 instances dedicated for each purpose: 1 EC2 for Mythic C2, 1 EC2 for Nginx, etc.
If discovered, file share can be retrieved by adversaries to reverse-engineer the Red Team Operation. Hardcoded file server URL in Javascript dropper.	Usage of complex or temporary URLs, unique and short-lived authentication if possible. The implementation of such countermeasure may outweigh the benefits in some cases. Include the URL inside the DLL and add obfuscation techniques to slow down reverse engineering efforts.
Unreliability of current efforts to deliver the payload through Email. Phishing emails being flagged as malicious (Potentially burning our sending domains) or SPAM.	Additional and careful analysis and planning might be required to improve deliverability due to the nature of modern Email gateways and their evolving threat-detection and protection mechanisms. Several changes were made to improve the deliverability such as URL direction instead of email attachments, etc. But it can improve to adapt to modern scenarios.

Appendix B - Additional Infrastructure Information

Email Sending Services: The Email sending software (Gophish) as well as the SMTP server (Opern Source Postal SMTP server) were isolated from the PoC AWS Environment due to SMTP specific requirements.

Domain Names: Custom domain names weren’t utilized for this PoC infrastructure, as Cloufront’s domain names appear to be generic enough and trusted in most environments, aiding stealth efforts. Although further analysis is required, it appears that Cloudfront domain names are easily changed, hard to keep track of by defenders, and this potentially helps in a red team live operation vs. the use of custom domain names for C2 communication (The use of AWS ACM or Cloudflare for DNS handling).
Custom domain names: Only Phishing emails contain custom domain names, with proper DKIM, DMARC and SPF configurations to help with successful delivery.