Command and Control: Beaconing, Channels & Detection

An attacker who lands code on one machine has a problem: that machine is behind a firewall they do not control, and they need to steer it. Command and control, usually shortened to C2, is how they solve it. The implant on the victim reaches back out to infrastructure the attacker runs, and from there the operator can issue commands, pull files, and pivot deeper.

Almost every hands-on intrusion passes through this stage. Ransomware crews, espionage groups, and commodity botnets all need a channel back to their operators. Understanding how that channel is built and why it is shaped the way it is tells a defender exactly where to look.

On the MITRE ATT&CK matrix, Command and Control (TA0011) is a whole tactic, sitting between the attacker gaining execution and achieving their final goal. It is the connective tissue of an operation. Cut it and the implant on the victim goes deaf: it cannot receive new commands, cannot be tasked to spread, and cannot ship data out. That leverage is what makes C2 such a rewarding place to invest detection effort. A defender who reliably finds callbacks catches intrusions in the window between the first foothold and the damage.

Why implants call out instead of listening

The instinctive picture of remote control is the attacker connecting inward to the victim. In practice it is the reverse. Corporate firewalls block most unsolicited inbound connections, but they allow machines to make outbound connections all day, because that is how the internet works for users.

So the implant initiates. It reaches out from inside the network to the controller, and the controller answers on that already-open connection. The firewall sees a workstation browsing the web, which is unremarkable. This outbound-first design is the foundation of nearly all modern C2, and it is why egress, the traffic leaving your network, is where the action is.

Beaconing and its rhythm

The most common pattern is the beacon. On a set interval the implant calls home, asks whether there is any work, executes whatever it receives, and returns the result. Then it sleeps until the next callback.

That schedule is the beacon's defining trait and its weakness. Automated callbacks produce a regularity no human browsing generates: connections to the same destination at steady intervals, often with small, similar request sizes. To fight this, operators add jitter, randomizing the interval by a percentage so the rhythm looks less mechanical. They also lengthen the sleep, so an implant might beacon once an hour rather than once a minute, trading responsiveness for stealth.

Even with jitter, beaconing leaves a statistical footprint. Over hours or days, the regularity reasserts itself in aggregate, which is the basis for most C2 detection.

Not all C2 beacons on a fixed schedule. Some operators prefer interactive sessions, where the implant holds a connection open for real-time control, and others use triggered callbacks that fire only on an event, like a user logging in. Interactive C2 is faster for the attacker but noisier, since a long-lived connection to an odd destination stands out. Triggered C2 is stealthier but slower. Most real operations blend modes: a low, slow beacon to stay resident, switched to interactive control only during the short windows when the operator is actively working the intrusion.

The channels attackers use

A channel is the protocol the beacon rides on. The choice is driven by one goal: blend into traffic the network already permits. The behaviour maps to Application Layer Protocol (T1071) and its sub-techniques.

Channel	Why attackers pick it	Detection angle	ATT&CK
HTTPS / web	Ubiquitous, encrypted, rarely blocked	Beacon timing, TLS fingerprints, odd user agents and destinations	T1071.001
DNS	Almost always allowed outbound, easy to overlook	High query volume, long or random subdomains, rare record types	T1071.004
Web services / social media	Traffic to trusted domains looks benign	Automation patterns to services the host does not normally use	T1102
Custom or non-standard ports	Simple to stand up	Protocol on the wrong port, unusual raw connections	T1095

HTTPS is the default for most frameworks. The payload hides inside encrypted web requests, and to inspection it looks like browsing. DNS is a favourite fallback because even locked-down networks usually let DNS resolve, so data can be smuggled inside queries and responses, a technique explored in more depth in DNS tunneling. Web-service C2 takes it further by using a legitimate platform as the dead drop: the implant reads commands from an account or page on a trusted site, so the traffic goes to a domain no firewall would block.

Redirectors and hiding the real server

Operators rarely point implants straight at their controller. That would expose the server and make takedown easy. Instead they place redirectors in front: lightweight relays that forward beacon traffic to the hidden backend. The victim only ever talks to the redirector, so defenders who block or seize it still do not see the real infrastructure.

Domain fronting and its successors push this further, routing traffic through large shared platforms so the visible destination is a reputable domain while the true endpoint is hidden. The result is C2 that appears to be talking to trusted infrastructure. This is also why our Threat Groups directory tracks the infrastructure and tooling different actors favour, because the shape of the C2 is often one of the more durable fingerprints a group leaves.

Redirectors also let an operator rotate infrastructure cheaply. If defenders identify and block one relay, the operator stands up another and repoints it at the same hidden backend, and the implants keep working through whichever relay is live. This is why blocking a single indicator, one domain or one address, rarely ends an intrusion. The controller behind it is untouched, and the campaign simply moves. Durable defense has to target the behaviour of the beacon itself rather than the specific address it happens to be calling this week.

Encryption does not hide the pattern

Wrapping C2 in TLS conceals the contents of each request but not the metadata around it. The destination, the timing, the frequency, and the size of connections are all still visible. Beacon detection leans on exactly that metadata, which is why encrypted channels remain findable without ever decrypting a single payload.

How C2 techniques evolved

The arc of C2 is a long game of blending in. Early remote-access tools often listened for inbound connections or used custom protocols on odd ports, which made them easy to block once defenders knew the port. As perimeter firewalls became universal and default-denied inbound traffic, operators flipped the model to outbound-first beaconing, riding the connections that firewalls have to allow for users to work.

The next move was into the protocols that are always permitted. HTTP and then HTTPS became the default carrier because web traffic is ubiquitous and, once encrypted, its contents are opaque to inspection. Operators added redirectors to protect their real infrastructure and reached for shared platforms so the visible destination looked reputable. When defenders learned to inspect web egress, DNS became the reliable fallback, since it resolves out of nearly every network and is frequently unwatched. More recently, using legitimate web services as dead drops pushed the trend to its logical end: the implant talks only to domains no firewall would dream of blocking.

Detection evolved in step. Signature matching on payloads gave way to metadata analysis, because encryption removed the payload from view but left the timing, volume, and destination exposed. The durable insight, and the reason this stage rewards defensive investment, is that a channel has to cross the boundary and repeat over time no matter how it is dressed, and repetition across a boundary is measurable.

The stages of a C2 session

A C2 channel is not a single event. It runs through a sequence, and knowing the sequence tells a defender which artifacts to expect at each point.

Staging and initial check-in. The first payload to land is often a small loader whose only job is to fetch and run the real implant, either from the controller or from a public host chosen to look benign. The moment the implant first calls home is the initial check-in, and it usually carries a compact fingerprint of the victim: hostname, user, operating system, and privilege level. That first callback is a high-value detection point, because it happens before any damage and it establishes the destination the implant will keep returning to.

Tasking. With the foothold confirmed, the operator queues work. On each beacon the implant asks for tasking, receives zero or more commands, executes them, and returns the output on the next callback. Tasking is where the operation becomes interactive: enumerate the network, dump credentials, upload a tool, run it. The request-and-response rhythm of tasking is what produces the steady callback pattern that timing analysis keys on.

Result return and exfiltration. Command output and stolen data flow back over the same channel or a separate one the operator designates. Exfiltration is often deliberately throttled and spread over time so it never spikes into a volume alarm. A defender watching only for large outbound transfers misses data that leaves in a slow trickle disguised as ordinary requests.

Channel failover. Robust implants carry more than one way home. If the primary HTTPS channel is blocked, the implant falls back to DNS or to a web-service dead drop. This is why blocking one destination rarely ends an intrusion: the implant simply switches to a channel the defender did not close.

A worked example: reading a beacon in the logs

Imagine a workstation that, once an hour, makes an HTTPS request to the same host, and each request and response is roughly the same small size. On any single day it looks like an application checking for updates. Pull a week of connection logs and the pattern sharpens: the callbacks are too regular, they persist overnight when the user is away, and the destination is a domain no other host in the environment contacts and that was registered only weeks ago.

Now layer the endpoint. The process making those requests is not a browser and not a known updater. It is a signed system utility that has no business making periodic web requests to an unknown domain, or an unfamiliar process running from a user-writable directory. Neither the network pattern nor the process on its own is proof. Together they describe a beacon: automated timing, an anomalous destination, and a process with no legitimate reason to be talking to it. That correlation, weak signals from two vantage points lining up on the same host and the same minutes, is the core of practical C2 detection, and it is why mature teams join network and endpoint telemetry rather than watching either alone.

Why jitter does not defeat timing analysis

Adding jitter randomises the gap between callbacks so no two intervals match exactly, which defeats a naive rule that looks for a fixed period. Over enough samples the central tendency still shows: the average interval, the narrow spread of request sizes, and the persistence across idle hours all survive jitter. Timing analysis that works on distributions rather than exact periods sees through it.

How to detect and defend

C2 detection is a network-and-endpoint problem, and the payload is usually the least useful thing to chase. Focus on where traffic goes and how it behaves.

Control egress. Force outbound web traffic through a proxy, restrict which hosts can talk directly to the internet, and default-deny unusual ports. Every path you close removes a channel option.
Inspect DNS. Log and analyze DNS at the resolver. Watch for a single host making a high volume of queries, long or high-entropy subdomains, and unusual record types. DNS is the channel defenders most often forget to watch.
Hunt for beacon timing. Analyze connection logs for regular, repeated callbacks to the same destination, accounting for jitter. Tools and queries that measure inter-arrival regularity surface beacons that individually look harmless.
Fingerprint the client. TLS fingerprints and user-agent strings that do not match the browsers actually installed on a host point at a non-browser process making web requests.
Reputation and novelty. Newly registered domains, destinations no other host contacts, and connections to services a user has never used before are all worth flagging.
Correlate with the endpoint. Tie suspicious network patterns back to the process making them. A signed system utility or an unexpected process beaconing out is a strong lead, and it connects network detection to the host-level story.

Baseline what normal callbacks look like

Legitimate software beacons too: update checks, telemetry, and cloud sync all phone home on schedules. Build a baseline of the regular outbound talkers on your network so real C2 stands out against them, rather than drowning in benign automation. The anomaly you want is a new or unexplained beacon, not every scheduled callback.

C2 channels compared

Each channel trades stealth against reliability and bandwidth. The comparison explains why operators carry several and switch between them.

Channel	Bandwidth	Stealth	Main weakness for a defender to exploit
HTTPS / web	High	Blends into browsing	Non-browser client fingerprint, beacon timing, novel destination
DNS	Low	Rarely inspected	High query volume, long or high-entropy subdomains, odd record types
Web service / social dead drop	Low to moderate	Traffic goes to trusted domains	Automation to a service the host never normally uses
Non-standard ports / raw	Variable	Simple to stand up	Protocol on an unexpected port, connections nothing else makes
Interactive over a common port	High	Fast for the operator	Long-lived connection to an odd destination stands out

The pattern across the table is that stealthy channels tend to be low-bandwidth and slow, and fast channels tend to stand out. Operators resolve the tension by staying resident on a quiet low-and-slow beacon and switching to a faster interactive channel only during the short windows when they are actively working the intrusion. A defender who understands that split knows to watch both for the persistent quiet beacon and for the brief bursts of interactive traffic.

Common misconceptions

"If the traffic is encrypted, we cannot detect the C2." Encryption hides the contents of each request and hides nothing about the metadata around it. The destination, the timing, the frequency, and the size of connections are all still visible, and beacon detection runs entirely on that metadata. You never need to decrypt a payload to catch the rhythm.

"Blocking the malicious domain ends the intrusion." Operators front their real controller with disposable redirectors and give implants multiple channels. Block one domain and the campaign repoints to another relay or fails over to DNS. Durable defence targets the behaviour of the beacon rather than the specific address it happens to use this week.

"Only exotic malware uses C2." Almost every hands-on intrusion needs a channel home, from commodity botnets to espionage operations. C2 is a near-universal stage, which is exactly why investing detection effort there pays off across the whole threat spectrum.

"A firewall that blocks inbound connections stops C2." Modern C2 is outbound-first precisely to sidestep inbound filtering. The implant initiates the connection from inside, and the firewall sees an ordinary outbound request. Egress control and inspection, not inbound blocking, are where the leverage is.

Frequently asked questions

What is the difference between a beacon and a bot? A beacon is the callback behaviour: an implant that reaches out on a schedule to ask for tasking. A bot is a compromised machine enrolled in a larger network under one operator. A bot typically uses beaconing to receive commands, so the terms overlap, but a beacon describes the communication pattern and a bot describes the compromised host and its role.

Why is DNS such a popular C2 channel? DNS resolution is allowed out of almost every network, even locked-down ones, because normal operation depends on it, and many organisations never inspect it. That combination of near-universal egress and low scrutiny makes it an attractive fallback. Data can be smuggled inside query names and responses, which is slow but very hard to block wholesale without breaking legitimate resolution.

Can I just block all outbound traffic to stop C2? Not wholesale, because users and services need outbound access to function. The practical version is egress control: force web traffic through an inspecting proxy, restrict which hosts can talk directly to the internet, default-deny unusual ports, and inspect DNS. Every path you close removes a channel option and pushes operators toward noisier alternatives.

What is a redirector and why does it matter? A redirector is a lightweight relay placed in front of the real controller. Implants only ever talk to the redirector, which forwards their traffic to the hidden backend. It protects the operator's infrastructure from takedown and lets them rotate relays cheaply. For a defender it means the destination an implant contacts is usually disposable, so blocking it is a temporary win.

How is jitter different from the sleep interval? The sleep interval is the base time an implant waits between callbacks. Jitter is a randomised percentage added to or subtracted from that interval so the gaps are not identical each time. A longer sleep trades responsiveness for stealth, and jitter breaks up the perfectly mechanical rhythm that a naive detector would flag. Neither hides the underlying trend across many samples.

Does beacon detection produce a lot of false positives? It can, because legitimate software also beacons: update checkers, telemetry, and cloud sync all phone home on schedules. The way to keep it useful is to baseline the normal outbound talkers in your environment so that real C2 stands out against them. The anomaly you want is a new or unexplained beacon tied to a suspicious process, rather than every scheduled callback.

What is domain fronting and does it still work? Domain fronting routes C2 through a large shared platform so the visible connection appears to go to a reputable domain while the true endpoint is hidden behind it. It made C2 look like traffic to trusted infrastructure, which is very hard to block without collateral damage. Several major platforms have restricted the underlying behaviour, so its reliability has declined, but the broader idea of hiding behind trusted shared services persists in other forms.

Where in an intrusion does C2 sit? It sits between the attacker gaining execution and achieving their final goal. On the MITRE ATT&CK matrix it is a whole tactic of its own. Cut the channel and the implant goes deaf: it cannot receive new tasking, cannot be told to spread, and cannot ship data out. That position, downstream of the first foothold and upstream of the damage, is what makes it such a rewarding place to catch an intrusion early.

Command and control is the hinge of an intrusion, the point where a dormant infection becomes an operator with hands on the keyboard. Because it has to cross your network boundary and repeat over time, it is also one of the most detectable stages, if you watch the metadata instead of the payload. Own your egress, watch your DNS, and learn the rhythm of your own traffic.