Native API (T1106) is an execution technique. MITRE lists Linux, macOS and Windows. Unlike many techniques, it does not point to one tool or one command. It points to a layer, the operating system's own programming interface, which every program uses.
That makes it hard to treat as bad on its own. Detection depends on context.
How attackers use it
MITRE explains that native APIs give a controlled way to call low-level OS services in the kernel, such as those involving hardware, memory and processes. The OS uses them during boot, when other components are not yet initialized, and during routine work.
Adversaries may abuse these functions to execute behavior, in a similar way to command and scripting interpreters. MITRE gives examples:
- Native functions such as NtCreateProcess can be invoked directly through system calls.
- Interfaces and libraries expose them to user-mode programs, for example the Windows API CreateProcess() or GNU fork(), which start other processes. That can mean running a binary, a command line, or loading modules.
- Higher level frameworks such as Microsoft .NET and macOS Cocoa wrap native APIs with easier abstractions.
MITRE also notes that adversaries may use assembly to invoke syscalls directly or indirectly in an attempt to subvert defensive sensors and detection signatures, such as user mode API hooks. They may also try to tamper with sensors and defensive tools.
How to detect it
MITRE's strategy is Behavioral Detection of Native API Invocation via Unusual DLL Loads and Direct Syscalls. The analytics cover:
- Windows: unusual processes loading critical native API libraries such as ntdll.dll and kernel32.dll, followed by direct syscall behavior, memory manipulation or process hollowing.
- Linux: user-space processes calling syscall-heavy libraries such as libc, followed by fork, mmap or ptrace behavior associated with code injection.
- macOS: processes linking to CoreServices or Foundation APIs, followed by new memory regions, code execution or abnormal library injection.
Useful telemetry includes image load events (Sysmon event ID 7 on Windows), process creation with parent and command line, and memory or thread creation events from your endpoint tool. On Linux, auditd can record ptrace and related syscalls.
Think in sequences. A document or script host that suddenly loads low-level libraries, allocates memory and starts a thread is a story. A single DLL load is not.
How to reduce the risk
MITRE lists two mitigations:
- Execution prevention. Block potentially malicious software with application control tools, such as Windows Defender Application Control, AppLocker or Software Restriction Policies, where appropriate.
- Behavior prevention on endpoint. On Windows 10, enable Attack Surface Reduction rules to prevent Office VBA macros from calling Win32 APIs.
Application control matters most here because you cannot block the API itself. You can control what code is allowed to run and call it.
Check your own environment
- Is application control enforced, or only in audit mode, on your servers and workstations?
- Are the ASR rules that stop Office macros calling Win32 APIs turned on?
- Do your endpoint logs capture image loads and memory or thread creation?
- Do you have a baseline of which processes legitimately load low-level libraries?
- Do you alert on unusual parents for processes that do hollowing-like behavior?
# Windows (PowerShell): show current Attack Surface Reduction rule configuration (read-only)
Get-MpPreference | Select-Object AttackSurfaceReductionRules_Ids, AttackSurfaceReductionRules_Actions
Empty output means no ASR rules are configured on that machine.
Quick check
Why is Native API hard to detect with a simple signature?
Every program uses native APIs, so the call alone proves nothing. Detection relies on the context, such as an unusual process, direct syscalls or injection patterns.
What does the ASR rule MITRE mentions prevent?
It prevents Office VBA macros from calling Win32 APIs, on Windows 10.
Sources
- MITRE ATT&CK, Native API (T1106)
