PPLwindow is a proof-of-concept demonstrating that the NtUserGetWindowProcessHandle syscall on older win32kfull.sys versions fails to enforce protected-process checks, for authorized research and assessment use.

PPLwindow is a compact C proof-of-concept from R41N3RZUF477 that documents a specific weakness in how older Windows builds enforce Protected Process Light boundaries. The core finding is that on Windows 10 1809 through Windows 11 23H2, the NtUserGetWindowProcessHandle syscall exposed by the win32kfull.sys driver does not verify whether the owning process is protected before handing back a usable handle. The repository is deliberately minimal — a short README, the source, and a screenshot — which is appropriate for a single-vector PoC, and every fact in this writeup comes from that primary material.

The technical crux is worth unpacking for anyone who audits Windows internals. Normally, calls like OpenProcess are mediated by the object manager, which strips or denies access rights such as PROCESS_VM_WRITE against a PPL when the caller is unprotected. NtUserGetWindowProcessHandle is a user-to-kernel path that exists to let windowing code resolve which process owns an HWND, and historically it returned a handle with generous rights. Because the check for protected status was missing in the listed versions, an unprotected caller could receive a handle carrying PROCESS_QUERY_LIMITED_INFORMATION, PROCESS_VM_OPERATION, PROCESS_VM_READ, PROCESS_VM_WRITE, and PROCESS_DUP_HANDLE — enough to read and write the target's memory directly.

There is one structural precondition that shapes where this matters: the protected target must own a window. That is unusual for PPL services, which typically run headless, and it is exactly why the author initially shelved the bug. As the README recounts, the issue was found in 2023 alongside CVE-2023-41772, but no valid windowed protected process was identified as a target at the time. The breakthrough came from a public post by James Forshaw pointing at WerFaultSecure.exe, Windows' secure error-reporting process, which does create a window and runs under PP protection. The PoC exploits that target and, per the README, achieves PP-WinTcb — the highest trust level in the protected-process hierarchy, above the standard PPL tiers.

The significance of reaching PP-WinTcb deserves emphasis for defenders and researchers alike. Protected Process (PP) with the WinTcb trust level is the band reserved for the core of the OS itself; even antivirus agents, which typically run as PPL-Antimalware, are nominally insulated from it. A technique that lets an unprivileged caller cross into that band invalidates assumptions that EDR drivers and anti-tamper logic depend on — namely that an unsigned, non-admin process cannot obtain write access to PP memory. Notably, the README states that no admin privileges are required for this path, which places it squarely in the low-privilege-to-protected escalation category rather than an admin-to-admin curiosity.

The disclosure history embedded in the README is itself instructive. The author reports having told Microsoft about this behavior when reporting CVE-2023-41772, and infers that this may be why the flaw is fixed in Windows 11 24H2. That timeline — found in 2023, publicly surfaced with a target in late 2025, fixed in the 24H2 wave — is a realistic snapshot of how protected-process bypasses mature: the syscall flaw is often the easy part, and the viable target is the scarce resource. For threat-intelligence purposes, the practical exposure window is therefore large but bounded: any fleet still on Windows 10 1809 through Windows 11 23H2 with WerFaultSecure.exe reachable is theoretically in scope, while 24H2 and later close the handle-leak path.

There is a version wrinkle documented in the README that matters for lab reproduction. On Windows 10 1809 and Windows Server 2019, the stock WerFaultSecure.exe and wer.dll binaries apparently do not exhibit the required behavior, so the author suggests using the equivalents from Windows 10 21H2 or Windows Server 2022: place both binaries in a folder and pass the path to WerFaultSecure.exe as the first command-line argument to PPLwindow. We note this as documentation of the PoC's prerequisites, not as an operational endorsement; security teams should treat that binary-substitution detail purely as an indicator of how the research was validated and as a detection consideration, since it involves running mismatched system binaries on downlevel builds.

From a defensive engineering perspective, the lesson is about validating trust checks on every handle-granting path, not just the obvious ones. win32k syscalls are a well-known source of such gaps because they evolved from a user-mode windowing layer into kernel-mediated calls with legacy semantics. Blue-team teams monitoring pre-24H2 estates should consider whether their telemetry captures object-handle acquisitions against protected processes from unusual callers — ETW providers around process and handle events can surface this — and should inventory WerFaultSecure.exe execution chains, since a legitimate instance spawned in an anomalous context is exactly the shape this research leaves behind.

For authorized assessors, PPLwindow is most useful as a boundary-confirmation tool: it answers, on a given host, whether the pre-24H2 win32kfull.sys missing-check class is reachable in practice. It is a single-vector demonstration, not a framework — no persistence, no payload delivery, no post-exploitation plumbing. That narrowness is a feature for auditability. Anyone evaluating it should do so on isolated lab machines running the affected versions, with clear rules of engagement, and should remember that the fix shipped in Windows 11 24H2 makes patch status the first question to answer before the tool is even relevant.

The repository metadata rounds out the picture: 54 stars, C source, main branch, and no license file declared. The absence of a license is worth a brief caution — absent an explicit grant, default copyright applies to the code, so organizations incorporating or redistributing it should seek permission or treat it as read-only reference material. The topic list is empty and there is no CI or packaging, consistent with a researcher's one-shot disclosure artifact rather than a maintained product. Expect it to be a historical reference for the NtUserGetWindowProcessHandle bug class rather than something to build tooling on top of.

In sum, PPLwindow documents a clean, well-attributed instance of a recurring Windows pattern: a convenience syscall that forgot the protected-process check, a target that turned a dormant finding into a live bypass, and a fix that arrived with the next feature wave. For defenders, the action items are patch gap analysis across pre-24H2 builds and handle-telemetry review; for researchers, it is a reminder that hunting for windowed protected processes is a productive exercise when auditing win32k attack surface. The educational value is entirely in the mechanism — and the mechanism is now patched, which is where a good proof-of-concept should end up.

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.

Related coverage

• Inside QuickAssist_UAC_Bypass: how a UIAccess binary defeats always-notify UAC


• Automating AI-assisted code audits with seclab-taskflow-agent


• Automating AI-assisted code auditing with seclab-taskflows