TA0011: Command and Control
The adversary is trying to communicate with compromised systems to control them.
Command and Control consists of techniques that adversaries may use to communicate with systems under their control within a victim network. Adversaries commonly attempt to mimic normal, expected traffic to avoid detection. There are many ways an adversary can establish command and control with various levels of stealth depending on the victim’s network structure and defenses.
Analyst context for executives and security teams
Command and Control is the business-critical phase where a compromised system can become remotely directed instead of merely infected. The practical concern for leaders is whether the organization can notice and disrupt adversary communications that are designed to blend into normal network activity. Because the ATT&CK object is a tactic rather than a specific technique, it should be treated as a coverage-planning category for network visibility, SOC triage, incident response containment, and evidence that outbound communications are monitored and governed.
Executive priority
Prioritize this as an operational resilience and incident decision-making issue: if command-and-control traffic is not visible or controllable, responders may struggle to determine whether a compromised endpoint is still being directed by an adversary. Leaders should ask whether security teams can prove they collect and review the outbound network evidence needed to identify unusual communications, whether containment decisions can be made quickly, and whether normal traffic baselines are documented well enough to distinguish suspicious activity from business-as-usual operations.
Technical view
This ATT&CK object provides no platform-specific detection text, so SOC and IR validation should focus on the general behavior described: communication between compromised systems and adversary-controlled infrastructure, often disguised as expected traffic. Detection engineers should validate visibility across outbound network paths, proxy or gateway controls, DNS activity, endpoint-to-network correlation, and alert workflows for communications that are anomalous for the host, user, application, or environment. Because no relationship context was supplied, do not infer specific malware, procedures, or techniques from this tactic alone.
Likely telemetry
- Outbound network connection logs
- DNS query and response logs
- Proxy, secure web gateway, or firewall logs
- Endpoint network activity telemetry
- Network flow metadata
Detection direction
- Validate that outbound communications are logged from endpoints and network choke points rather than relying on inbound monitoring only.
- Tune detections around deviations from expected host, user, application, destination, frequency, or protocol patterns, since the tactic notes adversaries may mimic normal traffic.
- Correlate endpoint identity, asset criticality, and network destinations to reduce false positives from legitimate business applications.
- Check for blind spots created by unmanaged devices, encrypted traffic visibility limits, direct internet egress, incomplete DNS logging, and cloud or remote-user paths not passing through monitored controls.
- Use this tactic as a coverage map entry; specific analytics should be tied to the related ATT&CK techniques in local content, but no such relationships were supplied here.
Mitigation priorities
- Establish and document controlled outbound egress paths so security teams know where command-and-control evidence should appear.
- Maintain usable network, DNS, proxy, firewall, and endpoint telemetry with retention sufficient for incident response.
- Define normal communication baselines for critical assets and high-risk user populations.
- Integrate alert triage with containment procedures so suspected controlled systems can be isolated quickly when evidence supports it.
- Review exceptions, direct-to-internet paths, and monitoring gaps as part of security architecture, audit readiness, and incident response preparation.
Analyst notes and limits
This is a tactic-level ATT&CK object, so its value is mainly in prioritizing defensive coverage and executive questions rather than defining a single analytic. The supplied description emphasizes adversary communication with compromised systems and the tendency to mimic normal traffic, which makes baselining, egress visibility, and correlation important defensive themes.
No official detection guidance, platforms, tactics list, aliases, labels, or relationship context were supplied. This take does not identify specific techniques, tools, threat groups, platforms, or active exploitation. Local architecture, telemetry availability, and business traffic patterns are required to determine actual coverage and risk.
Command and Control
The adversary is trying to communicate with compromised systems to control them.
Command and Control consists of techniques that adversaries may use to communicate with systems under their control within a victim network. Adversaries commonly attempt to mimic normal, expected traffic to avoid detection. There are many ways an adversary can establish command and control with various levels of stealth depending on the victim’s network structure and defenses.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 04617b072860… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack TA0011Open source URL
Source: MITRE ATT&CK®. © 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. Glexia is not affiliated with or endorsed by MITRE.