Module 8: Full Chain, Detection & Countermeasures

The gate opens, but the watchtower sees everything -- or does it?

The Complete Execution Chain

Let us trace the entire Hell's Gate flow from process startup to syscall completion:

Detection Vector 1: Syscall Origin Validation

The most significant detection vector for direct syscalls is syscall origin validation. When the kernel receives a syscall, it can check where the syscall instruction was executed from (the return address in RCX). Legitimately, this should always be inside ntdll.dll's memory range.

C// Kernel-side syscall origin check (conceptual)
// In KiSystemCall64, RCX contains the return address (where syscall was called from)

PVOID syscallOrigin = (PVOID)TrapFrame->Rcx;  // Return address

// Get ntdll's memory range
PVOID ntdllBase = PsGetProcessNtdllBase(PsGetCurrentProcess());
SIZE_T ntdllSize = GetModuleSize(ntdllBase);

// Check if the syscall originated from within ntdll
if (syscallOrigin < ntdllBase ||
    syscallOrigin > (PBYTE)ntdllBase + ntdllSize) {
    // ALERT: syscall from outside ntdll!
    // This is a strong indicator of direct syscall usage
    LogSuspiciousSyscall(PsGetCurrentProcess(), syscallOrigin, SSN);
}

Detection Vector 2: ETW Syscall Telemetry

Event Tracing for Windows (ETW) provides kernel-level telemetry that cannot be bypassed by userland techniques. Several ETW providers are relevant:

The Threat Intelligence ETW provider (TI ETW) is particularly important. It is a kernel-level provider registered by the EtwTi (Threat Intelligence) routines in the kernel. It fires callback notifications for sensitive operations like cross-process memory writes, thread injection, and handle duplication -- regardless of whether the syscall came through ntdll or via a direct invocation.

C// Example: ETW TI provider detects NtAllocateVirtualMemory
// in a remote process, even via direct syscall
//
// The kernel function NtAllocateVirtualMemory internally calls:
//   EtwTiLogAllocExecVm()
// which generates an ETW event with:
//   - Caller process ID
//   - Target process ID
//   - Base address
//   - Size
//   - Protection flags
//   - Call stack (including the suspicious return address)
//
// The EDR's kernel-mode ETW consumer receives this event
// and can correlate it with other activity

Detection Vector 3: Kernel Callbacks

Windows provides kernel callback mechanisms that EDR drivers register with to receive notifications about security-relevant events:

These kernel callbacks fire based on the kernel operation, not on how the syscall was invoked. When NtCreateThreadEx creates a thread (whether called via ntdll or direct syscall), the thread creation notify callback fires. The EDR's kernel driver receives the notification with the process ID, thread ID, and start address -- enough to detect injection.

Detection Vector 4: Call Stack Analysis

Modern EDRs perform call stack inspection during kernel callbacks and ETW event processing. The call stack reveals the origin of the syscall:

C// Legitimate call stack for NtAllocateVirtualMemory:
//   ntdll!NtAllocateVirtualMemory+0x14      (syscall instruction)
//   KERNELBASE!VirtualAlloc+0x47             (wrapper)
//   myprogram!main+0x123                     (application code)
//   kernel32!BaseThreadInitThunk+0x14

// Suspicious call stack (direct syscall via Hell's Gate):
//   malware.exe!HellDescent+0x0A             (syscall from unknown module!)
//   malware.exe!main+0x456                   (caller)
//   kernel32!BaseThreadInitThunk+0x14

// The absence of ntdll in the call stack is a STRONG indicator

The Evolving Arms Race

Countermeasures Summary

OPSEC Considerations

If you are studying these techniques for red team operations or security research, consider the following operational security points:

C// OPSEC checklist for direct syscall implementations:

// 1. STATIC SIGNATURES
//    - DJB2 hash constants are known IOCs
//    - The HellsGate/HellDescent function names are signatured
//    - The wSystemCall global variable pattern is detectable
//    Solution: Use custom hash algorithms, randomize names, obfuscate

// 2. BEHAVIORAL INDICATORS
//    - PEB walking + EAT parsing sequence is suspicious
//    - Rapid succession of direct syscalls from non-ntdll code
//    - Allocate + Write + Protect + CreateThread pattern
//    Solution: Add delays, vary execution order, use alternative techniques

// 3. MEMORY INDICATORS
//    - The .text section contains syscall instructions (0F 05)
//    - The ASM stub pattern is identifiable in memory
//    - Shellcode in non-image-backed memory
//    Solution: Encrypt stubs when not in use, use stomped modules

// 4. BUILD ARTIFACTS
//    - Debug symbols, PDB paths, compiler metadata
//    - Import table reveals CRT usage (if not minimized)
//    - Section names and characteristics
//    Solution: Strip symbols, minimize imports, customize PE metadata