Security researchers have highlighted a new evasion framework called SindriKit, which decoupling system call resolution from execution to evade EDR call-stack telemetry. By leveraging PEB traversal and dynamic stack spoofing, it poses a direct challenge to modern security monitoring tools.
Decoupling the resolution of System Service Numbers (SSNs) from execution pipelines represents a major evolution in evasion tactics, allowing threat actors to manipulate memory footprints dynamically without restructuring compiled payload binaries. This technique has been brought to light through SindriKit, an open-source C-based evasion framework designed to bypass modern Endpoint Detection and Response (EDR) platforms. By modularizing the process of resolving system call numbers and executing them via indirect call gadgets, the framework successfully evades call-stack telemetry during crucial kernel transitions. Defenders must now adapt to a threat landscape where static signatures and basic dynamic analysis are rendered blind by decoupled stack-spoofing engines.
Historically, malware developers and offensive security researchers relied on direct system calls to bypass user-mode API hooks placed by security products inside the native Windows library, ntdll.dll. When security vendors countered by monitoring the source of system call transitions, attackers shifted to indirect system calls. These calls jump to a legitimate syscall instruction within ntdll.dll to make the call appear authorized. However, modern EDR platforms have integrated call-stack tracing, verifying whether the return address on the execution stack originates from a legitimate module. SindriKit addresses this telemetry head-on by decoupling finding the SSN from executing it, introducing a structured software architecture paradigm to malware development.
Resolve ntdll.dll base and extract system service numbers dynamically
Walk the .pdata section of kernel32.dll to find 'Fat Frames' (>= 120 bytes)
Construct synthetic stack layout with clean unwinding and 16-byte alignment
Jump to a legitimate syscall gadget in ntdll.dll to execute system call
The core architectural innovation of SindriKit lies in its complete separation of SSN resolution, gadget discovery, and execution mechanics. Most traditional offensive tools tightly couple their resolution logic with their assembly execution stubs, requiring significant manual rewrites if an operator needs to pivot from direct system calls to indirect system calls. SindriKit implements a dynamic pipeline where developers can dynamically swap components at runtime. This modular approach is handled through a sequence of configuration calls that set the resolver, invoker, and gadget finder components dynamically.
To establish an execution path without triggering static import table alerts, SindriKit begins by dynamically resolving necessary system APIs in memory. The framework utilizes a custom Process Environment Block (PEB) walker to locate the base memory address of ntdll.dll. This bypasses the need to call standard Windows API functions such as GetModuleHandle or LoadLibrary, which are heavily monitored by defensive tools. Once the base address is resolved, the framework parses the Export Address Table (EAT) of the module to locate system calls.
To determine the exact SSN required for a specific system call, such as NtAllocateVirtualMemory, the framework employs an API scanning utility. This process reads the function bytes directly from memory, mapping out system calls and extracting their associated numbers. By performing this resolution dynamically at runtime, the payload can seamlessly adapt to different Windows kernel builds without hardcoding static numbers, which frequently change between operating system updates.
To execute system calls indirectly, SindriKit must locate a legitimate syscall; ret instruction pair within the address space of ntdll.dll. The framework implements a custom scanning module that searches the memory of the natively loaded module for these execution gadgets. Once a valid gadget is located, its memory address is stored in the execution pipeline. Rather than invoking the system call directly from the payload's memory space, which would instantly trigger call-stack telemetry flags, the invoker jumps directly to the legitimate gadget inside ntdll.dll.
Before making this indirect transition, the framework must ensure that the CPU registers and execution stack conform to strict operating system requirements. On x64 Windows systems, the call stack must be 16-byte aligned before calling any function. Failing to maintain this alignment causes immediate stability issues or system crashes. SindriKit utilizes custom Microsoft Macro Assembler (MASM) stubs to handle this alignment, preparing the stack frame precisely before executing the jump to the indirect gadget.
While locating indirect system call gadgets helps bypass basic hook detection, advanced EDR agents perform thread call-stack unwinding using the native RtlVirtualUnwind function. This check allows the security agent to trace the execution path back to its root. If the unwind process reveals that the call originated from unbacked, executable memory (such as a private heap or a shellcode allocation), the activity is classified as malicious. To counter this, advanced versions of the framework implement deep stack spoofing.
To trick the virtual unwinder, the execution stack must appear to contain a legitimate sequence of function calls originating from a trusted system library like kernel32.dll. The evasion framework achieves this by dynamically parsing the Exception Directory (the .pdata section) of natively loaded Windows DLLs. The .pdata directory contains an array of RUNTIME_FUNCTION structures used by the operating system for exception handling and stack unwinding. By reading these structures, the framework calculates the exact stack size allocated by legitimate system functions.
The evasion engine specifically hunts for what are known as "Fat Frames", which are legitimate, natively loaded functions that allocate a significant amount of stack space (typically 120 bytes or more). This massive stack space provides enough shadow space to host system call arguments and a trampoline pointer without corrupting adjacent data. To prevent defenders from establishing simple, deterministic signatures based on the chosen decoy function, the framework randomizes its selection of these Fat Frames using entropy derived from system call hashes and memory addresses.
Once a suitable Fat Frame is identified, the framework constructs a synthetic stack layout. It places the address of a trampoline instruction (a simple RET inside the legitimate function body) as the primary return target. The actual return pointer of the malicious payload is hidden within the spoofed stack frame. When a kernel transition occurs, the EDR's virtual unwinder inspects the stack and reads a clean, structurally sound call chain back to kernel32.dll, failing to find any trace of the payload's memory space. Upon return, the CPU executes the trampoline, popping the hidden pointer and safely routing execution back to the payload's cleanup routine.
The availability of highly modular evasion frameworks like SindriKit lowers the barrier of entry for sophisticated adversaries looking to bypass enterprise defensive controls. These techniques allow off-the-shelf malware and custom implants to evade advanced detection mechanisms, rendering standard security monitoring ineffective against post-exploitation activities such as process injection and memory-only execution. For organizations aiming to test their defensive posture against these advanced techniques, implementing Red Team Operations is essential to simulate realistic adversary behaviors and identify telemetry gaps.
In addition to advanced simulations, security teams must ensure that their infrastructure is audited regularly to prevent initial access vectors that adversaries exploit to deploy these evasion tools. Conducting thorough Penetration Testing across corporate networks, applications, and APIs helps identify weaknesses before attackers can deploy highly evasive payloads. Furthermore, integrating memory protection policies, such as Hardware-Enforced Stack Protection (Intel CET), can completely neutralize stack-spoofing techniques by validating return addresses against a hardware-based shadow stack.
If your team may be exposed to a similar threat, FemtoSec can help validate blast radius, prioritize remediation, and connect the issue to a practical security program.
Underground distribution of tools like Digital Keylogger v3.3 highlights the ongoing risk of credential harvesting. When coupled with advanced tactics like the DarkHotel APT group's hotel Wi-Fi hijackings, enterprises face severe exposure risks. Learn the mechanics of kernel keylogging and how to protect your assets.
The commercial sale of SpyNote Pro Android RAT on underground forums highlights a growing mobile threat. Discover how this malware abuses accessibility services, performs dynamic payload execution, and executes overlay attacks to steal sensitive corporate credentials and bypass multi-factor authentication.
July 3, 2026
A threat actor known as the Infrastructure Destruction Squad has commercialized and leaked the source code for TRK25 ADVANCED SCADA, a PyQt5-based tool that targets industrial control systems, remote management ports, and Modbus-enabled machinery.
Defending against decoupled system calls and stack-spoofing engines requires a transition from static signature monitoring to behavioral and architectural detection. Since these tools operate entirely in memory, traditional file-based scanning provides minimal protection. Security teams must deploy detection rules targeting anomalous system behaviors and memory access patterns.
To detect compiled instances or unstripped binaries of this evasion framework within an enterprise environment, security operations centers can utilize specialized YARA rules. The following rule targets specific function names and the characteristic MASM stack-spoofing assembly patterns used to arrange spoofed frames in memory:
rule SindriKit_Evasion_Framework {
meta:
description = "Detects SindriKit evasion framework stubs, functions, and spoofing mechanics"
author = "FemtoSec Threat Intelligence"
date = "2026-07-09"
reference = "Internal Analysis of SindriKit Evasion Utilities"
strings:
$func_1 = "snd_syscall_resolve_ssn_scan"
$func_2 = "snd_syscall_indirect_invoke_asm"
$func_3 = "snd_syscall_find_gadget_scan"
$func_4 = "snd_syscall_find_spoof_scan"
$func_5 = "snd_peb_get_module_base_by_hash"
$masm_spoof_x64 = { 4C 89 04 24 48 8D 05 [4] 48 89 44 24 08 48 8B 45 10 }
condition:
any of ($func_*) or $masm_spoof_x64
}Organizations should configure their security information and event management (SIEM) systems and EDR agents to flag the following highly anomalous behavioral markers:
Anomalous Exception Directory Access: Monitor user-mode processes that read the .pdata sections or exception directories of kernel32.dll or ntdll.dll. Legitimate applications rarely parse exception directories dynamically unless they are performing active debugging or complex just-in-time (JIT) code compilation.
Unbacked Memory Execution: Flag system call execution threads where the instruction pointer points to memory pages marked as PAGE_EXECUTE_READWRITE or areas not backed by a physical file on disk.
Anomalous PEB Traversal: Detect processes that repeatedly traverse the InLoadOrderModuleList within the Process Environment Block without using official Windows API wrappers. This often indicates manual API resolution by an evasive loader trying to hide its import table footprints.
In the event that an evasive payload utilizing decoupled system calls is identified, immediate containment is critical. The compromised host must be isolated from the network immediately to prevent lateral movement. Security analysts should capture a physical memory dump of the affected processes before termination, as the volatile payload exists entirely fileless within the spoofed thread context. Finally, ensuring that all endpoint operating systems are configured with strict process mitigation policies, such as blocking unsigned modules, significantly limits an attacker's ability to inject code into legitimate processes.