Native API (T0834) is an adversary calling the low-level operating system functions of a host or a controller directly, below the vendor software that normally mediates access to hardware, memory and processes. On Windows and Linux hosts in the control network this looks much like the enterprise technique. On controllers it means calling the firmware's own system functions or reading and writing memory and registers, which is how some of the best known ICS malware worked. MITRE ATT&CK for ICS lists T0834 under Execution for Embedded, Windows, Linux and Network Devices platforms. This guide is a short, practical companion for OT security engineers and OT SOC analysts: what is different in OT, what ATT&CK records, and what you can realistically detect and prevent. For the higher-level interfaces adversaries call on controllers, see the MITRE ATT&CK for ICS T0871 Execution through API.
Key takeaways
- Native API sits below the vendor layer. ATT&CK describes calls to low-level OS services for hardware, memory and processes, and direct operations on memory registers.
- On controllers, the OS is the firmware. Stuxnet and PLC-Blaster called PLC system function blocks; Triton read and wrote controller memory through its own syscalls.
- One mitigation, and it is partial. ATT&CK's only mitigation is Execution Prevention (M0938): minimise the exposure of API calls that allow code execution.
- Detection keys on bypassing the vendor layer. v20 analytics look for raw device access from processes that are not recognised vendor applications, and for undocumented function codes or SNMP OIDs.
- Preventing the earlier step matters most. Native API use on a controller usually follows program download or exploitation, so the controls on those steps carry most of the weight.
What differs in OT
ATT&CK for ICS describes T0834 as adversaries directly interacting with the native OS API to access system functions, noting that these APIs provide a controlled means of calling low-level kernel services for hardware, devices, memory and processes, and that functions such as memcpy and direct operations on memory registers can modify user and system memory. The Enterprise equivalent is T1106 Native API. What changes in OT is the range of targets:
| Target | What "native API" means there | Where you can see it |
|---|---|---|
| Engineering workstations, HMIs, SCADA servers (Windows) | Direct CreateFile calls on raw device paths, DeviceIoControl calls to ICS hardware driver handles, bypassing the vendor SDK | EDR or kernel telemetry on the host |
| Linux-based OT hosts and gateways | Direct ioctl or mmap syscalls against ICS hardware device files | Linux audit rules on device file access |
| Controllers (PLCs, safety controllers) | Calls to firmware system functions and direct reads and writes of memory and registers | Mostly indirectly: in the protocol traffic that delivers or triggers the code, and in program or firmware integrity checks |
| Network devices in OT | Access to vendor-internal or undocumented management functions, observed for example through SNMP OIDs | Protocol-decoded SNMP monitoring |
What ATT&CK records about real use
- Stuxnet (S0603): called system function blocks that are part of the PLC's operating system, used for tasks such as reading the system clock (SFC1) and generating data blocks on the fly.
- PLC-Blaster (S1006): used the system function blocks TCON and TDISCON to open and close TCP connections to arbitrary systems, and TRCV and TSEND to receive and send data on them. In other words, the PLC's own functions turned it into a network client.
- Triton (S1009): its imain.bin payload took commands through the TsHi.ExplReadRam(Ex), TsHi.ExplWriteRam(Ex) and TsHi.ExplExec functions to operate on safety controller memory and registers using syscalls written in PowerPC shellcode.
In each case the native API calls ran inside code the adversary had already placed on the controller. The defensive lesson is that once malicious logic or firmware is running on a controller, its use of system functions is very hard to observe; the realistic detection points are before (the download or exploit) and after (changed behaviour, changed program). See the ICS Malware History Guide.
Detection: ATT&CK v20 analytics
ATT&CK's detection strategy for T0834 (DET0753) has four analytics. The host and embedded analytics share an OT operational fidelity gate: alert only when execution 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, diagnostics, patching, backup and documented maintenance.
| Platform | What the analytic looks for |
|---|---|
| Windows | A process that is not a recognised vendor application making direct native calls that bypass the ICS vendor SDK: CreateFile against raw device paths or DeviceIoControl to ICS hardware driver handles |
| Linux | Direct ioctl or mmap syscalls against ICS hardware device files from a process not in the recognised ICS application list |
| Embedded | ICS protocol messages using vendor-specific or undocumented function codes that access device hardware registers directly, from a source not in the approved engineering workstation list |
| Network devices | Access to vendor-internal or undocumented SNMP OIDs, especially SET operations or unusual walks, from sources outside the approved network management inventory; ATT&CK notes this is network protocol observation and needs decoded SNMP content |
The work is in the allowlists: which processes may open which device handles on each host, and which engineering workstations may use which function codes against which controllers. Build them with the control engineers and the vendor documentation, and run alerts in report-only mode through a maintenance period before treating them as high priority.
Prevention in practice
- M0938 Execution Prevention: ATT&CK's guidance is to minimise exposure of API calls that allow code execution. On hosts, application allowlisting on engineering workstations and servers stops unknown processes from running at all, which removes most of the Windows and Linux analytic cases. On controllers, disable unused remote programming and diagnostic services and use run mode or key switch protections where the product offers them.
- Protect the delivery step: restrict who can download programs and firmware to controllers and verify program integrity. See the PLC Security Guide.
- Harden the hosts that hold drivers: engineering workstations carry the drivers and libraries that make raw device access possible. See the Engineering Workstation Security Guide.
- Control SNMP: use read-only community or SNMPv3 credentials where possible and restrict SNMP to the network management system.
How to implement
- Inventory the drivers: list ICS hardware drivers and vendor libraries on each OT host type and the processes that legitimately use them.
- Allowlist in audit mode: deploy application allowlisting in audit mode on one engineering workstation, review blocks with the engineers, then enforce, keeping the previous policy ready to restore.
- Add host telemetry: device handle and syscall auditing scoped to ICS device paths, forwarded to the OT SOC.
- Close controller paths: disable unused remote programming services and set run mode protections after testing on a spare controller.
- Baseline programs: take approved offline copies of controller programs and schedule comparisons.
Decision guidance
- Hosts you control fully: enforced allowlisting is the strongest control and makes the host analytics rare and high-value.
- Vendor-managed hosts where allowlisting is not supported: agree monitoring with the vendor and rely on network restriction and program integrity checks.
- Small sites: run mode protection, restricted programming paths and periodic program comparison give most of the value without host telemetry.
Responding
A native API alert on an OT host is a host investigation: preserve memory and process history before reimaging, identify how the process got there, and check whether it reached any controller. If controller-level activity is suspected, involve operations first, capture the current program and configuration, compare it with the last approved offline copy, and treat the controller as untrusted until the vendor confirms its state. See the OT Incident Response Guide.
Detection and measurement
- Allowlisting coverage: percentage of engineering workstations, HMIs and SCADA servers enforcing application allowlisting.
- Device handle baseline: percentage of OT host types with a documented list of processes allowed to open ICS driver handles.
- Program integrity checks: percentage of controllers whose running program is compared with an approved copy on a schedule.
- SNMP exposure: number of OT network devices accepting SNMP writes from outside the management system.
Framework mapping
| Framework | Reference | How it applies |
|---|---|---|
| MITRE ATT&CK for ICS v20 | T0834; M0938; DET0753; S0603, S1006, S1009 | Technique, mitigation, analytics, procedure examples |
| MITRE ATT&CK Enterprise | T1106 Native API | Equivalent technique for IT hosts |
| NIST SP 800-53 Rev. 5 | CM-7, CM-5, SI-7, SI-4 | Least functionality, change restriction, software and firmware integrity, monitoring |
| NIST CSF 2.0 | PR.PS-01, DE.CM-09 | Configuration management, platform monitoring |
Common failure patterns
- No allowlisting on engineering workstations: any process can load drivers and talk to hardware.
- Remote programming always on: controllers accept new code at any time from any reachable host.
- No program baseline: without an approved copy, changed controller logic cannot be spotted.
- Alerting without allowlists: raw device access by legitimate vendor tools floods the SOC and the analytic gets switched off.
Practitioner checklist
- Enforce application allowlisting on engineering workstations, HMIs and SCADA servers.
- Document which processes may open ICS driver handles on each host type.
- Disable unused remote programming and diagnostic services on controllers.
- Use run mode or key switch protections where available.
- Keep approved offline program copies and compare them on a schedule.
- Restrict SNMP writes to the network management system.
- Run DET0753-style alerts in report-only mode before raising priority.
Standards and references
- MITRE ATT&CK for ICS: Native API (T0834)
- MITRE ATT&CK: Native API (T1106)
- MITRE ATT&CK: Triton (S1009)
- MITRE ATT&CK: PLC-Blaster (S1006)
- MITRE ATT&CK: Stuxnet (S0603)
- NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: MITRE ATT&CK for ICS Guide · MITRE ATT&CK for ICS T0871 Execution through API · PLC Security Guide · Engineering Workstation Security Guide