MITRE ATT&CK T1106 Native API: Detecting Malicious Execution

Malware does not need cmd.exe, PowerShell or a shell to run code: it can call the operating system's own APIs directly, and when it does, command-line logging sees nothing. MITRE ATT&CK T1106 Native API, in the Execution tactic (TA0002), covers adversaries using native operating system interfaces, from Windows calls such as CreateProcess and NtCreateProcess to fork() on Linux and frameworks such as .NET and macOS Cocoa, to launch processes, load modules and manipulate memory. ATT&CK v20 lists Linux, macOS and Windows as platforms and no sub-techniques. Because every legitimate program also calls these APIs, this is a technique you detect by context and sequence, not by the call itself. This guide is for detection engineers and endpoint teams. Note that this is about operating system APIs on endpoints; for securing web and service APIs, see the NIST SP 800-228 API Protection Guide.

Key takeaways

• The API is not the signal. Thousands of legitimate functions exist and every process uses them. Detection depends on which process makes which sequence of calls, against what target.
• It defeats command-line visibility. ATT&CK records Cobalt Strike's Beacon running shell and PowerShell commands without cmd.exe or powershell.exe. Process tree and command-line rules alone will miss it.
• Direct syscalls aim at your sensor. ATT&CK notes adversaries invoking syscalls directly to bypass user-mode API hooks, and unhooking monitored functions (T1685 Disable or Modify Tools). Prefer kernel-sourced telemetry.
• ATT&CK gives two mitigations. M1038 Execution Prevention (application control such as App Control for Business, AppLocker) and M1040 Behavior Prevention on Endpoint (the attack surface reduction rule that blocks Win32 API calls from Office macros).
• Detect the outcome. DET0529 looks for unusual processes loading native API libraries followed by direct syscall behaviour, memory manipulation or hollowing: target the effect (injection, credential access, new processes from odd parents).

What the technique covers

ATT&CK describes native APIs as a controlled way to call low-level operating system services in the kernel, such as those for hardware, memory and processes. Adversaries use them much as they would a command interpreter (T1059): to execute a binary, run a command, load modules and more. The calls may be made through documented libraries, through higher-level frameworks, or directly as system calls written in assembly to avoid user-mode hooks.

How adversaries use it: cases from ATT&CK

• Chimera (G0114): used direct Windows system calls by leveraging the public tool Dumpert, a clear example of syscalls used to sidestep user-mode monitoring.
• APT37 (G0067): used VirtualAlloc, WriteProcessMemory and CreateRemoteThread for process injection. See the T1055 Process Injection Defensive Guide.
• Operation Wocao (C0014): after injecting into a selected process, the actors used CreateProcessA and ShellExecute to launch commands, so the commands appeared to come from the injected process.
• Operation Honeybee (C0006): malware used API calls including CreateProcessAsUser, which starts a process under another user's token.
• Medusa Group (G1051): has used Windows native API functions to execute payloads. See the Medusa Ransomware Threat Actor Profile.
• Lazarus Group (G0032) and Operation Dream Job (C0022): used the Windows API ObtainUserAgentString to obtain the host's User-Agent string for command and control traffic, showing that native API use also supports discovery and blending in, not only execution.
• Cobalt Strike (S0154): ATT&CK records Beacon running shell commands without cmd.exe and PowerShell commands without powershell.exe.

ATT&CK lists more than 200 procedure examples for T1106, most of them malware families. The lesson is that native API use is nearly universal in malware, so the technique is best treated as a lens on other techniques: injection, credential access, defence impairment and execution without a shell.

What to detect and where

ATT&CK v20 detection strategy DET0529, Behavioral Detection of Native API Invocation via Unusual DLL Loads and Direct Syscalls, has three analytics:

Telemetry notes

Sysmon documents Event ID 7 (Image loaded) as disabled by default and warns that logging all image loads produces a significant volume; it also warns that Event ID 10 (ProcessAccess) can be noisy where diagnostic utilities repeatedly open processes. Collect both with targeted include rules. Event ID 8 (CreateRemoteThread) and Event ID 25 (ProcessTampering, which flags hollowing and similar process image changes) are high-value, low-volume additions. Most EDR platforms collect equivalent events from kernel callbacks, which direct syscalls do not bypass in the way they bypass user-mode hooks.

Rules that work in practice

• Cross-process access to sensitive targets: Event ID 10 where the target is lsass.exe or a browser, and the source is not a known security, backup or management tool. See the T1003 OS Credential Dumping guide.
• Remote thread creation: Event ID 8 from Office applications, script hosts, browsers or binaries in user-writable paths.
• Process tampering: any Event ID 25, triaged with the parent chain.
• Shell-less command execution: processes that spawn child processes with a different user token (the CreateProcessAsUser pattern) or that start system utilities without a parent shell when their normal behaviour is to have none.
• Unusual module loads: unsigned or newly seen binaries in temp or user directories loading ntdll.dll and immediately allocating executable memory, or a second copy of ntdll.dll mapped from disk, which can indicate unhooking.
• Linux ptrace: ptrace attach to another process by anything other than a debugger used by an authorised developer. On production servers, ptrace by non-root processes can often be restricted entirely.
• Sensor health: drops in event volume from a host, or EDR tamper alerts, since unhooking and sensor tampering travel with direct syscalls. See the T1685 Disable or Modify Tools Defensive Guide.

Mitigations

Microsoft documents that rule as supported on Windows 10 1709 or later and Windows 11, not applicable to Windows Server, deployable through Intune, MDM CSP or Group Policy, and reported in advanced hunting as AsrOfficeMacroWin32ApiCallsAudited or AsrOfficeMacroWin32ApiCallsBlocked. Microsoft notes most organisations do not need Win32 API calls from VBA macros. Two related rules address common follow-on behaviour: "Block Office applications from injecting code into other processes" (75668c1f-73b5-4cf0-bb93-3ecf5cb7cc84) and "Block credential stealing from the Windows local security authority subsystem" (9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2).

The following are NHI Mgmt Group recommendations:

• Protect LSASS: turn on LSA protection and Credential Guard so native API access to credential memory fails even when code runs.
• Restrict debugging rights: remove SeDebugPrivilege from accounts that do not need it on Windows, and restrict ptrace scope on Linux servers.
• Keep sensors in the kernel: choose and configure endpoint tooling that collects process, thread and memory events from kernel sources, and alert on sensor tampering.

Where identity fits

Several native API patterns are identity attacks in execution clothing. CreateProcessAsUser and related calls run code under another account's token, which is how a foothold under a low-privilege user becomes activity under a service account. Reading LSASS memory through native calls yields credentials and tokens for every account logged on to the host, including service accounts and scheduled task identities. Keep service accounts off workstations, use group managed service accounts where possible so passwords are not exposed for reuse, and alert when a service account's token appears in an interactive or unexpected process. See the MITRE ATT&CK T1134 Access Token Manipulation guide.

How to put it in place

1. Check telemetry: confirm your EDR records process access, remote thread creation and image loads, or deploy Sysmon with targeted Event ID 7 and 10 filters plus Event IDs 8 and 25.
2. Turn on ASR rules in audit mode: start with the Win32 API from Office macros rule, the Office injection rule and the LSASS rule. Review audit events for two to four weeks.
3. Move to block: enforce on a pilot ring, then broadly; keep documented, per-path exclusions for business macros that genuinely need them.
4. Deploy application control: start with an audit policy, add block rules for user-writable paths, then enforce. See App Control for Business (WDAC).
5. Build detections: LSASS access, remote threads, process tampering and token-switching rules, each allowlisting known security and management tools by signed publisher and path.
6. Test: use an authorised adversary emulation framework, with change approval, to exercise injection, LSASS access and shell-less execution on test hosts, and confirm both prevention and alerting.
7. Roll back: ASR rules and application control can be returned to audit mode per rule or per ring if a business process breaks; record each change.

Decision guidance

• Prevention or detection first: ASR rules and application control stop whole classes of behaviour cheaply and should come first; detection rules catch what slips past, especially on servers where those controls are harder to enforce.
• Sysmon or EDR: EDR provides kernel-sourced telemetry and tamper protection; Sysmon adds free, transparent events and is a good second source where you need to verify EDR coverage.
• Small organisations: enable the three ASR rules, LSA protection and your EDR's default injection and credential theft protections.
• Large organisations: add application control in enforcement, custom detections with allowlists maintained by owners, and regular emulation tests per platform.

Measurement

• ASR enforcement: share of Windows endpoints with the three rules in block mode.
• Application control coverage: share of endpoints and servers with an enforced policy.
• Telemetry coverage: share of hosts sending process access and remote thread events.
• Emulation detection rate: share of authorised test behaviours (injection, LSASS access, shell-less execution) blocked or alerted.
• Exclusion count: number of ASR and detection exclusions, each with an owner and review date.

Common failure patterns

• Command-line-only detection: relying on process creation and command-line rules, which Beacon-style execution without cmd.exe never triggers.
• Trusting user-mode hooks: assuming API hooking catches everything, when direct syscalls and unhooking are documented ways around it.
• ASR rules left in audit: audit mode deployed years ago and never promoted to block.
• Broad exclusions: whole folders or tools excluded from injection and LSASS protection to fix one false positive.
• No image load filtering: enabling every Sysmon image load event, flooding the SIEM, and then turning it off entirely.

Framework mapping

For the industrial control systems equivalent, see T0834 Native API.

Practitioner checklist

• Confirm endpoint telemetry covers process access, remote thread creation, process tampering and targeted image loads.
• Enforce the ASR rule blocking Win32 API calls from Office macros, after an audit period.
• Enforce the Office injection and LSASS credential theft ASR rules, or LSA protection with Credential Guard.
• Deploy application control that blocks execution from user-writable paths.
• Alert on LSASS access, remote threads and token switching by unexpected processes.
• Restrict SeDebugPrivilege and Linux ptrace on servers.
• Monitor sensor health and tamper alerts as part of this detection set.
• Test with authorised emulation on each platform and record detection results.

Standards and references

• MITRE ATT&CK: T1106 Native API
• MITRE ATT&CK: M1038 Execution Prevention
• MITRE ATT&CK: M1040 Behavior Prevention on Endpoint
• Microsoft Learn: Attack surface reduction rules reference
• Microsoft Learn: Sysmon
• NIST: SP 800-53 Rev 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: ATT&CK Execution Tactic Guide, T1059 Command and Scripting Interpreter Defensive Guide, M1038 Execution Prevention, M1040 Behavior Prevention on Endpoint, EDR Guide.