« Red Team Engineer

Phase 08 — C2 Infrastructure

Operation Cedar Lattice, Phase 08. Phase 07 mapped exactly which sensors Meridian Freight's EDR fired during each execution technique and built the durable detections the client keeps. Now the engagement moves to the network layer. The implant is running on Meridian Freight's internal host. We need it to phone home without being caught by the NOC, the SIEM, or the proxy team. This phase builds the command-and-control (C2) infrastructure analysis capability — understanding the full operator → team server → redirector → implant stack so deeply that we can design the network-level detections that would catch FIN-LATTICE regardless of which C2 framework they deploy.

Safety (non-negotiable). Authorized security-education only. This phase explains C2 architecture and beacon mechanics strictly to predict network telemetry and engineer detections. The labs are beacon-timing analyzers and malleable-profile analyzers over synthetic metadata. There is no working C2 server, no shellcode, no working implant, no deployable bypass, and no weaponized payload in this repo. Every offensive concept ends in its detection. This is the same boundary as every prior phase.

Why this phase exists

The network is the final checkpoint. An implant that silently exfiltrates data still has to talk to a team server — and every byte it sends crosses the wire where a sensor can see it. The operators who evade EDR but get caught on the network lose the engagement. The operators who understand what the SOC's NetFlow analysis, JA3 fingerprinting, and proxy logs actually see can design infrastructure that blends in — and, for a detection engineer, knowing that is how you build network detections that fire regardless of which C2 framework an adversary deploys.

Red team consultants who understand C2 infrastructure at this level can answer the question Meridian Freight's CISO will ask at the debrief: "What network evidence should we have seen, and why didn't our tools catch it?" That answer is a detection gap map — a deliverable with a dollar value.

This phase is also the place where JA3/JA4 TLS fingerprinting, beacon jitter math, and redirector architecture stop being buzzwords on a slide and become concrete engineering problems you can solve or detect.

Learning Objectives

By the end of this phase you can, without notes:

1. Draw the C2 architecture end to end — operator console → team server → redirector chain → implant — and explain each component's role, why each layer exists, and what telemetry it exposes.
2. Explain the beacon check-in cycle precisely: the sleep/jitter formula (sleep * (1 ± jitter/100)), HTTP staging URI structure, POST body encoding, and task-polling flow.
3. Explain JA3 and JA4 fingerprinting — the exact fields that compose the hash (TLS version, cipher suites as ordered decimal IDs, extensions, elliptic curves, point formats), why reordering ciphers changes the hash, and how defenders use JA3 blocklists and anomaly scoring.
4. Explain redirector patterns — Apache mod_rewrite rules, Nginx proxy_pass, domain fronting via CDN SNI/Host-header split — and the network-level detections that expose each.
5. Explain malleable profiles (Cobalt Strike nomenclature but framework-agnostic concept) — named pipe, user-agent, URI paths, sleep/jitter, cert subject — and identify the default indicators that make a profile "noisy."
6. Build a beacon timing analyzer: compute median inter-connection gap, coefficient of variation, and classify a process's connection pattern as beaconing, interactive, or benign.
7. Build a C2 profile analyzer: score a malleable profile for default indicators, enumerate redirector gaps, enumerate detection opportunities, and recommend the highest-impact mitigation.

Cedar Lattice Artifact

This phase produces the C2 Infrastructure Detection Map for the Meridian Freight engagement: a structured analysis of FIN-LATTICE's likely C2 channel — what beacon rhythm their implant uses, what redirector gaps their profile contains, and exactly which detection rules (JA3 blocklist, beacon-timing Sigma, process-to-network anomaly) would have caught the traffic at each stage. This document goes directly into the final red-team report as the network-layer finding.

Labs

How to run

# Lab 01 — run stubs (should fail with NotImplementedError)
cd lab-01-beacon-rhythm-analyzer
pytest -q

# Lab 01 — run reference solution (should pass)
LAB_MODULE=solution pytest -q

# Lab 02 — run stubs (should fail with NotImplementedError)
cd ../lab-02-c2-profile-analyzer
pytest -q

# Lab 02 — run reference solution (should pass)
LAB_MODULE=solution pytest -q

« Phase 07 | Phase 09 »