How T1106 Native API shows up in intrusions and how to detect it
T1106 Native API is the technique in which an adversary calls an operating system's own programming interface directly to run code or instructions, instead of starting a command interpreter or script. It matters for the Execution tactic (TA0002), whose stated purpose is to run malicious code or instructions on a system. For a SOC lead, the practical problem is that most execution alerting is built around interpreters and their child processes. Activity that goes straight to the API can produce few events that look suspicious at the shell level. In intrusions, it usually appears as one step in a longer chain, where a loader or implant uses system interfaces to start further activity after access has been gained through another technique. Treat an absence of interpreter alerts as no evidence that the technique is absent.
The signal sits below the shell, so detection depends on telemetry collected at the process and module layer on Linux, macOS and Windows. Process Creation shows which binaries start and from which parent, which still matters even when the malicious call itself is not a new process. Module Load shows unexpected libraries mapped into a process, and Process Access shows one process reaching into another. No single event is conclusive, so the detection value comes from correlating these streams for the same host and time window. On Windows, confirm whether your Sysmon or EDR configuration captures image loads and process access by default, since many default configurations do not. On Linux and macOS, confirm which audit or endpoint sensor events are enabled before writing rules that depend on them.
This page targets MITRE ATT&CK Enterprise version 20.0. ATT&CK releases can rename, deprecate or revoke techniques and sub-techniques, and mappings for T1106 should be checked against the version your detection content references before you rely on them. Record the ATT&CK version in your detection inventory next to each Sigma rule, Wazuh rule or analytic, and review it when your content is updated. The ATT&CK updates page lists each release and its changes. Ask your detection engineering lead to confirm which version your SIEM content and coverage reports use, so that gaps are not reported against a different technique definition.
Which telemetry reveals Native API activity on each platform
This table maps the three telemetry types ATT&CK most often ties to Native API activity (Process Creation, Module Load and Process Access) to Linux, macOS and Windows, along with the signal to look for and the open-source collector that captures it. Read each row as a starting point for your own log sources, and confirm field availability in your environment before writing rules. Process Access and Module Load usually produce the highest event volumes, so they need tuning before they drive alerts.
| Platform | Telemetry and signal to look for | Open-source collector |
|---|---|---|
| Windows | Process Creation (DC0032) with parent-child relationships and command line arguments, flagging unusual API-invoking processes spawned by scripts or Office applications | Sysmon event ID 1 forwarded through Wazuh agents, plus Windows Security process auditing where enabled |
| Windows | Module Load (DC0032 context) for unexpected DLL loads into processes that normally do not call system APIs directly, such as unsigned modules loaded by interpreters | Sysmon image load events, filtered and tuned to common signed modules before alerting |
| Windows | Process Access for cross-process handle requests against sensitive processes, which can reveal API calls used to inspect or inject into other processes | Sysmon process access events, scoped to a short list of high-value target processes to limit volume |
| Linux | Process Creation (DC0032) through execve audit records, watching for interpreters or binaries invoking low-level system call wrappers outside normal administrative patterns | auditd rules shipped through Wazuh, with Velociraptor hunts for historical correlation |
| Linux | Command Execution (DC0064) from shell history and process arguments, correlated with unusual shared library loads at process start | auditd and Wazuh log collection, with Velociraptor artifacts for on-demand collection |
| macOS | Process Creation (DC0032) and Command Execution (DC0064) from endpoint logs, looking for scripting runtimes calling native frameworks in unexpected parent chains | Unified log exported to Wazuh or a Velociraptor artifact, depending on the fleet's logging configuration |
| Network context (all platforms) | Network Connection Creation (DC0082) tied to a process that just invoked native APIs, useful when the API activity is followed by outbound traffic | Zeek connection logs and Suricata alerts in Security Onion, correlated by host and time window |
Detection logic for Native API calls that teams can tune
T1106 Native API covers programs that call operating system interfaces directly instead of going through a shell or a higher-level tool. Because legitimate software makes the same calls, the detection ideas below work best as tunable hypotheses that combine process, module and access telemetry, each with a documented baseline and a list of expected exceptions.
Parent-child process anomalies
Flag a process that has loaded core system libraries and then starts a child process that is rare for its parent image, such as a document viewer or a web service spawning a command interpreter or a binary from a user-writable path. Tune the rule per host role by building a baseline of normal parent-child pairs over a fixed learning window. Common false positives include software updaters, package managers, EDR agents and IT automation tools that spawn helpers by design, so maintain an allowlist keyed on signer and path rather than on name alone.
Unexpected process access to sensitive processes
Alert when a process requests memory-read or handle-duplication rights against a sensitive target such as the local security authority or another user's session, and the requesting image is not on the approved list. Start with a high-severity threshold and lower it only after reviewing a sample of hits. Debuggers, crash reporters, backup agents and endpoint security products routinely open handles to other processes, so record their signers and expected target sets before enabling the alert in blocking mode.
Rare module loads
Watch for DLLs on Windows or shared objects on Linux and macOS that are unsigned, loaded from unusual directories, or seen on fewer than a small number of hosts across the fleet. Pair the module name with the loading process so that a common library loaded by an unusual process is treated as the signal. Installers, self-extracting packages, language runtimes that compile code at run time and vendor plugins generate most false positives, so reconcile the rule against software inventory before tuning thresholds.
Rare API-heavy binaries
Score binaries by how many distinct system interfaces they import or resolve at run time, and by how rarely that hash or path appears in the fleet. Items that score high and have low prevalence deserve review, especially when they were recently written and then executed. Build the scoring model from your own software inventory, because compilers, security tools, database clients and developer utilities all have large interface footprints. Document the score threshold and the review queue so that changes to it can be audited.
Tuning and exception governance
Keep every detection under version control with its owner, its target ATT&CK version and a dated record of each allowlist change. Review exceptions on a fixed schedule and require a second reviewer for any suppression that covers a sensitive process or an unsigned module. Ask your managed service or implementation partner to show how exception changes are logged, tested in the cyber range and rolled back if the alert volume shifts.
How to confirm the Native API detection fires before you trust it
This sequence proves that the T1106 Native API detection produces the expected alerts, on the right hosts, with the right fields, before any team relies on it. It runs as a controlled exercise in a lab or cyber range and ends with a documented baseline that can be re-run after changes.
Define the behavior class to emulate
The detection owner selects the Native API behavior class to test, described in plain terms such as direct calls into operating system interfaces from an application that does not normally make them. The scope is written down with the ATT&CK version the team targets, so the test result is tied to a specific version of the technique and its detection strategy. The step is complete when the scope note names the technique, the platforms (Linux, macOS and Windows) and the telemetry sources expected to show it. The test plan itself describes behavior and expected evidence, not commands or payloads.
Pre-register expected alerts and fields
Before the exercise, the detection engineer records what should happen for each platform: which Process Creation, Module Load or Process Access events should appear, which alert rule should fire, and which fields should match (for example, parent process, image path, user context and host identifier). This record is stored in version control or a ticket so it cannot be edited after the test. The step is complete when every expected alert has a named rule, a severity and a list of matched fields, reviewed by someone other than the author.
Check the Sigma rule against the targeted ATT&CK version
The engineer confirms that the Sigma rule's ATT&CK tags, technique ID and detection logic still match the ATT&CK version the team targets. ATT&CK releases can rename, deprecate or revoke techniques, and the detection strategies for a technique can change between versions, so the check compares the rule against the current enterprise bundle for that version. Any mismatch is logged as a finding and fixed before the test. The step is complete when the rule's metadata and the version record agree, and the version is written into the test report.
Run the controlled test on each host platform
A tester runs the agreed behavior class on lab hosts for Linux, macOS and Windows, following the written test plan under change control. The run is timestamped, the host inventory and agent versions are recorded, and an observer confirms each run started and stopped as planned. The step is complete when each platform has a recorded run window and the exercise log matches the plan, with no unplanned activity on the range.
Record alert time, matched fields and misses
The analyst compares what the SIEM and endpoint tools produced with the pre-registered list. For each expected event, the record shows whether an alert fired, the time between the activity and the alert, the fields that matched, and any field that was missing or empty. Expected events with no alert are logged as misses with the telemetry source checked. The step is complete when every expected event has one of three outcomes: alert fired with time and fields, alert missing with a cause, or telemetry absent with a cause.
Triage gaps against telemetry and rule logic
The detection engineer traces each miss back to its root cause: the telemetry was not collected, the agent did not log the event, the rule logic filtered it out, or the platform field names differed. Fixes are made to the collection, parsing or rule, and each fix is linked to the miss it addresses. The step is complete when every miss has a documented cause and either a fix or an accepted risk signed by the detection owner.
Re-run after telemetry or rule changes
Whenever an agent is upgraded, a log source changes format, the Sigma rule is edited, or the ATT&CK version the team targets is updated, the same test plan is run again. Results are compared with the previous baseline to confirm that alerts still fire and fields still match. The step is complete when the new run is filed next to the baseline and any regression is opened as a tracked defect. Ask your detection platform provider and telemetry vendors which changes can silently alter field names or event coverage.
Preventive controls that reduce Native API abuse
Native API calls are legitimate operating system functionality, so preventive controls cannot simply block them. The cards below cover the two ATT&CK mitigations mapped to T1106 Native API, plus the audit evidence needed to show they work. Each control narrows what a process may do, and each one needs testing against your own software before enforcement.
Execution prevention controls
Execution Prevention (M1038) covers application allowlisting and code integrity policies that decide which binaries and libraries may run. For T1106, the useful question is whether unsigned or unexpected modules can load into trusted processes that call system APIs. Confirm with your endpoint vendor which enforcement modes exist, whether they can be scoped per host group, and how they handle signed binaries from software vendors you already run. Start in audit or monitor mode before enforcing.
Behavior prevention on endpoint
Behavior Prevention on Endpoint (M1040) uses runtime rules to flag or block suspicious call sequences, such as a process spawning a shell or injecting into another process after loading an unusual module. This matters for T1106 because the API call itself is ordinary. Ask your vendor which behaviors are covered out of the box, which can be tuned, and whether rules can be exported and version controlled. Expect false positives from installers, backup agents and developer tools.
Breakage risk for legitimate software
Aggressive blocking can disrupt line-of-business applications, update agents, security tools and build pipelines that load libraries or call system APIs directly. Before enforcement, inventory the software that legitimately performs these calls on each platform, including Linux, macOS and Windows hosts. Define exception handling with owners, expiry dates and a rollback path. Ask vendors for documented exclusion mechanisms and for the process to test updates against your exceptions.
Audit as the evidence source
Audit (M1047) ensures the platform records the events needed to prove that preventive controls are active and to investigate alerts. For T1106, confirm that process creation, module load and process access events are retained with enough context to show parent process, command line, user and signing status. Verify log forwarding to your SIEM, clock sync across hosts and retention that matches your policy. Without this evidence, you cannot show that a control worked.
Policy ownership and change control
Preventive rules degrade quietly when no one owns them. Assign a named owner for each allow rule, behavior rule and exception, and route changes through the same review as other security configuration. Keep rule sets in version control so you can show what was in force on a given date. Map the owner and review cadence to your existing change management process, and confirm the vendor supports exporting policy state for audits.
What the SOC does in the first hour after a Native API alert
The first hour after a T1106 Native API alert is about deciding whether the call came from a legitimate program doing ordinary work or from something that should not be touching the operating system directly. Start by rebuilding the process tree around the alerting event. On Linux and macOS, look at the parent chain for the process that made the system call or loaded the library. On Windows, confirm which binary issued the Process Access or Module Load event, which user context it ran under, and whether the parent is an interpreter, an office application or a signed utility that has no business making that call. Record the calling binary path, hash, signer and account before anyone changes anything on the host.
Next, check the Process Access targets and loaded modules. Ask whether the call touched another process, such as a memory read or handle open against a security tool, a browser or an authentication service, and whether any unfamiliar module was loaded into the calling process. If Velociraptor is deployed in your environment, use an existing artifact or a reviewed custom artifact to collect the process memory map, loaded module list and open handles for the suspect process, and store the output with a hash. Confirm first that your Velociraptor version and artifact set support these collections, because capabilities vary by platform and release. Decide on isolation using a written rule: isolate when the caller is unsigned or unknown, when the target is a security control or credential store, or when the same pattern appears on other hosts. Otherwise keep the host online and monitor it.
Close the hour with evidence preservation and escalation. Preserve the raw events, the Wazuh or Security Onion alert, the process tree export and any Velociraptor output in write-once storage with a chain of custody note. Escalate to incident response when the caller cannot be explained within the window your playbook sets, and to the asset owner when the activity is an approved application that behaves unusually. For every alert closed as a false positive, record the binary, parent, user, target, the reason it was benign and the rule change made, such as a scoped exception or a revised Sigma condition. Tie each tuning change to the ATT&CK version your mapping targets, so later reviews can tell whether a change reflects new behavior or an outdated assumption.
Rehearsing Native API detection in a private cyber range
On Linux, the range should hold a small set of representative hosts: a jump host, an application server and a build or administration host, all forwarding audit and process telemetry to the same Wazuh or Security Onion stack used in production. Injects are scripted by the white cell and delivered as activity that calls native interfaces from ordinary user sessions and from a service account, so the blue team must separate expected administrative behavior from unexpected behavior. Good detection means an alert appears inside the window agreed before the exercise, and the alert names the correct host, user and parent process. Good response means the analyst records triage notes with the telemetry relied on, makes a documented containment decision, and logs lessons learned against the detection rule.
- Topology: Keep the hosts at the same kernel and audit configuration as production, and confirm which audit rules are active before the exercise starts.
- Injects: Vary the account type, the time of day and the parent process so the team cannot match on a single fixed pattern.
- Detection quality: Check host attribution as closely as alert timing, since a correct alert on the wrong host is a failed result.
- Response record: Require triage notes that cite the specific events reviewed, not a general statement that the alert was investigated.
- Lessons logged: Feed gaps back into the rule set and record the ATT&CK version the rule targets.
Before the exercise, confirm with your platform team which Linux audit sources are retained and for how long.
macOS endpoints are often managed fleet laptops or build machines, so the range should include both a managed workstation and an unmanaged developer-style host. Telemetry on macOS depends on the endpoint agent and the unified logging configuration in place, so the range must confirm which of these sources reach the SIEM before any inject runs. The white cell delivers injects as activity that uses native system interfaces from a standard user session and from an elevated administrative session. Good detection means the alert fires within the agreed window and attributes the activity to the correct device and user. Good response means documented triage, a containment decision recorded with its reasoning, and lessons logged against the endpoint coverage gaps found.
- Topology: Include one managed endpoint with the production agent and one unmanaged host, so the team sees how coverage differs.
- Injects: Mix user-level and administrator-level activity, and include one benign developer workflow to test false positive handling.
- Coverage check: Confirm with the endpoint vendor which process and file events are exported, since this varies by product and version.
- Attribution: Verify that the device identifier and the logged-in user in the alert match the range asset inventory.
- Response record: Capture whether containment would have disrupted the benign workflow, and note the business impact in the lessons log.
Ask your endpoint provider to confirm in writing which macOS telemetry fields are available before you commit to a detection expectation.
Windows hosts usually give the richest telemetry for Native API activity, which makes them the best place to test whether your detections are specific enough. The range should include a domain-joined workstation, a member server and a domain controller in a segregated test domain, with Sysmon or an equivalent sensor and Windows event forwarding feeding Wazuh or Security Onion. The white cell delivers injects that call native interfaces from user and service contexts, and mixes them with routine administrative tooling so that analysts must justify each alert. Good detection means an alert appears inside the agreed window, the correct host and account are named, and the process lineage is visible to the analyst. Good response means triage notes that cite the events reviewed, a containment decision with a recorded owner, and lessons logged against tuning changes.
- Topology: Keep the domain controller in an isolated test forest, never in a production domain, and document the isolation.
- Injects: Combine Native API calls with normal administrative activity so the team must separate them by context.
- Lineage: Check that the parent and child process relationship survives into the SIEM, because many Windows detections depend on it.
- Timing: Measure the interval from inject to alert against the window agreed in the rules of engagement.
- Tuning record: Log every rule change with the ATT&CK version and the exercise that prompted it.
Confirm with your Windows and SOC leads which event IDs and sensor configurations are in scope before the exercise is scheduled.
Questions detection engineers ask about T1106 Native API
Why is Native API so hard to separate from normal software behavior?
Native API calls are the ordinary way Windows, Linux and macOS programs talk to the operating system, so a single call tells you little on its own. The signal comes from context: which process made the call, what its parent was, whether the binary is signed and expected in that path, and whether the sequence of calls matches a known workflow. Build a baseline of legitimate software on your fleet first, then alert on deviations such as unsigned binaries calling sensitive APIs, unusual parent-child chains, or calls made from user-writable directories. Expect the baseline to take iteration, because development tools, installers and management agents all make heavy use of these interfaces.
How do we handle Process Access noise without missing real activity?
Process Access telemetry is high volume because security tools, debuggers, backup agents and monitoring products open handles to other processes constantly. Start by allowlisting known-good source binaries by signer, hash and install path, and scope rules to high-value target processes such as the Local Security Authority or domain-facing services rather than every process on the host. Tune in stages: run new rules in a logging-only mode in your SIEM for a defined period, review the top sources, and document each exclusion with an owner and a review date. Recheck exclusions after each ATT&CK release or endpoint agent upgrade, since both can change which behaviors are expected.
Are Sigma rules alone enough to detect T1106?
No. Sigma rules are a useful, portable way to express detection logic, but they only detect what your log sources actually collect. Native API activity often requires endpoint telemetry that goes beyond default Windows event logging, such as process creation with full command lines, module loads and process access events from a sensor like Sysmon or an EDR agent. Confirm that your Wazuh, Security Onion or other SIEM pipeline ingests those fields, check that Sigma field mappings match your backend, and pair rules with analytics that use baselines and host context. Treat each Sigma rule as one control in a layered set, not as the detection program itself.
How should we map T1106 detections to ATT&CK 20.0 data components?
Map each detection to the ATT&CK version you target, because ATT&CK v18 moved detections from technique pages into detection strategies and analytics, and later releases can rename or deprecate content. For T1106, the most relevant data components in the Enterprise ATT&CK 20.0 STIX bundle include Process Creation (DC0032), Command Execution (DC0064) and Application Log Content (DC0038), with other components where your environment provides them. Record the version, the DC IDs, the log source and the field used for each analytic in a shared mapping table. Review that table whenever MITRE publishes a new release, and check the MITRE ATT&CK updates page before each review.
How do we test T1106 detections without running live malware?
Test with benign, documented simulations that generate the same telemetry as the technique, run in an isolated environment and approved in writing before execution. Atomic-style test libraries and purpose-built emulation tools are common choices, but confirm each test's behavior and safety in your own lab before use. Validate each detection by checking that the expected event appears in the SIEM with the expected fields, that the alert fires once, and that the response playbook runs. Keep a test log with the date, ATT&CK version, rule version and result, so the same validation can be repeated after tuning changes. A private cyber range is a practical place to run these tests against production-like images.
How do we measure T1106 detection coverage over time?
Measure coverage as a set of observable outcomes rather than a single score. Track the share of in-scope platforms that send the required telemetry, the number of T1106 analytics that have passed a validation test in the last review cycle, the alert precision after tuning, and the mean time from alert to triage decision. Store these metrics in your SIEM or reporting tool and compare them against the ATT&CK version in use. Ask any service provider to show the raw test results and the mapping table, not only a summary chart, so your team can check the figures independently.
How DeployOpen builds and tests Native API detections
DeployOpen treats T1106 Native API as a detection engineering task inside your own environment, not a generic monitoring checklist. Work starts from a written scope, produces Sigma-based analytics mapped to the ATT&CK version you target, and proves them in a private cyber range before handover.
How we scope
- Confirm which operating systems, endpoint agents and telemetry sources cover Linux, macOS and Windows hosts in scope for T1106.
- Agree in writing which Process Creation, Module Load and Process Access data sources are available, and which gaps need closing first.
- Record the ATT&CK version and sub-technique set the detections will target, so mappings stay traceable after future releases.
How we build
- Write detection logic for Native API activity as Sigma rules and convert them to the Wazuh or Security Onion stack you already run.
- Tune thresholds and allowlists against your own baseline of legitimate software, so noisy system binaries do not flood the queue.
- Map each analytic to the Execution Prevention and Behavior Prevention on Endpoint mitigations, and note where the control is configured rather than detected.
How we hand over
- Deliver a rule set with a plain-language description of the behavior each rule detects, its data dependencies and known blind spots.
- Document a test plan that replays benign and simulated T1106 activity in the private cyber range, with expected alert outcomes recorded.
- Provide runbooks for triage, escalation and containment, and train the analysts who will operate the rules.
How we support
- Review rule performance after handover and adjust logic when ATT&CK releases rename, deprecate or revoke related content.
- Offer ongoing support, upgrades and continuous testing as a retainer, priced separately from the fixed-scope engagement.
- Retest the detections after changes to endpoint agents, operating system versions or logging configuration in your environment.
