Listen to this Post
Introduction:
Virtualization-Based Security (VBS) and Hypervisor-protected Code Integrity (HVCI) are cornerstone mitigations in modern Windows versions, designed to prevent kernel-mode code injection and modification. However, attackers continue to evolve, turning data‑only attacks into full code execution by manipulating control flow through existing, legitimate threads. This article dissects a novel technique that abuses suspended threads to redirect execution into a ROP chain, effectively bypassing HVCI on Windows 11 25H2. We will explore the internals, provide step‑by‑step guidance for security researchers, and discuss how to defend against such sophisticated exploits.
Learning Objectives:
- Understand the role of VBS and HVCI in protecting the Windows kernel.
- Learn how suspended threads can be hijacked to influence control flow.
- Explore the construction of ROP chains in an HVCI‑enabled environment.
- Gain hands‑on experience with debugging tools and kernel‑mode analysis.
- Identify detection and mitigation strategies against thread‑abuse attacks.
You Should Know:
- Understanding Windows 11 25H2 Security Features: VBS and HVCI
VBS uses hardware virtualization to isolate critical system processes from the main OS, while HVCI ensures that all kernel‑mode code is signed and has not been tampered with. Together, they prevent direct code injection and execution of unsigned code. To check if these features are enabled on your system:PowerShell: Check VBS and HVCI status Get-ComputerInfo -Property "DeviceGuard", "HyperVisorPresent"
Alternatively, run `msinfo32.exe` and look for “Virtualization‑based security” and “Hypervisor‑enforced code integrity”. Under HVCI, any attempt to modify executable code pages or inject shellcode will trigger a violation, forcing attackers to use return‑oriented programming (ROP) with existing kernel code.
2. The Anatomy of a Suspended Thread
Threads can be suspended via API calls like `SuspendThread` or by the kernel during certain operations. A suspended thread’s execution context (registers, stack, instruction pointer) is preserved in its kernel thread object. Inspecting threads on a live system can be done with:
List all threads of a process (e.g., explorer.exe) Get-Process -Name explorer | Select-Object -ExpandProperty Threads
For deeper analysis, WinDbg is indispensable. Attach to a target process or the kernel and use:
!process 0 0 explorer.exe Find process !thread <thread_address> Examine thread details
The thread’s `CONTEXT` record holds the register state, including `RIP` – the instruction pointer that can be hijacked.
3. Turning Data‑Only Attacks into Code Execution
A data‑only attack might corrupt a pointer or a flag, but cannot directly execute code under HVCI. By targeting a suspended thread, an attacker can overwrite its context (e.g., RIP, RSP) to point to a ROP chain located in a readable/writable data section. When the thread is resumed, execution resumes at the new RIP, now inside the ROP chain. This bypasses HVCI because no code is modified – only data (the thread context) is changed.
4. Crafting a ROP Chain for HVCI‑Protected Environments
ROP under HVCI requires gadgets from kernel modules that are already loaded and signed. Common targets are ntoskrnl.exe, win32k.sys, and ci.dll. Gadgets must avoid violating Control Flow Guard (CFG) and Intel CET if enabled. Use WinDbg to find gadgets:
lm m ntoskrnl List module details !dh nt Dump headers to find code section s -b 0xfffff800`00000000 L?0x7fffffff 0xc3 Search for RET (0xc3) instructions
Tools like `rp++` or `mona.py` can automate gadget discovery offline. A typical ROP chain might disable SMEP, set up a payload, and call `ExAllocatePoolWithTag` to allocate executable memory – though under HVCI, even allocated pages must be signed, so the final goal often is to steal a token or disable mitigations temporarily.
5. Step‑by‑Step Exploitation Process
Assume an attacker has a kernel vulnerability that allows arbitrary memory write (a data‑only primitive). The steps are:
– Identify a suspended thread. Attackers can create their own suspended thread via `CreateProcess` with `CREATE_SUSPENDED` flag, or find an existing one.
– Overwrite the thread’s kernel `ETHREAD` structure’s context area. This requires knowing the offset of the `Context` field (varies by Windows build). A typical overwrite using a fake `CONTEXT` record:
CONTEXT ctx = {0};
ctx.ContextFlags = CONTEXT_FULL;
ctx.Rip = (DWORD64)rop_chain_address; // address in non‑executable data
ctx.Rsp = (DWORD64)fake_stack;
// Write ctx to the thread's context area via the vulnerability
– Resume the thread (e.g., NtResumeThread). The kernel restores the context, and execution jumps into the ROP chain.
6. Debugging and Verification with WinDbg
To verify the exploit, set a breakpoint on the target thread’s resume routine or on the ROP chain address:
bp nt!NtResumeThread bp <rop_chain_address> g
When the breakpoint hits, inspect registers with `r` and stack with dqs @rsp. Ensure that HVCI did not trigger a violation – if it does, the system will bugcheck with CRITICAL_STRUCTURE_CORRUPTION. Successful exploitation may lead to privilege escalation or kernel code execution without modifying code pages.
7. Mitigations and Detection
Defenders can monitor for unusual thread suspension/resume patterns using Event Tracing for Windows (ETW):
Enable ETW for thread events logman start "NT Kernel Logger" -p "Microsoft-Windows-Kernel-Process" 0x10 -ets
Kernel callbacks (e.g., PsSetCreateThreadNotifyRoutine) can also alert on thread creation and termination. Additionally, enabling CET (Control‑flow Enforcement Technology) in the kernel can disrupt ROP chains that rely on indirect branches. Microsoft may further restrict thread context modification by validating that the new `RIP` points to a valid, signed code section.
What Undercode Say:
- Key Takeaway 1: Suspended threads provide a powerful and stealthy vector for control‑flow hijacking that evades HVCI by modifying only data structures.
- Key Takeaway 2: ROP chains remain viable under HVCI as long as they reuse existing kernel code; the challenge shifts to finding suitable gadgets without triggering CFG/CET.
- Analysis: This technique underscores the cat‑and‑mouse game between exploit developers and platform security. While VBS/HVCI raise the bar, they do not eliminate the risk – attackers adapt by targeting thread management and other kernel metadata. Security teams must broaden their monitoring to include thread state changes and use kernel integrity checks (e.g., System Guard runtime monitoring) to detect anomalies. As Windows 11 evolves, expect deeper integration of hardware defenses like Intel TDX and AMD SEV to protect even thread contexts, but for now, researchers must stay vigilant and understand these low‑level attack surfaces.
Prediction:
Future iterations of Windows will likely introduce additional validation of thread contexts upon resume, possibly requiring that the instruction pointer remains within the original module or that the thread’s stack is marked as executable only under strict conditions. We may also see kernel‑mode CET becoming mandatory, forcing ROP chains to rely on JMP/CALL instructions rather than RET, complicating gadget reuse. The arms race will continue, with attackers pivoting to asynchronous procedure calls (APCs) and timer objects as alternative hijacking primitives. Expect a surge in research around abusing Windows synchronization primitives to achieve similar effects under even stricter hardware‑enforced security.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Https: – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
