Module 1: EDR Call Stack Analysis

Every API call leaves a trail of return addresses. EDRs read that trail like a forensic report.

1. What EDRs See When Code Runs

Modern EDR products don't just scan files on disk. They install kernel-mode drivers that subscribe to a set of notification callbacks built into the Windows kernel. These callbacks fire in the context of the calling thread, giving the EDR direct access to the thread's user-mode stack.

The critical detail: when ObRegisterCallbacks fires because your code called NtOpenProcess with PROCESS_ALL_ACCESS, the callback executes on your thread. The EDR kernel driver can read your thread's user-mode stack directly from kernel mode. It doesn't need to inject anything — it's already running in your context.

2. Stack Walking with RtlWalkFrameChain

When the kernel callback fires, the EDR calls one of two APIs to capture the current thread's stack frames:

C (Kernel Mode)// Captures an array of return addresses from the current call stack
ULONG RtlWalkFrameChain(
    PVOID  *Callers,     // Output: array of return addresses
    ULONG  Count,        // Max frames to capture
    ULONG  Flags         // 0 = kernel frames, 1 = user frames
);

// Alternative: captures from the calling thread's stack
USHORT RtlCaptureStackBackTrace(
    ULONG  FramesToSkip,
    ULONG  FramesToCapture,
    PVOID  *BackTrace,
    PULONG BackTraceHash
);

Both functions return an array of return addresses. Each return address is the instruction pointer (RIP) that will be returned to when the current function completes. The EDR iterates through this array and, for each address, determines which module it belongs to.

The EDR checks each return address against the list of loaded modules (from the PEB's InMemoryOrderModuleList or via MmGetSystemAddressForMdl). If a return address falls within ntdll.dll, kernel32.dll, or kernelbase.dll, that's expected. If it falls in a region that isn't mapped to any file on disk, that's a problem.

3. Backed vs Unbacked Memory

This distinction is the foundation of call stack-based detection:

When the EDR walks your call stack and finds a return address like 0x000001A4F2C01337, it checks: does this address fall within any loaded module's address range? If not, it checks the VAD (Virtual Address Descriptor) tree. If the VAD entry shows MEM_PRIVATE with no file backing, the verdict is clear: code is executing from unbacked memory.

4. What a Legitimate Call Stack Looks Like

Every Windows thread begins execution at the same two functions. This is hardcoded into the operating system's thread initialization path and is the same for every process on every Windows version:

Call Stack// Every normal thread in Windows starts with this exact chain:
ntdll!RtlUserThreadStart         ; Thread entry point (set by kernel)
  ntdll!BaseThreadInitThunk      ; Called by RtlUserThreadStart (kernel32 forwarded)
    application!actual_function  ; The function passed to CreateThread()
      ...                        ; Whatever the function calls

When a thread calls NtAllocateVirtualMemory, the EDR expects to see a call stack that terminates with RtlUserThreadStart at the bottom and BaseThreadInitThunk above it. These two functions are the anchor frames that prove the thread was legitimately created by the OS.

EDRs validate this pattern. If the bottom two frames are missing, if they're in the wrong order, or if there's unbacked memory between the Nt* call and BaseThreadInitThunk, the call stack is flagged as anomalous.

5. The Problem for Shellcode and BOFs

When shellcode or a Beacon Object File calls a sensitive API like NtAllocateVirtualMemory, the call stack reveals the truth:

Suspicious Stack// Shellcode calling NtAllocateVirtualMemory via indirect syscall:
ntdll!NtAllocateVirtualMemory     ; syscall stub (return addr in ntdll = good)
0x00000234A8001200                ; UNBACKED - shellcode called the stub
0x00000234A8000050                ; UNBACKED - shellcode entry point
                                  ; Missing: RtlUserThreadStart, BaseThreadInitThunk!

This is the fundamental problem. Every technique that runs code from dynamically allocated memory — shellcode, BOFs, reflective DLLs — produces a call stack with unbacked return addresses. Direct syscalls, indirect syscalls, and even simple function pointer calls all have the same weakness: the return address chain exposes the true origin of the call.

6. ETW and Kernel-Level Telemetry

Beyond call stack analysis, EDRs also leverage Event Tracing for Windows (ETW) and the Microsoft-Windows-Threat-Intelligence (EtwTi) provider. This kernel-level telemetry is separate from stack walking and monitors specific API patterns:

It is important to understand that Draugr addresses a specific detection surface: call stack analysis during kernel callbacks. It does not suppress ETW telemetry, avoid kernel callback registration, or interfere with other detection layers. A comprehensive evasion strategy would combine Draugr's stack spoofing with additional techniques for ETW and other telemetry sources.

Key Terminology

7. What Draugr Does

Spoofed Stack (what the EDR sees)ntdll!NtAllocateVirtualMemory     ; The actual syscall
kernel32!BaseThreadInitThunk      ; SYNTHETIC FRAME (Draugr placed this)
ntdll!RtlUserThreadStart          ; SYNTHETIC FRAME (Draugr placed this)
                                  ; Clean termination - looks like normal thread init

Draugr's approach is fundamentally different from timer-based stack spoofing (like ThreadStackSpoofer). Instead of spoofing the stack only during sleep, Draugr spoofs the stack at the exact moment of the sensitive API call — when the kernel callback fires and the EDR inspects the stack.