Using /createtoken causes 'imm32.dll' to not load for non-elevated users (error code 0xC0000142)

[cubiclesoft]

I'm opening this issue before anyone else does. As seen in the video, the new /createtoken option can start 'cmd.exe' without any issues as another user on the system as a child process of a non-elevated process in the same session.

However, attempting to start basically any other process within 'cmd.exe' results in an error message. For example, running 'whoami.exe' causes the Windows loader to fail to run the executable. Digging into the situation, it looks like 'imm32.dll' is the culprit. Actually, the DLL loads BUT the DllMain() function is apparently having issues with something, so it returns an error condition to the Windows loader and THAT causes the error code 0xC0000142 to be raised. There are no errors, warnings, or other logs in the Windows Event log. Because this is Windows. I am only guessing that the problem is in 'imm32.dll' but it's a pretty safe bet given how many 0xC0000142 errors I had to suffer through adding all of the token options to various tools over the past few months and using SysInternals Process Monitor to debug the situation each time. You kind of learn what to look for. It's the last DLL mentioned by the Windows loader in Process Monitor before the process suddenly quits.

The problem is that it isn't possible to get Visual Studio or another debugger injected into the mix because those programs also try to load 'imm32.dll' and, well, the Windows loader also fails to load those applications. And, since the process needs to run with a completely different token to replicate the issue, the current crop of Windows debuggers are completely useless. AFAIK, it's not possible to get a debugger attached to the Windows loader itself and tell it to hook into the Visual Studio debugger when it goes to run DllMain() for a specific DLL.

Very little is actually known about 'imm32.dll' but appears to be integral to starting most processes. It appears to be related to the Input Method Manager and IME, so it's probably related to keyboard handling. There also appear to be a bunch of COM-related things that it does. Dumping a decompiled version of the DLL via Reko turned up an interesting and possibly relevant call to GetProcessMitigationPolicy() in a function that DllMain() calls and I believe PROCESS_MITIGATION_IMAGE_LOAD_POLICY is the structure passed but it could also be PROCESS_MITIGATION_SIDE_CHANNEL_ISOLATION_POLICY. Reko kind of barfed on the decompile, so it's kind of tough to figure out what exactly is going on. My best guess that I've been able to come up with so far is that it could be that the DLL thinks it is running in a remote environment and therefore fails to load. But it's just a guess. It could be something entirely different.

However, it's pretty odd that the second /createtoken call with the same user account but operating at System IL (i.e. the "slightly broken token") works totally fine in roughly the same structure (i.e. imm32.dll loads okay but 'whoami' has some minor issues - possibly environment variable related). I know I kind of downplayed the default DACL in the video but that could be part of the issue and maybe Windows has defenses in place to prevent the very thing I'm trying to do unless it is System IL. And maybe it would also work fine with a SYSTEM parent. At this point, I honestly have no idea and I really just wanted to shove the entire project + video out the door and get some semblance of normalcy back into my life before my own brain melted.

At any rate, this is all completely brand new, unexplored territory in Windows OS process creation. There are bound to be a number of issues to resolve.

[hubermarkus]

Hi, was this ever fixed? I have a service running with the nt-autority\system user, so i have full rights. i want to search my active user (who is not admin on the machine) and give him a cmd.exe with UAC Access. That should be possible? i could not really get this working right now.

[cubiclesoft]

No. This issue has not been fixed. It's also probably not related to whatever you are running into. It's also possible that this issue is a non-issue due to how I was testing it.

Just so you know, NT AUTHORITY\SYSTEM, by default, does not have every privilege in the OS. This is by design. There is no single all-powerful account on Windows like there is on most other OSes.

UAC is its own thing. Users with admin rights have a split token. Users without admin rights just have their regular token. Creating a token from scratch, on the other hand, completely bypasses UAC. Creating a token with the /createtoken option requires constructing a very long and complex string.

If you haven't already done so, then I recommend watching the YouTube video at the root of this repo on how tokens and this tool works and getting more familiar with security tokens and privileges.

However, I don't believe this tool can create a process on a different desktop from another desktop without knowing, in advance, the target desktop name. You would first have to get a list of available desktops and then target the active desktop. Even then, it's a largely untested aspect of this tool.