DET0753: Detection of Native API
DET0753 is a MITRE ATT&CK for ICS detection strategy for identifying use of Native API behavior, where software interacts directly with low-level operating...
Analyst context for executives and security teams
DET0753 is a MITRE ATT&CK for ICS detection strategy for identifying use of Native API behavior, where software interacts directly with low-level operating system services such as hardware/device, memory, and process functions. For leaders, the significance is that this behavior can sit below ordinary application activity and may be difficult to assess if OT/ICS hosts lack endpoint, process, or system-level visibility.
Executive priority
Treat this as a visibility and assurance question for critical environments: can the organization distinguish expected native OS/API use from suspicious low-level access on systems that support operations? Because the ATT&CK object provides no platform, tactic, or official detection detail, priority should be based on local asset criticality, available telemetry, and whether incident responders can produce defensible evidence during an ICS investigation or audit.
Technical view
SOC, detection engineering, and IR teams should map this strategy to ATT&CK technique T0834 Native API and validate whether monitored ICS assets produce evidence of low-level OS interactions involving processes, memory, hardware, or devices. Since MITRE does not provide a detection analytic or platform scope for DET0753, teams should avoid assuming coverage and instead test which sensors can observe native API-related behavior in the specific operating environments used by critical assets.
Likely telemetry
- Endpoint or host process telemetry, where available
- System call or API-level monitoring, where available
- Kernel, driver, device, or hardware access events, where collected
- Memory access or process manipulation evidence from endpoint security tools, where supported
- Application control or allowlisting logs showing unusual executable behavior
Detection direction
- Validate coverage against T0834 Native API rather than relying on the detection strategy name alone.
- Establish baselines for legitimate low-level OS interactions on critical ICS hosts before alerting on deviations.
- Tune detections to account for normal operating system boot activity and routine system tasks, since the related technique description notes native APIs are used by the OS during boot and normal operations.
- Prioritize correlation with process identity, executable provenance, parent-child process context, device or driver access, and asset criticality.
- Document blind spots where ICS assets cannot support endpoint or API-level telemetry.
Mitigation priorities
- Inventory critical ICS assets and identify where native API-level visibility is technically feasible.
- Prioritize monitoring and hardening for systems where low-level OS access could affect operational reliability or incident response confidence.
- Use allowlisting, least privilege, and controlled administrative access where locally supported to reduce unnecessary low-level execution paths.
- Ensure incident response playbooks include evidence collection for process, memory, device, and system-level activity on affected assets.
- Use ATT&CK mapping to support compliance and audit discussions about monitoring coverage and known visibility gaps.
Analyst notes and limits
This take is intentionally conservative because DET0753 has no official description, no official detection text, no specified platforms, and no tactics in the supplied fields. The only relationship provided is that it detects ICS technique T0834 Native API, whose description concerns direct use of native OS APIs for low-level kernel-related services involving hardware/devices, memory, and processes.
Local validation is required. The supplied ATT&CK fields do not identify affected platforms, specific data sources, analytic logic, false-positive patterns, or mitigations. Any claim of detection coverage depends on the organization’s actual ICS asset mix, endpoint instrumentation, logging depth, and response procedures.
Detection of Native API
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| ICS | T0834 | Native API | This object detects Native API. |
All related ATT&CK context
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 | fc00a4469ff8… |
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 DET0753Open 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.