HookChain A new perspective for Bypassing EDR Solutions

HookChain: A New Perspective for Bypassing EDR Solutions

Speakers: Helvio Carvalho Junior

Conference: DEF CON 32

YouTube: https://www.youtube.com/watch?v=0L6TlFYwy2U

Overview

In the ever-escalating arms race between attackers and defenders, Endpoint Detection and Response (EDR) and Extended Detection and Response (XDR) solutions are critical components of modern cybersecurity strategies. However, the pervasive belief that these systems offer 100% protection is a dangerous misconception, as eloquently articulated by Helvio Carvalho Junior in his DEF CON 32 talk, "HookChain: A new perspective for Bypassing EDR Solutions." This presentation introduces HookChain, a novel technique designed to bypass the monitoring capabilities of EDRs and XDRs by manipulating user-land hooks within the Windows NTDLL.dll.

Helvio Carvalho Junior, also known as Maverick, delves into the intricate mechanisms of Windows system calls and how EDRs typically intercept these calls to detect malicious activity. He then reveals how HookChain subverts this process, operating entirely in user-land (Ring 3) and specifically targeting 64-bit systems. The significance of HookChain lies in its ability to circumvent security controls without touching the kernel (Ring 0) or modifying the original application code, presenting a formidable challenge to current EDR architectures.

This research underscores a fundamental truth in offensive security: a red teamer or penetration tester only needs to find one flaw to achieve their objective within a specific environment, not bypass every possible defense. HookChain serves as a potent reminder that even sophisticated EDR/XDR solutions are susceptible to innovative bypass techniques, urging a continuous evolution in defensive strategies and a critical re-evaluation of security postures that rely on a single "silver bullet."

Background

▶ Watch: Welcome and talk agenda overview (0:00)

To appreciate the ingenuity of HookChain, it's essential to understand the fundamental architecture of Windows operating systems and how security solutions typically operate within them. Windows employs a layered security model, primarily segregating operations into two privilege levels: Ring 0 (kernel land) and Ring 3 (user land). Applications and most user-facing software run in user land, while the core operating system components, device drivers, and critical security functions reside in kernel land.

The transition between user land and kernel land is tightly controlled and occurs via system calls. When a user-mode application needs to perform a privileged operation—such as allocating memory, creating a file, or launching a process—it cannot directly access kernel resources. Instead, it must invoke a system call, which acts as a gateway to the kernel. This process typically involves a sequence of function calls: a user application calls a high-level API in kernel32.dll, which then translates this request into a lower-level API call within NTDLL.dll. NTDLL.dll is the critical interface that prepares the necessary parameters and executes a special assembly instruction (e.g., syscall on 64-bit systems) to transition from user mode to kernel mode. The kernel then executes the requested function and returns the result to the user-mode application.

Modern EDR and XDR solutions heavily rely on monitoring these system calls to detect suspicious behavior. A common technique employed by these solutions is API hooking. EDR agents inject themselves into user-mode processes and modify the entry points of critical functions within DLLs like kernel32.dll and, more commonly, NTDLL.dll. Instead of calling the original system function directly, the application's call is redirected to an EDR-controlled "hook function." This hook function first inspects the parameters, logs the activity, or performs behavioral analysis. If the activity is deemed benign, the hook function then calls the original system function. If it's malicious, the EDR can block the operation, terminate the process, or trigger an alert. This proactive interception is the cornerstone of many EDRs' detection capabilities.

The problem, as highlighted by Helvio, is that EDRs themselves are operating within user land when performing these hooks. This creates a potential vulnerability: if an attacker can understand and mimic or subvert the EDR's hooking mechanism, they can bypass its monitoring. Prior work in EDR bypass often involves techniques like unhooking (restoring the original bytes of a hooked function), direct system calls (bypassing the hooked NTDLL function by crafting the syscall instruction directly), or syscall stubs (creating custom code that performs the syscall without calling NTDLL functions). HookChain takes a novel approach, essentially turning the EDR's own strategy against it.

Key Findings

▶ Watch: Motivation: No EDR silver bullet (2:00)

Helvio Carvalho Junior's research introduces HookChain as a significant contribution to the field of EDR/XDR bypass. The core findings and contributions of this technique are:

1. A Novel User-Land Bypassing Technique: HookChain is presented as a new method for circumventing the monitoring capabilities of EDR and XDR solutions. Unlike some other bypasses that might involve direct syscalls or unhooking, HookChain introduces a distinct methodology for redirecting system call execution.
2. Exclusive Focus on NTDLL User-Land Hooks: The technique specifically targets API hooks implemented by EDRs within the NTDLL.dll module, operating entirely within user-land (Ring 3). This is a crucial distinction, as it means HookChain does not require any kernel-level (Ring 0) interaction or privileges, making it potentially more stable and harder to detect than kernel-mode exploits.
3. 64-bit System Specificity: HookChain is designed and limited to 64-bit programming environments. This reflects the prevalent architecture of modern Windows systems and acknowledges the differences in system call mechanisms between 32-bit and 64-bit applications.
4. No Modification of Original Application Code: A key advantage of HookChain is that it does not necessitate altering the code of the application being monitored. This means an attacker can inject HookChain into an existing process or use it within their custom malware without needing to patch or modify legitimate software binaries.
5. Reversal of EDR's Own Strategy: Fundamentally, HookChain mirrors the EDR's own approach to monitoring. EDRs hook functions to intercept and inspect. HookChain, in essence, hooks the EDR's hooks (or rather, positions its own hooks in a way that EDRs fail to detect), demonstrating that the very mechanism used for defense can be exploited for offense. The speaker explicitly states, "EDR do this. Whoa, I can do this also."
6. Not a Tool, but a Technique: Helvio emphasizes that HookChain is a technique, not a ready-to-use tool. While he developed code to prove the concept, the research focuses on the methodology, which can be adapted and implemented in various ways by red teams and malware developers. He is not releasing a specific tool.
7. Undetectable Potential: The goal of HookChain is to achieve "full undetectable" status, at least within the specific environment being targeted. This aligns with the red team philosophy of needing to bypass a defense, not all defenses, to achieve an objective.

These findings collectively highlight a significant blind spot or vulnerability in common EDR/XDR user-land hooking implementations, pushing the boundaries of offensive security research and demanding a re-evaluation of defensive strategies.

Technical Deep Dive

▶ Watch: Understanding userland to kerneland transitions (4:10)

The technical foundation of HookChain lies in a deep understanding of the Windows system call mechanism and how EDRs typically intercept these calls. Helvio breaks down the process into several key stages, demonstrating how HookChain inserts itself into this flow.

At its core, any user-mode application requiring a privileged operation interacts with the operating system through a series of libraries. For example, if an application wants to allocate memory, it might call VirtualAlloc from kernel32.dll. kernel32.dll then acts as an intermediary, calling a corresponding lower-level function within NTDLL.dll, such as NtAllocateVirtualMemory.

NTDLL.dll is the crucial gateway. It's responsible for preparing the stack and registers with the necessary parameters for the system call and then executing the syscall assembly instruction. This instruction is the actual transition point from user mode (Ring 3) to kernel mode (Ring 0). Upon successful transition, the kernel executes the requested function (e.g., NtAllocateVirtualMemory in kernel space) and returns the result back to NTDLL.dll, which then passes it back up the call stack to the original application.

The speaker explains that the kernel maintains a table, conceptually similar to the System Service Descriptor Table (SSDT), where each system service number (SSN) corresponds to a pointer to a specific kernel function. When NTDLL.dll executes the syscall instruction, it passes an SSN, which the kernel uses as an index to find and execute the correct kernel function. Helvio mentions an "index from zero to I have no idea how much more than 400 numbers that match each ID from a pointer to a kernel function" (06:00), referring to this system.

EDR solutions typically operate by injecting a hook into the NTDLL.dll functions. When an application calls NtAllocateVirtualMemory, instead of executing the original NTDLL code that leads to the syscall instruction, the EDR's hook redirects execution to its own custom code. This custom code, controlled by the EDR agent, inspects the call, makes a decision (allow, block, alert), and then, if permitted, manually calls the original NtAllocateVirtualMemory function (or its unhooked equivalent) to proceed with the system call. This is essentially a "function in the middle" attack, as Helvio describes it (07:00).

HookChain leverages this understanding. Its methodology involves three main steps:

1. Resolve System Service Number (SSN): The first step for HookChain is to identify the specific System Service Numbers (SSNs) corresponding to the NTDLL functions it intends to bypass. This involves dynamically parsing NTDLL.dll to extract the SSNs associated with target functions (e.g., NtAllocateVirtualMemory, NtCreateRemoteThread, etc.). These SSNs are critical because they represent the direct identifier for the kernel-mode function.

1. Create a Custom Stub Function Table: Once the relevant SSNs are identified, HookChain constructs an internal table. This table maps each target SSN to the address of a custom stub function that HookChain controls. This stub function is designed to mimic the behavior of the original NTDLL function but without triggering the EDR's monitoring. The key is that these custom stubs will directly prepare the stack and registers and then execute the syscall instruction, completely bypassing any EDR-inserted hooks in the NTDLL function's prologue.

1. Redirect Execution to Custom Stubs: The most critical part of HookChain is the redirection. Instead of letting the application call the EDR-hooked NTDLL function, HookChain ensures that when the application attempts to call a monitored NTDLL function, its execution is rerouted to the corresponding custom stub function in HookChain's internal table. This rerouting might involve modifying import address tables (IAT), creating trampolines, or other code injection techniques to ensure that the application's calls land in HookChain's control. The speaker emphasizes that this is achieved without needing to change the original application's code (09:15), meaning HookChain can be injected into an existing process.

By implementing these steps, HookChain effectively creates its own "clean" path to the kernel. While EDRs are busy intercepting calls to the original NTDLL functions (which they have hooked), HookChain's custom stubs perform the direct syscall instruction, making the call directly to the kernel without passing through the EDR's monitoring logic. This allows the malicious operation to proceed undetected by the user-land EDR agent. The technique is limited to 64-bit systems because the syscall instruction and parameter passing conventions differ significantly from 32-bit systems (which often use int 0x2e).

Demo / Proof of Concept

▶ Watch: NTDLL's role in system call stack (5:40)

While the talk meticulously details the theoretical underpinnings and methodology of HookChain, the transcript does not include a live demonstration or detailed walkthrough of a proof-of-concept (PoC) in action. Helvio Carvalho Junior explicitly states, "I need to do some programming. I need to to create a code to prove the concept, but it is a technique, okay?" (10:00). This indicates that a PoC implementation exists to validate the technique.

The speaker also mentioned a public call for vendors to collaborate and get early access to the code, which went unanswered. However, after publishing some bypasses on LinkedIn, he received calls from vendors "just three weeks ago" (04:00) interested in testing the technique. This suggests that the PoC has been shared or discussed with industry players, even if not publicly shown during the conference presentation. The absence of a live demo in the transcript does not diminish the technical validity of the described methodology.

Defensive Implications

▶ Watch: HookChain's core steps: resolve SSN, create stub table (8:20)

HookChain presents significant challenges for current EDR and XDR solutions, particularly those that rely heavily on user-land API hooking for detection. The defensive implications are profound and necessitate an evolution in how these security products operate:

1. Rethink User-Land Hooking Reliance: EDRs that place their primary detection logic solely on user-land hooks in NTDLL.dll are directly vulnerable to HookChain. Defenders and EDR vendors must acknowledge that these hooks can be bypassed by techniques that understand the underlying system call mechanism and can craft direct calls to the kernel. This suggests a need to diversify detection methods beyond simple API interception.

1. Enhanced Behavioral Analysis: Since HookChain bypasses the initial API call interception, EDRs need to rely more heavily on post-execution behavioral analysis or contextual monitoring. This means detecting malicious activity not by what API was called, but by what happened as a result of the API call. For example, if HookChain is used to allocate executable memory or create a remote thread, the EDR might not see the NtAllocateVirtualMemory or NtCreateRemoteThread call, but it could potentially detect the subsequent execution of code in an unusual memory region or the creation of a suspicious thread in a legitimate process.

1. Kernel-Level Monitoring (with caveats): To truly counter techniques like HookChain, EDRs might need to incorporate more kernel-level monitoring. By placing hooks or filters in Ring 0, they could potentially intercept system calls after they have transitioned from user land, regardless of how they were initiated (via NTDLL or a direct syscall instruction). However, kernel-level monitoring introduces significant complexity, stability issues (e.g., potential for Blue Screens of Death), and compatibility challenges across different Windows versions and updates. It also raises the bar for attackers, requiring kernel exploits to bypass.

1. Hardware-Assisted Security: Leveraging hardware-assisted security features, such as Intel VT-x/AMD-V for virtualization-based security (VBS) or Control-flow Enforcement Technology (CET), could offer more robust protection. These technologies can enforce stricter memory and execution policies, making it harder for attackers to inject and execute arbitrary code or bypass control flow integrity checks, even if they manage to bypass user-land API hooks.

1. Memory Protection and Integrity: EDRs should strengthen their capabilities in monitoring and protecting memory regions, especially those belonging to critical system DLLs like NTDLL.dll. Detecting unauthorized modifications to .text sections or suspicious executable memory allocations could provide indicators of compromise. Memory integrity checks, such as those performed by Windows Defender Credential Guard, could also be extended.

1. Supply Chain and Trust Validation: While not directly addressed by HookChain, the broader implications suggest that relying solely on runtime monitoring is insufficient. Ensuring the integrity of software from its source and validating trust chains can prevent malicious code from being introduced in the first place.

1. Continuous Research and Adaptation: The talk itself is a testament to the need for continuous research. EDR vendors must actively engage with offensive security researchers and integrate their findings to improve their products. The speaker's initial difficulty in getting vendors to engage (04:00) highlights a potential disconnect that needs to be bridged for effective defense.

In summary, HookChain serves as a critical wake-up call, emphasizing that defenders must move beyond superficial API hooking and embrace a multi-layered, behavioral, and perhaps hardware-assisted approach to EDR/XDR. The "no silver bullet" philosophy applies equally to defensive strategies.

Key Takeaways

• No Silver Bullet in EDR/XDR: Modern EDR and XDR solutions, despite their sophistication, are not foolproof and can be bypassed. Relying solely on a single security product for complete protection is a dangerous misconception.
• HookChain Targets User-Land NTDLL Hooks: This novel technique specifically bypasses EDR/XDR monitoring by manipulating user-land hooks within the NTDLL.dll module, operating entirely in Ring 3.
• 64-bit Systems are the Focus: HookChain is tailored for 64-bit Windows environments, leveraging the specific system call mechanisms of this architecture.
• Bypasses Without Kernel Interaction: A key advantage is that HookChain achieves its bypass without needing kernel-level privileges or interaction, making it more stable and potentially harder to detect than kernel-mode exploits.
• Mimics EDR's Own Strategy: HookChain works by understanding how EDRs hook system calls and then creating its own "clean" path to the kernel by resolving System Service Numbers (SSNs) and using custom stub functions, effectively turning the EDR's defense mechanism against itself.
• Demands EDR Evolution: Defenders must evolve beyond simple API hooking, incorporating more robust behavioral analysis, potentially kernel-level monitoring (with caution), and leveraging hardware-assisted security to counter such advanced bypass techniques.

About the Speaker(s)

Helvio Carvalho Junior, also known by his alias "Maverick," is a distinguished figure in the cybersecurity community with a unique background. Before delving into the intricacies of low-level security, he pursued an undergraduate degree as an airplane pilot, showcasing a diverse skill set. Helvio holds the prestigious OSCP3 certification, being the first individual in Latin America to achieve this accomplishment, and is actively studying for the OSEE. His passion lies in low-level exploitation, including buffer overflows, shellcoding, malware development, and, critically, AV, EDR, and XDR bypasses. He is also the CEO of Sec4Us, a Brazilian company specializing in providing training, research, and consulting services in the cybersecurity domain.