Command and control

Authorization first — C2 belongs in a lab, not on someone else’s network

Before any mechanism below, the rule that opens this whole track still holds: standing up command-and-control infrastructure and pointing an implant at a host is only legitimate against systems you own or are explicitly scoped to test. Running an implant that beacons to your server from a machine you don’t control is unauthorized access and persistence on someone else’s network — a serious crime in nearly every jurisdiction, and a contract-ending mistake even inside a sanctioned engagement if the host is out of scope. Everything here is framed for a CTF range, a deliberately built lab, or a red-team engagement with a signed rules-of-engagement document that names the target ranges and the C2 domains in advance.

We teach the mechanism so you can break it. In MITRE ATT&CK, command and control is the tactic TA0011; the step before it — getting your code to run and survive — is Execution and Persistence, and the Lockheed Martin Cyber Kill Chain lists Command & Control as the sixth link, right before Actions on Objectives. The kill-chain framing is the point: C2 is the chokepoint. An attacker can slip past every earlier stage quietly, but they cannot act on the target without a channel back — so if a defender breaks C2, the intrusion stalls with code on the box and no hand on the wheel.

Why beacon out instead of connecting in

The firewall problem is asymmetric, and that asymmetry shapes everything. A default corporate perimeter drops unsolicited inbound connections — there is no listening port for the operator to dial. But it almost always permits outbound traffic on 443, because employees need the web. So the implant inverts the direction: it does not wait to be connected to; it beacons — it periodically initiates a connection out to the C2 server, pulls down any queued task, runs it, and posts the result back, all over a protocol the firewall already trusts.

This is why HTTPS is the workhorse C2 channel. The request blends into the haystack of normal web traffic, and TLS encrypts the body so a network inspector sees a connection to some host on 443 but not the tasking inside it. The cost is latency: a beacon that calls home once a minute means up to sixty seconds between your command and its execution. Operators tune that interval — short for interactive work, long to stay quiet — and that single tuning knob is the seam a defender pries open.

What the beacon leaks: the signals a defender hunts

A human browsing the web is bursty and irregular — pages, idle, a video, idle, a different site. An implant on a default config is the opposite: it phones the same destination at the same cadence, indefinitely. That regularity is the primary tell. Defenders compute the time between connections from the same source to the same destination and look for a tight, repeating period — a beacon at a 60-second interval shows up as a near-vertical spike in the inter-arrival histogram that no human session produces.

Three more signals stack on top of the rhythm. The beacon request and response are small and uniform — a few hundred bytes each way, every time — versus the lopsided, variable sizes of real web browsing where responses dwarf requests. The destination is often a young or low-reputation domain with little legitimate traffic, not a CDN every other host also talks to. And a long-lived beacon produces a high connection count to a single rare destination over hours, which stands out the moment you aggregate NetFlow by destination. None of these is conclusive alone; together they are how the channel gets caught.

Evasion and its own tells: jitter, domain fronting, DNS tunneling

Operators know the rhythm is the giveaway, so they blunt it. The first move is jitter: randomize the sleep interval by some percentage so the period is not exactly 60 seconds but 45–75. This smears the inter-arrival peak, but it does not erase it — over hours, the mean still clusters, and detection that bins inter-arrival times with tolerance for jitter still finds the central tendency that random human traffic never has. Jitter buys time; it does not make the beacon look human.

When 443 to a strange domain is itself the problem, operators reach for channels that hide where the traffic goes. Domain fronting sends the TLS SNI to a trusted CDN host while the encrypted Host header routes to the C2 origin behind the same CDN — the network sees a connection to a reputable domain. DNS tunneling is the more desperate, more detectable option: it smuggles tasking inside DNS queries and responses, because DNS resolves even on networks that block direct web egress. But DNS was built for short cacheable names, so tunneling produces long, high-entropy subdomains and an abnormal volume of unique queries to one zone — which, as the table shows, is a loud signal of its own. Every evasion trades one tell for another; the defender’s job is to know which tell each technique leaves behind.

How a defender reads it — and how that informs the operator

The detection engineer does not look for a payload; they look for a behavior. The durable hunt is: for each internal host, group outbound flows by destination, and flag destinations that are contacted on a regular cadence, with uniform small payloads, that are rare across the fleet, and young or low-reputation. That logic survives because it targets the structural fact that an implant must call home repeatedly — you can change the protocol, the domain, and the interval, but a remote operator fundamentally needs a recurring channel, and recurrence is detectable. For the authorized tester, this is the design constraint to respect: the stealthiest C2 is the one that minimizes total contacts and blends destination into the host’s normal traffic, not the one that merely encrypts the body.