---
{
  "title": "Native API",
  "summary": "Native API abuse uses operating-system interfaces to perform unauthorized operations.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    6
  ],
  "aliases": [
    "T1106"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1106: Native API",
      "url": "https://attack.mitre.org/techniques/T1106"
    }
  ],
  "editorialVersion": 2
}
---

## Ordinary programs use operating-system interfaces

Native APIs provide programmatic access to operating-system services such as processes, memory, files, and devices. Applications use them routinely, and an actor can use the same interfaces to perform unauthorized actions. API use is therefore a mechanism to understand, not a standalone verdict.

The security meaning comes from the calling process, identity, sequence, parameters where visible, and resulting effects. A familiar function name can appear in legitimate and malicious software. An investigation should focus on behavior and context rather than treating every low-level call as suspicious.

## A process performs an unexpected operation

In a fictional endpoint case, monitoring reports an unfamiliar program performing a series of memory and process operations. The analyst examines the program's provenance, parent process, effective identity, relevant API telemetry, and what happened afterward.

A debugger, security product, or approved monitoring tool may perform similar operations. Compare the observed sequence with the software's documented purpose and deployment history. An API alert summarized by a product may not expose every parameter or result, so inspect the underlying evidence where available.

The team separates an attempted call from a successful operation. An error result may show a failed attempt, while a later artifact or process action can establish a completed effect. Do not infer an entire attack chain from one function name.

## Understand the observation layer

Different sensors record different levels of API behavior. Some expose selected calls, while others report higher-level outcomes. Absence from one view does not prove that no equivalent operation occurred through another path.

[[process-injection]] describes a specific behavior that can involve operating-system interfaces. [[inter-process-communication]] covers requests between components. These concepts require additional evidence beyond generic native-API activity.

Preserve relevant process context and artifacts promptly where practical. Volatile state may disappear when a process exits, and later file analysis may not reproduce the exact runtime sequence.

## Respond to the unauthorized action

Contain harmful behavior as justified and investigate the access or execution path that introduced the program. Blocking one API name is rarely a complete explanation of remediation because legitimate software may depend on it and equivalent behavior may have several implementations.

Coordinate changes with endpoint and application owners. Define verification around the actual unwanted effect, the program's presence, and the authority it used.

For practice, compare an approved diagnostic tool with a fictional unknown program performing similar low-level operations. Identify provenance, identity, sequence, result, and effect evidence needed for a decision. Explain what cannot be concluded from an API name alone. [[logs-and-telemetry]] and [[incident-reporting]] support a precise description of the observation and its limits.

## Related concepts

- [[mitre-attack]]
- [[incident-response]]
- [[command-and-scripting-interpreter]]