← Glossary

Techniques & Tradecraft

C2 (Command and Control)

Also: command and control · C&C · beaconing · C2 server · C2 framework

Last reviewed:

In one sentence

C2 (Command and Control) is the channel an attacker uses to remotely control compromised hosts — send commands, pull data, push new tools — after the initial compromise.

Why it matters

Almost every meaningful intrusion needs a working C2 channel, which makes it one of the highest-value places to detect an attacker: block or spot the C2 traffic and the attacker loses control of the foothold, regardless of how they got in. It is also one of the fourteen tactics in the ATT&CK Enterprise matrix, with its own set of techniques — DNS tunnelling, web protocols disguised as normal traffic, legitimate cloud services (Slack, Discord, Google Drive, GitHub) used as the relay so the destination looks harmless.

The implant side is usually a commercial or open-source C2 framework — Cobalt Strike, Sliver, Mythic, Havoc — whose default profiles are well fingerprinted, which is why serious actors customise them ("malleable" profiles) to imitate ordinary applications.

How it is usually spotted

Most C2 traffic is designed to look like something ordinary — HTTPS to a plausible-looking domain, DNS queries that resemble CDN traffic. What tends to give it away is pattern, not payload:

  • Beaconing: check-ins at a regular interval (every 60 s, every 5 min) with small, similar-sized requests, often with a little random "jitter" added precisely to defeat naive interval detection. Long-tail analysis of connections per host per destination finds it.
  • Destination reputation and age: a domain registered days ago, a bare IP over TLS, an unusual ASN for the organisation, a certificate with default or self-signed fields.
  • Protocol anomalies: DNS queries with long, high-entropy subdomains (tunnelling), HTTP with a mismatched or rare user agent, TLS fingerprints (JA3/JA4) that match a known framework.
  • Volume asymmetry: a workstation that uploads far more than it downloads to one host is exfiltrating over the C2 channel (T1041).

Try it yourself hands-on

You have found a host beaconing to cdn-assets-sync.example every 60 seconds over HTTPS.

  1. Look up the tactic in the MITRE ATT&CK Search: filter by the Command and Control chip. T1071 Application Layer Protocol covers this; its sub-technique list has .001 Web Protocols for HTTPS beaconing and .004 DNS if the check-ins turn out to be DNS queries. T1572 Protocol Tunneling and T1105 Ingress Tool Transfer are the neighbours to check next.
  2. Characterise the domain: the DNS Record Lookup shows where it resolves and how short its TTLs are (fast-flux infrastructure rotates quickly); a low-TTL A record pointing at a hosting range with no MX and no history is the typical C2 shape.
  3. Before sharing the domain in a ticket, chat or an external report, run it through the IOC Defangercdn-assets-sync[.]example — so it cannot be clicked or auto-linked by chat tooling and previewed by a bot, which would itself be a beacon.
  4. Record the technique ID next to the defanged indicator, and the host, in the IOC Pivoting Tool. The pairing — what it is (T1071.001) plus what to key detection on (the beacon pattern, the domain) — is what makes the finding reusable by someone on a different tool.

Common misreadings

  • Blocking the domain is not the end. Frameworks fall back to secondary channels; treat a blocked C2 as the start of containment, not proof of eradication.
  • Legitimate software beacons too. Update checkers, telemetry and chat clients all poll on intervals. The signal is beaconing to an unknown destination from a host that should not need it.
  • Do not interact with it. Browsing to a suspected C2 URL from a corporate machine tells the operator you found them and hands them another IP.