Safeguard
Incident Analysis•

How Do Command and Control (C2) Attacks Work and How Do You Spot Them?

Command and control is how an attacker talks to a compromised machine. MITRE lists 18 techniques. Learn what to hunt for in DNS, proxy and endpoint logs.

Safeguard Security Team
5 min read

Command and control (C2) is the channel an attacker uses to send instructions to a compromised system and receive results. MITRE defines the tactic as the adversary trying to communicate with compromised systems to control them. Detecting C2 means finding that outbound conversation, often hidden in ordinary-looking web or DNS traffic.

What does MITRE ATT&CK list under C2?

The Command and Control tactic (TA0011) lists 18 techniques. Read as a group, they show how many ways there are to hide a conversation:

  • Blend in: Application Layer Protocol (T1071), Web Service (T1102), Encrypted Channel (T1573).
  • Change the path: Proxy (T1090), Protocol Tunneling (T1572), Non-Standard Port (T1571), Non-Application Layer Protocol (T1095).
  • Stay reachable: Fallback Channels (T1008), Multi-Stage Channels (T1104), Dynamic Resolution (T1568), Hide Infrastructure (T1665).
  • Disguise content: Data Encoding (T1132), Data Obfuscation (T1001).
  • Bring more tools: Ingress Tool Transfer (T1105), Remote Access Tools (T1219).
  • Unusual routes: Communication Through Removable Media (T1092), Traffic Signaling (T1205), Content Injection (T1659).

The takeaway is not to memorize the list. It is that no single network rule covers all of them.

Why is C2 hard to see?

Most environments allow outbound web traffic, so malware that talks over HTTPS to a popular web service looks like a user browsing. Encryption hides content. Dynamic resolution lets attackers change the addresses they use, so a blocklist goes stale. A channel that checks in rarely produces little data.

What stays visible is behavior. The pattern of connections, the process that made them, and the destination's history are often the best evidence.

What patterns should you hunt for?

Regular beaconing. A host contacts the same destination at steady intervals, with small request sizes, day and night. Humans do not behave that way, though software updaters do, so check the process.

Odd process, odd destination. A document viewer or script interpreter making outbound connections to a rarely seen domain is worth a look.

Unusual DNS. Many queries to one recently registered domain, very long or random-looking subdomains, or large volumes of lookups from a single host can signal tunneling or dynamic resolution.

Non-standard ports for standard protocols. Web traffic on a strange port, or a protocol that does not match its port.

First-seen tools. A newly installed remote access program, especially one nobody requested, matches the Remote Access Tools technique.

NIST SP 800-53 supports this approach. SI-4(4) asks organizations to determine criteria for unusual or unauthorized activity in inbound and outbound communications traffic and to monitor accordingly. SC-7(8) describes routing selected traffic through authenticated proxy servers at managed interfaces, which gives you a place to see and control outbound connections.

A constructed example

A security analyst reviews proxy logs and sees a finance workstation connecting to the same unfamiliar domain every 60 seconds, with identical small requests. The process behind the connections is a spreadsheet application launching a script host.

That fits an Application Layer Protocol channel, and the spreadsheet link points to initial access through a document. The analyst isolates the workstation, collects the proxy and endpoint evidence, blocks the domain, and searches for other hosts that contacted it. Two more machines appear. The hunt result becomes a standing alert for periodic outbound connections from office applications.

How to reduce the opportunity?

Block outbound traffic by default where practical and allow what is needed, which is the deny by default idea in SC-7(5). Force web traffic through a proxy with logging. Use a DNS resolver that logs queries and can block newly registered or known malicious domains. Restrict who can install remote access tools, per least functionality in CM-7.

How to check or apply this

  1. Confirm that proxy, DNS and endpoint process logs are collected and retained long enough to investigate.
  2. Write a detection for periodic outbound connections with consistent size and interval, and test it with a harmless script in a lab.
  3. Alert when office applications or script interpreters create outbound connections.
  4. Review new remote access tools monthly against an approved list.
  5. Route egress through monitored choke points, and deny direct internet access from servers that do not need it.
  6. Map your detections to the 18 techniques and note the gaps.
  7. Prepare a containment checklist: isolate host, preserve evidence, block destination, search for other contacts.

Quick check

Does encrypted traffic make C2 undetectable?

No. You lose the content but can still see timing, volume, destination, the originating process and DNS behavior, which are often enough to flag it.

Is blocking known bad domains enough?

No. Attackers change infrastructure and can use dynamic resolution, so also monitor behavior and restrict outbound paths.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.