SITH STALKER // INDIRECT SYSCALL ENGINE RESEARCH

22DIV / george wu // CSEC research on own hardware // June 2026

OVERVIEW

Sith Stalker studies how security products that hook ntdll.dll user-mode functions can be bypassed using direct and indirect syscall techniques. Understanding this bypass class is essential for EDR developers — if defenders do not understand the bypass, they cannot design detection for it.

The project implements a syscall stub engine that resolves Windows native API numbers at runtime and calls the kernel directly, bypassing ntdll.dll hooks entirely.

INDIRECT SYSCALLS XOR-ENCRYPTED HASH TABLE MASM STUB GENERATION CSEC RESEARCH

TECHNIQUE

The Hook Problem

EDR products inject a DLL into every process and overwrite the first few bytes of NtCreateFile, NtOpenProcess, and similar functions in ntdll.dll with a jump to their inspection code. Every call goes through the EDR before reaching the kernel.

The Bypass

The Windows syscall number for each native API is stable within a Windows version. Sith Stalker resolves syscall numbers by scanning a clean copy of ntdll.dll (not the hooked in-memory version), builds an XOR-encrypted hash table of function names to syscall IDs, and generates MASM stubs that call the kernel directly via syscall instruction — never touching the hooked entry points.

ComponentFunction
gate_v2.cRuntime syscall number resolution, hash table population
gate_stub_v2.asmMASM stubs — set RAX to syscall ID, execute syscall instruction
XOR hash tableEncrypted at rest, decrypted per-call — avoids static signature

DEFENSIVE IMPLICATIONS

DETECTION APPROACH
Kernel-level callstack inspection

Indirect syscalls bypass user-mode hooks but the kernel still receives the call. Modern EDRs moving to kernel callbacks can detect syscalls whose callstack does not originate from the expected ntdll.dll return address — a strong behavioural indicator of syscall-based bypass.

for cheyanne. always.