C2 Server (Command and Control)

A C2 server (command and control server, also written C&C) is the infrastructure an attacker uses to communicate with and control malware on compromised machines. A small program on each infected host, the beacon, checks in for instructions and sends stolen data back out. Deny that channel, and the attacker loses control of everything they have compromised.

That last point is why C2 matters more than most single indicators. Malware sitting on a machine with no way to reach its operator is largely inert. The command and control channel is what turns a foothold into an active intrusion, and one of the most valuable things a defender can learn to detect.

This page explains what a C2 server is, how the beacon loop works, how C2 differs from a botnet and a RAT, the real frameworks you will meet in reports, and how defenders detect command and control traffic in practice.

Explain It Like I'm 10

Think of a spy who has slipped into a building. The spy is no use to their handler until they can pass messages out, so every so often they step outside and quietly phone home: "Anything for me?" The handler gives orders and takes whatever the spy has copied. The handler never enters the building; the spy always calls out, blending in with all the other phone calls so nobody notices. A C2 server is that handler. Cut the phone line and the handler is stuck with a spy they can no longer reach.

What a C2 server actually does: the beacon loop

The most important thing to understand about command and control is the direction of the connection. The malware sits on the victim's machine and calls out to the attacker's C2 server. The server does not reach into the network to find the victim. This matters because most networks allow outbound connections freely while blocking unsolicited inbound ones, so calling out is the path of least resistance.

The beacon: check-in and jitter

The program doing the calling is usually referred to as a beacon. It runs on the compromised host and periodically checks in with the C2 server to receive commands, which is why a single implant can quietly do a great deal over time: Huntress describes the Beacon in the widely used Cobalt Strike framework as a component that "periodically checks in with the attacker's Team Server to receive commands - stealing passwords, logging keystrokes, taking screenshots, or deploying ransomware across the network."

That word "periodically" is doing a lot of work. In Cobalt Strike's Beacon, the check-in interval is sixty seconds by default. Left exactly that regular, the traffic would be trivial to spot, so operators add jitter - a randomized variance on the interval. The tool's own documentation gives the example sleep 300 20, which makes the beacon "sleep for a random value between 240s to 300s after each check-in." The result is a connection that looks less like a metronome and more like ordinary, irregular activity.

Whose machine is at risk?

Here is a point that trips up even engaged learners. In one public thread asking someone to explain C2, a reader worried that if the malicious code sits on the victim's PC, the exposed data is "risky to the botmaster." It is worth being precise: the implant on the victim's machine is the victim's exposure, not the attacker's risk. The attacker's server stays comfortably remote. The beacon does the work of reaching out, and the operator only ever handles the connections that come to them.

C2 vs botnet vs RAT: what's the difference?

These three terms get used interchangeably, and they should not be. They describe three different things.

Put simply: the RAT is the tool on the host, C2 is the channel it talks over, and a botnet is what you get when one operator runs that channel across thousands of machines at once. MITRE ATT&CK tracks the remote-access-tool category as its own technique (T1219, recently renamed from "Remote Access Software" to Remote Access Tools). All three concepts share the same backbone, which is the command and control channel, and that shared dependency is exactly what makes C2 such a useful thing to detect.

The frameworks you'll actually meet: Cobalt Strike, Sliver, Mythic

Command and control is not improvised from scratch for every intrusion. Operators use frameworks, and a handful come up again and again in reporting.

Cobalt Strike is the one you will see most. MITRE ATT&CK describes it as "a commercial, full-featured, remote access tool that bills itself as 'adversary simulation software designed to execute targeted attacks and emulate the post-exploitation actions of advanced threat actors,'" and notes it "leverages the capabilities of other well-known tools such as Metasploit and Mimikatz." It is a legitimate red-team product, sold by Fortra and licensed to security teams.

Cracked copies and the 2023 takedown

The complication is that cracked copies became a favored criminal tool. In 2023, Microsoft, Fortra, and Health-ISAC obtained a court order to disrupt the infrastructure behind illegal copies, which the plaintiffs linked to "more than 68 ransomware attacks impacting healthcare organizations in more than 19 countries." So the same tool sits on both sides of the line, which is worth remembering whenever you see it named in an incident report.

Cobalt Strike still dominates observed C2 tooling, though not as completely as it once did. In its review of 2025 malicious infrastructure, Recorded Future found that Cobalt Strike "retained clear dominance in OST detections (~50%) despite declining share," with Sliver and Mythic among the alternatives holding their ground. Sliver, from Bishop Fox, is "an open source cross-platform adversary emulation/red team framework." Mythic is a cross-platform, modular red-team framework. Both are open source, both are legitimately used by red teams, and both have been adopted by some threat actors as Cobalt Strike alternatives.

Why C2 is so hard to catch: the channels

If these tools and their servers are known, why is C2 not simply blocked? Because good command and control is designed to look like traffic you cannot afford to block. MITRE's one-line framing of the tactic is that adversaries "commonly attempt to mimic normal, expected traffic to avoid detection."

They mimic it through the channels they choose:

• Encrypted web traffic. Most modern C2 rides HTTPS, so the payloads are unreadable in transit and the connections blend in with ordinary web browsing. ATT&CK catalogs this as the Encrypted Channel technique.
• DNS. DNS is rarely blocked and often allowed before a device has even authenticated, and low-volume DNS beacons hide inside normal DNS noise. (This is the basis of DNS tunneling, a large enough topic to deserve its own page.)
• Domain fronting. An attacker can route C2 through a trusted CDN by putting one domain in the TLS SNI field and a different one in the HTTP host header, so a network defender sees only the reputable front domain.
• Legitimate services. Slack, Discord, Telegram, GitHub, and cloud storage can all be used to relay commands, because traffic to a trusted platform draws no attention.

That last category is not theoretical. In 2026, security reporting on an FBI advisory described Iran-linked actors who "configured a command and control (C2) using a Telegram bot, allowing bidirectional communication between the compromised device and api.telegram[.]org." To a firewall, that is just a connection to Telegram.

There is one more reason simple blocking fails. Attackers can generate destination domains on the fly using a domain generation algorithm, so blocking a static IP or domain today does little tomorrow. That is why the lowest, cheapest indicators are the ones adversaries replace without breaking stride, and why detection has to reach higher.

How defenders actually detect C2

The durable answer is to detect the behavior rather than the individual indicator. A rotating IP is cheap to change; the way a beacon behaves is not.

Beacon timing and size analysis

The regularity that jitter tries to hide is still statistically visible. As Elastic's security research puts it, beaconing "has some unique traits with respect to timing and packet size," and "a key attribute of beaconing traffic is it often has similar netflow bytes for the majority of its communication." Defenders model the distribution of connection intervals and sizes rather than looking for a fixed period. Open-source tooling exists for exactly this: RITA, from Active Countermeasures, is a network-traffic-analysis framework whose features include hunting for "signs of beaconing behavior in and out of your network."

TLS fingerprinting

Because so much C2 is encrypted, defenders fingerprint the encrypted handshake itself. JA3 fingerprints the TLS client, and as its authors note, "it doesn't matter if malware uses DGA (Domain Generation Algorithms), or different IPs for each C2 host" - the client fingerprint stays recognizable. JA3S extends the idea to the server's response, and JARM actively fingerprints servers to "identify malware command and control infrastructure and other malicious servers on the Internet."

No silver bullet

It is important to be honest about what these techniques buy you. Fingerprinting gives, in the authors' own words, "reasonable confidence," not proof. JA3 itself is no longer actively maintained and has been superseded by newer methods like JA4, and fingerprints can be changed. Detection here raises the attacker's cost and the odds you catch them; it is not a signature that guarantees a hit. That is the case for detecting at the level of behavior and technique, where MITRE ATT&CK - "a globally-accessible knowledge base of adversary tactics and techniques based on real-world observations" - gives defenders a shared map. Behavior outlasts the indicators an attacker can swap in an afternoon.

What happens once C2 is live

The reason all of this matters is speed. Once command and control is established, attackers move quickly. CrowdStrike reported that the average eCrime breakout time - how long before an intruder starts moving to other systems - "fell to just 29 minutes in 2025, with the fastest observed breakout occurring in only 27 seconds." What follows the beacon is a familiar playbook. The CISA advisory on Volt Typhoon describes actors who:

• obtain administrator credentials
• "use valid administrator credentials to move laterally to the domain controller"
• establish persistent access
• rely on living-off-the-land techniques
• perform "targeted log deletion to conceal their actions"

So the takeaway is the one to carry into your next alert. A C2 server is the attacker's control channel, and you cannot reliably block your way out of the problem one indicator at a time. Understand the beacon loop, watch for the behavior, and treat the command and control channel as the thing worth cutting. If you want to go deeper on one of the hardest channels to catch, C2 over DNS - DNS tunneling - is the natural next step.