Project Zero

On the Effectiveness of Mutational Grammar Fuzzing

2026-03-05T00:00:00-08:00

Mutational grammar fuzzing is a fuzzing technique in which the fuzzer uses a predefined grammar that describes the structure of the samples. When a sample gets mutated, the mutations happen in such a way that any resulting samples still adhere to the grammar rules, thus the structure of the samples gets maintained by the mutation process. In case of coverage-guided grammar fuzzing, if the resulting sample (after the mutation) triggers previously unseen code coverage, this sample is saved to the sample corpus and used as a basis for future mutations.

This technique has proven capable of finding complex issues and I have used it successfully in the past, including to find issues in XSLT implementations in web browsers and even JIT engine bugs.

However, despite the approach being effective, it is not without its flaws which, for a casual fuzzer user, might not be obvious. In this blogpost I will introduce what I perceive to be the flaws of the mutational coverage-guided grammar fuzzing approach. I will also describe a very simple but effective technique I use in my fuzzing runs to counter these flaws.

Please note that while this blogpost focuses on grammar fuzzing, the issues discussed here are not limited to grammar fuzzing as they also affect other structure-aware fuzzing techniques to various degrees. This research is based on the grammar fuzzing implementation in my Jackalope fuzzer, but the issues are not implementation specific.

Issue #1: More coverage does not mean more bugs

The fact that coverage is not a great measure for finding bugs is well known and affects coverage-guided fuzzing in general, not just grammar fuzzing. However this tends to be more problematic for the types of targets where structure-aware fuzzing (including grammar fuzzing) is typically used, such as in language fuzzing. Let’s demonstrate this on an example:

In language fuzzing, bugs often require functions to be called in a certain order or that a result of one function is used as an input to another function. To trigger a recent bug in libxslt two XPath functions need to be called, the document() function and the generate-id() function, where the result of the document() function is used as an input to generate-id() function. There are other requirements to trigger the bug, but for now let’s focus on this requirement.

Here’s a somewhat minimal sample required to trigger the bug:

 xml:base="#" version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
 match="/">
   select="generate-id(document('')/xsl:stylesheet/xsl:template/xsl:message)" />
   terminate="no">

With the most relevant part for this discussion being the following element and the XPath expression in the select attribute:

 select="generate-id(document('')/xsl:stylesheet/xsl:template/xsl:message)" />

If you run a mutational, coverage guided fuzzer capable of generating XSLT stylesheets, what it might do is generate two separate samples containing the following snippets:

Sample 1:

 select="document('')/xsl:stylesheet/xsl:template/xsl:message" />

Sample 2:

 select="generate-id(/a)" />

The union of these two samples’ coverage is going to be the same as the coverage of the buggy sample, however having document() and generate-id() in two different samples in the corpus isn’t really helpful for triggering the bug.

It is also possible for the fuzzer to generate a single sample with both of these functions that again results in the same coverage as the buggy sample, but with both functions operating on independent data:

 match="/">
...
 select="document('')/xsl:stylesheet/xsl:template/xsl:message" />
 select="generate-id(/a)" />
...

This issue also demonstrates how crucial it is for any fuzzer to be able to combine multiple samples in the corpus in order to produce new samples. However, in this case, note that combining the two samples wouldn’t trigger any previously unseen coverage and thus the resulting sample wouldn’t be saved, despite climbing closer to triggering the bug.

In this case, because triggering the bug requires chaining only two function calls, a fuzzer would eventually find this bug by randomly combining the samples. But in case three or more function calls need to be chained in order to trigger the bug, it becomes increasingly expensive to do so and coverage feedback, as demonstrated, does not really help.

In fact, triggering this bug might be easier (or equally easy) with a generative fuzzer (that will generate a new sample from scratch every time) without coverage feedback. But even though coverage feedback is not ideal, it still helps in a lot of cases.

As previously stated, this issue does not only affect grammar fuzzing, but also other fuzzing approaches, in particular those focused on language fuzzing. For example, Fuzzilli documentation describes a similar version of this problem.

A possible solution for this problem would be having some kind of dataflow coverage that could identify that data flowing from document() into generate-id() is something previously unseen and worth saving, however I am not aware of any practical implementation of such an approach.

Issue #2: Mutational grammar fuzzing tends to produce samples that are very similar

To demonstrate this issue, let’s take a look at some samples from one of my XSLT fuzzing sessions:

Part of sample 1128 in the corpus:

 namespace="http://www.w3.org/url2" > > xml:id="{lxl:node-set($name2)}:" att3="{[$name4document('')att4.|document('')$name4namespace::]document('')}{ns2}" >

Part of sample 603 in the corpus:

 namespace="http://www.w3.org/url2" > > xml:id="{lxl:node-set($name2)}:" att3="{[$name4document('')att4.|document('')$name4namespace::]document('')}{ns2}" xmlns:xsl="http://www.w3.org/url3" > >eHhDC?^5= elements="eee" > stylesheet-prefix="ns3" priority="3" >t

As you can see from the example, even though these two samples are different and come from different points in time during the fuzzing session, a large part of these two samples are the same.

This follows from the greedy nature of mutational coverage guided fuzzing: when a sample is mutated to produce new coverage, it gets immediately saved to the corpus. Likely a large part of the original sample wasn’t mutated, but it is still part of the new sample so it gets saved. This new sample can get mutated again and if the resulting (third) sample triggers new coverage it will also get saved, despite large similarities with the starting sample. This results in a general lack of diversity in a corpus produced by mutational fuzzing.

While Jackalope’s grammar mutator can also ignore the base sample and generate an entire sample from scratch, it is rare for this to trigger new coverage compared to the more localized mutations, especially later on in the fuzzing session.

One approach of combating this issue could be to minimize each new sample so that only the part that triggers new coverage gets saved, but I observed that this isn’t an optimal strategy either and it’s beneficial to leave (some) of the original sample. Jackalope implements this by minimizing each grammar sample, but stops the minimization when a certain number of grammar tokens has been reached.

Even though this blogpost focuses on grammar fuzzing, I observed this issue with other structure aware fuzzers as well.

A simple solution?

Both of these issues hint that there might be benefits of combining generative fuzzing with mutational fuzzing in some way. Generative fuzzing produces more diverse samples than mutational fuzzing but suffers from other issues such as that it typically generates lots of samples that trigger errors in the target. Additionally, as stated previously, although coverage is not an ideal criteria for finding bugs it is still helpful in a lot of cases.

In the past, when I was doing grammar fuzzing on a large number of machines, an approach I used was to delay syncing individual fuzz workers. That way, each worker would initially work with its own (fully independent) corpus. Only after some time has passed, the fuzzers would exchange sample sets and each worker would get the samples that correspond to the coverage this worker is missing.

But what to do when fuzzing on a single machine? During my XSLT fuzzing project, I used the following approach:

Start a fuzzing worker with an empty corpus. Run for T seconds.
After T seconds sync the worker with the fuzzing server. Get the missing coverage and corresponding samples from the server. Upload any coverage the server doesn’t have (and the corresponding samples) to the server.
Run with combined corpus (generated by the worker + obtained from the server) for another T seconds.
Sync with the server again (to upload any new samples) and shut down the worker.
Go back to step 1.

The result is that the fuzzing worker spends half of the time creating a fully independent corpus generated from scratch and half of the time working on a larger corpus that also incorporates interesting samples (as measured by the coverage) from the previous workers. This results in more sample diversity as each new generation is independent from the previous one. However the worker eventually still ends up with a sample set corresponding to the full coverage seen so far during any worker lifetime. Ideally, new coverage and, more importantly, new bugs can be found by combining the fresh samples from the current generation with samples from the previous generations.

In Jackalope, this can be implemented by first running the server, e.g.

/path/to/fuzzer -start_server 127.0.0.1:8337 -out serverout

And then running the workers sequentially with the following Python script:

import subprocess
import time

T = 3600

while True:
  subprocess.run(["rm", "-rf", "workerout"])
  p = subprocess.Popen(["/path/to/fuzzer", "-grammar", "grammar.txt", "-instrumentation", "sancov", "-in", "empty", "-out", "workerout", "-t", "1000", "-delivery", "shmem", "-iterations", "10000", "-mute_child", "-nthreads", "6", "-server", "127.0.0.1:8337", "-server_update_interval", str(T), "--", "./harness", "-m", "@@"])
  time.sleep(T * 2)
  p.kill()

Note that Jackalope parameters in the script above are from my libxslt fuzzing run and should be adjusted according to the target.

Additionally, Jackalope implements the -skip_initial_server_sync flag to avoid syncing a worker with the server as soon as the worker starts, but this flag is now the default in grammar fuzzing mode so it does not need to be specified explicitly.

Does this trick work better than running a single uninterrupted fuzzing session? Let’s do some experiments. I used an older version of libxslt as the target (libxslt commit 2ee18b3517ca7144949858e40caf0bbf9ab274e5, libxml2 commit 5737466a31830c017867e3831a329c8f605c877b) and measured the number of unique crashes over time. Note that while the number of unique crashes does not directly correspond to the number of unique bugs, being able to trigger the same bug in different ways still gives a good indication of bug finding capabilities. I ran each session for one week on a single machine.

I ran two default experiments (with a single long-lived worker) as well as the two experiments with the proposed solution with different values of T, T=3600 (one hour) and T=600 (10 minutes).

As demonstrated in the chart, restarting the worker periodically (but keeping the server), as proposed in this blog post, helped uncover more unique crashes than either of the default sessions. The crashes were also found more quickly. The default sessions proved sensitive to starting conditions where one run discovered 5 but the other run only 2 unique crashes during the experiment time.

The value of T dictates how soon a worker will switch from working on only its own samples to working on its own + the server samples. The best value in the libxslt experiment (3600) is when the worker already found most of the “easy” coverage and discovered the corresponding samples. As can be seen from the experiment, different values of T can produce different results. The optimal value is likely target-dependent.

Conclusion

Although the trick described in this blogpost is very simple, it nevertheless worked surprisingly well and helped discover issues in libxslt quicker than I would likely be able to find using default settings. It also underlines the benefits of experimenting with different fuzzing setups according to the target specifics, rather than relying on tooling out-of-the-box.

Future work might include researching fuzzing strategies that favor novelty and would e.g. replace samples with the newer ones, even when doing so does not change the overall fuzzer coverage.

A Deep Dive into the GetProcessHandleFromHwnd API

2026-02-26T00:00:00-08:00

In my previous blog post I mentioned the GetProcessHandleFromHwnd API. This was an API I didn’t know existed until I found a publicly disclosed UAC bypass using the Quick Assist UI Access application. This API looked interesting so I thought I should take a closer look.

I typically start by reading the documentation for an API I don’t know about, assuming it’s documented at all. It can give you an idea of how long the API has existed as well as its security properties. The documentation’s remarks contain the following three statements that I thought were interesting:

If the caller has UIAccess, however, they can use a windows hook to inject code into the target process, and from within the target process, send a handle back to the caller.

GetProcessHandleFromHwnd is a convenience function that uses this technique to obtain the handle of the process that owns the specified HWND.

Note that it only succeeds in cases where the caller and target process are running as the same user.

The interesting thing about these statements is none of them are completely true. Firstly as the previous blog post outlined it’s not sufficient to have UI Access enabled to use windows hooks, you need to have the same or greater integrity level as the target process. Secondly, if you go and look at how GetProcessHandleFromHwnd is implemented in Windows 11 it’s a Win32k kernel function which opens the process directly, not using windows hooks. And finally, the fact that the Quick Assist bypass which uses the API still works with Administrator Protection means the processes can be running as different users.

Of course some of the factual inaccuracies might be changes made to UAC and UI Access over the years since Vista was released. Therefore I thought it’d be interesting to do a quick bit of code archaeology to see how this API has changed over the years and perhaps find some interesting behaviors.

The First Version

The first version of the API exists in Vista, implemented in the oleacc.dll library. The documentation claims it was supported back in Windows XP, but that makes little sense for what the API was designed for. Checking a copy of the library from XP SP3 doesn’t show the API, so we can assume the documentation is incorrect. The API first tries to open the process directly, but if that fails it’ll use a windows hook exactly as the documentation described.

The oleacc.dll library with the hook will be loaded into the process associated with the window using the SetWindowsHookEx API and specifying the thread ID parameter. However it still won’t do anything until a custom window message, WM_OLEACC_HOOK is sent to the window. The hook function is roughly as follows (I’ve removed error checking):

void HandleHookMessage(CWPSTRUCT *cwp) {
  UINT msg = RegisterWindowMessage(L"WM_OLEACC_HOOK");
  if (cwp->message != msg)
	return;
  WCHAR name[64];
  wParam = cwp->wParam;
  StringCchPrintf(name, _countof(name),
                   L"OLEACC_HOOK_SHMEM_%d_%d", wParam,
                   cwp->lParam);
  HANDLE mapping = OpenFileMapping(FILE_MAP_READ |
                                   FILE_MAP_WRITE, FALSE,
                                   name);
  DWORD* buffer = (DWORD*)MapViewOfFile(mapping,
           FILE_MAP_READ | FILE_MAP_WRITE,
		0, 0, sizeof(DWORD));
  HANDLE caller = OpenProcess(PROCESS_DUP_HANDLE, FALSE,
                              cwp->wParam);
  HANDLE current = OpenProcess(PROCESS_DUP_HANDLE |
			  PROCESS_VM_OPERATION | PROCESS_VM_READ |
			  PROCESS_VM_WRITE | SYNCHRONIZE,
                   FALSE, GetCurrentProcessId());
  HANDLE dup;
  DuplicateHandle(CurrentProcess, current, caller, &dup,
                  0, 0, DUPLICATE_SAME_ACCESS);
  InterlockedExchange(buffer, (DWORD)dup);
  // Cleanup handles etc.
}

The message parameters are the process ID of the caller, who wants to open the process handle and an incrementing counter. These parameters are used to open a named memory section to transfer the duplicated handle value back to the caller. A copy of the current process handle is then opened with a limited set of access rights and duplicated to the caller. Finally the handle value is copied into the shared memory and the message handler returns. The caller of the API can now pick up the duplicated handle and use it as desired.

This code might explain a few additional things about the API documentation. If the two processes are running as different users it’s possible that the target process won’t be able to open the caller for PROCESS_DUP_HANDLE access and the transfer will fail. While the API does set the integrity level of the shared memory it doesn’t set the DACL so that will also prevent it being opened by a different user. Of course if the target process was running as an administrator, like in the UAC case, it almost certainly will have access to both the caller process as well as the shared memory making this a moot point.

One minor change was made in Windows 7, the hook function was moved out of the main oleacc.dll library into its own binary, oleacchooks.dll. The hook function is exposed as ordinal 1 in the export table with no name. This DLL still exists on the latest version of Windows 11 even though the API has since moved into the kernel and there’s no longer any users.

The Second Version

The second version of the API doesn’t appear until well into Windows 10’s lifetime, in version 1803. This version is where the API was moved into a Win32k kernel function. The kernel API is exposed as NtUserGetWindowProcessHandle from win32kfull.sys. It’s roughly implemented as follows:

HANDLE NtUserGetWindowProcessHandle(HWND hWnd,
                                    ACCESS_MASK DesiredAccess) {
  WND* wnd = ValidateHwnd(Wnd);
  if (!wnd) {
    return NULL;
  }
  THREADINFO* curr_thread =
                W32GetThreadWin32Thread(KeGetCurrentThread());
  THREADINFO* win_thread = wnd->Thread;;
  if (curr_thread->Desktop != win_thread->Desktop) {
     goto access_denied;
  }

  PROCESSINFO* win_process = win_thread->ppi;
  PROCESSINFO* curr_process = curr_thread->ppi;
  if (gbEnforceUIPI) {
    if (!CheckAccess(curr_process->UIPIInfo,
                     win_process->UIPIInfo)) {
      if (!curr_process->HasUiAccessFlag) {
        goto access_denied;
      }
    }
  }
  else if (win_thread->AuthId != curr_thread->AuthId) {
    goto access_denied;
  }
  if (win_thread->TIF_flags & (TIF_SYSTEMTHREAD |
                                TIF_CSRSSTHREAD)) {
    goto access_denied;
  }

  KPROCESS process = NULL;
  DWORD process_id = PsGetThreadProcessId(win_thread->KThread);
  PsLookupProcessByProcessId(process_id, &process);
  HANDLE handle = NULL;
  ObOpenObjectByPointer(process, 0, NULL, DesiredAccess,
    PsProcessType, KernelMode, &handle);
  return handle;

access_denied:
  UserSetLastError(ERROR_ACCESS_DENIED);
  return NULL;
}

One thing to note with the new API is it takes an ACCESS_MASK to specify what access the caller wants on the process handle. This is different from the old implementation where the access desired was a fixed value. The window handle is validated and used to lookup the Win32k THREADINFO structure for the associated thread and a check is made to ensure both the caller’s thread and the target window are on the same desktop.

We then get to the UIPI enforcement checks, first it checks the gbEnforceUIPI global variable. If UIPI is enabled it’ll call a CheckAccess method to see if the caller is permitted to access the process for the target window. If the check fails it’ll test if the caller has the UI Access flag enabled, if not the function will deny access, otherwise it’ll be allowed to continue. The access check is quite simple:

BOOLEAN CheckAccess(UIPI_INFO *Current, UIPI_INFO* Target) {
  if (Current->IntegrityLevel > Target->IntegrityLevel) {
    return TRUE;
  }

  if (Current->IntegrityLevel != Target->IntegrityLevel) {
    return FALSE;
  }

  if (Current->AppContainerNo != Target->AppContainerNo &&
      Current->AppContainerNo != -1 &&
      Target->AppContainerNo != -1) {
    return FALSE;
  }

  return TRUE:
}

If the caller’s integrity level is greater than the target’s, the check is passed immediately. If it’s less than the target’s then it fails immediately. However if the integrity level is the same it does a check to make sure if the processes are in an AppContainer sandbox and that they’re in the same one. If a process is not in an AppContainer sandbox the AppContainerNo value is set to -1. The check also ensures that this doesn’t allow a low integrity process access to an AppContainer process as there’s an existing check to prevent this happening via OpenProcess. If everything passes the check returns TRUE.

If UIPI is not enforced then the authentication IDs are compared. The function will only permit access if the caller is in the same logon session, which would mean if UIPI was disabled this wouldn’t permit accessing elevated UAC processes. The final check is whether the target thread is in the system (i.e. kernel) process or a CSRSS process. If they are then access is denied.

Finally, the target process is opened by its process ID by looking up the KPROCESS pointer then using ObOpenObjectByPointer to open a handle with the desired access. Crucially the access mode is set to KernelMode. This means that no access checks are performed on the process object.

One glaring security issue with this function is that the target process is opened without access checking for any access rights the caller wants. This is a problem as it allows any process with the same or higher integrity level to open any other process as long as it has at least one window.

This is a special problem for two process types, first is restricted token sandbox processes. While you might assume this wouldn’t be a big deal if two restricted token sandboxed processes running at the same integrity could access each other, that isn’t always the case. For example Chromium doesn’t allow renderers to open each other, and some renderers have more privilege that others for example if they’re rendering WebUI content. Fortunately at least in this case renderers run under win32k lockdown meaning they can’t create a window even if they wanted to.

The second is protected processes. If you open a handle to a protected process with the access mode set to KernelMode then it’ll be permitted completely bypassing the protection. You might not think a protected process would create a window, but it could be a message-only window such as to support COM which the code might not even realize it created.

However, even if the caller doesn’t have a suitable integrity level it’s sufficient to just have the UI Access flag enabled. This means that tricks such as my token stealing attack would be sufficient to open any other process on the same desktop which created a window. This issue was reported to MSRC and fixed as CVE-2023-41772. The reporter was the same researcher Sascha Mayer who found the Quick Assist UI Access bypass that I mentioned earlier.

The Third Version

This version’s goal was to fix CVE-2023-41772 and there are two major changes. First and most importantly, if the UIPI check fails, the function will still check for the UI Access flag being enabled. However, rather than permitting it to continue, it’ll force the call to ObOpenObjectByPointer to open a handle with the access mode set to UserMode rather than KernelMode.

Passing UserMode ensures that access checking is enabled. The end result is having the UI Access flag enabled doesn’t grant any additional privileges over calling the NtOpenProcess system call directly. Presumably it was left this way for compatibility reasons. However, this didn’t change the behavior when the caller’s integrity level is greater or equal to the target’s, the process object will still be opened with the access mode set to KernelMode. This means that when it comes to restricted token sandboxes or protected processes nothing has changed.

The second, less important change is that the desired access is now restricted to a limited set of access rights matching the original hook based implementation. The caller can only pass the following access to the function, PROCESS_DUP_HANDLE, PROCESS_VM_OPERATION, PROCESS_VM_READ and PROCESS_VM_WRITE otherwise access is denied. However this amount of access is more than sufficient to completely compromise the target process.

The Latest Version

Windows 11 24H2 introduced two major changes to the behavior of NtUserGetWindowProcessHandle. First there is a change to the UIPI access check, let’s look at a code snippet:

BOOLEAN UIPrivilegeIsolation::CheckAccess(UIPI_INFO *Current, UIPI_INFO* Target) {
  if (!Feature_UIPIAlwaysOn_IsEnabled() &&
      !UIPrivilegeIsolation::fEnforceUIPI) {
    return TRUE;
  }

  if (Target->ProcessProtection != 0 &&
     (Target->ProcessProtection != Current->Protection)) {
    return FALSE;
  }

  if (Current->IntegrityLevel > Target->IntegrityLevel) {
    return TRUE;
  }
...
}

The change introduces a Window feature flag to force UIPI on all the time, previously it was possible to disable UIPI using a system configuration change. A feature flag allows Microsoft to run A/B testing on Windows systems; it likely means that they want to enable UIPI permanently in the future.

The kernel driver also captures the process protection as part of the UIPI information and does a check that either the target is unprotected or the caller has a matching protection level. This stops the previous attack that allows NtUserGetWindowProcessHandle from opening a protected process.

One weakness in this check is it doesn’t use the comparison that the kernel uses to determine whether a protected level supersedes another. While that’s good in a way, there is a slight mistake. There’s a PPL App level that’s designed so that other processes at the same level can’t open one another. This behavior is presumably because the PPL App level was designed to be used by third party applications from the Windows Store. The implemented check would allow one PPL App process to open another, of course you’d still need to get code execution in a PPL App process to begin with so this doesn’t seem a major issue.

It’s important to note that the protection check is ignored if UIPI is disabled at a system level. Therefore if you’re willing to reboot the system and have administrator access you can disable UIPI by setting an EnforceUIPI DWORD registry value with the value of 0 inside the key HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System. You might also need to disable the UIPIAlwaysOn feature flag, you can do that using a tool like ViVe and running the command ViveTool.exe /disable /id:56625134 as an administrator and rebooting the machine.

The second major change is in NtUserGetWindowProcessHandle. The function now has two paths controlled by a feature flag ResponsiblePid. If the feature flag is disabled it takes the old path, but if it’s enabled it calls a new function GetWindowProcessHandleUnsafe. Ironically, contrary to the name this seems to be a safer version of the API.

The big change here is that to open a process the caller must have the UI Access flag enabled. Calling the API without the UI Access flag will give an access denied error. Also if you disable UIPI at the system level the API will also return access denied, it won’t fall back to an insecure mode of operation. At least on my 25H2 VM the ResponsiblePid feature flag is always enabled, but I could just be subject to A/B testing.

To open the process with KernelMode access you’ll still need to pass the UIPI check. As you can’t short circuit the check by disabling enforcement; this blocks opening protected processes. Therefore on the latest versions of Windows 11 to access a protected process, not only do you need to disable UIPI, and the UIPIAlwaysOn feature flag but also the ResponsiblePid feature flag to access the old implementation. The ResponsiblePid feature flag ID is 56032228 if you want to disable it with ViVe. This of course requires administrator access and rebooting the machine, it might just be easier to load a kernel driver.

Hijacking a TCB level Protected Process

Assuming you’re still running Windows 10 (where this will likely be a forever bug), a pre-24H2 Windows 11 (23H2 Enterprise/Education is still supported until November 2026) or have fully disabled UIPI, we can now GetProcessHandleFromHwnd to compromise a protected process.

Ideally we want to get the highest level, Protected TCB to allow us to then open any other user process on the system regardless of the protection state. How do we get a process running at Protected TCB level to create a window we can use to open the process handle? I’ve already described how to do this in a previous blog post back in 2018 on hijacking a protected process through the use of the COM IRundown interface.

Specifically it was possible to force WerFaultSecure.exe running at Protected TCB level to initialize a COM single-threaded apartment (STA). This allowed access to the IRundown interface, but more importantly for our purposes a STA also sets up a message only window with the OleMainThreadWndClass class, which is used for posting calls back to the apartment thread.

However it turns out even easier if we no longer need to force COM to initialize. WerSecureFault.exe will create a number of windows automatically during normal operation. First you need to run the process at the protected level in “upload” mode. Using the following command line:

WerFaultSecure.exe -u -p {PID} -ip {PARENT_PID} -s {SECTION_HANDLE}

Replace PID with the process ID of a dummy process to debug, PARENT_PID with your current process ID and SECTION_HANDLE is a handle to a shared memory section containing the following 32 bit integers, 0xF8, PID and TID where PID and TID are the process ID and thread ID of the dummy debug process. This section handle must be inherited into the new process at creation time.

Next you need to find the created window, but that’s easy. Just enumerate windows using the FindWindowEx API. For each window you can lookup the PID using GetWindowThreadProcessId and match it against the created protected process.You might need to use something like an opportunistic lock to suspend the WerFaultSecure.exe process after it has created the window to give you time to enumerate them.

The final step is to call GetProcessHandleFromHwnd with the found window handle and you should get a process handle back with PROCESS_DUP_HANDLE, PROCESS_VM_OPERATION, PROCESS_VM_READ, PROCESS_VM_WRITE, PROCESS_QUERY_LIMITED_INFORMATION access. Typically with this access I’d duplicate a copy of the current process pseudo handle to get a full access handle. However due to the way protected processes work this will fail, as the protection checks cover both opening the process directly and duplicating the handle.

Therefore, this is all the access you’re going to get. While you can’t just create a new thread in the process, it gives you sufficient access to the process to allocate and modify executable memory so a simple attack would be to write some shell code into the process and modify an existing jump to execute the code. I’ll leave the final exploitation as an exercise for the reader. Alternatively Sascha Mayer has published a PoC after I had posted a screenshot of my version’s console output that you can play with instead.

Conclusions

In conclusion the GetProcessHandleFromHwnd function is quite interesting in how it’s evolved over the years. The first version using windows hooks was actually secure against accessing protected processes as you can’t duplicate a process handle with access rights such as PROCESS_VM_READ from a protected process to a non-protected process. However it was decided it’d be better to do it all in kernel mode, but the check for protected processes was forgotten.

Finally in Windows 11 24H2, along with a general shake up of UIPI this seems to be fixed and the function is also no longer quite so dangerous. Time will tell if at least some of the changes, like making UIPI permanent, come to pass.

Bypassing Administrator Protection by Abusing UI Access

2026-02-12T00:00:00-08:00

In my last blog post I introduced the new Windows feature, Administrator Protection and how it aimed to create a secure boundary for UAC where one didn’t exist. I described one of the ways I was able to bypass the feature before it was released. In total I found 9 bypasses during my research that have now all been fixed.

In this blog post I wanted to describe the root cause of 5 of those 9 issues, specifically the implementation of UI Access, how this has been a long standing problem with UAC that’s been under-appreciated, and how it’s being fixed now.

A Question of Accessibility

Prior to Windows Vista any process running on a user’s desktop could control any window created by another, such as by sending window messages. This behavior could be abused if a privileged user, such as SYSTEM, displayed a user interface on the desktop. A limited user could control the UI and potentially elevate privileges. This was referred to as a Shatter Attack, and was usually fixed by removing user interface components from privileged code.

As UAC encouraged running processes at different privilege levels on the same desktop, Microsoft introduced an additional feature, User Interface Privacy Isolation (UIPI). This used the Mandatory Integrity Control feature in UAC to limit what windows a process could interact with. If the integrity level of a process was lower than the process which created a window then it would be blocked from operations such as sending messages to that window. As an additional protection, Vista no longer ran user processes on the “service” desktop so that even if UIPI was inadequate a user interface exposed by a service process was not accessible to limited processes.

To take an example, a limited user process has an assigned integrity level of “Medium” while a UAC administrator process is “High”. In this case UIPI would block the limited user process sending messages to any window created by the administrator process, excluding a small set of explicitly permitted messages. It would also block other UI functionality such as windows hooks.

This introduced a problem for any user who relied on accessibility technology, such as screen readers. If the accessibility process was running as the limited user it could no longer interact with administrator processes created on the desktop. It would be blocked from both reading the contents of windows as well as performing operations such as clicking a button. This was not an acceptable compromise, so Vista needed a way to allow these applications to continue to work.

The solution Microsoft chose was to allocate a flag for the access token of a process called UI Access. If the process’ access token had this flag set when it initialized its connection to the Win32 subsystem, the process would be granted special permissions to bypass many of the restrictions imposed by UIPI. Enabling this flag through a call to NtSetInformationToken with the TokenUIAccess information class was gated behind a check for SE_TCB_NAME privilege, and so it couldn’t be performed by a limited user. Therefore in order to create a UI Access capable process a system service was necessary to enable the flag and create the new process.

UAC already needed a system service, so creating a UI Access process was made part of the same flow that was used for launching an administrator process through the RAiLaunchAdminProcess RPC call. When a UI Access process is created through this RPC call it does not show the consent prompt unlike administrator elevation. This is important as otherwise there was a risk that a user couldn’t create the accessibility application needed by them to click the consent prompt for elevation.

In order to prevent malware just claiming to be an accessibility application the service imposed some additional checks on the executable file which must be met to enable the UI access flag on the new process:

It must have an embedded manifest with the uiAccess attribute set to true.
It must be signed by a code signing certificate that’s trusted by the local machine root certificate store. There was no special requirement for the certificate outside of this, for example it doesn’t need to have a special EKU or cross signing by Microsoft.
It must be stored in an administrator only location on the system drive, such as:
- The Program Files directory
- The Windows directory (excluding some known writable locations)
- The System32 directory (excluding some known writable locations)

If all the criteria are met then when the process is launched via RAiLaunchAdminProcess the service will take a copy of the caller’s access token, enable the UI Access flag and increase the integrity level as follows based on the caller:

If the caller is a limited user of an UAC administrator it will set the integrity level to High.
If the caller is an administrator then it will set the integrity level to High (normally a no-op).
If the caller is a normal user, the integrity level is set to the caller’s integrity plus 16 up to a maximum of High.

A High integrity level is the absolute maximum allowed to be set, although there exists a higher level, “System” that’s reserved for service processes. Also note that the integrity level of the token is not changed if the caller already has the UI Access flag enabled, this is only important for normal users who don’t automatically get set to High integrity. One benefit of setting an elevated integrity level is the created process cannot be opened for read or write access by a lower integrity process, preventing a limited user from injecting code into the new process and by extension getting access to the UI Access flag.

As an aside, you can disable the UI Access flag on the token without TCB privilege. A valid UI Access process running as a normal user can “ratchet” itself up to High integrity by clearing the flag on its own token then respawning another copy of itself via the UAC service. As there’s 4096 levels between Medium and High that would require calling the UAC service 255 times which is a little on the noisy side but it does work.

Importantly, the UI Access flag only permits bypassing a limited set of operations such as sending window messages to other higher integrity processes. It doesn’t permit using things like windows hooks which allow for code injection into a process. Therefore for a UI Access process running as a normal user with integrity level less than High it can interact with a spawned administrator process through messages, but it couldn’t do something more invasive like hooking the window message queue.

However, if a limited user creates a UI access process, it would run with a High integrity level and could take over any administrator process that contains a window. A service process with a System integrity level could only be interacted with using windows messages. But there’s no security boundary between an administrator and a system service so this is meaningless in practice.

The end result is having the UI Access flag without having a High integrity level isn’t sufficient to trivially compromise an administrator process, you would need the process to expose a user interface that could be automated to get privileged code to run. For example, an administrator command prompt can be sent key strokes to run an arbitrary command.

However, if you have the same integrity level as the target process, the UI Access flag becomes irrelevant and you can directly compromise the process with at least one window by using windows hooks to inject a DLL. This window doesn’t need to present a user interface, in fact technologies such as COM use message-only windows under the hood that can be used to compromise the process without ever showing anything to the user.

Of course this is how things worked in UAC, but what about the new and improved Administrator Protection? Exactly the same as for the existing admin-approval UAC. The UI Access process will run under the caller’s token, which in this case will be the limited user, not the shadow administrator. The process will have the UI Access flag enabled as well as the integrity level set to High.

This is a problem, having a process running at High integrity level allows you to compromise any other process running at that level on the same desktop even if that process runs as a different user. As the UI Access process is running as the limited user there’s no profile separation which is one of the key improvements in Administrator Protection.

The elevation to High integrity is also silent, so at a minimum it’d be possible to break the security boundary without prompting the user, assuming there was a suitable administrator process to exploit. All we now need is a way of getting arbitrary code execution in a High integrity UI Access process. Fortunately, there are plenty of ways of doing this.

Achieving Arbitrary UI Access Execution

Over the years there’s been a number of ways to get arbitrary code executing as a High integrity level UI Access process. While Microsoft had made it clear that they were not a priority to be fixed, they sometimes were. Let’s break it down in a series of categories with some historical detail as well as my more recent research.

Bypassing the Secure Application Directory Check

One approach to getting arbitrary code to run is by bypassing the secure directory location check in the UAC service. If you could bypass this check, you could place either your own signed executable, or an existing executable that can be hijacked, say through DLL planting.

One approach is to find a bug in the AiCheckSecureApplicationDirectory method in appinfo.dll which implements the check. This method first opens the file path provided via RAiLaunchAdminProcess, then calls GetFinalPathNameByHandle on the handle to ensure the path isn’t redirected to an insecure location. It then does a simple string check on the path looking for included and excluded directories. I found a bypass for the check back in 2017 and reported it to MSRC. The check didn’t take into account that it’s possible to write an NTFS named stream to a directory if the limited user has write access to that directory.

For example the directory C:\Windows\tracing is writable by a limited user but the tracing subdirectory is explicitly excluded in the check so that C:\Windows\tracing\file.exe would not be considered secure. However, with the same access you could write a named stream on the directory so that C:\Windows\tracing:file.exe would be considered inside the C:\Windows directory and thus secure. This bug wasn’t fixed as a security bulletin but it did eventually get resolved in a later version of Windows and is not applicable to Windows 11.

Another approach is to find a writable file or directory in a secure location that is not explicitly excluded in the check. If you find a writable file then you could overwrite it with the executable file as the CreateProcessAsUser API used by the UAC service doesn’t need a specific file extension for the executable file to be used. If you find a directory then you can just copy the executable file into that location.

On a default installation there doesn’t seem to be any location that’s not covered. One location I did find during the research is that sometimes on major Windows updates the Tasks directory is copied to the Tasks_Migrated directory as a backup. This backup directory is writable like the original Tasks and was not included in the list of excluded directories. However, you have no known way of forcing it to be created, and since I pointed it out Microsoft have added it to the list of directories to exclude.

Note: Microsoft did forget to add a check for named streams on Tasks_Migrated, however due to the access control on the directory it’s not possible to exploit as a normal user.

You can use my PowerShell tools to find potential candidates using the following command. For best results run it as an administrator and replace with a process ID of a limited user process. It doesn’t filter out excluded directories, so you’d have to check yourself.

PS> $paths = "C:\Windows","C:\Program Files","C:\Program Files (x86)"
PS> Get-AccessibleFile -Win32Path $paths -Access Execute,WriteData `
       -DirectoryAccess AddFile -Recurse -ProcessId <PID>

A final approach is finding a way to write a file to an existing secure location though a separate mechanism that doesn’t require bypassing the access control of that directory. I found just such an issue in my recent research. The Windows installer will install MSIX files into the C:\Program Files\WindowsApps directory, which is not excluded by the check. Windows 11 is configured by default to permit installing signed MSIX files without needing administrator privileges.

Therefore you can package up a UI Access executable into an MSIX installer, sign the installer with an arbitrary certificate then when installed the executable will be in a secure location. Of course to do this you’d need a code signing certificate but that isn’t as big of a challenge as it seems. You might even be able to slip the signed UI Access executable file into a store application if you were so inclined. But this is now fixed as the WindowsApps directory is also excluded.

Interestingly there is a uiAccess restricted capability you can add to the manifest when building the MSIX which will elevate the packaged executable to High integrity UI Access. However, when you do that, installing the package requires administrator privileges as shown below and so it’s not a bypass.

Repurposing an Existing Secure UI Access Executable

A second category is finding functionality inside an UI Access capable executable file that’s already in a secure location that can be abused. You have full control over the UI Access process’ command line, perhaps there’s an option to load an arbitrary DLL?

Before you can find exploitable behavior you need to find candidate executables that you can reverse engineer. You can use my PowerShell tools to find executable files which have the uiAccess manifest option set to true.

PS> $paths = "C:\Windows","C:\Program Files","C:\Program Files (x86)"
PS> Get-ChildItem -Path $paths -Include *.exe -Recurse | 
  % { 
       Get-Win32ModuleManifest $_.FullName 
  } | Where-Object UiAccess | Select-Object -ExpandProperty FullPath

With the list of candidates you’ll need to do some reverse engineering. I’ll leave that up to you.

Shared Profile and Environment

One of the big changes in Administrator Protection was the separation of the shared profile between the limited user and the administrator. The goal was to prevent privilege escalation by modifying the user’s profile on disk or the registry. Unfortunately as UI Access processes are created based on the limited user, the same as it was with UAC, this separation doesn’t apply and you can find ways of exploiting this behavior.

A simple way of inspecting for potential exploitable behavior is to run Process Monitor and capture events accessing the limited user’s registry hive or profile directory. It’s also possible to hijack things like the user’s C: drive mapping as the logon session is the same between the limited user and its UI Access processes.

This is a well known issue with UI Access and UAC so when I found it in Administrator Protection I didn’t really need to report it, but felt I should. To ensure it got handled appropriately I found a specific exploitable condition and sent an accompanying proof-of-concept. In this case I found that the On-Screen Keyboard loaded a DLL from a path based on the CommonProgramFiles environment variable. By overriding this variable in the user’s registry hive I could redirect the DLL load and get arbitrary code execution in the UI Access process.

During my research I stumbled upon a public bypass, originally for UAC but it still worked with Administrator Protection. This bypass was in the Quick Assist application, which seems to be an optional component but is installed by default on Windows 11. It abused the fact that the Quick Assist application would load the WebView2 APIs to display HTML content. WebView2 would look in the user’s hive for an overridable installation location to load its library, by overriding this to a location under the user’s control it’s possible to force a DLL to be loaded into the UI Access process.

One of the most interesting aspects of this bypass is it uses an API I didn’t know existed, GetProcessHandleFromHwnd, to get a kernel handle to the process which created a window to get arbitrary code execution in the UI Access process.

Exploit RAiLaunchAdminProcess

To launch a UI Access process, the shell calls the RAiLaunchAdminProcess RPC method in the UAC service. As is all too common with APIs that are not directly exposed or documented they can hide functionality that can result in exploitable behavior.

I reported two issues that allowed me to get arbitrary code execution in a UI Access process, one was a publicly known bypass while the other was a TOCTOU in the handling of the path to the executable file. The public bypass was described by myself in a blog post about using my PowerShell tooling to call local RPC methods. The example I gave was of calling RAiLaunchAdminProcess and abusing the fact the service doesn’t sanitize the process creation flags.

You could pass the DEBUG_PROCESS flag, and from that get full control over the created process. The blog post described this in the context of a UAC bypass, but of course it applied equally well to UI Access processes as I detailed in the report I sent to MSRC. This was one of those bugs that I was concerned hadn’t been remediated during the development of Administrator Protection, but as it was just a UAC bypass it’d clearly slipped through the cracks.

The second issue is in the handling of the path to the executable file, which allows us to compromise a UI Access process. The RAiLaunchAdminProcess RPC method has a very similar set of parameters to the CreateProcessAsUser API that’s ultimately called to create the new process. This includes having a separate string representing the path to the executable to create and the command line to pass to the new process.

As I already described in the section on the secure application directory check, the validation is not done using the untrusted path string provided by the user but instead the file is opened and the final resolved path extracted to do the comparison. However, this resolved path is only used during the check, when it comes to create the process the original untrusted path is passed to CreateProcessAsUser’s lpApplicationName parameter.

For example, if you passed the path Z:\osk.exe as the executable file the service would try to open that path then resolve the final name. If the Z: drive was mapped to the C:\Windows\system32 directory it would find the executable located at C:\Windows\system32\osk.exe which would be a permitted secure directory. However, Z:\osk.exe would then be passed as lpApplicationName to CreateProcessAsUser.

What use is this? The new process needs a base directory from where it’ll check for local DLL loads, and the CreateProcessAsUser API uses the lpApplicationName parameter, with the executable filename removed, for this base directory. This means that you can start a UI Access process using the Z:\osk.exe path; it will try to load unknown DLLs first from the Z:\ directory. If you remap the Z: drive to an untrusted location between the process being created and when it tries to load DLLs you can force an untrusted DLL to be loaded into the process and get arbitrary code execution. This is easy to do, as the UI Access process can be created suspended by passing the CREATE_SUSPENDED when calling RAiLaunchAdminProcess, remapping the drive, then resuming the process.

Access Token Stealing

The final category I’ll mention is access token stealing. This is somewhat different from the others as you commonly can’t get High integrity level from it, instead you get a process with the UI Access flag enabled which can be used to control higher integrity UI, just not abuse things like windows hooks.

As I described in an old blog post, if you create a UI Access process, you can open the process’ access token, duplicate it, reduce the integrity level to Medium and finally create a new process using that token. No step in that process disabled the UI Access flag on the token.

Subsequent to the blog post Microsoft made a change. Now if the integrity level of a token is reduced via the NtSetInformationToken system call, it will also disable the UI Access flag. If you can’t reduce the integrity level to Medium it’s not possible to impersonate the token or use it for a new process, thereby mitigating the issue.

However, I noticed that there are some places in the kernel that lower the integrity level of the token which do not go through NtSetInformationToken and thus do not end up disabling the UI Access flag. One option was the creation of an App Container token via the NtCreateLowBoxToken system call. This will set the integrity level to Low which will allow the new token to be used to create a process. Even though the process would then run in an App Container sandbox it was still sufficient to send arbitrary window messages to more privileged processes.

Silently Bypass Windows Administrator Protection

Let’s assume we now have code execution in a High integrity level UI Access process. How do we exploit that to bypass Administrator Protection? We need a process to be created silently as the shadow administrator that creates a window during its execution. From that we can use the SetWindowsHookEx, to force an arbitrary DLL to be loaded into the new process.

The best vector I found was using the fact that scheduled tasks can be configured to run with administrator privileges when executed. This still works when Administrator Protection is enabled, just the task process runs as the shadow administrator. We need a task that is enabled, can be started by the limited user and runs with administrator privileges. We can use my PowerShell tools Get-AccessibleScheduledTask command to find one:

PS> Get-AccessibleScheduledTask -Access Execute | 
   ? { $_.AllowDemandStart -and $_.Enabled -and ($_.RunLevel -eq "Highest") } |
   Select-Object Name

Name
----
\Microsoft\Windows\DiskCleanup\SilentCleanup
\Microsoft\Windows\Input\LocalUserSyncDataAvailable
\Microsoft\Windows\Input\MouseSyncDataAvailable
...

The first task in the list SilentCleanup is well known to me. It’s been used multiple times to bypass UAC, such as by abusing the fact it uses environment variables to find the executable file which a limited user can override. Unexpectedly the issue with environment variables wasn’t fixed in the version of Administrator Protection I tested, so I reported that as a separate issue.

If we ignore the issue in handling environment variables, we can abuse this task as it’ll create a window when the process runs, so we just setup a hook, start the task, wait for your hook DLL to be loaded by the cleanmgr.exe process and you’ve bypassed administrator protection. You can find a full PoC using this approach here.

Note: If you want to use the GetProcessHandleFromHwnd API, like the QuickAssist public bypass does, you’ll probably need to win a race between the process creating a window and it terminating. For example, QuickAssist uses a file oplock to cause the task process to hang when it opens a specific file. If you use the windows hooks approach you don’t need to worry about this.

Conclusions

All of the issues I reported were fixed, but that doesn’t mean there’s nothing left to find. Hopefully it’s a little bit harder than before. However, it’s still the case that if you can get code execution in a High integrity level process, with UI Access enabled or not, then you can leverage that to bypass Administrator Protection. Hopefully anything which is now found allowing code execution in a UI Access process is a serviceable security vulnerability and will be fixed.

One big change to UI Access processes over the original design of Administrator Protection is they now no longer run as the limited user. This change was introduced to fix issue 437868751. Instead they are created with a filtered copy of the shadow administrator token. This eliminates the shared profile issues, introducing much clearer separation between the administrator processes and the limited user.

Time will tell whether Administrator Protection is successful as a security boundary or not. Microsoft is taking it seriously, but more rigorous testing during development would have prevented many pre existing UAC bypasses from being missed. I’d recommend anyone interested in this feature to take a look now it’s released and the previously known bugs have been fixed.