TA0101: Command and Control
The adversary is trying to communicate with and control compromised systems, controllers, and platforms with access to your ICS environment.
Command and Control consists of techniques that adversaries use to communicate with and send commands to compromised systems, devices, controllers, and platforms with specialized applications used in ICS environments. Examples of these specialized communication devices include human machine interfaces (HMIs), data historians, SCADA servers, and engineering workstations (EWS). Adversaries often seek to use commonly available resources and mimic expected network traffic to avoid detection and suspicion. For instance, commonly used ports and protocols in ICS environments, and even expected IT resources, depending on the target network. Command and Control may be established to varying degrees of stealth, often depending on the victim’s network structure and defenses.
Analyst context for executives and security teams
Command and Control in ICS matters because it is the point where a compromised system, controller, or ICS-adjacent platform may start receiving instructions from an adversary. For executives and security leaders, the practical issue is not just malware communication; it is whether the organization can see, contain, and investigate unexpected control paths involving HMIs, data historians, SCADA servers, engineering workstations, or other systems with access to the ICS environment.
Executive priority
Prioritize validation of ICS network visibility and incident response decision-making. This tactic can affect operational resilience because adversary communications may blend into expected ICS ports, protocols, or IT resources. Leaders should ask whether SOC and OT teams can distinguish approved operational communications from suspicious command channels, whether containment actions are pre-planned for sensitive ICS assets, and whether audit evidence exists for monitoring across IT/OT boundaries.
Technical view
ATT&CK provides no specific detection guidance for this tactic, so defenders should map local ICS communication patterns and validate monitoring around systems and applications named in the description: HMIs, data historians, SCADA servers, and engineering workstations. Detection engineering should focus on identifying unexpected communications, unusual destinations, abnormal use of commonly available resources, and traffic that mimics expected ICS network behavior. Because platforms and relationships are not specified, coverage must be confirmed against the local architecture rather than assumed from the ATT&CK object alone.
Likely telemetry
- Network flow records across ICS and IT/OT boundary segments
- Protocol and port usage baselines for ICS environments
- Firewall, proxy, and remote access logs where ICS-accessible systems communicate externally or across zones
- Logs from HMIs, data historians, SCADA servers, and engineering workstations where available
- Asset inventory and network topology records to identify approved communication paths
Detection direction
- Establish baselines for expected ICS communications before tuning alerts, because adversaries may use common ports, protocols, or expected IT resources.
- Validate monitoring at network boundaries and between ICS zones, not only on enterprise IT endpoints.
- Review whether SOC alerts can identify new, rare, or policy-violating communications from systems with access to the ICS environment.
- Account for false positives from legitimate engineering, historian, SCADA, or maintenance activity by using approved asset relationships and change windows.
- Treat the absence of official ATT&CK detection text as a prompt for local control validation, not as evidence that detection is unavailable.
Mitigation priorities
- Document approved ICS communication paths and enforce segmentation or access controls around deviations where operationally safe.
- Prioritize visibility for systems with access to the ICS environment, especially specialized applications and operator/engineering platforms referenced by ATT&CK.
- Create incident response playbooks for suspected command and control involving ICS assets, including escalation between SOC, OT operations, and engineering teams.
- Use asset inventory, network architecture, and change management records to support compliance evidence and monitoring scope decisions.
- Regularly test whether monitoring detects unauthorized or unusual communications without disrupting operational processes.
Analyst notes and limits
This is an ICS ATT&CK tactic object, not a specific technique. The supplied ATT&CK fields describe adversary intent and common ICS communication context but do not provide procedure examples, mitigations, detections, platforms, or relationships. The Glexia interpretation therefore emphasizes governance, telemetry validation, and defensive readiness rather than technique-specific analytics.
No official detection text, platforms, tactics list, aliases, labels, or relationship context were supplied. Any assessment of exposure, exploitability, alert coverage, or business impact requires local environment evidence such as asset inventory, network architecture, ICS protocol use, and SOC logging coverage.
Command and Control
The adversary is trying to communicate with and control compromised systems, controllers, and platforms with access to your ICS environment.
Command and Control consists of techniques that adversaries use to communicate with and send commands to compromised systems, devices, controllers, and platforms with specialized applications used in ICS environments. Examples of these specialized communication devices include human machine interfaces (HMIs), data historians, SCADA servers, and engineering workstations (EWS). Adversaries often seek to use commonly available resources and mimic expected network traffic to avoid detection and suspicion. For instance, commonly used ports and protocols in ICS environments, and even expected IT resources, depending on the target network. Command and Control may be established to varying degrees of stealth, often 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 | 010742a4d911… |
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 TA0101Open 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.