Command & Control

Command & Control (C2 or C&C) is the channel through which an implant receives orders and returns data to the operator. This card covers it with Red Team / Blue Team parity: how C2 channels and behavior are designed at a conceptual level —to emulate them in an authorized engagement and to recognize them when analyzing a sample— and how to detect them, extract their indicators (IOCs), and cut them. C2 is MITRE ATT&CK tactic TA0011 and the point in the kill chain where the defender has the most leverage: cutting it cuts the adversary’s control.

sequenceDiagram
    participant I as Implant
    participant C as C2 server
    loop Periodic beaconing (with jitter)
        I->>C: check-in (HTTPS / DNS)
        C-->>I: task (command)
        I->>C: result
    end

Threat model

The implant has to reach the operator through egress, proxies, TLS inspection, and NDR without standing out. The adversary solves this by blending into legitimate traffic and spacing out communications; the defender hunts it by what that traffic can’t fully hide: its periodicity, its destination, and its correlation with an anomalous process on the endpoint.

Red Team — C2 design (conceptual)

Channels (how traffic blends in)

HTTP/HTTPS      the most common; blends with web traffic (sometimes domain fronting / CDN)
DNS             data in queries/responses; slow but usually allowed (see net-dnsattacks)
Legitimate protocols  Slack/Telegram/Discord/GitHub/cloud services as carrier ("C2 over trusted")
Dead drop       collect orders from public profiles/pastes (social media, pastebin)
P2P             serverless botnets, more takedown-resistant

The principle: the more the destination and shape of the traffic resemble something expected on the target network, the less it stands out.

Beaconing (the check-in pattern)

The implant checks in with the C2 periodically (“beacon”). Beacon design balances stealth against control:

- interval (sleep) + random jitter to break exact periodicity
- small, similarly-sized check-ins when there's no pending command
- a longer interval evades better but gives the operator less interactivity

That same regular pattern is, for the blue team, one of the most detectable behavioral signatures (see below).

Malleable profiles and mimicry

Modern frameworks let operators shape the traffic (headers, URIs, User-Agent, request form) to imitate a real service —malleable C2 profiles— and execute in memory (BOFs, in-process post-ex) to leave few disk artifacts. It’s the union of C2 and evasion (see Defense Evasion).

Infrastructure resilience

redirectors     layers (e.g. CDN/trusted categories) that hide the real server
DGA             the implant generates pseudo-random domains by date -> hard to pre-block
fast-flux       fast rotation of IPs/domains to resist takedown

Frameworks the red team uses (reference)

Authorized engagements use off-the-shelf C2 frameworks: Cobalt Strike (commercial, the de facto standard), Sliver, Mythic, Havoc, Metasploit/Meterpreter. Recognizing their artifacts and default profiles is also blue team work: their leaks and open-source maturity have spread these capabilities to attackers of every level.

Blue Team — detection

# network (the most powerful angle against C2)
- beacon analysis: traffic periodicity in NDR/SIEM (RITA, Zeek, Arkime)
- destinations to newly-registered, odd, or low-reputation domains
- DNS: long/random subdomains, anomalous TXT, high volume (tunneling/DGA)
- TLS: JA3/JA3S of known families, self-signed/anomalous certificates
- C2 IOCs (domains/IPs) from threat intel -> block in DNS/firewall/proxy
# endpoint
- an unusual process making periodic outbound connections (EDR + Sysmon event 3)
- correlation: the same process that persists (mal-persist) and talks to a fixed destination

Telemetry

Sysmon network connect (3), DNS query (22), process create (1); proxy/DNS/firewall logs; packet capture for periodicity analysis (Zeek/RITA). The process↔network correlation in the SIEM is what turns a beacon into an actionable alert.

Extract the C2 from a sample (analysis)

# static (see mal-static): domains/IPs/URLs in strings or in the encrypted config
#   -> after unpacking/decrypting the C2s appear (config extraction, see mal-dynamic)
# dynamic (see mal-dynamic): run in an ISOLATED lab with a simulated network (INetSim/FakeNet)
#   -> capture which destinations it tries to connect to and what it sends
# DGA: recognizing the algorithm lets you predict and block/sinkhole future domains

Hardening

Egress filtering: default-deny outbound + a destination allowlist cut most C2 (see Firewall and IDS Evasion).
Protective DNS and category filtering (newly-registered domains, DGA, tunneling).
NDR / beacon analysis (RITA/Zeek) + EDR correlating process↔network.
Threat intel (C2 IOCs) in DNS/firewall/proxy/EDR; TLS inspection where feasible.
After detecting a C2, retrospective hunting: search those IOCs in historical logs across the fleet.

CVEs and real-world cases

C2 over legitimate services: APTs and commodity malware using Telegram/Discord/GitHub/Google Drive as carrier (MITRE T1102 Web Service, T1071 Application Layer Protocol).
Cobalt Strike leaks: its mass use by ransomware (Conti, LockBit) and the hunting of its default beacons (profiles, named pipes) are a detection reference.
DGA: families such as Conficker and many botnets; sinkholing DGA domains is an established response technique.
DNS tunneling (T1071.004) and domain fronting (T1090.004) as egress evasion in real campaigns.

Testing checklist

Identify the sample’s C2 channel (HTTP/DNS/legitimate/dead drop)
Extract the C2s (static + config / dynamic with isolated simulated network)
Does it use DGA? → recognize the algorithm to predict domains
Characterize the beaconing (interval, jitter, sizes)
Capture network IOCs (domains/IPs/URLs/JA3)
Identify the framework if applicable (artifacts/default profile)
Blue: does beacon analysis (RITA/Zeek) and process↔network correlation catch it?
Map to MITRE ATT&CK (TA0011 Command and Control)
Block/sinkhole + retrospective IOC hunting