Once an attacker has code running on a target, they need a way to keep talking to it: to send commands, receive output, run tools, and pivot deeper — all while blending into normal network traffic. That channel and the software that manages it is command and control (C2). Almost every real intrusion and every serious red-team operation runs on a C2 framework; understanding how one is built explains a large part of modern offensive tradecraft. This page is the general model. Sliver is one concrete implementation, and the commands live in the Toolkit.
The three moving parts
Every C2 framework, whatever its name, is built from the same three components.
| Component | What it is |
|---|---|
| Team server (C2 server) | The attacker-controlled server that holds operation state, issues tasks, and receives results. Often supports multiple operators at once (multiplayer) |
| Implant / agent | The code running on the compromised host that calls back to the server, executes tasks, and returns output. Also called a beacon, payload, or RAT |
| Listener | The server-side endpoint the implant connects to, speaking a specific egress protocol (HTTPS, DNS, mTLS, …) on a specific port |
The whole design is inverted from a normal remote-access tool: the implant dials out to the server rather than the server connecting in. Outbound connections from a workstation to the internet are ordinary and rarely blocked, so the implant hides in that expected flow — which is why C2 is so hard to stop at the perimeter.
Beacons versus interactive sessions
The single most important design choice is how often the implant talks to the server, and it produces two modes that every operator switches between.
| Mode | Behaviour |
|---|---|
| Beacon (asynchronous) | The implant sleeps, then wakes on an interval (the sleep, often with random jitter), asks the server for queued tasks, runs them, returns output, and sleeps again. Low, bursty traffic that looks like periodic web requests — quiet and hard to spot |
| Interactive session | A live, low-latency connection where commands and output flow in real time. Convenient for fast work (a shell, a socks proxy) but chatty and far easier to detect |
Good operations spend most of their time in beacon mode with a long sleep for stealth and switch to an interactive session only for short, deliberate bursts of hands-on-keyboard work. The trade-off — stealth versus latency — is the rhythm of the whole engagement.
Egress channels
The implant has to reach the server across whatever egress the network allows, so mature frameworks speak several protocols and let the operator pick per environment.
| Channel | Why you'd choose it |
|---|---|
| HTTP(S) | The default almost everywhere — blends with normal web browsing, survives proxies, and the TLS wrapper hides the payload. Often shaped to imitate a real site's traffic (a malleable or procedurally generated profile) |
| DNS | Extremely slow but nearly always allowed out; a last-resort channel that works when everything else is filtered |
| mTLS | Mutually-authenticated TLS — strong encryption and both ends verified, good where raw sockets are permitted |
| WireGuard / raw TCP | Efficient tunnels for internal use, typically behind a foothold rather than facing the internet |
Staging: how the implant gets there
A payload can be delivered whole or in two steps, and the choice affects both size and detectability.
| Type | Detail |
|---|---|
| Stageless | The full implant is delivered in one artifact. Larger, but a single self-contained file with no follow-up network fetch to flag |
| Staged | A tiny first-stage stager lands first, then pulls the full implant from the server over the C2 channel. Small initial footprint, but the second fetch is an extra detection opportunity |
Redirectors and infrastructure
Operators almost never point implants straight at the team server. Traffic is bounced through redirectors — cheap proxy hosts (or CDN/domain-fronting) that forward C2 traffic to the real server. If a redirector is burned and blocked, the team server and the operation survive; only a disposable relay is lost. This separation of the public-facing relay from the sensitive backend is standard attack-infrastructure hygiene.
In segmented networks the same idea goes inward: only one foothold host talks to the internet, and every other compromised machine tunnels its C2 through that foothold over an internal protocol (a pivot). One egress point, many internal agents — smaller network footprint and one place to shape the traffic.
Sleep, jitter, and the beaconing signature
A beacon's sleep is the interval it waits between check-ins; jitter is a random percentage added to or subtracted from that interval so callbacks don't land on a perfect metronome. This one setting is the crux of the whole stealth-versus-latency trade-off, and it is worth understanding why defenders can still find a beacon even with jitter turned up.
Network analytics treat beaconing as a signal-processing problem. Take the set of connection timestamps from one internal host to one external destination and compute the intervals between them. A human browsing the web produces intervals that are wildly irregular and bursty; a beacon — even with 50% jitter — produces intervals that cluster around a mean. Run those intervals through autocorrelation or an FFT and a periodic component stands out from the noise. Jitter widens the distribution but does not remove the central tendency, so a long enough capture still reveals the period. This is why the defensive research literature talks about beacon hunting in terms of variance, the coefficient of variation, and Fourier peaks rather than fixed thresholds.
The operator's counter is to make the sleep long (hours, not seconds), push jitter high, and keep the total number of callbacks small — fewer data points make the statistics weaker. Some frameworks add a working-hours constraint so the beacon only calls back during the target's business day, hiding inside the times when real user traffic is densest.
Sleep masking: hiding in memory between check-ins
A beacon spends almost all of its life asleep, and for most of that time its implant sits in the memory of some host process. That resident image is the single richest source of host evidence: an EDR or a memory scanner can walk process memory looking for the framework's decrypted strings, its configuration block, or the RWX regions typical of injected code. A beacon that leaves itself in the clear while sleeping is easy to catch with a periodic scan, regardless of how good its network profile is.
Mature implants answer this with sleep masking: just before sleeping, the implant encrypts its own image and configuration in place and restores normal page permissions, then decrypts itself again on wake. For the entire dormant window there is nothing in memory that pattern-matches a known tool — the interesting bytes only exist for the brief moment the beacon is actually running a task. Some implementations go further and use a legitimate timer or APC callback to trigger the encrypt/decrypt so that even the act of sleeping doesn't look like a tight custom loop. The research point is that C2 detection is a contest across two surfaces at once — the network channel and the resident memory image — and a serious framework has to defeat both, not just the one that's easier to reason about.
Traffic shaping: malleable and procedural profiles
The default HTTP a framework emits — its URIs, headers, User-Agent, cookie format, and response bodies — is a fingerprint. Threat-intel feeds publish those defaults, and a proxy or IDS can match on them even when the payload inside is encrypted. So the second half of a good egress channel isn't the encryption, it's making the request and response look like something ordinary.
Two approaches dominate. A malleable profile is an operator-written template that dictates exactly how the traffic is dressed: which URI paths to use, what headers to send, how to encode the task data (base64 in a cookie, wrapped in what looks like a JSON API response, appended to a fake image), and how to imitate a specific real application's traffic. A procedural / randomised profile instead generates plausible-looking traffic on the fly so no two implants share a static template. Either way, the encrypted C2 data is smuggled inside a request/response that a casual look — and many automated classifiers — will read as normal web activity. Detection then has to fall back to the behavioural signals below rather than a clean content match.
Peer-to-peer topologies: pivots and mesh
Not every implant talks to the internet. In a segmented network only a handful of hosts can egress at all, so frameworks support peer-to-peer links where one implant relays another's C2 over an internal protocol — most commonly an SMB named pipe or a raw TCP connection between two compromised machines. An internal host beacons to a foothold; the foothold forwards that traffic out over the real egress channel. To the network, the internal machine never contacts anything unusual — it only speaks to another domain-joined host over a port (445 for SMB) that is expected to be busy.
This produces a tree or mesh of implants with a single egress point at the root, which has three OPSEC benefits: one place to shape and monitor egress traffic, a much smaller external footprint, and resilience — if a leaf is caught, the branch above it survives. The cost is fragility in the chain: kill an intermediate node and everything behind it goes dark until the operator re-links. Named-pipe links are especially valued because inter-process and inter-host pipe traffic is a normal part of Windows operation, so the C2 hides inside expected IPC rather than standing up a new listening port.
Why defenders still catch C2
The channel is designed to blend in, so detection shifts to behaviour and pattern:
- Beaconing regularity — even with jitter, a callback every N seconds to the same destination is a statistical signature network analytics hunt for.
- JA3/TLS and header fingerprints — a framework's default TLS stack or HTTP headers can be recognised even inside encryption.
- Host-side telemetry — process injection, unusual parent/child process trees, and in-memory .NET execution generate endpoint signals regardless of how clean the network looks (see Windows telemetry and in-memory tradecraft).
- Known indicators — default certificates, ports, URIs, and named-pipe names ship with every framework and are widely signatured until the operator changes them.
The takeaway
A C2 framework is a team server, an implant that dials out to it, and a listener that speaks a chosen egress protocol — with the beacon/session trade-off setting the tempo and redirectors and pivots shaping the infrastructure. Every operator decision is really the same decision in different clothes: how much noise to make for how much control. The concrete mechanics of one modern framework are on the Sliver C2 page, and its full command reference is in the Toolkit.