GetProcessHandleFromHwnd: How One Windows API Enabled a Persistent UAC Bypass

Google Project Zero's deep dive into GetProcessHandleFromHwnd is a good reminder that vendor-neutral security review of "boring" platform APIs still finds real bugs. The researcher's starting point was a publicly disclosed UAC bypass abusing the Quick Assist UI Access application — reported to Microsoft by researcher Sascha Mayer and fixed as CVE-2023-41772. Curious why that bypass worked, Project Zero went looking for the API behind it, and found it undocumented in practice and inaccurately documented on paper.

What the API does — and why its docs are wrong

GetProcessHandleFromHwnd retrieves a process handle from a window handle, gated by User Interface Privilege Isolation (UIPI) — the mechanism that stops lower-integrity processes from messing with higher-integrity ones through window messages. Microsoft's own documentation makes three claims about it that Project Zero found to be factually wrong: that a UIAccess caller can use a Windows hook to inject code (the real requirement is a matching or higher integrity level), that the function works via Windows hooks at all (modern Windows implements it as a kernel function), and that it only succeeds when caller and target run as the same user — which the Quick Assist bypass directly contradicts.

From a Vista-era hook to a kernel primitive

The API's history explains the confusion. In Vista, it lived in oleacc.dll, using SetWindowsHookEx and shared memory, and communicating via custom WM_OLEACC_HOOK messages. In Windows 10 version 1803, Microsoft moved the logic into the kernel as NtUserGetWindowProcessHandle inside win32kfull.sys. The kernel version could open a target process with KernelMode access, bypassing normal access checks — including checks meant to stop unprotected code from touching protected processes.

CVE-2023-41772 fixed half the problem

Microsoft's 2023 fix forced the function down to UserMode access whenever the UIPI integrity check failed, which closed the cross-integrity abuse Mayer had reported. But when caller and target sit at the *same or higher* integrity level, the kernel path still ran — still handing out KernelMode access, still granting PROCESS_DUP_HANDLE, PROCESS_VM_OPERATION, PROCESS_VM_READ and PROCESS_VM_WRITE. That's enough to inject and execute code inside a target process. Project Zero demonstrates the residual gap by compromising WerFaultSecure.exe, a process running at the Protected TCB level, by launching it with arguments that give it an enumerable window and then calling the API against it.

What changed in Windows 11 24H2

24H2 adds real protection-level checking, so the function can no longer bridge different process-protection states unless UIPI enforcement is disabled system-wide, plus a new ResponsiblePid feature that denies access outright if UIPI is off. Disabling that protection is deliberately awkward: it requires setting EnforceUIPI to 0 under HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System, turning off the UIPIAlwaysOn and ResponsiblePid ViVe feature flags, and a reboot with administrative rights — not something that happens by accident.

The practitioner takeaway

This is a useful case study for anyone assessing Windows attack surface rather than just patch level. Windows 10 and pre-24H2 Windows 11 — including 23H2 Enterprise/Education builds supported into November 2026 — remain exposed to the same-integrity variant of this issue if unpatched. It's also a reminder not to take platform security documentation at face value when scoping a privilege-escalation review: Microsoft's own remarks on this API were wrong on the exact points that mattered for exploitability, and the only way to know was to read the disassembly.

If the caller has UIAccess, however, they can use a windows hook to inject code — a documentation claim Project Zero found does not match how the modern, kernel-mode implementation actually enforces access.

— Microsoft API documentation, as quoted by Google Project Zero