Skip to main content
Blog ·
·951 words·5 mins· loading · loading

Infra Kes7a - Red Team Infrastructure Overview

A technical overview on Infra Kes7a, a resilient red team infrastructure.

Taha
Author
Taha
A persistent, self-taught and serious learner.
Table of Contents
Series Infra Kes7a 6 parts
  1. 01 Infra Kes7a - Red Team Infrastructure Overview You are here
  2. 02 Picking Up The Correct Attack Scenario
  3. 03 Red Team Domain Names
  4. 04 Domain Fronting: A Red Teamer perspective of AWS Cloudfront
  5. 05 Domain Fronting - A Red Team perspective of Cloudflare
  6. 06 Domain Fronting: A Red Team Perspective of GCP CDNs
Warning: What’s not covered

EDR/XDR evasion techniques are not our focus for this project.
Our objective is maintaining the connection with the implant AFTER it has successfully executed and evaded whatever defenses there are.
We aim to make it harder for the blue team to spot our traffic in action and let our traffic blend in with the legit traffic.

What is this
#

infra kes7a

Infra Kes7a is a multi-cloud, Infrastructure-as-Code (IaC) framework designed to deploy a resilient Red Team C2 environment. It moves away from the “one-server-one-target” model of CTFs and instead emulates the sophisticated, multi-layered redirection used by real-world APTs.

By leveraging Domain Fronting, Reverse Proxy Filtering, and Automated Failover, this infrastructure ensures that even if your primary communication channel is “burned,” your operation remains alive through hidden, low-frequency persistence layers.

Why I’m building this
#

Most CTF labs and platforms provide great practice and insights into how vulnerabilities are chained and exploited. They are a great way to get our hands dirty and move away from theory.

But, let’s be real: Most CTF labs train us to get clapped in a real-world engagement. Attacking from a single VM, extensive unlimited probing, unrestricted data transfer, clear-text and unencrypted channels? As delulu as can be.

After digging into how actual APTs move, I realized their 0-days and advanced evasion skills are supported by a whole ecosystem—not simple attack machines. They build robust, fortified, and fault-tolerant infrastructures from which they carry out long, persistent campaigns without getting caught.

So, in an attempt to move away from script kiddie networking, build an infrastructure that is resilient enough to feed my main character syndrome, and manage resources across multiple cloud providers, I’m building Infra Kes7a.

Use cases
#

Red Team Ops
#

Executing an engagement where stealth is the priority. It allows operators to use high-reputation CDN domains (AWS, Google, Cloudflare) to mask malicious traffic as legitimate cloud service heartbeats.

APT Simulation & Adversary Emulation
#

Providing a realistic, multi-tier environment so Blue Teams can test detection engineering against techniques like CDN masking and cross-cloud redirection. (BYOAL: Bring Your Own APT Lab).

High quality DFIR Challenges
#

Instead of a single pcap, authors can generate logs from multiple redirectors, cloud providers, and VPN tunnels to challenge analysts with The Big Picture of a sophisticated attack from an advanced infrastructure


What makes Infra Kes7a actually Kes7a
#

FeatureStandard “Lab” SetupInfra Kes7a
ExposureThe main attacking IP is public and easily scanned.The core is isolated behind a full private environment.
ResponseBlue Team blocks the IP, session dies, operation fails.Traffic is redirected to a benign decoy.
DeploymentManual setup (Slow/Error-prone).Fully automated via IaC (Terraform/Ansible).
SegmentationSingle domain for all stages.Tiered domains (Phishing, Persistence, Exfil all isolated and seperated).
ResilienceSingle point of failure. Everything falls out once detected.Short-Haul and Long-Haul, failover logic.

The Layers
#

The fronting server: The exposed endpoint
#

Major cloud providers offer multiple domain fronting services. These services are generally CDN distributions that:

  • Offer as free and valid SSL certificates from high reputation providers (AWS ACM, Google, Cloudflare, Microsoft…etc)

  • Are part of a high reputation network and IP ranges of major vendors (AWS, Google, Microsoft)

  • May provide domain names that are generally whitelisted (example: *.cloudfront.net).

  • Help us blend our traffic with the usual entreprise traffic.

This is the first layer of deception in our infrastructure, the part that is logged and view by the blue team.

Classic and Modern Domain Fronting

Modern “domain fronting” no longer relies on mismatching SNI and Host headers (a technique now blocked by major CDNs like Google, AWS, and Cloudflare). Instead, it has evolved into traffic blending: attackers place their infrastructure behind legitimate CDN services and use realistic domain names, paths, and behaviors (e.g., SaaS APIs, analytics endpoints, or static asset delivery) to make traffic appear normal. By leveraging CDN edge networks and redirectors, the goal is no longer to hide the destination domain, but to make communications indistinguishable from legitimate web traffic.

Redirectors
#

These are the link between our C2 and the fronting services we setup. This part is the decision maker for the incoming callback.

  • If it is evaluated as :

    • a legit callback that follows the principles and properties we designed at build time, it forwards it the C2 instance.

    • an invalid request, it silently redirects it to a legit website (that fits in our story of course).

  • Logs everything and anything and uses this data for further analysis on performance, statistics, any unwanted behavior and blue team traces..

  • Fortified via custom headers and fake responses that mimick real and trusted servers.

The C2
#

The brain we set up all these protections for. It controls, commands and orders the infected hosts with the tasks to achieve.
Choosing which C2 framework to use depends on the target environment and the maturity of the red team. You can view a more comprehensive comparaison on C2 frameworks in The C2 Matrix


The Tech Stack
#

  • Orchestration: Terraform (Provisioning), Ansible (Configuration).
  • Initial Access: Evilginx (MFA Bypass) & GoPhish (Isolated Stage 0, not linked to the implant’s callbacks path).
  • C2 Framework: Mythic (MUltiple agents, HTTPx HTTP and DNS profiles).
  • Network Layer: Restricted isolated access to the hidden instances (the redirectors and C2)
  • Cloud Providers: Redundant deployment across AWS, Google Cloud, DigitalOcean and Microsoft Azure.

Takeaway
#

This project is for when you want to learn more about:

  • Engineering a resilient, OPSEC-friendly infrastructure.
  • How APTs maintain persistence via multiple instances and callbacks.
  • How spear phishing is crafted and how hard it can get to spot.
  • Building, connecting, and managing cloud resources from different providers.
  • What IaS is through automating the process of building, configuring, and tearing down the infrastructure at command.
Next in this series · Infra Kes7a 02 Picking Up The Correct Attack Scenario