T0871: Execution through API
Adversaries may attempt to leverage Application Program Interfaces (APIs) used for communication between control software and the hardware. Specific functionality is often coded into APIs which can be called by software to engage specific functions on a device or other software.
Analyst context for executives and security teams
Execution through API matters because ICS control software often uses APIs to communicate with hardware and other control components. If an adversary can call those interfaces without proper authentication, authorization, or execution controls, they may be able to invoke functions that affect operational devices. For leaders, the issue is not just malware execution; it is whether critical control paths can distinguish approved operator or engineering activity from unauthorized API-driven actions.
Executive priority
Treat this as a cyber-physical control assurance question: which APIs can cause operational changes, who is allowed to call them, and what evidence proves those calls are authenticated, authorized, and monitored? Priority should focus on high-consequence ICS assets referenced by ATT&CK, including HMIs, workstations, PLCs, RTUs, IEDs, safety controllers, DCS controllers, PACs, field I/O, data gateways, switches, and firewalls. This technique also supports compliance and audit readiness because authorization enforcement, access management, user authentication, and execution prevention are explicit mitigation relationships.
Technical view
MITRE provides no official detection text and no direct platform field for T0871, so SOC and IR teams should validate coverage against the targeted ICS asset relationships rather than assume endpoint-only visibility. Review where control applications, HMIs, engineering workstations, gateways, controllers, and safety-related devices expose APIs or callable functions. Confirm that API calls capable of reading, manipulating, or executing device functions are logged with identity, source, destination, function/action, timestamp, and result where technically feasible. The related DET0742 detection strategy indicates ATT&CK has a detection concept for this behavior, but the supplied object does not include its analytic details. The Triton software relationship is relevant context because ATT&CK records Triton as using this technique, but that does not by itself establish current activity or exposure in any environment.
Likely telemetry
- Control application and HMI logs showing API/function calls and operator or service account context
- Engineering workstation activity logs, including control software actions where available
- Authentication and authorization logs for ICS applications, gateways, and management services
- Network traffic metadata between workstations, HMIs, gateways, controllers, RTUs, IEDs, and other field devices
- Device or controller event logs indicating accepted, rejected, or abnormal command execution
Detection direction
- Inventory APIs or callable control functions that can engage device or software functions, then map which assets and accounts are expected to use them.
- Baseline normal API/function-call patterns for operator, engineering, maintenance, and automated service activity; tune detections for unusual source systems, times, accounts, or command types.
- Correlate API execution evidence with authentication, authorization, change-management, and network-session data to reduce false positives from legitimate operations.
- Pay special attention to safety controllers and other high-consequence control assets where unauthorized function calls could have operational significance.
- Validate visibility on embedded and network ICS assets; many may not produce rich host logs, making network and gateway telemetry more important.
Mitigation priorities
- Enforce authorization so only authenticated users with approved roles can read, manipulate, or execute functions on devices or systems, consistent with M0800 Authorization Enforcement.
- Apply access management controls, including gateways or in-line enforcement where field devices cannot provide sufficient identification and authentication, consistent with M0801 Access Management.
- Require human user authentication before accepting commands or access to data where feasible, consistent with M0804 Human User Authentication.
- Use execution prevention controls such as application control or script blocking where applicable to systems that can execute code, consistent with M0938 Execution Prevention.
- Prioritize controls first on assets that can initiate or broker control actions, such as HMIs, workstations, data gateways, and firewalls, and then validate protections for controllers and field devices based on operational constraints.
Analyst notes and limits
The supplied ATT&CK object is an ICS technique with sparse tactic, platform, and detection detail. Its relationship set is highly useful: it targets a broad set of ICS assets and is mitigated by authorization enforcement, access management, human user authentication, and execution prevention. The software relationship to Triton should be treated as ATT&CK context for relevance to safety-controller environments, not as evidence of activity in a specific organization.
MITRE does not provide official detection text, tactics, aliases, labels, or direct platforms for this technique in the supplied fields. Detection feasibility depends heavily on local ICS architecture, vendor/device logging, gateway placement, authentication design, and the ability to collect telemetry without disrupting operations. This take does not infer active exploitation, attribution, or guaranteed detection coverage.
Execution through API
Adversaries may attempt to leverage Application Program Interfaces (APIs) used for communication between control software and the hardware. Specific functionality is often coded into APIs which can be called by software to engage specific functions on a device or other software.
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
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 | fe9ca0f1503b… |
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 T0871Open 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.