Listen to this Post
Introduction:
Microsoft’s relentless hardening of the Windows kernel has reached a pivotal point with Windows 11 25H2, systematically closing long-standing avenues for attackers. A critical change is the severe restriction of kernel address leaks to user mode, directly targeting the foundational step of many exploits: bypassing Kernel Address Space Layout Randomization (KASLR). This evolution forces a fundamental shift in low-level offensive security research and red team operations.
Learning Objectives:
- Understand why the traditional method of retrieving `PsInitialSystemProcess` is now obsolete on modern Windows 11 builds.
- Learn the stable, albeit more complex, technique of traversing the active process list from the KPCR/KPRCB to find the System process.
- Gain practical knowledge through verified code snippets and commands to implement this new approach.
- Analyze the broader implications for exploit development and rootkit detection.
- Explore defensive configurations that leverage these new protections.
You Should Know:
1. The Death of Direct PsInitialSystemProcess Resolution
The `PsInitialSystemProcess` global variable, a traditional anchor point in kernel exploitation for locating the `_EPROCESS` of the `System` process (PID 4), is no longer a reliable export. Microsoft’s ongoing kernel hardening in Windows 11 25H2 and beyond deliberately obfuscates and restricts such informational exports to user-mode components and drivers, crippling simple KASLR bypass methods that relied on these leaks.
Step‑by‑step guide explaining what this does and how to use it.
Previously, an attacker could use a driver or leveraged read primitive to directly query this symbol.
Old (Now Broken) Method Concept:
// Pseudo-code for illustrative purposes
ULONG_PTR GetPsInitialSystemProcessOld() {
// 1. Load or leverage ntoskrnl.exe base address (itself often leaked).
// 2. Resolve export "PsInitialSystemProcess" via EAT.
// 3. Read the pointer value at that address.
return (ULONG_PTR)ResolvedAddress;
}
This direct resolution is now blocked or returns unstable results, necessitating an indirect path.
- The Anchor: Locating the KPCR (Kernel Processor Control Region)
The Key to the new method is the Kernel Processor Control Region (KPCR). This structure, unique per CPU core, contains a pointer to the Kernel Processor Control Block (KPRCB), which in turn holds a pointer to the current thread (_KTHREAD). The KPCR can be reliably located from user mode via the `gs` segment register on x64 systems (or `fs` for 32-bit on WoW64).
Step‑by‑step guide explaining what this does and how to use it.
Windows Command / Internal Knowledge:
The `gs` segment selector is set by the OS on context switch to point to the current core’s KPCR. In kernel-mode drivers or with read primitives, we can access it directly.
Code Snippet (Kernel-Mode Driver):
include <ntddk.h>
// Function to get the current _EPROCESS from the KPCR
PEPROCESS GetCurrentEProcessFromKpcr() {
PKPCR pKpcr = (PKPCR)__readgsqword(FIELD_OFFSET(KPCR, Self)); // Read GS base
if (!pKpcr || !pKpcr->Prcb) {
return NULL;
}
PKTHREAD pCurrentThread = pKpcr->Prcb->CurrentThread;
if (!pCurrentThread) {
return NULL;
}
// The _KTHREAD's ApcState.Process field points to the owning _EPROCESS
return (PEPROCESS)(pCurrentThread->ApcState.Process);
}
3. Traversing the ActiveProcessLinks List
Every `_EPROCESS` structure is linked into a circular doubly-linked list via its `ActiveProcessLinks` field (LIST_ENTRY). By starting from a known `_EPROCESS` (like the current process obtained via KPCR), we can walk this list until we find the entry with `UniqueProcessId` equal to 4, which is the System process.
Step‑by‑step guide explaining what this does and how to use it.
Step-by-Step Traversal Logic:
- Use the above method to obtain a pointer to the `_EPROCESS` of the current thread.
- Get the offset of the `ActiveProcessLinks` field within `_EPROCESS` (this offset is stable across a specific Windows build but requires proper OS versioning in your code).
- Follow the `Flink` (forward link) pointer. This pointer points to the `ActiveProcessLinks` field of the next
_EPROCESS. - To get the base address of that next
_EPROCESS, subtract the offset of `ActiveProcessLinks` from the pointer you just followed.
5. Read the `UniqueProcessId` (PID) of that `_EPROCESS`.
- If PID != 4, repeat from step 3 using the new
_EPROCESS. - When PID == 4, you have located the `_EPROCESS` of the System process.
Code Snippet (Conceptual Traversal):
PLIST_ENTRY GetSystemProcessListEntry(PEPROCESS StartEprocess) {
PEPROCESS CurrentEprocess = StartEprocess;
ULONG_PTR ActiveProcessLinksOffset = 0x448; // EXAMPLE OFFSET for Win11 22H2, MUST BE VERIFIED
do {
PLIST_ENTRY CurrentList = (PLIST_ENTRY)((ULONG_PTR)CurrentEprocess + ActiveProcessLinksOffset);
PLIST_ENTRY NextList = CurrentList->Flink;
// Calculate the next EPROCESS base from the LIST_ENTRY pointer
PEPROCESS NextEprocess = (PEPROCESS)((ULONG_PTR)NextList - ActiveProcessLinksOffset);
// Read PID (offset also build-dependent, e.g., 0x440 for UniqueProcessId)
ULONG_PTR Pid = (ULONG_PTR)((ULONG_PTR)NextEprocess + 0x440);
if (Pid == 4) {
return NextList; // Found the System process's list entry
}
CurrentEprocess = NextEprocess;
} while (CurrentEprocess != StartEprocess); // Loop until we circle back
return NULL;
}
4. Defensive Perspective: Monitoring for List Traversal
Blue teams and EDR developers can detect this technique by hooking or monitoring sensitive kernel functions and tracking unusual access patterns to the `ActiveProcessLinks` field from non-system threads or unknown modules.
Step‑by‑step guide explaining what this does and how to use it.
Example Sysmon Configuration (Event ID 11 – FileCreate) for Driver Load: While this doesn’t catch in-memory traversal, blocking unknown drivers is first line of defense.
<Sysmon> <EventFiltering> <RuleGroup name="" groupRelation="or"> <DriverLoad onmatch="exclude"> <Image condition="is">C:\Windows\System32\drivers\knowngood.sys</Image> </DriverLoad> <DriverLoad onmatch="include"> <!-- Alert on unsigned or unusual drivers --> <Signature condition="is not">Microsoft Windows</Signature> <Signature condition="is not">Microsoft Corporation</Signature> </DriverLoad> </RuleGroup> </EventFiltering> </Sysmon>
5. The Future: Embracing HVCI and Kernel CET
This change is part of a broader push towards Hypervisor-Protected Code Integrity (HVCI) and Kernel Control-Flow Enforcement Technology (CET). These technologies make injecting arbitrary kernel code or manipulating control flow exponentially harder.
Step‑by‑step guide explaining what this does and how to use it.
Admin Command to Check HVCI Status:
Run in an elevated PowerShell window Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard
Look for `”HypervisorEnforcedCodeIntegrity”` properties with a value of `”1″` or "True", indicating it’s enabled. Red teams must now focus on purely data-only attacks or find flaws in the hypervisor layer itself.
What Undercode Say:
- Key Takeaway 1: The era of simple kernel symbol resolution for exploit primitives is over. Microsoft’s systematic lockdown forces a move towards more complex, but more stable, indirect techniques that rely on fundamental, unchanging kernel data structures like the KPCR and process list.
- Key Takeaway 2: This represents a healthy evolution in the cat-and-mouse game. It raises the barrier to entry for low-level attacks, forcing broader skill development. Defenders must now also shift their detection logic from monitoring simple API calls to understanding and profiling these deeper structural access patterns.
The analysis underscores a strategic win for defense-in-depth. While not eliminating kernel exploits, it breaks canned techniques and automated tools, requiring a deeper understanding of Windows Internals from attackers. This change, combined with HVCI and CET, is slowly transforming the Windows kernel into a modern, resilient core that prioritizes breaking legacy exploit chains, even at the cost of some debugging visibility. The red team community’s adaptation—documented in posts like the one analyzed—is a testament to the ongoing, sophisticated dialogue that drives security forward.
Prediction:
In the next 2-3 years, we will see a sharp decline in generic kernel-level malware and a rise in two opposing trends: highly sophisticated, state-sponsored rootkits that master these new indirect techniques, and a pivot by broader threat actors towards “living-off-the-land” in user space, abusing legitimate drivers (Bring Your Own Vulnerable Driver – BYOVD) and firmware interfaces. Exploit development will increasingly require custom research for each major Windows build, mimicking the “n-days” model of browser exploitation. Defensively, EDR solutions will deepen their kernel integration, moving beyond callbacks to actively validate the integrity of kernel data structure linkages in real-time.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Simon Ngoy – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
