Exetools - Strange question about CreateRemoteThread

Exetools (https://forum.exetools.com/index.php)

- General Discussion (https://forum.exetools.com/forumdisplay.php?f=2)

- - Strange question about CreateRemoteThread (https://forum.exetools.com/showthread.php?t=19554)

Strange question about CreateRemoteThread

Hi,

I have noticed that when I create a process in a suspended state and use CreateRemoteThread to load a dll (using LoadLibraryA) into that process, after the call to CreateRemoteThread even when the dllmain o the library is set to do nothing in addition to the 1 main thread and the one on purpose created thread I see 3 more appear with the start address ntdll.dll!RtlInitializeResource+0x410 why?!
And can I somehow avoid that?

Are you sure there are no statically loaded DLLs into that process that are creating the threads either from the original process or loaded DLL? There can be lots of DLLMain codes running in that process not to mention the one WinMain. You probably have to check the DLL import list recursively from the process and for your injected DLL.

The goal is to load the injection dll into any process without much prior knowledge about it. The process doesn't get a chance to start WinMain as its being created with the CREATE_SUSPENDED flag.
My DLL definitely does not cause the thread creation, as when I run CreateRemoteThread with LoadLibraryA and an invalid path the same behavior manifests, minus the thread for my DLL as it terminates instantly.

When I use my DLL in sandboxie (instructed to inject it) it works fine but sandboxie does not use CreateRemoteThread it just hijacks the main thread.

I would like to use it also without sandboxie, but the simple approach with CREATE_SUSPENDED and CreateRemoteThread seams to have unwanted side-effects.

PS: I also tried calling CreateRemoteThread fo the function Sleep with a 10 sec delay, with the same effect, my thread gets created, this time it just waits 10 sec and terminated, but also these strange 3 threads appear.
Also tried a mostly clean test VM.
My suspicion is that for whatever reason CreateRemoteThread (or NtCreateThreadEx) ends up triggering something that adds this additional threads.

Just google "ntdll.dll!RtlInitializeResource+0x410", you will find it may be related to Windows Search. Most of them are complaining about high CPU utilization.

for example(with stacktrace):
https://forums.stardock.com/495882/start10-is-adding-25-cpu-usage-with-every-search

When a thread is started (doesn't really matter, main or injected yours), the process has to be initialized including loading DLLs and some standard DLLs may create threads.

I'm guessing you're using Windows 10? Where the Windows PE Image Loader uses the thread pool to parallel load images.

You can disable parallel loading in the registry and retry for fun (not profit):
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\FILENAME.exe]
"MaxLoaderThreads"=dword:00000001

Note that you have to replace the 'FILENAME.exe' key with whatever is the file name of the target.

You could also set the value in the targets PEB (untested):
PEB.ProcessParameters.LoaderThreads = 1

this LoaderThreads stuff sounds like its the cause of my issues: https://stackoverflow.com/questions/42789199/why-there-are-three-unexpected-worker-threads-when-a-win32-console-application-s/42789684

lets see if I can do something against it without modifying the registry.

Quote:

Originally Posted by DavidXanatos (Post 120298)

I already mentioned another option that doesnt involves the registry in my post:
"You could also set the value in the targets PEB (untested):
PEB.ProcessParameters.LoaderThreads = 1"

Yes I saw that, and it seams to work :D

Code:

        PROCESS_BASIC_INFORMATION basicInfo;

        if (NT_SUCCESS(NtQueryInformationProcess(pi.hProcess, ProcessBasicInformation, &basicInfo, sizeof(PROCESS_BASIC_INFORMATION), NULL)) && basicInfo.PebBaseAddress != 0)

        {

                PEB peb;

                NTSTATUS status = ReadProcessMemory(pi.hProcess, basicInfo.PebBaseAddress, &peb, sizeof(PEB), NULL);



                BYTE ProcessParameters[1040];

                status = ReadProcessMemory(pi.hProcess, peb.ProcessParameters, &ProcessParameters, sizeof(ProcessParameters), NULL);



                const int LoaderThreads = 1036; // FIELD_OFFSET(RTL_USER_PROCESS_PARAMETERS, LoaderThreads);

                *((ULONG*)(ProcessParameters + LoaderThreads)) = 1; // disable parallel loading



                status = WriteProcessMemory(pi.hProcess, peb.ProcessParameters, &ProcessParameters, sizeof(ProcessParameters), NULL);

        }