A Google Project Zero researcher has published a detailed code archaeology study of GetProcessHandleFromHwnd, a Windows API that came to attention through a publicly disclosed UAC bypass involving the Quick Assist UI Access application. The analysis reveals that Microsoft’s own documentation for the API contains several factual inaccuracies, and that the implementation has changed substantially since Vista.

What the Documentation Gets Wrong

The official documentation makes three key claims about the API, and the researcher found each to be at least partially incorrect:

  • The docs state that having UIAccess enabled is sufficient to use Windows hooks. In practice, the caller also needs the same or greater integrity level as the target process.
  • The docs describe an injection mechanism using Windows hooks. On Windows 11, the API is implemented as a Win32k kernel function that opens the process directly, with no hook injection involved.
  • The docs assert the API only succeeds when caller and target run as the same user. The Quick Assist UAC bypass, which uses this API, still works under Administrator Protection, meaning different-user scenarios can succeed.

The Vista-Era Implementation

The first version of GetProcessHandleFromHwnd appeared in Vista, implemented inside oleacc.dll. Despite documentation claiming Windows XP support, the researcher confirmed the API is absent from XP SP3 binaries.

The Vista implementation first attempts a direct process open. On failure, it falls back to injecting oleacc.dll into the target process via SetWindowsHookEx, then triggering a custom registered window message (WM_OLEACC_HOOK). The hook handler opens a named shared memory section, duplicates a handle to the current process with a limited access mask, and writes the duplicated handle value back to the caller through that shared memory.

A notable security detail: the shared memory section has its integrity level set, but no explicit DACL, meaning cross-user scenarios could fail simply because the target cannot open the section. However, if the target is an administrator, as in the UAC bypass case, it will typically have the access needed to complete the operation regardless.

In Windows 7, the hook function was moved from oleacc.dll into a dedicated binary, oleacchooks.dll, exposed as an unnamed export at ordinal 1. This DLL still ships on current Windows 11 builds despite being unused by any known caller.

The Kernel-Mode Rewrite

Beginning with Windows 10 version 1803, the API was reimplemented as a kernel function, NtUserGetWindowProcessHandle, inside win32kfull.sys. The new implementation validates the target window, checks that caller and target share the same desktop, and enforces UIPI (User Interface Privilege Isolation) access checks when the global enforcement flag is set. Only after passing those checks does the kernel open the target process handle directly, without any user-mode hook injection.

Takeaway for Security Practitioners

The research illustrates how Windows security APIs can accumulate documentation debt as implementations evolve across major releases. Security assumptions built on reading API documentation rather than auditing the underlying implementation may not hold. Practitioners relying on UIPI or user-boundary assumptions around this API should verify behavior against the specific Windows version in their environment, particularly given the demonstrated UAC bypass that remains functional even under Administrator Protection.