TA0037: Command and Control
The adversary is trying to communicate with compromised devices to control them.
The command and control tactic represents how adversaries communicate with systems under their control within a target network. There are many ways an adversary can establish command and control with various levels of covertness, depending on system configuration and network topology. Due to the wide degree of variation available to the adversary at the network level, only the most common factors were used to describe the differences in command and control. There are still a great many specific techniques within the documented methods, largely due to how easy it is to define new protocols and use existing, legitimate protocols and network services for communication.
The resulting breakdown should help convey the concept that detecting intrusion through command and control protocols without prior knowledge is a difficult proposition over the long term. Adversaries' main constraints in network-level defense avoidance are testing and deployment of tools to rapidly change their protocols, awareness of existing defensive technologies, and access to legitimate Web services that, when used appropriately, make their tools difficult to distinguish from benign traffic.
Additionally, in the mobile environment, mobile devices are frequently connected to networks outside enterprise control such as cellular networks or public Wi-Fi networks. Adversaries could attempt to evade detection by communicating on these networks, and potentially even by using non-Internet Protocol mechanisms such as Short Message Service (SMS). However, cellular networks often have data caps and/or extra data charges that could increase the potential for adversarial communication to be detected.
Analyst context for executives and security teams
Command and Control in mobile ATT&CK is the business problem of a compromised device continuing to receive instructions from an adversary. The key risk is not just malware presence; it is whether the organization can see and disrupt unauthorized communications when the device may be on enterprise Wi-Fi, cellular networks, public Wi-Fi, or even non-IP channels such as SMS. This makes mobile C2 a coverage and evidence problem for security leaders, especially where mobile devices access sensitive business services.
Executive priority
Treat this tactic as a test of mobile security visibility and incident readiness. Leaders should ask whether the organization can make decisions when a suspected device communicates outside enterprise-controlled networks, whether mobile events are available to the SOC and incident responders, and whether policies account for cellular/public network use. Because MITRE notes that C2 can blend into legitimate services and protocols, budget and control prioritization should focus on telemetry access, device management, network visibility where available, and response procedures rather than assuming perimeter monitoring alone is sufficient.
Technical view
This is a mobile ATT&CK tactic, not a specific technique, and no official detection guidance or platform list was supplied. SOC and IR teams should validate whether they can observe suspicious mobile communication patterns across managed network paths and mobile-device telemetry, while recognizing that cellular, public Wi-Fi, legitimate web services, custom protocols, and SMS may create blind spots. Detection engineering should focus on evidence correlation: device state, app behavior, network destinations where visible, unusual data transfer patterns, and management/security alerts. Since relationship context was not supplied, do not infer specific C2 techniques; use this tactic as a coverage review area.
Likely telemetry
- Mobile device management or enterprise mobility management device inventory, compliance state, and security events
- Mobile endpoint or mobile threat defense alerts where deployed
- Network connection metadata from enterprise Wi-Fi, VPN, proxy, DNS, firewall, or secure web gateway paths where mobile traffic is routed through them
- Authentication and access logs for business services used by mobile devices
- Application inventory, installation, permission, and configuration change records from managed devices
Detection direction
- Validate which mobile traffic is actually visible to the SOC when devices are on enterprise networks versus cellular or public Wi-Fi.
- Tune detections for suspicious communication behavior without relying only on known-bad protocols or destinations, because MITRE notes adversaries can use legitimate services and easily define new protocols.
- Correlate mobile device alerts with identity, application access, and network metadata to reduce false positives from normal mobile app background activity.
- Review blind spots for non-enterprise networks and non-IP mechanisms such as SMS, which MITRE explicitly identifies as possible evasion paths in mobile environments.
- Use this tactic to assess coverage gaps rather than to claim detection success, since the ATT&CK object does not provide official detection analytics.
Mitigation priorities
- Prioritize governance of managed mobile devices, including visibility into device state, installed applications, permissions, and compliance posture.
- Route enterprise mobile access through controlled and logged paths where feasible, such as managed connectivity or protected access to business services.
- Ensure mobile incident response playbooks include containment options for devices that may be off-network or using cellular/public networks.
- Integrate mobile telemetry with SOC workflows so investigations are not limited to perimeter network logs.
- Use policy, user guidance, and technical controls to reduce unmanaged mobile access to sensitive services where monitoring and response evidence would be insufficient.
Analyst notes and limits
This take is based on the ATT&CK mobile tactic TA0037, Command and Control. The object describes adversary communication with compromised devices and emphasizes the difficulty of detecting C2 without prior knowledge, especially when communications use legitimate services, custom protocols, cellular networks, public Wi-Fi, or SMS. No technique relationships, official detection text, or specific platforms were supplied, so the guidance is framed as coverage validation and defensive planning rather than specific analytic content.
The supplied object is a tactic-level ATT&CK entry with no official detection field, no platforms, and no relationship context. Local architecture, mobile management scope, carrier visibility, logging design, and deployed security controls are required to determine actual detection or response coverage.
Command and Control
The adversary is trying to communicate with compromised devices to control them.
The command and control tactic represents how adversaries communicate with systems under their control within a target network. There are many ways an adversary can establish command and control with various levels of covertness, depending on system configuration and network topology. Due to the wide degree of variation available to the adversary at the network level, only the most common factors were used to describe the differences in command and control. There are still a great many specific techniques within the documented methods, largely due to how easy it is to define new protocols and use existing, legitimate protocols and network services for communication.
The resulting breakdown should help convey the concept that detecting intrusion through command and control protocols without prior knowledge is a difficult proposition over the long term. Adversaries' main constraints in network-level defense avoidance are testing and deployment of tools to rapidly change their protocols, awareness of existing defensive technologies, and access to legitimate Web services that, when used appropriately, make their tools difficult to distinguish from benign traffic.
Additionally, in the mobile environment, mobile devices are frequently connected to networks outside enterprise control such as cellular networks or public Wi-Fi networks. Adversaries could attempt to evade detection by communicating on these networks, and potentially even by using non-Internet Protocol mechanisms such as Short Message Service (SMS). However, cellular networks often have data caps and/or extra data charges that could increase the potential for adversarial communication to be detected.
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 | 5520b0e187c9… |
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 TA0037Open 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.