System Design: C2 Infrastructure for a 90-Day Engagement

1. Problem Statement

Design a Command and Control (C2) infrastructure for a 90-day adversary emulation engagement against a large enterprise client (Meridian Freight International, ~5,000 endpoints). The infrastructure must support 3–5 red team operators working concurrently, maintain OPSEC for the duration of the engagement, and be teardown-able cleanly at engagement end.

Functional requirements:

• Operators can issue tasks to beacons from a shared team server
• Beacons communicate over HTTPS; traffic is indistinguishable from legitimate traffic
• Infrastructure is resilient: losing a redirector does not stop the engagement
• Multiple beacon profiles (long-haul persistence vs. short-haul interactive sessions)
• Out-of-band access path if primary C2 is burned
• All operator actions are logged for the engagement report

Non-functional requirements:

• Availability: redirectors must survive the engagement duration without manual maintenance
• Burn resistance: burning one component (redirector domain) does not expose another (team server IP)
• Attribution resistance: infrastructure is not linked to the consulting firm's corporate IP space
• Teardown: all infrastructure is removed within 24 hours of engagement end
• Audit trail: all operator commands logged and immutable (for report and deconfliction)

2. Constraints and Assumptions

In scope:

• Infrastructure architecture and component design
• OPSEC requirements per component
• Beacon profile design
• Operator workflow

Out of scope:

• Selection of specific C2 framework (Cobalt Strike, Mythic, Havoc — not named here)
• Specific exploit code or implant implementation
• Network protocol cryptographic implementation details

Assumptions:

• The engagement is authorized with a signed ROE
• Infrastructure is spun up on cloud providers using pre-purchased non-attributable accounts
• The team server runs on a hardened Linux instance
• Beacons are pre-compiled before the engagement with the correct redirector domains embedded

3. High-Level Architecture

┌──────────────────────────────────────────────────────────────────────────┐
│  Operator workstations (3–5 operators, VPN to team server)               │
└───────────────────────┬──────────────────────────────────────────────────┘
                        │ Operator VPN (WireGuard / OpenVPN)
                        ▼
┌──────────────────────────────────────────────────────────────────────────┐
│  Team Server (hardened Linux VM, non-attributable cloud account)         │
│  - C2 framework backend                                                  │
│  - Operator log database (append-only)                                   │
│  - Firewall: only VPN IPs and redirector IPs allowed                    │
└──────────┬────────────────────────────────────────┬──────────────────────┘
           │ HTTPS (mutual TLS, redirector → team)   │
           ▼                                         ▼
┌────────────────────┐                   ┌────────────────────────────────┐
│  Primary Redirector│                   │  Backup Redirector             │
│  (CDN-fronted)     │                   │  (different provider/region)   │
│  Nginx mod_rewrite │                   │  Nginx mod_rewrite             │
│  Domain: cdn-*.com │                   │  Domain: update-*.com          │
└─────────┬──────────┘                   └────────────┬───────────────────┘
          │ HTTPS (client → redirector)                │
          │                                            │
          ▼                                            ▼
┌──────────────────────────────────────────────────────────────────────────┐
│  Target environment (Meridian Freight International)                     │
│  Long-haul beacons (60s sleep, 20% jitter) + short-haul (5s, 0.1 jitter)│
└──────────────────────────────────────────────────────────────────────────┘

                    ┌─────────────────────────────────┐
                    │  OOB (Out-of-Band) Channel       │
                    │  DNS beacon, low-and-slow        │
                    │  Domain: *[.]ntp-sync.net        │
                    └─────────────────────────────────┘

Component list:

1. Operator VPN gateway — operators connect to the team server exclusively over VPN
2. Team server — hardened Linux VM, firewall-restricted to VPN + redirector IPs only
3. Primary redirector — CDN-fronted Nginx; rewrites C2 URIs, decoys for non-matching requests
4. Backup redirector — separate cloud provider; activated if primary domain is burned
5. OOB (Out-of-Band) channel — DNS-based C2 beacon for use if HTTPS C2 is entirely burned; very low bandwidth, persistence-only
6. Operator log store — append-only log of all operator commands, timestamps, and targets

4. Component Deep-Dives

4.1 Redirector Design

Purpose: Sit between the target and the team server. The target's defender sees only the redirector's domain and IP. If the redirector is burned (domain blocked, IP blacklisted), the team server is not revealed.

Implementation:

• Nginx with mod_rewrite (or Apache .htaccess)
• proxy_pass only for requests matching the C2 URI pattern (e.g., /api/v2/status)
• All other requests: return HTTP 200 with decoy HTML that matches the masquerade domain (if masquerading as a CDN asset server, return a plausible 200 with static content)

Firewall rules on the redirector:

• Inbound: allow 443 from any (the target's beacons connect here)
• Outbound to team server: allow only on team server port, only to team server IP, only from the redirector IP
• Deny all other outbound

Domain selection: use aged domains (registered 6+ months ago), with valid TLS certificates (Let's Encrypt), and with realistic DNS history. Never use a domain registered the day of the engagement.

CDN fronting (conceptual): some CDN providers allow a request to arrive at a CDN edge node addressed to a legitimate CDN domain, but be routed via a Host header override to the actual backend (the redirector). This obscures the true destination IP behind the CDN provider's IP space. Note: major CDN providers have increasingly disabled this technique; current applicability is scenario-specific.

4.2 Beacon Profile Design

Two profile tiers:

URI paths: match the masquerade domain's expected traffic. If masquerading as an ad network: /pixel.gif, /track.js, /impression. These URIs appear in the malleable profile.

User-agent: match a current, common browser on the target's OS baseline. Do not use a pre-2022 browser string. Do not use the C2 framework's default UA.

Named pipe (for local comms, if used): not a default name. Generate a name that matches the naming convention of installed software in the target environment (e.g., if the target runs Sophos, use a pipe name that matches Sophos's known named pipe pattern to blend in).

4.3 Team Server Hardening

• Non-attributable cloud account (not linked to the consulting firm's corporate accounts)
• Firewall: inbound connections allowed only from VPN gateway IP and known redirector IPs
• All ports not needed are closed
• SSH: key-only, no password auth, non-standard port
• Operator access over WireGuard VPN (not SSH directly)
• Operator log database: PostgreSQL with append-only table; operators cannot delete log entries; entries are backed up hourly to an encrypted S3 bucket in a separate account

4.4 OOB Channel

When to use: if the primary HTTPS C2 is fully burned (both redirectors blocked, all domains blacklisted), the OOB channel provides a fallback path.

DNS beaconing (concept): the beacon encodes task results and check-ins in DNS TXT query subdomains (aGVsbG8=.task.ntp-sync.net → base64-encoded data). A custom DNS server on the attacker side receives these queries and decodes them. Very low bandwidth (dozens of bytes per query), but survives most network controls since DNS is rarely blocked outbound.

OPSEC: the DNS server for the OOB domain must not be the same IP as the team server. Use a separate VM. The OOB channel is used only when the primary channel is confirmed burned — it is not activated routinely.

4.5 Operator Log Store

Requirement: immutable audit trail for deconfliction and reporting.

Design:

• All operator commands flow through a logging proxy before execution: log → execute
• Log record: {operator_id, timestamp_utc, target_host, command, arguments, session_id}
• Append-only table (PostgreSQL: INSERT only, no UPDATE or DELETE permissions for any operator role)
• Hourly encrypted backup to isolated S3 bucket
• Log retention: through engagement end + 30 days (per engagement agreement)

Use in deconfliction: when the client SOC calls during an engagement, the operator pulls the log for the flagged timestamp range and provides it to deconflict.

5. Tradeoffs

CDN fronting vs. direct redirector:

• CDN fronting obscures the redirector IP behind a CDN provider's IP space → harder to burn.
• CDN fronting is increasingly detected by monitoring the Host vs SNI mismatch in TLS traffic.
• Decision: use CDN fronting for the long-haul beacon profile (lower traffic, harder to notice SNI mismatch at scale); use direct redirector for short-haul.

Single team server vs. multiple:

• Multiple team servers increase complexity; each needs VPN, firewall configuration, and log sync.
• Single team server is simpler and more auditable.
• Decision: single team server for a 90-day engagement with 3–5 operators; acceptable single point of failure since the team server's IP is not exposed to the target.

Real-time operator logging vs. async:

• Async logging could miss events if the team server crashes.
• Synchronous logging adds minimal latency for a red team tool.
• Decision: synchronous append before command execution.

6. Detection-Forward Perspective

What a defender can see:

Residual detection opportunity (always present):

• ETW-TI fires on memory operations regardless of beacon OPSEC
• Sysmon EID 3 (network connection) from an unusual process is always detectable
• Beacon timing regularity (low CV) is always measurable in NetFlow data

This is the core pedagogical point: C2 OPSEC reduces detection probability at the bottom of the Pyramid of Pain (hash, IP, domain, artifact), but TTP-level detections survive any infrastructure rotation. The engagement tests whether the client has built TTP-level detections, not just hash/IP blocklists.