Glossary

#C2 #incident response #threat intelligence #detection

What is C2 (command and control): the channel attackers use to control a device after a breach

C2 (command and control) is the channel a compromised device uses to call back to an attacker's server. The beaconing that flags it, and egress monitoring.

Published 2026-06-11 Updated 2026-10-06 7 min read

On this page

C2 is the traffic an attacker uses to keep controlling a device after a breach. Here's how it works and how to spot and stop it (no attack tooling or operation details).

Where it sits in the attack flow

C2 isn't the breach itself — it comes after it.

1) Breach (e.g. RCE, phishing, malware)

↓

2) The device 'calls back' to the attacker's server (a beacon = periodic heartbeat)

↓

3) Receive commands / exfiltrate data (remote control)

After the breach, the device calls back to the attacker's server (C2). That's the chance to detect and cut it.

The important point: the outbound traffic in (2) is the chance to detect and cut. Preventing a breach 100% is hard, but there's room to notice and stop it at the outbound-traffic stage.

C2 vs backdoor vs botnet

These terms get mixed up. Split by role, they look like this.

Term	What it means	Relation to C2
C2 (C&C)	The remote-control channel between an attacker and a compromised device, and the server that sends commands	—
Backdoor	An entry point left on a device that bypasses normal authentication	Often talks to C2 to receive commands
Botnet	A large group of hijacked devices that take commands from the same C2 at once	C2 controls many devices from one place
RCE	A vulnerability that lets someone run arbitrary code remotely	One way to get the breach that comes before C2
Beacon	A short message a device sends to C2 at regular intervals	A sign that C2 is still active

Why it blends in with normal traffic

MITRE ATT&CK, which catalogs attacker techniques, treats C2 as its own stage (TA0011): the adversary trying to communicate with compromised systems to control them. A typical technique it lists is using everyday protocols such as web and DNS traffic to blend in with existing traffic and avoid detection and filtering.

That's why blocking specific port numbers isn't enough. The mitigations ATT&CK lists are filtering network traffic and network intrusion prevention. In practice, two ideas work:

Limit by destination: decide which destinations a server may reach with an allowlist, and block other outbound traffic
Notice by shape: look not at the content but at destination, interval, volume and which program is talking

How to spot it (clues)

Clue	What to look at
Beaconing (periodic traffic)	Regular outbound traffic to the same destination at intervals
Unfamiliar destinations	Suspicious domains/IPs (match against known-bad = IOCs)
Odd DNS	Queries to unfamiliar domains; abnormally heavy DNS
Unexpected paths	Outbound traffic over unexpected ports/protocols

How to defend

Don't get breached in the first place (the basics)

Patching (CVE monitoring), least privilege, MFA, no plaintext secrets. C2 is the 'after-breach' stage, so the better you prevent breaches, the less often C2 comes into play.

Restrict outbound traffic (egress)

Limit servers' and devices' outbound traffic to only the destinations/ports needed (egress filtering). Even if breached, C2 struggles when the device can't call out.

Monitor DNS and traffic logs

Reach a state where you can notice suspicious periodic traffic, unfamiliar destinations, and abnormal DNS (→ IOA = notice by behavior).

Match and block known-bad destinations

Cross-check known C2 destinations (IOCs) from threat feeds against your traffic logs and firewall, and block.

Real example: when outbound traffic was the clue

In the Codecov compromise (2021) covered on this site, a distributed script run in CI was tampered with, and secrets were reportedly sent from customers' CI environments to an outside server for about two months. Because the tampered code wasn't the customers' own, reviewing their code wouldn't have caught it.

The clue that can be checked afterwards is outbound traffic from CI to an unfamiliar destination. If CI's outbound traffic had been limited to the destinations it needed, with everything else logged, there was room to block the sending or notice it sooner. Whether it's C2 or data theft, a post-breach attack has to talk to the outside to achieve its goal.

How to check in your own environment

List current outbound connections: on Windows, Get-NetTCPConnection -State Established shows each destination and its OwningProcess (the ID of the program talking), and Get-Process -Id <ID> gives the program's name. On Linux, ss -tunp does the same
Review cloud outbound rules: for example, AWS's default security group allows all outbound traffic. Write down what your server really needs to reach (OS updates, payment or email APIs, and so on) and restrict the rest
Check DNS query history: in your router's or DNS service's logs, look for queries to unfamiliar domains repeating at regular intervals
Count by destination: aggregate proxy or firewall logs per destination and look for small amounts of traffic at the same interval all day. When you find one, check who owns the destination to tell whether it's a legitimate update check
Match against published destinations: search your logs for C2 destinations (IOCs) published by authorities or vendors

This site's view: protect outbound traffic too, and confirming 'no C2' is part of the investigation

The biggest lesson the C2 concept brings is that defense isn't only about preventing the breach. Even when perfect prevention is hard, there's room to restrict outbound traffic and notice suspicious callbacks. On this site we keep "a design that doesn't get breached (patching, least privilege, MFA)" as the main goal, while also holding egress control and traffic monitoring as a final layer. Note that when a breach is suspected, confirming there's no resident C2 (a backdoor or rogue periodic traffic) is a key step. To conclude "the impact was limited," you can't skip checking outbound traffic.

Sources (primary)

MITRE ATT&CK, "Command and Control (TA0011)" — attack.mitre.org (definition of the C2 stage)
MITRE ATT&CK, "Application Layer Protocol (T1071)" — attack.mitre.org (blending into existing traffic, and mitigations such as traffic filtering)
AWS, "Default security groups for your VPCs" — docs.aws.amazon.com (default outbound rules)
Sources for Codecov are listed in the case article

Classification

CWE classifies the types of weakness behind vulnerabilities; MITRE ATT&CK classifies attacker techniques. Both are maintained by MITRE and widely used to label vulnerability reports and detection rules.

ATT&CK (attack technique)

TA0011Command and Control

© 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. The MITRE Corporation (MITRE) hereby grants you a non-exclusive, royalty-free license to use ATT&CK® for research, development, and commercial purposes. Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ATT&CK Terms of Use

FAQ

QWhat is C2 (command and control)?

It's the remote-control channel a compromised device (a PC/server infected with malware or taken over via a vulnerability) uses to 'call back' to an attacker's server — to receive commands and send out stolen data. In the flow of an attack, it's the stage after a breach (e.g. RCE) succeeds, used to keep controlling the device.

QHow can C2 be spotted?

The main clue is outbound traffic. An infected device often sends a periodic 'heartbeat' (a beacon) to the attacker's server at regular intervals. Regular periodic traffic to an unusual destination, DNS queries to unfamiliar domains, and outbound traffic over unexpected ports/protocols are clues. You can catch these via traces (IOCs) or behavior (IOAs).

QWhat are the basics of defending against C2?

(1) Don't get breached in the first place (patching, least privilege, MFA); (2) restrict outbound traffic ('egress filtering'); (3) monitor DNS and traffic logs to notice suspicious periodic traffic or destinations; (4) match known-bad C2 destinations (IOCs) from threat feeds and block them. The key idea: an attack can be stopped not only at the point of entry but also at the outbound-traffic stage.

QWhat's the difference between C2 and C&C?

They mean the same thing. C&C (Command and Control) is the older abbreviation; C2 is more common today. A 'C&C server' and a 'C2 server' are both the attacker-side server that sends commands to compromised devices.

QWhat is a C2 beacon?

A short message a compromised device sends to the C2 server at regular intervals, to report that it's still running and to check for new commands. Its signature is small amounts of traffic to the same destination on a regular schedule, so sorting traffic logs by destination can reveal it. Legitimate traffic such as software update checks looks the same, so confirm what the destination is before deciding.

QCan you detect C2 traffic that's encrypted with HTTPS?

Even without seeing the content, clues remain: which destination, at what interval, how much data, and which program on the device is sending it. Unfamiliar domains, regular intervals and network traffic from programs that shouldn't use the network are all visible even when encrypted. And if outbound traffic is limited to the destinations you need, the traffic is stopped regardless of encryption.