« Phase 08

Hitchhiker's Guide — Phase 08: C2 Infrastructure

Operation Cedar Lattice — Phase 08 Range Walkthrough

This guide walks you through the Cedar Lattice engagement from the perspective of a principal red-team engineer standing up and analyzing C2 infrastructure against Meridian Freight International's environment. Each step includes the red-team action, the corresponding blue-team telemetry, and the OPSEC decision point.

Pre-Flight Checks

Before beginning Phase 08 labs, confirm:

• Phase 07 EDR gap map is complete (you know which Meridian Freight sensors fire on which technique)
• Both labs run with LAB_MODULE=solution pytest -q from each lab directory
• You can draw the C2 stack diagram from memory (operator → team server → redirector → beacon)
• You have read WARMUP.md Chapters 1-4 (architecture, beacon mechanics, redirectors, JA3)

Phase 08 Range Topology

Describe the fictional Meridian Freight environment:

Meridian Freight International — Notional Network Layout

[Internet]
    │
    ▼
[Meridian Perimeter Firewall]
    │
    ├── DMZ (192.168.10.0/24)
    │       └── mf-webproxy-01 (192.168.10.5)  ← Squid proxy, logs all HTTP/S
    │
    ├── Corporate (10.10.0.0/16)
    │       ├── mf-dc-01 (10.10.1.10)     ← Domain Controller
    │       ├── mf-siem-01 (10.10.1.20)   ← Splunk, receives Sysmon/Zeek
    │       ├── mf-ws-042 (10.10.5.42)    ← Compromised workstation (Phase 04 foothold)
    │       └── mf-srv-finance-01 (10.10.8.100) ← Target: Finance server
    │
    └── NetFlow Collector (10.10.1.30)   ← IPFIX/NetFlow v9 from all segments

FIN-LATTICE Operator Infrastructure (external, fictional)

[FIN-LATTICE Operator]
    │
    ├── Team Server: 203.0.113.50 (VPS, AS64496)
    │       └── Listening: 50050/tcp (operator), 443/tcp (beacon HTTPS)
    │
    ├── Redirector: cdn-assets-delivery.example (203.0.113.99)
    │       └── Apache mod_rewrite → 203.0.113.50
    │
    └── Cover Domain: cdn-assets-delivery.example
            └── Registered 14 days ago, categorized: CDN/Technology

Step-by-Step Cedar Lattice Artifact Production

Step 1: Profile the Beacon

Red-team action: Retrieve the synthetic beacon metadata for the FIN-LATTICE implant running on mf-ws-042. The metadata includes a list of NetworkConnect events (Sysmon EID 3) from the past 4 hours.

Blue-team telemetry at this point: Sysmon EID 3 events are in Splunk. An analyst who pulls index=sysmon EventID=3 host=mf-ws-042 would see repeated outbound connections from svchost.exe to 203.0.113.99:443. Without beacon timing analysis, this looks like normal Windows telemetry traffic.

OPSEC decision point: The beacon is using svchost.exe as the host process (process injection from Phase 06). This is a LOLBin — svchost legitimately makes network connections. The question is whether the connection rhythm betrays it.

Lab 01 action: Feed the synthetic connection list to beacon_interval(), jitter_coefficient(), and classify_rhythm(). A beaconing result here means the SOC could detect it with periodic-connection analysis — document as a detection opportunity.

Step 2: Enumerate Profile Defaults

Red-team action: Extract the C2 profile configuration from the synthetic engagement record. The profile shows the beacon's observable network characteristics.

Blue-team telemetry: Zeek ssl.log captures the JA3 hash on every TLS handshake at the perimeter. Proxy logs capture the User-Agent string. NetFlow captures connection timing.

OPSEC decision point: Does the profile use default indicators? A default JA3, default UA, or default URIs each provide a single-rule detection for the SOC. Even one default indicator is a finding in the final report.

Lab 02 action: Feed the synthetic profile to profile_noise_score(). Score >= 4 means the engagement would have been detected by a competent SOC within hours of the first check-in. Score 0 means the profile requires behavioral (timing) analysis to detect — a much harder problem for the defender.

Step 3: Enumerate Redirector Gaps

Red-team action: Review the redirector configuration for missing mitigations.

Blue-team telemetry: An IR analyst who discovers the redirector domain (cdn-assets-delivery.example) can check:

• Certificate serial number → pivot to other domains using the same cert
• ASN (AS64496) → pivot to other VPS hosts on the same provider
• SSL scan (e.g., via Shodan, censys.io) → enumerate listening ports

OPSEC decision point: Is CDN fronting configured? Without fronting, the redirector IP is directly visible in NetFlow. One pivot from the redirector exposes the team server. With fronting, the visible IP is a CDN node with thousands of other customers — much harder to pivot from.

Lab 02 action: Call redirector_gaps() on the profile. Each gap is a finding. A clean profile with no gaps means IR must work harder — they need to obtain CDN-layer logs or find the staging URI in proxy logs.

Step 4: Enumerate Detection Opportunities

Red-team action: Build the detection-opportunity list — what would a well-instrumented SOC have seen?

Blue-team telemetry: A well-instrumented Meridian Freight SOC with:

• Zeek at the perimeter (ssl.log, conn.log, dns.log)
• Sysmon on endpoints (EID 3, EID 17, EID 22)
• NetFlow collection (IPFIX from perimeter firewall)
• Proxy logging (Squid, full URI + UA)

...would have multiple detection opportunities even against a partially-customized profile.

Lab 02 action: Call detection_opportunities() to enumerate exactly what the blue team could detect. This list goes into the Cedar Lattice Detection Gap Map — the deliverable the client uses to prioritize detection engineering work.

Step 5: Recommend Highest-Impact Mitigation

Red-team action: For the engagement debrief, identify the single change the operator should have made to most significantly reduce detection probability.

OPSEC decision point: The priority order matters: changing the JA3 hash (which requires changing the TLS library or using a JA3 randomizer) eliminates the single most-fingerprinted C2 indicator. Adding jitter is cheap (one config line) but only addresses timing detection. Randomizing URIs addresses signature-based proxy detection.

Lab 02 action: Call best_mitigation(). The result is the recommendation in the report. If the score is 0, the profile has no critical default indicators and detection requires purely behavioral analysis.

Step 6: Compile the Cedar Lattice Detection Map

Output format: A structured document with four sections:

1. Beacon Timing Analysis — median interval, CV, classification, anomalous processes
2. Profile Noise Assessment — noise score (0-6), specific default indicators found
3. Detection Opportunities — enumerated list of what the SOC could have detected
4. Recommended Mitigations — prioritized list, highest-impact first

This document is the Phase 08 deliverable. It goes into the red-team final report as the "Network-Layer Findings" section.

Red-Team vs Blue-Team Perspective Summary

Decision Tree: Is This Beacon Detectable?

START: Analyze beacon connection list
    │
    ├── Fewer than 3 connections? → Insufficient data (inconclusive)
    │
    ├── Median interval >= 3600s?
    │       └── Yes → Long-haul beacon → Check DNS periodic query pattern
    │
    ├── CV < 0.3?
    │       └── Yes → BEACONING → High-confidence periodic-connection detection
    │
    ├── CV in [0.3, 1.0)?
    │       └── Yes → INTERACTIVE → Behavioral analysis needed, lower confidence
    │
    └── CV >= 1.0? → BENIGN or noise → No reliable beacon signature

Gotchas and Pitfalls

1. Redirector IP in the cert: If the redirector's TLS certificate lists the team server IP in the Subject Alternative Name, a single SSL scan exposes the team server. Always use a cover domain in the cert.

2. Staging URI in proxy logs: The initial staging request (fetching the second-stage payload) often uses a different URI than the polling loop. If both URIs match Snort signatures, the beacon is detected before it even starts polling.

3. Sleep jitter doesn't hide exfil spikes: A beacon with good jitter timing but a sudden 50MB POST body during data exfiltration is immediately anomalous. Exfil must be chunked to stay within normal bytes_out ranges.

4. Domain age is the first pivot: IR teams check domain registration age as step one. A domain registered 14 days ago categorized as "CDN/Technology" passes category filters but fails age-based threat intelligence enrichment (Palo Alto PDNS, VirusTotal passive DNS).

5. Named pipe names survive process migration: When the operator migrates the beacon to a new process, the named pipe is recreated. If the pipe name is default, Sysmon EID 17 fires again in the new process, giving the SOC a second chance to catch it.

« Phase 07 | Phase 09 »