What is Native API Abuse – Bitdefender TechZone

An incident responder reviewing endpoint telemetry sees a suspicious memory write complete in a target process. The injected content executed, yet no NtWriteVirtualMemory call appeared in the EDR hook trace.

The operation was invisible to the sensor's usermode hook layer because the attacking loader never touched ntdll's hooked stub. It issued the syscall instruction directly — Extended Accumulator Register (EAX) preloaded with the correct service number, execution transferred straight into the kernel. The hook was never invoked because it was never reached.

The detection signal that eventually flagged the activity was a syscall address range check: the syscall instruction address was outside the address range of ntdll as mapped in the process. That discrepancy catches one family of this evasion class. The other two require sensors that operate inside ntdll's address range or at the kernel layer, beyond where usermode sensors can reach. Each bypass family exploits a different property of Windows syscall dispatch. The detection section below maps which signals catch which families — and which blind spots each signal carries.

Native API abuse is not an exploit technique. It does not attack a vulnerability in the target process or the operating system. It uses Windows' own syscall dispatch mechanism — the architecture that every process on the system uses legitimately — to issue sensitive operations while bypassing the EDR's interception layer.

The distinction that matters for detection: because the bypass operates at or below the usermode hook surface, the EDR's hook never executes. Detection depends on sensors that operate below that surface — kernel callbacks, ETW-TI events, hypervisor-level monitoring — not on the hook state of ntdll in the attacking process. The tool issuing the syscall is irrelevant. The mechanism is what matters.

Win32 API functions — CreateRemoteThread, WriteProcessMemory, and their peers — are thin wrappers. Each translates to a corresponding Native API function exported from ntdll.dll: NtCreateThreadEx, NtWriteVirtualMemory, and so on. Each ntdll export contains a short stub that loads a System Service Number (SSN) into the EAX register and executes the syscall instruction, transferring execution from usermode into the Windows kernel. The kernel reads the SSN, looks up the corresponding function in the System Service Dispatch Table (SSDT), and invokes it.

ntdll is the lowest layer of Windows accessible from usermode. Below it sits the kernel, reachable only through the syscall gate. MITRE ATT&CK T1106 covers the abuse of this boundary to execute process operations while bypassing higher-level API monitoring.

EDR products hook ntdll stubs because it is the logical intercept point: the stubs run in the same address space as the inspected process, carry full call context, and are reachable without kernel modifications. The mechanism works because Windows allows a process to modify its own virtual memory, including its private copy of ntdll. The EDR overwrites the first bytes of each stub with a JMP instruction into its inspection engine. What makes this design convenient for security vendors is also what makes it bypassable: the hook lives entirely in the process's private committed memory mapping for ntdll. It is not written to the on-disk image, nor is it enforced by hardware. Any code running in that process with write access to its own memory space can route around it.

Unhooking

If an EDR hook lives in the process's private memory mapping of ntdll, replacing that mapping with a clean version removes the hook entirely without altering the on-disk binary.

Three practical implementation variants:

• Disk reloading: Reading ntdll.dll directly from \System32\ on disk and copying its clean .text section over the hooked in-memory section.

• KnownDlls mapping: Mapping ntdll directly from the \KnownDlls\ section object — a repository of pre-mapped system DLL images maintained by the Session Manager at boot that EDR hooks never touch.

• Section remap: Calling NtMapViewOfSection to map a fresh view of ntdll's image file section directly over the process's existing hooked mapping.

Why this works: EDR hooks are injected into memory by the security agent after the process loads. They are never written to the on-disk image, never reflected in the \KnownDlls\ section, and not tracked by the Windows kernel. Overwriting the modified in-memory mapping discards the hook bytes and restores original native stubs.

The detection angle: Anomalous NtMapViewOfSection calls requesting an ntdll image mapping outside the standard Windows loader initialization sequence, as well as .text section memory modification events or unexpected page permission changes (PAGE_EXECUTE_READWRITE) during section remapping.

Dynamic SSN Resolution: Hell's Gate, Halo's Gate, Tartarus' Gate

Direct and indirect syscalls both require the correct System Service Number (SSN) for each target function. SSNs are not static — they change across Windows major releases and even between cumulative updates within the same release. A loader using a hardcoded SSN for NtWriteVirtualMemory on Windows 10 22H2 will issue the wrong syscall on Windows 11 24H2. The kernel then dispatches whichever function happens to correspond to that provided SSN, resulting in undefined behavior or a process crash.

Dynamic resolution solves this problem through several evolving techniques:

• Hell's Gate (2020): Scans each ntdll stub for the mov eax, <SSN> instruction at the stub's entry point and reads the SSN from that immediate value — a technique that works reliably when the stub is intact and unhooked.

• Halo's Gate: Addresses scenarios where the target stub is hooked and its opening bytes are replaced with a JMP. It scans neighboring functions in ntdll's export table and infers the target function's SSN by offset, exploiting the predictable numeric increment across adjacent syscall stubs.

• Tartarus' Gate: Extends this logic to handle stubs that are selectively patched mid-instruction or protected by non-standard hooks, using anomaly checking across multiple neighboring exports to calculate the correct SSN.

The detection angle: A loader relying on dynamic resolution must iterate ntdll's export table and inspect raw bytes across the .text section at runtime. This sequential byte-reading scan pattern is distinct from standard loader behavior and serves as a key behavioral indicator when correlated with subsequent suspicious process or memory operations.

No signal below catches every bypass family; the value is in knowing which one each covers and where it goes blind. Each is rated against a standard Windows 10/11 endpoint with a kernel-mode sensor present. The detection angle for each technique is covered in its section above.

Reliability High means the signal produces very few false positives on an endpoint with a kernel-mode sensor present. Reliability Medium means it requires tuning or correlation before it is actionable.

Correlation Strategy: A single syscall address anomaly in isolation carries low confidence; that same signal immediately preceding remote thread creation in a high-value process is a high-confidence injection indicator. When an anomaly triggers:

Every control below assumes the usermode hook will be bypassed and shifts detection to layers beyond where usermode evasions can reach.

Bypass techniques that operate at or below the usermode hook surface require detection sensors that operate at the kernel layer, beyond where usermode evasions can reach.

Kernel-API Monitoring is the layer that catches the attack in the demonstration. GravityZone's kernel driver registers callbacks for process creation, thread creation, and module loading, while also subscribing to ETW-TI events — which the kernel generates regardless of whether the call passed through ntdll. Because it operates in kernel mode, it can unwind the call stack upon syscall completion. This is the exact signal that exposes Havoc's Demon agent: while its syscall executes from inside ntdll's mapped range and passes the address origin check, its return-address chain exits ntdll without passing through the expected caller hierarchy.

Process Protection pairs Advanced Threat Control (ATC) with kernel-mode Process Introspection to monitor process behavior at runtime. ATC applies over 300 behavioral patterns alongside machine learning to process groups during execution. It keys on behavioral sequences — anomalous cross-process memory allocation, RWX memory regions in processes lacking legitimate JIT runtimes, suspicious handle requests, and remote thread creation — rather than the specific API path used. This sequence-based focus preserves detection effectiveness even after usermode instrumentation is bypassed. Process Introspection complements ATC at the kernel level by identifying trusted processes being abused as injection targets.

The Endpoint Sensor (EDR) and GravityZone XDR Correlation Engine consolidate handle requests, memory allocations, thread creations, and network connections into a single incident graph. This ties the anomalous syscall directly to the injection payload it served instead of leaving it as an isolated event, while Historical Search exposes the full execution context for Security Operations Center (SOC) investigation.

MITRE ATT&CK T1106: Native API — technique reference covering usermode Native API use to execute process operations while bypassing higher-level monitoring.

SysWhispers3, GitHub (klezVirus) — current generation of direct syscall stub generation tooling; documents the SSN resolution problem and its evolution across SysWhispers versions.

Outflank, "Direct Syscalls in Beacon Object Files" (December 2020) — primary documentation of direct syscall use in Cobalt Strike BOF payloads.

Hell's Gate (smelly__vx and am0nsec, 2020) — foundational SSN dynamic resolution technique; the lineage origin for Halo's Gate and Tartarus' Gate.