T0834: Native API
Adversaries may directly interact with the native OS application programming interface (API) to access system functions. Native APIs provide a controlled means of calling low-level OS services within the kernel, such as those involving hardware/devices, memory, and processes. [1] These native APIs are leveraged by the OS during system boot (when other system components are not yet initialized) as well as carrying out tasks and requests during routine operations.
Functionality provided by native APIs are often also exposed to user-mode applications via interfaces and libraries. For example, functions such as memcpy and direct operations on memory registers can be used to modify user and system memory space.
Analyst context for executives and security teams
Native API matters because it represents low-level interaction with operating system services that can affect memory, processes, hardware, and devices. In ICS environments, that makes the behavior relevant beyond normal IT malware analysis: the related ATT&CK asset context spans operator workstations, HMIs, control servers, historians, gateways, safety controllers, embedded controllers, VPN servers, jump hosts, firewalls, and switches. For executives and security leaders, the practical question is whether critical control-system assets have enough execution control, monitoring, and incident-response visibility to distinguish legitimate system or vendor activity from suspicious low-level behavior.
Executive priority
Prioritize this as an ICS resilience and visibility issue, not just an endpoint detection topic. Because ATT&CK maps this technique to many ICS asset types and identifies Execution Prevention as a mitigation, leaders should ask whether application control or script/code execution blocking is actually deployed, tested, and supportable on engineering workstations, HMIs, servers, remote access infrastructure, and embedded or network devices where applicable. This also has audit and incident-readiness value: teams should be able to show what assets can execute code, what is allowed, what is monitored, and how exceptions are governed for operational continuity.
Technical view
MITRE provides no tactic or official detection text for T0834, so defenders should anchor validation to the described behavior: direct use of native OS APIs to call low-level services involving hardware/devices, memory, and processes. SOC and IR teams should confirm whether they can observe unusual process behavior, memory manipulation indicators, driver or device interaction, code execution attempts, and activity from ICS management applications on the related asset classes. Relationship context shows a detection strategy, DET0753 Detection of Native API, detects this object, and mitigation M0938 Execution Prevention applies. The technique is also used by ICS-related software entries Stuxnet, PLC-Blaster, and Triton, which supports treating native API visibility as relevant to ICS malware and attack-framework analysis without implying current activity.
Likely telemetry
- Endpoint process creation and parent-child process context on Windows and Linux ICS systems where collected
- Application control, script blocking, and execution prevention allow/deny events
- Process memory access or modification events where endpoint tooling supports them
- Driver, kernel, device, or hardware-interface access logs where available
- Security events from workstations, HMIs, control servers, application servers, historians, jump hosts, VPN servers, and data gateways
Detection direction
- Validate the coverage and assumptions of DET0753 against the organization’s actual ICS asset inventory; do not assume the same telemetry exists on embedded, network, Windows, and Linux assets.
- Tune detections around unexpected low-level API usage by unapproved processes, especially on systems that support engineering, operations, remote access, or control functions.
- Account for false positives from legitimate operating system activity, vendor control software, diagnostics, engineering tools, and boot-time or maintenance operations that may legitimately use native APIs.
- Correlate low-level API behavior with execution-control alerts, process ancestry, asset role, maintenance windows, and whether the binary or script is approved for that ICS function.
- Identify blind spots where endpoint monitoring is unavailable, unsupported, or unsafe to deploy on embedded controllers and network devices; compensate with configuration baselines, change monitoring, and incident-response procedures.
Mitigation priorities
- Start with asset criticality: prioritize execution prevention controls on workstations, HMIs, control servers, application servers, historians, jump hosts, VPN servers, and gateways where standard operating systems and business access paths increase exposure.
- Use M0938 Execution Prevention principles: application control and script/code blocking where operationally tested and supportable.
- Maintain approved software and script inventories for engineering and operations systems so low-level API usage can be interpreted in context.
- For embedded and network assets where endpoint controls may be limited, emphasize vendor-supported hardening, change control, firmware/software integrity checks, and restricted administrative access.
- Document exceptions and operational dependencies so security controls do not disrupt safety or availability while still producing defensible compliance evidence.
Analyst notes and limits
This object is sparse: platforms and tactics are not specified, and MITRE does not provide official detection guidance. The strongest context comes from the description, the DET0753 detection-strategy relationship, M0938 Execution Prevention, broad ICS asset targeting relationships, and software-use relationships for Stuxnet, PLC-Blaster, and Triton. Local engineering software behavior, vendor constraints, and asset logging capabilities are required to turn this into reliable detections.
This take does not assert active exploitation, customer exposure, attribution, or guaranteed detection. The ATT&CK object does not specify platforms or tactics for the technique itself, so platform references are limited to related ICS assets and software relationships. Detection and mitigation recommendations require local validation before operational use.
Native API
Adversaries may directly interact with the native OS application programming interface (API) to access system functions. Native APIs provide a controlled means of calling low-level OS services within the kernel, such as those involving hardware/devices, memory, and processes. [1] These native APIs are leveraged by the OS during system boot (when other system components are not yet initialized) as well as carrying out tasks and requests during routine operations.
Functionality provided by native APIs are often also exposed to user-mode applications via interfaces and libraries. For example, functions such as memcpy and direct operations on memory registers can be used to modify user and system memory space.
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
S1009: Triton
S1006: PLC-Blaster
PLC-Blaster is a piece of proof-of-concept malware that runs on Siemens S7 PLCs. This worm locates other Siemens S7 PLCs on the network and attempts to infect them. Once this worm has infected its target and attempted to infect other devices on the network, the worm can then run one of many modules. [1] [2]
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]
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.0 | Current bundle | 0652271b61ba… |
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]
The MITRE Corporation May 2017
The MITRE Corporation 2017, May 31 ATT&CK T1106: Native API Retrieved. 2021/04/26
Open source URL -
[2]
mitre-attack T0834Open 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.