T0807: Command-Line Interface
Adversaries may utilize command-line interfaces (CLIs) to interact with systems and execute commands. CLIs provide a means of interacting with computer systems and are a common feature across many types of platforms and devices within control systems environments. [1] Adversaries may also use CLIs to install and run new software, including malicious tools that may be installed over the course of an operation.
CLIs are typically accessed locally, but can also be exposed via services, such as SSH, Telnet, and RDP. Commands that are executed in the CLI execute with the current permissions level of the process running the terminal emulator, unless the command specifies a change in permissions context. Many controllers have CLI interfaces for management purposes.
Analyst context for executives and security teams
Command-line access in ICS matters because it is a normal administrative capability that can also become a high-consequence execution path. On workstations, HMIs, historians, control servers, jump hosts, data gateways, switches, and firewalls, a CLI can let a user or process run tools, change configurations, or launch software with the permissions currently available to that session. For leaders, the key issue is not whether CLIs exist; it is whether critical control-system assets have accountable, monitored, and restricted command execution paths.
Executive priority
Treat this as an operational resilience and audit-evidence issue for ICS environments. The ATT&CK relationships show CLI use associated with major ICS campaigns and malware, but the supplied object does not establish current exposure in any specific environment. Executives should ask which ICS assets permit local or remote CLI access, whether SSH/Telnet/RDP-style access is governed through approved paths such as jump hosts, and whether command execution evidence is retained for incident response and compliance review. Priority should go first to assets that bridge trust zones or support operations: jump hosts, HMIs, control servers, historians, data gateways, switches, and firewalls.
Technical view
SOC, detection engineering, and IR teams should validate visibility into interactive and remote command execution across the targeted ICS asset classes. The official object has no tactic, platform, or detection text, so coverage must be mapped locally rather than assumed from ATT&CK metadata. Focus validation on command execution from terminal emulators and remote services, especially where permissions can enable software installation, tool execution, configuration changes, or access to control-system management interfaces. Use the related DET0760 detection strategy as the ATT&CK-linked detection context, and pair it with asset role awareness so commands on HMIs, engineering workstations, jump hosts, control servers, gateways, switches, and firewalls are triaged differently from routine IT administration.
Likely telemetry
- Process creation and command-line execution records on Windows, Linux, and embedded/management systems where available
- Authentication and session logs for local console access and remote access services such as SSH, Telnet, and RDP where present
- Jump host session records, privileged access logs, and administrator activity trails
- Application control, script blocking, and execution prevention events
- Configuration change logs from control servers, HMIs, data gateways, switches, and firewalls
Detection direction
- Inventory where CLI access is enabled on the ATT&CK-targeted ICS assets and confirm which systems actually generate usable command/session telemetry.
- Tune detections around unusual command execution on operational assets, but account for legitimate engineering, maintenance, vendor support, and troubleshooting activity to reduce false positives.
- Correlate command execution with user identity, asset role, remote access path, and privilege context; a command on a jump host, HMI, or control server carries different risk than the same command on a general workstation.
- Pay special attention to remote CLI exposure through services such as SSH, Telnet, and RDP because the official description identifies these as access paths.
- Validate retention and time synchronization for logs needed during incident response; absence of command-line logging is a material blind spot for this technique.
Mitigation priorities
- Start with least-functionality decisions: remove or disable unnecessary CLI-accessible features, programs, or remote services where operations do not require them, aligning with M0942.
- Apply execution prevention controls such as application control and script blocking where feasible for the asset role, aligning with M0938.
- Restrict remote administrative access through approved management paths, especially jump hosts, and ensure sessions are attributable to named users or authorized processes.
- Harden privilege boundaries so terminal sessions do not routinely run with broad administrative rights unless operationally justified.
- Document exceptions for ICS maintenance workflows and review them periodically with operations, engineering, and security stakeholders.
Analyst notes and limits
This technique is broad and foundational: CLI use is often legitimate, so the defensive value comes from asset-aware baselining, control of remote administration paths, and reliable evidence collection. The relationship context shows relevance to ICS assets including workstations, HMIs, historians, control servers, application servers, data gateways, jump hosts, switches, and firewalls, and to several ATT&CK-tracked campaigns/software. That context should guide prioritization for threat-informed defense exercises and tabletop scenarios.
The supplied ATT&CK object provides no official detection text, no tactics, and no direct platform list for the technique itself. Platform references come from related targeted ICS assets and related software, not from the technique platforms field. Local architecture, vendor constraints, safety requirements, and available logging determine what can be monitored or restricted. This summary does not assert active exploitation or detection coverage in any environment.
Command-Line Interface
Adversaries may utilize command-line interfaces (CLIs) to interact with systems and execute commands. CLIs provide a means of interacting with computer systems and are a common feature across many types of platforms and devices within control systems environments. [1] Adversaries may also use CLIs to install and run new software, including malicious tools that may be installed over the course of an operation.
CLIs are typically accessed locally, but can also be exposed via services, such as SSH, Telnet, and RDP. Commands that are executed in the CLI execute with the current permissions level of the process running the terminal emulator, unless the command specifies a change in permissions context. Many controllers have CLI interfaces for management purposes.
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.
Groups, software, and campaigns
G0034: Sandworm Team
Sandworm Team is a destructive threat group that has been attributed to Russia's General Staff Main Intelligence Directorate (GRU) Main Center for Special Technologies (GTsST) military unit 74455.[1][2] This group has been active since at least 2009.[3][4][5][6]
In October 2020, the US indicted six GRU Unit 74455 officers associated with Sandworm Team for the following cyber operations: the 2015 and 2016 attacks against Ukrainian electrical companies and government organizations, the 2017 worldwide NotPetya attack, targeting of the 2017 French presidential campaign, the 2018 Olympic Destroyer attack against the Winter Olympic Games, the 2018 operation against the Organisation for the Prohibition of Chemical Weapons, and attacks against the country of Georgia in 2018 and 2019.[1][2] Some of these were conducted with the assistance of GRU Unit 26165, which is also referred to as APT28.[7]
S0604: Industroyer
Industroyer is a sophisticated malware framework designed to cause an impact to the working processes of Industrial Control Systems (ICS), specifically components used in electrical substations.[1] Industroyer was used in the attacks on the Ukrainian power grid in December 2016.[2] This is the first publicly known malware specifically designed to target and impact operations in the electric grid.[3]
S0603: Stuxnet
Stuxnet was the first publicly reported malware to specifically target industrial control systems devices. Stuxnet is a large and complex malware that utilized multiple behaviors, including numerous zero-day vulnerabilities, a sophisticated Windows rootkit, and network infection routines.[1][2][3][4] Stuxnet was discovered in 2010, with some components being used as early as November 2008.[1]
S1165: FrostyGoop
FrostyGoop is a Windows-based binary written in Golang that allows for interaction with industrial control system (ICS) equipment via Modbus TCP over port 502. FrostyGoop allows for reading and writing data to holding registers on targeted devices, manipulating the operation of systems for malicious purposes. FrostyGoop is associated with the FrostyGoop Incident in Ukraine.[1][2]
C0030: Triton Safety Instrumented System Attack
Triton Safety Instrumented System Attack was a campaign employed by TEMP.Veles which leveraged the Triton malware framework against a petrochemical organization.[1] The malware and techniques used within this campaign targeted specific Triconex Safety Controllers within the environment.[2] The incident was eventually discovered due to a safety trip that occurred as a result of an issue in the malware.[3]
C0063: 2025 Poland Wiper Attacks
2025 Poland Wiper Attacks is a Russian state-sponsored campaign that conducted destructive cyberattacks against Polish energy infrastructure in December 2025. Targets included more than 30 wind and photovoltaic farms, a combined heat and power (CHP) plant, and a manufacturing sector company. The attacks on the distributed energy resources (DER) disrupted communications between affected facilities and the distribution system operator, but did not impact electricity generation or heat supply. Across the campaign, threat actors deployed two previously undocumented wiper tools, DynoWiper, a Windows-based wiper and LazyWiper, a PowerShell wiper, distributed via malicious Group Policy Objects. At the CHP plant, threat actors had maintained access since at least March 2025, using that foothold to obtain credentials and move laterally before attempting wiper deployment. Some reporting has assessed the activity to be consistent with Russian Federal Security Service (FSB) threat activity group Dragonfly, also tracked as STATIC TUNDRA, while other reporting attributes the destructive wiper activities to the Russian General Staff Main Intelligence Directorate (GRU) threat activity group ELECTRUM, also tracked as Sandworm Team.[1][2][3][4]
C0025: 2016 Ukraine Electric Power Attack
2016 Ukraine Electric Power Attack was a Sandworm Team campaign during which they used Industroyer malware to target and disrupt distribution substations within the Ukrainian power grid. This campaign was the second major public attack conducted against Ukraine by Sandworm Team.[1][2]
C0034: 2022 Ukraine Electric Power Attack
The 2022 Ukraine Electric Power Attack was a Sandworm Team campaign that used a combination of GOGETTER, Neo-REGEORG, CaddyWiper, and living of the land (LotL) techniques to gain access to a Ukrainian electric utility to send unauthorized commands from their SCADA system.[1][2]
All related ATT&CK context
Mitigation direction
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.1 | Current bundle | 227351bbbb39… |
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]
Enterprise ATT&CK January 2018
Enterprise ATT&CK 2018, January 11 Command-Line Interface Retrieved. 2018/05/17
Open source URL -
[2]
mitre-attack T0807Open 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.