MITRE ATT&CK® Technique

T1106: Native API

Adversaries may interact with the native OS application programming interface (API) to execute behaviors. Native APIs provide a controlled means of calling low-level OS services within the kernel, such as those involving hardware/devices, memory, and processes.CitationNT API WindowsCitationLinux Kernel API 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.

Adversaries may abuse these OS API functions as a means of executing behaviors. Similar to Command and Scripting Interpreter, the native API and its hierarchy of interfaces provide mechanisms to interact with and utilize various components of a victimized system.

Native API functions (such as NtCreateProcess) may be directed invoked via system calls / syscalls, but these features are also often exposed to user-mode applications via interfaces and libraries.CitationOutFlank System CallsCitationCyberBit System CallsCitationMDSec System Calls For example, functions such as the Windows API CreateProcess() or GNU fork() will allow programs and scripts to start other processes.CitationMicrosoft CreateProcessCitationGNU Fork This may allow API callers to execute a binary, run a CLI command, load modules, etc. as thousands of similar API functions exist for various system operations.CitationMicrosoft Win32CitationLIBCCitationGLIBC

Higher level software frameworks, such as Microsoft .NET and macOS Cocoa, are also available to interact with native APIs. These frameworks typically provide language wrappers/abstractions to API functionalities and are designed for ease-of-use/portability of code.CitationMicrosoft NETCitationApple Core ServicesCitationMACOS CocoaCitationmacOS Foundation

Adversaries may use assembly to directly or in-directly invoke syscalls in an attempt to subvert defensive sensors and detection signatures such as user mode API-hooks.CitationRedops Syscalls Adversaries may also attempt to tamper with sensors and defensive tools associated with API monitoring, such as unhooking monitored functions via Disable or Modify Tools.

EnterpriseT1106TechniqueObject v2.3ModifiedMay 12, 2026, 15:12 UTC (UTC+00:00)

Discuss defensive coverage Back to ATT&CK

Native API abuse matters because it is not a niche tool or command; it is the normal operating-system interface used to start processes, load modules, manage memory, and interact with devices. That makes it useful to adversaries and difficult for defenders to separate from legitimate software behavior. For leaders, the key question is whether endpoint controls and SOC telemetry can see suspicious execution behavior even when activity avoids obvious command-line patterns or attempts to bypass user-mode API monitoring.

Executive priority

Treat T1106 as a core execution-visibility risk across Windows, Linux, and macOS. ATT&CK maps this technique to multiple groups and campaigns, including espionage and financially motivated activity, so coverage should be prioritized as a broad defensive capability rather than a malware-specific rule. Budget and assurance discussions should focus on endpoint behavior prevention, execution prevention, and evidence that monitoring still works when direct or indirect syscalls and unusual library/module loading are involved.

Technical view

T1106 sits in the Execution tactic and covers adversary use of native OS APIs, user-mode libraries/frameworks, and direct or indirect syscalls to execute binaries, run commands, load modules, or perform other low-level system actions. Because MITRE does not provide official detection text for this technique, teams should validate coverage using the related detection strategy DET0529: behavioral detection of native API invocation via unusual DLL loads and direct syscalls. Detection engineering should correlate process creation, module/library loads, API/syscall-related endpoint events, and signs of monitoring tamper or unhooking where available.

Likely telemetry

Process creation and parent/child process lineage across Windows, Linux, and macOS
Command-line and executable launch metadata where available
Module, shared library, and DLL load events, especially unusual loads tied to execution behavior
Endpoint behavioral telemetry for API calls, syscall patterns, memory/process operations, and code/module loading
Framework-mediated execution evidence such as .NET on Windows and Cocoa/Foundation/Core Services activity on macOS where collected

Detection direction

Confirm whether endpoint telemetry can observe behavior below command and scripting layers, since native API use may not produce obvious shell activity.
Use DET0529-style analytics to look for unusual DLL or module loads and direct syscall patterns, but tune carefully because native APIs are used constantly by legitimate software.
Correlate API/syscall indicators with process lineage, newly executed binaries, loaded modules, and command execution outcomes rather than alerting on API use alone.
Validate blind spots in user-mode API-hook based monitoring, because ATT&CK notes adversaries may use assembly/direct syscalls to subvert such sensors.
Include monitoring for defensive-tool tampering associated with API monitoring, consistent with the technique’s reference to Disable or Modify Tools behavior.

Mitigation priorities

Prioritize execution prevention controls so only trusted or authorized code can run where business processes allow, aligning to M1038.
Deploy or validate endpoint behavior prevention capabilities that analyze process, file, API-call, and endpoint behavior patterns, aligning to M1040.
Harden monitoring resilience by ensuring endpoint sensors report health and tamper conditions, not just detections.
Apply controls consistently across Windows, Linux, and macOS assets where those platforms are in scope.
Use incident response exercises to test whether suspicious native API execution can be reconstructed from available telemetry.

Additional notes and limits

This technique is important because it describes an execution substrate used by normal software and by adversaries. The relationship set is broad, including campaigns such as Operation Honeybee, Operation Sharpshooter, Operation Wocao, Operation Dream Job, and Operation Digital Eye, and groups including Turla, Lazarus Group, Sandworm Team, menuPass, Gamaredon Group, APT37, APT38, TA505, Kimsuky, BlackTech, and others. That breadth supports prioritizing resilient behavioral visibility rather than relying only on signatures or command-line detections.

MITRE provides no official detection text for T1106 in the supplied object. Practical detection quality depends on local endpoint sensor depth, operating-system audit configuration, ability to capture module/library loads and syscall/API-related behavior, and environment-specific baselines for legitimate software. The supplied data does not support claims of current exploitation, customer exposure, or guaranteed detection coverage.

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Official MITRE ATT&CK definition

Native API

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

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.

ATT&CK release: 19.1
Object version: 2.3
Created: May 31, 2017, 21:31 UTC (UTC+00:00)
Modified: May 12, 2026, 15:12 UTC (UTC+00:00)
Raw hash: 26c79e9e44625220...

Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy

Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use