DC0021: OS API Execution
Calls made by a process to operating system-provided Application Programming Interfaces (APIs). These calls are essential for interacting with system resources such as memory, files, and hardware, or for performing system-level tasks. Monitoring these calls can provide insight into a process's intent, especially if the process is malicious.
Analyst context for executives and security teams
OS API Execution is a broad telemetry concept: observing the calls a process makes to operating-system APIs to understand what that process is trying to do. For leaders, its value is not that it maps to one specific attack path, but that it can help distinguish ordinary software behavior from suspicious intent when higher-level logs are too limited.
Executive priority
Treat this as a coverage and evidence question for SOC and incident response readiness. If the organization relies only on coarse process or file logs, investigators may miss the intent behind suspicious activity. However, because ATT&CK provides no specific platform, tactic, or detection guidance for this data component, investment decisions should be based on local risk, endpoint visibility requirements, privacy/performance constraints, and incident response evidence needs.
Technical view
SOC and detection teams should validate whether they collect any telemetry that represents process calls to operating-system-provided APIs, especially calls related to memory, files, hardware interaction, or system-level tasks as described by MITRE. Because no platforms or related techniques are supplied, teams should avoid assuming universal applicability and should map available API-call telemetry to their actual endpoint and workload environments.
Likely telemetry
- Process-to-OS API call events, where available
- API call metadata showing the calling process and target system resource
- Memory-related API activity
- File-related API activity
- Hardware or system-level task API activity
Detection direction
- Confirm whether OS API call telemetry is actually collected, retained, and searchable; do not assume standard endpoint logs provide this depth.
- Tune detections around suspicious combinations or sequences of API behavior rather than single API calls, since benign software also uses OS APIs constantly.
- Use process context to reduce false positives, including expected application behavior and environment-specific baselines.
- Validate performance, data volume, and privacy tradeoffs before expanding API-level monitoring.
- Because no ATT&CK relationships are supplied, map this data component locally to the techniques and incident scenarios your team cares about.
Mitigation priorities
- Prioritize endpoint visibility requirements that support incident investigation before building highly specific detections.
- Define which systems or workloads justify API-level monitoring based on business criticality and investigative need.
- Maintain process and endpoint context so API-call observations can be interpreted accurately.
- Document telemetry availability and retention as compliance and incident response evidence where relevant.
- Review control gaps where high-risk systems lack sufficient low-level process behavior visibility.
Analyst notes and limits
This object is a data component, not an adversary technique. Its defensive value is as a telemetry source for understanding process intent through calls to operating-system APIs. The supplied ATT&CK fields do not include tactics, platforms, relationships, or detection logic, so any operational use must be grounded in local tooling and environment evidence.
Official detection guidance is not provided. Platforms and tactics are not specified. No relationship context is supplied. This take therefore cannot assert specific attack mappings, detection coverage, affected technologies, or active threat use.
OS API Execution
Calls made by a process to operating system-provided Application Programming Interfaces (APIs). These calls are essential for interacting with system resources such as memory, files, and hardware, or for performing system-level tasks. Monitoring these calls can provide insight into a process's intent, especially if the process is malicious.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 2.1 | Current bundle | 0e44d7f99ca6… |
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 DC0021Open 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.