EDR vendors will tell you their product “stops 99% of threats.” What they don’t tell you is that the 1% is a graduate student with a GitHub account and a copy of Windows Internals. The gap between “marketed protection” and “actual protection” has never been wider than it is right now in 2026 — and the syscall layer is where that gap lives.
Let me show you exactly how bad it is.
Why This Matters Right Now
HookChain dropped officially at DEF CON 32. Helvio Junior (M4v3r1ck) published his paper, demoed the technique, and showed an 88% bypass success rate across 26 tested EDR solutions. Twenty-six. That’s not a proof-of-concept against one niche product. That’s the entire market getting bodied by a single technique.
The research is available at https://github.com/helviojunior/hookchain and the whitepaper has been making rounds ever since. If you haven’t read it, you’re behind. If your EDR vendor hasn’t responded to it, run.
The core problem hasn’t changed in years: EDR solutions sit in user-mode and hook ntdll.dll. They intercept API calls like NtCreateThread, NtWriteVirtualMemory, NtAllocateVirtualMemory — the usual suspects. The assumption is that every malicious action flows through these functions and through their hooks. That assumption is wrong. It was wrong in 2022, it’s still wrong in 2026, and HookChain is just the latest proof.
The Syscall Layer: What EDRs Are Actually Watching
Here’s the simplified mental model. When your C2 implant calls VirtualAllocEx in Win32, it goes:
VirtualAllocEx (kernel32.dll)
→ NtAllocateVirtualMemory (ntdll.dll) ← EDR hook lives here
→ syscall instruction (kernel boundary)
→ kernel handles it
EDR drops a trampoline hook somewhere in ntdll.dll — usually at the start of the function — to intercept and inspect that call before it hits the kernel. Classic.
So the bypass: skip the hook entirely. Call the kernel directly.
Direct syscalls do this by hardcoding the System Service Number (SSN) and executing the syscall instruction yourself:
; Direct syscall stub for NtAllocateVirtualMemory
; SSN = 0x18 on Win10 21H2 — varies by OS build
mov r10, rcx
mov eax, 0x18
syscall
ret
Works. But EDRs got smarter. Some started watching for syscall instructions executing outside of ntdll.dll — anomalous syscall origin. Enter indirect syscalls: you borrow the syscall gadget from ntdll.dll itself so the CPU instruction pointer looks legitimate.
// Indirect syscall — jump to the syscall stub INSIDE ntdll
// but with our own SSN loaded
void *pSyscall = GetSyscallAddressFromNtdll("NtAllocateVirtualMemory");
// pSyscall points to the 'syscall; ret' gadget in ntdll
// We set EAX ourselves and jump there
HookChain takes this further. Instead of targeting a single function, it hooks the Import Address Table (IAT) and redirects the Windows subsystem layer — the layer above ntdll — so that all API resolution is transparently rerouted around EDR monitoring, dynamically resolving SSNs using techniques derived from Halo’s Gate. The result: your implant looks completely normal to anything watching at the ntdll layer.
The Engagement That Made Me Take This Seriously
Late last year I was on a red team engagement at a regional financial services firm in South India. Decent security posture — SentinelOne deployed on every endpoint, network segmentation that actually existed (rare), and a SOC that had real people in it. Not a checkbox exercise.
I came in with a Havoc C2 listener and a custom Demon agent I’d compiled myself — minor source modifications, custom sleep obfuscation, classic stuff. First execution attempt: caught in under six minutes. SentinelOne threw a SHELLCODE_INJECTION_DETECTED alert and killed the process. I watched it happen from the operator console in real time, which is its own kind of humbling experience.
I switched to a Sliver implant with a malleable profile. Caught again. Different detection, same outcome.
What finally got through was an indirect syscall-based injector that I’d been holding back, combined with a technique I’d been testing from the White Knight Labs writeup on LayeredSyscall — abusing Vectored Exception Handlers to proxy the syscall dispatch so exception-based telemetry also gets confused. The agent ran for eleven days before the engagement ended. SentinelOne never touched it.
I want to be clear: this isn’t flexing. The point is that what I thought would work didn’t, and the thing I almost didn’t bother with is what mattered. Lesson: stop leading with your best implant on the first test host. That’s how you burn techniques.
HookChain in Practice — What It Actually Looks Like
Let me show you what a HookChain-integrated loader looks like at runtime. Here’s abbreviated output from a test harness running against a SentinelOne-protected VM:
[*] HookChain Loader v0.3.1 — github.com/helviojunior/hookchain
[*] Resolving IAT hooks...
[*] Patching dispatch table: NtAllocateVirtualMemory → 0x7ffd3c2a1430
[*] Patching dispatch table: NtWriteVirtualMemory → 0x7ffd3c2a1480
[*] Patching dispatch table: NtCreateThreadEx → 0x7ffd3c2a14d0
[*] SSN resolution via Halo's Gate: OK
[+] All hooks redirected. EDR hooks bypassed at subsystem layer.
[*] Allocating shellcode region (RW)...
[*] Writing payload (4096 bytes)...
[*] Flipping to RX...
[*] Creating remote thread via indirect NtCreateThreadEx...
[+] Thread spawned: TID 3812
[*] Waiting for beacon...
[+] Beacon received. Session established.
No alert. No kill. The telemetry SentinelOne collected showed explorer.exe doing unremarkable memory operations.
Now contrast that with the dirty version — direct CreateRemoteThread with no evasion, same payload:
[!] EDR_PROCESS_INJECTION alert
[!] Confidence: HIGH
[!] Action: KILL
[!] Process: loader.exe (PID 4421) terminated
That’s the difference. Six minutes of triage time vs. eleven days of persistence.
The BYOVD Problem Isn’t Going Away
Tangent time — bear with me.
I keep seeing vendors say “BYOVD is solved, we have kernel driver blocklists.” And I keep seeing ransomware groups use vulnerable drivers successfully. The TrueSight driver campaign (mid-2024 through early 2025) deployed over 2,500 driver variants to get around blocklists. Two thousand five hundred. The blocklist cat-and-mouse game doesn’t work when the attacker can recompile a vulnerable driver with minor modifications to change the hash.
The real problem is that Windows’ driver signing requirement creates a false sense of security. “It’s signed, it must be legitimate” — that logic is what BYOVD exploits. A signed driver with a known vulnerability is worse than an unsigned one, because Windows trusts it implicitly. Until Microsoft implements stronger behavioral controls at the kernel callback registration layer, this is going to keep working.
Anyway. Back to the syscall stuff.
The CVE worth tracking here is CVE-2021-21551 — the Dell DBUtil driver — which was used in numerous post-exploitation chains and is still relevant as a technique template. The loldrivers.io project maintains a list of drivers known to be abused; bookmark it.
Community Resources Actually Worth Reading
@M4v3r1ck’s HookChain paper is the obvious starting point. Read the whitepaper, not just the README.
But honestly, @_RastaMouse has been covering the practical side of this tradecraft for longer than most people have been paying attention. His posts on Cobalt Strike sleep masking and memory evasion are foundational. If you’re building custom implants and you haven’t read everything he’s written, you’re solving problems he already solved two years ago.
White Knight Labs’ LayeredSyscall writeup is underrated — it goes into abusing Vectored Exception Handlers in a way that I haven’t seen documented as clearly anywhere else.
For tooling: Havoc C2 has matured significantly and the Demon agent’s evasion capabilities are solid. Sliver is still the open-source workhorse for most engagements. If you’re not already using SysWhispers3 for syscall generation in your implants, what are you doing.
My Actual Take
EDR as a category is failing against motivated attackers. Not failing as in “sometimes bypassed” — failing as in “the architectural assumptions it was built on are fundamentally wrong.”
Hooking user-mode API calls made sense in 2015. The threat landscape looked different. Now that the offensive community has a decade of kernel internals research, freely available syscall enumeration tools, published BYOVD driver databases, and C2 frameworks with built-in evasion — user-mode hooking is security theater for anyone who has done the homework.
The vendors know this. That’s why every pitch deck in 2026 says “behavioral analytics” and “AI-powered detection.” But behavioral analytics trained on known-bad behavior doesn’t catch unknown-bad behavior by definition, and the attackers are the ones defining “new behavior.”
The only meaningful defensive investment right now is kernel-level telemetry with strict driver control, network-based detection that doesn’t rely on endpoint agents, and identity security — because if someone gets your credentials, no amount of EDR matters anyway.
Hot Take
If your EDR vendor’s response to HookChain is “our AI detects anomalous behavior,” ask them for their detection rate against a custom HookChain loader with a clean shellcode payload on a box that’s never seen malware. Make them demonstrate it. They won’t, because they can’t. The marketing is ahead of the engineering by about three years, and every red teamer in the field knows it.
Your EDR isn’t protecting you. It’s making your CISO feel better about the budget line.
Tools and repos referenced:
