Implemented Bleak to handle DLL Injection

[ghost]

So I went ahead and added my library to replace the code that you use to inject a DLL.

You will notice that I didn't actually remove / rewrite the underlying function ExecuteFunction as I noticed it was being to used to call .net dll functions.

Let me know if this works. I didn't realise that you were dealing with calling .net functions from DLL's as well (I have a library in the works for doing this but it's no where near finished) so I couldn't use my library to replace the entire functionality.

[unknownv2]

Hi @Akaion,

I tested the injection method using the manual map method and it doesn't seem to load the DLL into the remote process. I tested using Notepad (64-bit) as a remote process on Windows 10.

I also tested the other methods from your library and those worked though (such NtCreateThreadEx, SetThreadContext, etc..). Are there any specific requirements for the target process for the manual map process to work?

[ghost]

Hi @unknownv2

How do you determine whether the dll is loaded into the process? By manual mapping the dll into the process, the process isn't aware that there is a module loaded into the process and thus won't show up in any module lists etc (why it is so effective at being stealthy.) The only way you would know if the dll was loaded into the process was if the dll main method did something like open a gui or display a message.

I just realised that in your case you might still want access to the dll in which case the best method to use would be SetThreadContext (thread hijacking) as it is the most stealthy but still maintains the ability to interact with the dll. This will allow the dll to show up in module lists.

Another thing you could look at doing would be to use something like SetThreadContext and Erase / Randomise the PE headers (Randomise being the best option in my opinion) which would make the dll very hard to identify.

If this sounds better I will update my pull request later for you.

[unknownv2]

@Akaion I think SetThreadContext is the way to go since I have to be able to get the injected DLL's exports addresses to execute the functions required for starting and initializing the loading of the .NET assemblies from the host process.

What kind of information does the PE randomization hide or obfuscate that would be used to detect the DLL?

[ghost]

@unknownv2 It seems like the best option for your situation.

In regards to randomising the PE headers, this prevents identification of the DLL through scanning the headers of loaded modules as well as dumps of the modules in the process. Essentially you will know that a module is loaded but you won't be able to tell if it is legit or not. This is also better than erasing the headers as it looks a lot less suspicious.

Do you want me to implement this in a pull request or can you do it?

[unknownv2]

@Akaion I think I can take it from here. Thank you very much for the information and suggestions. I will test with your library's methods!

[ghost]

No problem! Let me know if you need any assistance. Awesome library btw. Must be a tremendous effort maintaining something this big.

[unknownv2]

Thank you and I'm trying my best, just thought EasyHook was great so I thought why not give it a shot at porting it.