Avoiding loader lock on DLL payload

[cookpoo78]

Hey guys, In the framework the main payload is being executed within DllMain PROCESS_ATTACH, for example here (I guess there are more examples here where the main payload is executed in the context of the current process rather than injection to another). I'm very curious to understand how is that possible with the loader lock held. MSDN really discourages from doing actions like creating processes and so, so how we bypass that limitation and everything is running smoothly from Dllmain?

[github-actions[bot]]

Hi!

This issue has been left open with no activity for a while now.

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.

[cookpoo78]

still relevant

[smcintyre-r7]

It works because we inject the payload into a new process where it runs for an arbitrary amount of time. This technique is a combination of Process Hollowing in the sense that we create a process in a suspended state and Thread Execution Hijacking due to how we update the process's main thread. It would be more traditional Process Hollowing if we bothered to unmap the existing executable sections memory and replaced it rather than allocating our own.

As for the load lock, those are just guidelines put forth by MSDN. It would be a larger problem for us if the functions we used required more DLLs to be loaded than those provided by kernel32. Kernel32 is pretty much always available in a target process, along with NTDLL. There are only a few rare exceptions.