Command and Control (C2) Guide: Cobalt Strike, Sliver and Beaconing

Once an intruder has code running inside your network, almost everything that follows depends on a command and control (C2) channel back to them, and that channel is usually built to look like ordinary web, DNS or cloud traffic. MITRE ATT&CK describes the Command and Control tactic (TA0011) simply: "The adversary is trying to communicate with compromised systems to control them." This guide is for SOC analysts, detection engineers, network and proxy owners and incident responders. It describes C2 techniques only at the level of ATT&CK, names common frameworks only to say what defenders can see, and spends most of its length on detection, egress control, DNS, remote access tooling and response.

Key takeaways

• C2 hides in permitted traffic. HTTPS, DNS, remote access tools and popular cloud APIs carry most C2, so blocking known-bad indicators alone will always lag behind.
• Behaviour beats indicators. Regular beaconing, rare destinations, unusual TLS fingerprints and processes that should never talk to the internet survive infrastructure changes better than IP and domain lists.
• Egress control is the cheapest prevention. Servers that cannot reach the internet directly, and endpoints that must use an authenticated proxy and a protective resolver, leave far fewer channels to watch.
• Legitimate remote access tools are C2 too. ATT&CK T1219 and CISA guidance treat unapproved RMM and remote desktop software as a control channel, so application control and an approved-tools list matter as much as network rules.
• Finding one beacon means scoping many. C2 implies hands-on access and stolen credentials, so containment covers every implant, every channel and every identity the attacker touched, at the same moment.

What command and control is in ATT&CK v20

In ATT&CK v20 the Command and Control tactic holds 18 techniques and 27 sub-techniques, grouped here by the question a defender asks. Older names still common in searches are in brackets.

Exfiltration over C2 is covered in the Data Exfiltration Guide; built-in binaries used to pull tools down are covered in the Living off the Land Guide.

C2 frameworks: what defenders should know

Many intrusions use off-the-shelf frameworks, several of which began as red team products and now also circulate among criminals as cracked copies. In Operation Morpheus (June 2024), led by the UK National Crime Agency and coordinated by Europol, 690 IP addresses hosting older, unlicensed Cobalt Strike were flagged to providers in 27 countries and 593 were taken down within the week. The table lists only what ATT&CK records and what that means for detection; it contains no configuration or usage detail.

Customisable ("malleable") traffic profiles can make C2 resemble almost any web service, so matching one published profile proves little. Authorised red teams use the same tools: keep a register of engagements and operator source addresses so the SOC can deconflict quickly.

Detecting C2: beaconing, fingerprints and DNS

Beaconing analysis

An implant typically checks in on a schedule, adds random jitter, and sends small, similar-sized requests to the same destination. Long-window analysis of flow or proxy data finds this even when the content is encrypted.

• Data sources: NetFlow or IPFIX from the egress firewall, proxy access logs, Zeek conn.log, ssl.log and dns.log, and EDR network events that tie a connection to a process and user. See the Sysmon Guide.
• Features to score (over several days): interval regularity after jitter, consistent request and response sizes, long low-volume connections, and destination prevalence (one or two internal hosts is far more suspicious than five thousand).
• Suppressing the noise: updaters and telemetry agents also beacon. Suppress by signed process and destination, never destination alone, or an attacker on the same CDN inherits the exemption.

TLS and connection fingerprints

Encrypted C2 still reveals how client and server negotiate. JA3 hashed the TLS Client Hello and weakened when Chromium began randomising extension order; JA4 sorts extensions and ciphers to stay stable. The JA4+ suite adds JA4S (server response), JA4H (HTTP client), JA4X (certificates), JA4SSH and JA4T (TCP). JA4 is BSD 3-Clause licensed; the others use the FoxIO License 1.1, which matters for commercial use. JARM instead actively sends 10 TLS Client Hello packets to a server and produces a 62-character fingerprint that its authors say can help "Identify malware command and control infrastructure and other malicious servers on the Internet."

• Use fingerprints as context, not verdicts: legitimate applications built on the same libraries share fingerprints. The signal is a rare fingerprint, from an unexpected process, to a young domain.
• Expect drift: fingerprints change when TLS libraries update, roughly once a year according to the JA4 maintainers, so refresh lists and baselines.
• Where to compute them: NDR sensors, Zeek, proxies and some firewalls can log JA4 or JA3 without decrypting traffic.

DNS analytics

• DNS tunnelling (T1071.004): long, high-entropy subdomain labels, many unique subdomains under one zone, unusual record types such as TXT or NULL, and high query volume from one host.
• Dynamic resolution (T1568): domain generation algorithms produce bursts of NXDOMAIN responses; fast flux shows very short TTLs and a rapidly changing set of IP addresses for one name. An April 2025 joint advisory from NSA, CISA, FBI and Five Eyes partners called fast flux a national security threat and said protective DNS providers "should track, share information about, and block fast flux."
• DNS calculation (T1568.003): the implant derives its real destination from the IP address in a DNS answer, so look for connections to addresses that never appeared in any DNS response the host received.
• Resolver bypass: endpoints querying external resolvers directly, or using DNS over HTTPS to public resolvers, are invisible to your DNS logs. See the DNS Security Guide.

Proxy, TLS inspection and NDR telemetry

• Proxy logs: user, URL category, domain age, user agent and bytes in and out. Uncategorised or newly registered domains contacted by a single host are a classic pivot.
• TLS inspection: decrypting selected categories exposes URIs, headers and payload shapes that fingerprints cannot. Decide scope, exemptions and privacy first. See the TLS Inspection Guide.
• Domain fronting (T1090.004): with inspection, compare the TLS SNI with the HTTP Host header; a mismatch on a CDN is a strong signal.
• NDR: sensors at egress and between server segments model beaconing, internal relays (T1090.001), ICMP payloads (T1095) and traffic that does not match its port (T1571).

Abuse of cloud services and tunnelling tools

Web service C2 (T1102) and tunnelling (T1572) hide behind domains you cannot block outright. In a July 2025 intrusion, Microsoft's incident responders found the SesameOp backdoor relaying commands and results through the OpenAI Assistants API; Microsoft stressed "This threat does not represent a vulnerability or misconfiguration," and OpenAI disabled the API key and account involved. ATT&CK's T1572 page lists ngrok in several procedure examples and records Scattered Spider, the group linked to the MGM Resorts breach, tunnelling through trycloudflare[.]com subdomains.

• Ask which hosts should use the service at all: a domain controller calling an AI API or a tunnelling service is the anomaly, whatever the domain's reputation.
• Prefer tenant-aware controls: where the proxy or CASB supports it, restrict sanctioned SaaS to your own tenant so personal accounts on the same service are blocked.
• Watch developer tooling: IDE remote tunnels (T1219.001) and personal tunnelling agents on servers are both remote access paths that bypass the VPN.

For turning these signals into tested rules, see the Detection Engineering Guide.

Preventing C2: egress, DNS and remote access tools

Egress filtering

• Servers deny by default: servers, domain controllers and OT gateways should have no direct internet route. Allow named update and API destinations through a proxy, by exception. See the Firewall Management Guide.
• Endpoints through an authenticated proxy: block direct outbound TCP 80 and 443 from user subnets so traffic must traverse a proxy that logs user and category.
• Close side doors: block outbound DNS (53), DNS over TLS (853) and SMTP (25) except from designated resolvers and mail relays, restrict ICMP to what operations need, and block or inspect QUIC (UDP 443) where your proxy cannot see it. See the Network Ports and Protocols Security Guide.
• Block uncategorised and newly registered domains for servers outright, and for users with a warning page at minimum.
• Segment internally: workstation-to-workstation SMB and RPC let internal relays (T1090.001) chain hosts with no internet access. See the Network Segmentation Guide.

DNS security

• Force clients to internal resolvers that forward to a protective DNS service, block unapproved DoH through browser policy and the proxy, log every query with the client address, and sinkhole known C2 domains with response policy zones.

Application control for remote access tools

CISA, NSA and MS-ISAC warned in January 2023 that "threat actors can maliciously leverage any legitimate RMM software", including portable executables that run without installation or administrator rights. Their advisory recommends:

• Inventorying remote access tools and approving a short list.
• Application control that blocks unapproved tools: "Application controls should prevent both installation and execution of portable versions of unauthorized RMM software." See the Application Allowlisting Guide.
• Allowing approved RMM only from inside the network or through VPN or VDI, and blocking inbound and outbound traffic on common RMM ports and protocols at the perimeter.
• Reviewing logs for RMM execution, especially portable copies.

Where identity fits

Operators use C2 to harvest credentials and then reconnect through identities that look legitimate, so identity is both a detection source and a containment lever.

• API keys as C2 infrastructure: in SesameOp the channel depended on an attacker-held API key for a cloud AI service; revoking it ended that channel. See the API Key Management Guide.
• Remote support credentials: commercial remote access platforms are effectively sanctioned C2. The BeyondTrust breach shows what a stolen API key for a remote support service can reach. Treat vendor accounts on these tools as privileged. See the Third-Party Access Guide.
• Process owner: a beacon running as a service account or SYSTEM outranks one in a user session; triage by the identity behind the connection.

Choosing an approach

Small organisations: start with protective DNS, server egress deny-by-default, EDR and an approved RMM list; an MDR provider can run beaconing analysis. Large organisations: add NDR at egress and data centre choke points, selective TLS inspection, JA4 logging, and a hunting cadence for low-and-slow channels.

Rolling out C2 defences

1. Map egress: list every internet path (proxies, firewalls, cloud NAT gateways, branch breakouts) and every DNS resolver. Unknown paths are where C2 will go.
2. Centralise telemetry: send DNS, proxy, firewall flow and EDR network events to the SIEM with consistent host and user fields. See the SIEM Guide.
3. Restrict servers first: build allowlists from 30 days of observed traffic, run them log-only for two weeks with system owners reviewing denies, then enforce by tier, starting with domain controllers and identity systems. Roll back by reverting that tier's rule set.
4. Force DNS and block bypass: redirect or block external DNS, DoT and unapproved DoH, then enable protective DNS blocking after a monitor-only week.
5. Control remote access tools: inventory RMM and tunnelling software, approve a short list, and block the rest with application control in audit mode first, then enforce through pilot rings.
6. Deploy beaconing and fingerprint analytics: baseline for two to four weeks, build suppression for known updaters, and route high-scoring pairs to analysts.
7. Test: run benign beacon simulations or an authorised red team exercise and confirm each control fires.

Responding to a C2 finding

1. Scope before blocking: blocking one domain warns the operator and may trigger a fallback channel (T1008). First find other hosts with the same destination, fingerprint or timing.
2. Capture evidence: memory from affected hosts (many frameworks run only in memory), process trees, and DNS, proxy and flow records for the full dwell period.
3. Find the identities: accounts used on the host since first contact, new remote access tools, API keys and OAuth grants.
4. Contain together: block all known domains, IPs and fingerprints at DNS, proxy and firewall, isolate hosts with EDR, and reset or revoke affected credentials in the same window.
5. Hunt for fallbacks: watch for new beacons on other protocols or services over the following weeks.

Full process: Incident Response Guide.

Detection and measurement

• Egress coverage: percentage of servers with deny-by-default outbound rules enforced (target: all tier 0 and tier 1).
• DNS visibility: share of endpoint DNS queries reaching logged resolvers, and blocked bypass attempts per week.
• Unapproved remote access: number of executions of unapproved RMM or tunnelling tools per month, trending to zero.
• Time to detect: median time from first beacon to alert in red team and simulation exercises.
• Intel to block: time from receiving a C2 indicator to enforcement at DNS, proxy and firewall.
• Analytic precision: share of beaconing alerts that lead to investigation rather than suppression.

Framework mapping

Common failure patterns

• Servers with open outbound internet: default-allow egress on server VLANs and cloud subnets lets every exploited service call home on the first try.
• Allowlisting a whole CDN or cloud provider: exempting a provider's domains from inspection or analytics also exempts every attacker using that provider, including fronted and tunnelled traffic.
• DNS logging that misses the client: logs taken after a forwarder show only the resolver's address, so a tunnelling host cannot be identified.
• RMM tools nobody owns: several products installed by different teams and MSPs, none in an inventory, so an attacker's copy looks normal. CISA's RMM advisory recommends starting with exactly this inventory.
• Blocking before scoping: one domain is blocked, the operator moves to a fallback channel, and the incident is closed while the intrusion continues.
• Static indicator lists only: IP and hash feeds age within days; behaviour and fingerprint analytics survive infrastructure changes.

Practitioner checklist

• Enforce deny-by-default outbound rules for servers and identity systems, with named exceptions through a proxy.
• Force all DNS through logged internal resolvers and a protective DNS service, and block DoT and unapproved DoH.
• Route user web traffic through an authenticated proxy and log user, process, category and bytes.
• Log JA4 or JA3 and JARM-style server data at NDR, Zeek or proxy points, and baseline them.
• Run beaconing analysis over multi-day windows with process-aware suppression of known updaters.
• Maintain an approved remote access tool list and block the rest, including portable copies.
• Write a C2 response runbook: scope, capture memory, contain all channels and credentials together.
• Test detections with authorised red team or simulation exercises at least twice a year.

Standards and references

• MITRE ATT&CK: Command and Control (TA0011)
• MITRE ATT&CK: Remote Access Tools (T1219)
• MITRE ATT&CK: Protocol Tunneling (T1572)
• CISA, NSA and MS-ISAC: Protecting Against Malicious Use of Remote Monitoring and Management Software
• CISA: NSA, CISA, FBI and International Partners Release Cybersecurity Advisory on Fast Flux
• FoxIO: JA4+ Network Fingerprinting
• Salesforce: JARM Active TLS Server Fingerprinting
• Microsoft Security: SesameOp, Novel Backdoor Uses OpenAI Assistants API for Command and Control

Related NHI Mgmt Group resources: Living off the Land Guide · Detection Engineering Guide · TLS Inspection Guide · Firewall Management Guide · Incident Response Guide