NtCreateThreadEx fails with status 0xc0000022 (ACCESS DENIED)

[bodgergely]

PEB address: af9000
ImageBase address: 7ff601990000
[+] Parameters mapped!
PEB address: af9000
PEB address: af9000
> ProcessParameters addr: 000001FF954B13F0
[+] Process created! Pid = 4444
EntryPoint at: 7ff601a57318
NtCreateThreadEx failed: cb
[-] Failed!
Press any key to continue . . 

I am consistently getting the above output, both Debug and Release builds. I tried both on my physical machine and VM. I suspect something is still not working out with the env variables, I saw a closed issue related to that. Inspecting from different debuggers (ProcessHacker etc) the environment string seems to be set correctly in the created remote process and properly set up via setup_process_parameters().

I am trying to run this on Win10H1 build 19043.

https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-

ERROR_ENVVAR_NOT_FOUND
203 (0xCB)

[hasherezade]

On newer versions of Windows, the API NtCreateThreadEx is usually blocked by Defender. It may also be blocked by other AV products. Try to disable it and check again.

[bodgergely]

I doubt NtCreateThreadEx is failing because Windows Defender or other AV product is blocking its call.

I tried:

1. Turning off Windows Defender temporarely -> made no difference
2. Decided to try to create another POC to see if NtCreateThreadEx is blocked or works in more normal circumstances:

• init_ntdll_func()
• CreateFile ("C:\Windows\notepad.exe")
• NtCreateSection from the file opened -> section handle
• NtCreateProcessEx from the section handle -> process handle
• NtCreateThreadEx successfully creates a thread with the given start address (entrypoint of executable)

It seems to me that NtCreateThreadEx is definitely not blocked by WD, also the error code indicates that the failure has to do with the Environment string setup.
Not sure if you have bandwidth or desire to try yourself. I will try to poke around it a bit more. Might be the case that some Windows Update changed the implementation of NtCreateThreadEx?

[hasherezade]

Thank you for checking it. In such case, it seems indeed I was wrong (probably I confused it with some other error on NtCreateThreadEx that was occurring due to AV interference - because I remember encountering it before).
Fixing it will probably need some more digging into all the parameters required for process creation on Windows 10. Unfortunately, currently I don't have time to dedicate to it. But I will keep it in mind and try to fix soon.

[PraMiD]

I'm getting the same behavior on Windows 10 Build 19043.
I'm not sure if the 0xcb is the correct error code. This code is returned by GetLastError(). Is this the right function to retrieve errors from Nt* calls? The status returned by NtCreateProcessEx is 0xc0000022, i.e. ACCESS DENIED.

I also tried to create the initial process using CreateRemoteThread after setting up the process like in the source code of this repo. Here GetLastError returns 0x5 which is ERROR_ACCESS_DENIED.

[hasherezade]

I'm not sure if the 0xcb is the correct error code. This code is returned by GetLastError(). Is this the right function to retrieve errors from Nt* calls? The status returned by NtCreateProcessEx is 0xc0000022, i.e. ACCESS DENIED.

@PraMiD - you are right. I fixed it: 0866549

[hasherezade]

I doubt NtCreateThreadEx is failing because Windows Defender or other AV product is blocking its call.

I tried:

1. Turning off Windows Defender temporarely -> made no difference

2. Decided to try to create another POC to see if `NtCreateThreadEx` is blocked or works in more normal circumstances:


* `init_ntdll_func()`

* `CreateFile` ("C:\Windows\notepad.exe")

* `NtCreateSection` from the file opened -> section handle

* `NtCreateProcessEx` from the section handle -> process handle

* `NtCreateThreadEx` successfully creates a thread with the given start address (entrypoint of executable)

It seems to me that NtCreateThreadEx is definitely not blocked by WD, also the error code indicates that the failure has to do with the Environment string setup.
Not sure if you have bandwidth or desire to try yourself. I will try to poke around it a bit more. Might be the case that some Windows Update changed the implementation of NtCreateThreadEx?

@bodgergely - I repeated your experiment and you are right. So I will have to research it more, and add an implementation for Windows 10. It is on my TODO now, but it has to wait because I have some more urgent work.

[bodgergely]

@hasherezade @PraMiD Both of you are right, that error is 0xc0000022 (ACCESS_DENIED) as reported by API Monitor (the tool) as well.
I am already in the middle of some kernel reversing to understand where this error code is coming from (nt!PspCallProcessNotifyRoutines which calls WdFilter code) and I have narrowed it already down quite a bit, will report back my findings soon.

[bodgergely]

So to cut the story short:
Windows Defender's minifilter called WdFilter has mitigations against transacted process creation.

The filter driver will log this message (reversing wdfilter.sys)
"[Mini-filter] Blocked transacted process creation f"

I realized this after reversing the
nt!NtCreateThreaxEx -> nt!PspCallProcessNotifyRoutines->wdfilter!MpCreateProcessNotifyRoutineEx -> (realizes it is a process created from a transaction) -> nt!IoGetTransactionParameterBlock() -> Logging of the above message and blocking proc creation

Basically Windows Defender's kernel driver realizes what we are trying to do here. I have not dissected enough of it to understand how exactly, but it does. To cicumvent this, more reversing, trying to find holes etc. is needed. For now, I think this attack is dead as it is.

[bodgergely]

See here:
https://www.kernelmode.info/forum/viewtopic0b8b.html?t=4879

This issue has already been raised on some "hacker forums" with some possible workarounds:
https://hackforums.net/printthread.php?tid=6036393

[hasherezade]

@bodgergely - great work, thank you for checking the details. so, it was indeed the Defender.

I also tested Process Ghosting (which uses an identical way of setting up the process parameters as Doppelganging), and it works on Windows 10. So it excludes the theory that the problem is caused by the invalid parameters setup.

[hasherezade]

Another similar technique, that works on Windows 10 is Transacted Hollowing

[bodgergely]

Thanks for the links, I want to analyze (maybe mitigate) both Transacted Hollowing and Porcess Ghosting. Your POCs on these techniques are immensely helpful! :)