MITRE ATT&CK for ICS T0871 Execution through API: Detection and Response in OT

Execution through API (T0871) is an adversary using the same interfaces your engineering and supervisory software uses to make controllers do things: download a program, change a mode, write a value or call a method. Because these APIs exist to be called, the activity looks like normal engineering unless you know which applications, users and hosts are supposed to call which functions. MITRE ATT&CK for ICS lists T0871 under Execution for Embedded, Windows, Linux and Network Devices platforms. This guide is for OT security engineers, control system engineers and OT SOC analysts: what counts as an ICS API, how real intrusions used them, what ATT&CK's v20 analytics look for, and how to restrict and monitor API use without breaking operations. For the wider matrix see the MITRE ATT&CK for ICS Guide.

Key takeaways

• The API is a legitimate feature. Vendor libraries, OPC UA methods and controller management protocols exist so software can command hardware, which is why abuse blends in.
• Who calls matters more than what is called. ATT&CK's analytics alert on write and control calls from client identities, processes or hosts outside an approved list, not on the calls themselves.
• Triton showed the stakes. ATT&CK records Triton using a reconstructed TriStation protocol to trigger program download, allocation and change functions on a safety instrumented system controller.
• Many field devices cannot authenticate callers. ATT&CK's mitigations add access management in front of devices that cannot identify users themselves.
• OPC UA auditing is an underused source. Servers that support auditing can record each method call and write with the client user and application, which is exactly the evidence needed.

What T0871 covers

ATT&CK for ICS describes T0871 as adversaries leveraging application program interfaces (APIs) used for communication between control software and hardware. Specific functionality is often coded into APIs that software can call to engage functions on a device or other software. In practice that covers three layers:

T0871 is about the execution step. What the adversary achieves through the API is often a separate technique: Program Download (T0843), Change Operating Mode (T0858), Modify Controller Tasking (T0821) or Modify Parameter (T0836). Map detections to both, since an API alert is the earliest point in that chain.

The procedure examples and what they teach

• Triton (S1009): ATT&CK records Triton using a reconstructed TriStation protocol to trigger APIs for program download, program allocation and program changes on safety instrumented system controllers, communicating over TriStation's default UDP port 1502, and using TriStation functions to halt or run programs. The lesson: if an attacker can reach the controller from a host that speaks its management protocol, the API does the rest. Safety systems need the strictest controls on who can reach them.
• CyberAv3ngers (G1027): ATT&CK v20 records the group, during the 2026 Iranian Water Campaign (C0065), using existing PLC management protocols through the manufacturer's engineering tools, including EtherNet/IP CIP, S7Comm and UMAS. No custom malware was needed; the vendor's own tooling was the means of execution.

An earlier CyberAv3ngers operation, described in CISA advisory AA23-335A (December 2023, updated December 2024), shows how exposure enables this kind of access: the actors logged into internet-connected PLCs on their default port using default or absent passwords, replaced the ladder logic and disabled upload and download functions. The direct cause there was exposure and weak authentication, which is why the access controls below matter as much as the detections. See the PLC Security Guide.

Detection: ATT&CK v20 analytics

MITRE's v20 detection strategy for T0871 (DET0742) has four platform analytics, all with ATT&CK's OT operational fidelity gate: alert only on activity that breaks an approved signer, hash, path, parent, process or tool allowlist, or comes from an unauthorised user or tool, and is tied to an OT asset or follow-on OT-relevant action, while suppressing vendor-signed software, approved engineering utilities and documented maintenance.

The tunable inputs ATT&CK names are three allowlists: applications authorised to issue OPC UA or IEC 61850 write and control requests, OPC clients authorised to call write and control methods, and executables permitted to load ICS vendor API libraries. Building these lists with control engineers is the core of the work.

Using OPC UA audit events

The OPC UA specification (OPC 10000-5) defines AuditUpdateMethodEventType, generated for each method called, recording the hosting object (SourceNode), the MethodId, the input arguments and, in profiles from version 1.05, the returned status code and output arguments. Where your OPC UA servers support auditing, turn it on, forward the events to the OT SOC and alert on calls whose client user or application is not in the approved list. Confirm with the vendor that auditing is supported and the performance impact acceptable before enabling it on a production server.

Prevention: ATT&CK mitigations in practice

• M0800 Authorization Enforcement: APIs that perform execution, especially those hosted on controllers, should enforce authorisation, and users should have access only to the calls they need. On OPC UA servers, use role-based permissions so most clients can only read and subscribe.
• M0804 Human User Authentication: APIs on remote systems or local processes should authenticate users before executing code or system changes. Turn on controller and engineering software passwords and project protection where the product supports them, and replace default credentials.
• M0801 Access Management: where field devices cannot identify and authenticate users, put access management technology in front of them, such as an authenticating gateway or a jump host that is the only permitted path to the controller.
• M0938 Execution Prevention: minimise exposure of API calls that can execute code. Disable unused services and remote programming functions, and use controller key switches or run mode protections where available so program changes need physical presence.

Network design reinforces all four. Allow management protocol traffic to controllers only from named engineering workstations, block it at every other conduit, and keep safety system networks separate from basic process control. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.

Where identity fits

Every API call comes from an identity of some kind: a named engineer, a shared engineering account, an OPC UA application instance certificate or a service account running an HMI. Shared accounts and default credentials make the approved client lists meaningless, because the attacker becomes an approved client. Use named accounts on engineering software, issue OPC UA application certificates per application instance and manage their trust lists, and remove standing access for integrators outside agreed windows. See the OT and ICS Identity and Access Guide.

How to implement

1. Map API use. With control engineers, list which applications, hosts and accounts legitimately call write, control and program functions on each controller family, and when.
2. Restrict reachability first. Limit management protocol and OPC UA write access to the hosts on that list at the conduit firewall, logging denies for a period before enforcing.
3. Turn on the telemetry: OPC UA auditing where supported, Sysmon image load events scoped to ICS vendor libraries on engineering workstations and servers, and OT network monitoring with protocol decoding.
4. Deploy DET0742-style alerts in alert-only mode through at least one maintenance cycle (our recommendation), suppressing work logged against change tickets.
5. Harden the APIs: enable authorisation and authentication features, remove defaults, disable unused remote programming functions, after testing on a spare or test controller.
6. Keep a rollback: record each configuration change with the previous setting and keep offline copies of controller programs, so a security setting that disrupts operations can be reversed quickly. See the OT Backup, Recovery and Golden Image Guide.

Decision guidance

• Controllers with authentication support: turn it on and manage credentials centrally; it is the strongest control and costs little once tested.
• Legacy controllers without authentication: rely on network restriction to a single engineering path, physical run mode protection and network monitoring, and plan replacement.
• Small sites: conduit firewall rules plus a single hardened engineering workstation remove most exposure without new tooling.
• Large or safety-critical sites: add OPC UA auditing, protocol-aware monitoring and an OT SOC process, and give safety controllers their own stricter allowlist. See the OT Security Operations Centre Guide.

Responding to suspicious API activity

Treat an unapproved write or program call as a possible process-impacting event. Start with operations: confirm the process state, whether values or logic changed, and whether the system can run safely. Preserve evidence before restoring anything: the current controller program and configuration, OPC UA audit records, network captures and the calling host's process and module load history. Contain at the conduit by blocking the calling host's access to controllers, rather than isolating supervisory hosts operators depend on. Compare the controller program with the last approved offline copy and restore it under engineering supervision if it changed. Then investigate the calling host and identity, since an engineering workstation used for unapproved calls is likely compromised. See the OT Incident Response Guide and the Engineering Workstation Security Guide.

Detection and measurement

• Allowlist coverage: percentage of controllers with a documented list of approved calling applications, hosts and accounts.
• Reachability: number of hosts able to reach controller management ports, tracked against the approved list.
• Audit coverage: percentage of OPC UA servers with auditing enabled and forwarded.
• Authentication coverage: percentage of controllers and engineering projects with authentication or protection enabled where supported.
• Unexplained calls: count of write, control or program calls not matched to a change ticket, each investigated.

Framework mapping

Common failure patterns

• Every host can talk to every controller: flat control networks let any compromised machine use the management protocol.
• Shared engineering accounts: approved client lists are meaningless when everyone, including the attacker, uses the same account.
• Controller protections left off: passwords, project protection and run mode settings are available but disabled for convenience.
• Monitoring that cannot decode the protocol: flow data shows a connection to port 4840 or a vendor port but not whether it read or wrote.
• Safety controllers on the same allowlist as the basic process control system: the Triton lesson is that safety systems need a narrower path.

Practitioner checklist

• Document approved calling applications, hosts and accounts for each controller family with control engineers.
• Restrict controller management and OPC UA write traffic to approved hosts at every conduit.
• Enable OPC UA auditing where supported and forward method and write events to the OT SOC.
• Monitor ICS vendor library loads on engineering workstations and servers against an allowlist.
• Turn on controller authentication, project protection and run mode protections after testing.
• Replace default credentials and shared engineering accounts with named accounts.
• Keep offline copies of approved controller programs and compare after any unexplained call.
• Give safety instrumented systems a separate, narrower access path and allowlist.

Standards and references

• MITRE ATT&CK for ICS: Execution through API (T0871)
• MITRE ATT&CK: Detection of Execution through API (DET0742)
• MITRE ATT&CK: Triton (S1009)
• OPC Foundation: OPC 10000-5, AuditUpdateMethodEventType
• CISA and partners: AA23-335A, IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors
• NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
• CISA, FBI, EPA and DOE: Primary Mitigations to Reduce Cyber Threats to Operational Technology

Related NHI Mgmt Group resources: MITRE ATT&CK for ICS Guide · PLC Security Guide · Engineering Workstation Security Guide · OT Network Security Monitoring Guide · OT and ICS Identity and Access Guide