Automating Universal ASLR Bypasses on Windows 11

TLDR: High-Entropy ASLR is often treated as a silver bullet for memory corruption, but it remains vulnerable to reliable, automated bypasses. By targeting the Process Environment Block (PEB) and Thread Environment Block (TEB) through techniques like GS register access or specific system calls, researchers can consistently leak base addresses for core system DLLs. This research provides a repeatable, automated framework for neutralizing these protections, turning what was once a manual, tedious task into a trivial step in an exploit chain.

Modern Windows security relies heavily on High-Entropy ASLR to stop memory corruption bugs from becoming reliable code execution primitives. For years, the industry has operated under the assumption that if you randomize the address space enough, the cost of guessing the location of critical modules becomes prohibitive for an attacker. This assumption is fundamentally flawed. If an attacker can leak a single pointer from the PEB or TEB, the entire entropy-based defense collapses.

The Mechanics of the Leak

The core of this research centers on the fact that the PEB and TEB are still readable from user-mode. These structures contain the metadata necessary for the Windows loader to manage modules, and they are not protected by the same rigorous isolation as kernel-mode structures. If you have an initial primitive—like a memory read or a controlled write—you can target these structures to extract the base addresses of ntdll.dll, kernel32.dll, and kernelbase.dll.

The research demonstrates four distinct, reliable methods to achieve this:

1. Accessing the GS register directly.
2. Using the RDGSBASE instruction.
3. Invoking NtQueryInformationProcess.
4. Invoking NtQueryInformationThread.

Each of these methods provides a path to the PEB or TEB. Once you have the address of these structures, you can traverse the doubly-linked lists of loaded modules. By following the InInitializationOrderModuleList or similar structures, you can pinpoint the exact base address of any loaded DLL. This is not a probabilistic attack; it is deterministic.

Automating the Chain

Manual ROP chain construction is a relic of the past. The ROP ROCKET framework, specifically the new aslr-bypass feature set, automates the entire process. Instead of hunting for gadgets manually in WinDbg, the tool generates a complete 64-bit ROP chain that performs the leak and returns the base address to a register of your choice.

The following snippet illustrates the logic used to leak the PEB via the GS register:

; Leak PEB via GS register
sbb rcx, qword ptr gs:[rsi+0x78DBDE873]
add al, byte ptr [eax]
pop ebp
ret 0x10

This gadget is admittedly ugly, but it is effective. By using an integer overflow to manipulate the RCX register, the attacker can force the system to reveal the PEB address. The tool handles the gadget discovery and chain assembly, outputting a Python script that can be dropped directly into an exploit.

Real-World Impact

During a penetration test or a bug bounty engagement, you rarely have the luxury of spending days crafting a custom ROP chain for every target binary. This research changes the engagement model. If you have a memory corruption vulnerability—such as a use-after-free or a buffer overflow—you no longer need to worry about the target's ASLR configuration. You treat the PEB/TEB leak as a standard, automated phase of your exploit development.

The impact is significant. By bypassing ASLR, you effectively turn a "crash" into a "shell." This technique works across Windows 10 and Windows 11, and because it relies on fundamental Windows structures that are unlikely to change without breaking legacy application compatibility, it is a persistent threat.

The Defensive Reality

Defenders often look for ways to detect these leaks, but the reality is grim. Microsoft has historically been reluctant to treat these bypasses as high-severity vulnerabilities, often citing that they rely on a pre-existing memory corruption bug. While Export Address Table Filtering (EAF) can provide some protection against common export table lookups, it does nothing to stop a direct traversal of the PEB module lists.

To truly mitigate this, Microsoft would need to implement a major architectural change, such as pointer obfuscation or making the PEB/TEB non-readable to user-mode processes. Until then, the burden falls on endpoint detection and response (EDR) vendors to flag abnormal access patterns to these structures. If you are a defender, look for processes that perform unusual memory reads on the TEB or attempt to traverse module lists in ways that deviate from standard loader behavior.

This research proves that High-Entropy ASLR is not a panacea. It is a hurdle, and like any hurdle, it can be cleared with the right tools. For researchers, the takeaway is clear: stop fighting the randomization and start automating the leak. The structures that hold the system together are the same ones that will help you take it apart.