Advice Request Protecting processes from injection via SetWindowsHookEx() ?

[ForgottenSeer 69673]

Oh oh maybe opcode didn't read my links. oh well I gave you the source's to the horses mouth

 

[Deleted member 65228]

Oh oh maybe opcode didn't read my links. oh well I gave you the source's to the horses mouth

I've already read them in the past, don't worry. I already saw the DSEFix one when it was first made a long time ago and I was already aware of the other project.

 

[ForgottenSeer 69673]

I've already read them in the past, don't worry. I already saw the DSEFix one when it was first made a long time ago and I was already aware of the other project.

Right but there were newer post and advances. and so I will stay out of this discussion. I been following EP_XOFF for many years. He created Ruskstock A B ect and was a loyal member of Rootkit.com . And was there before and after Holy Fathers unexplainable death.

 

[tim one]

Very good explanations, nice thread

 

[Mecanik]

Method 1:
1. NtQuerySystemInformation -> find PID of target process
2. NtOpenProcess -> open a handle to the target process
3. EAT scanning -> locate the address of the routines you want to re-patch in the target process within your own process (for your own virtual address space)
4. NtProtectVirtualMemory -> change the memory access protection at the target address within the address space of the target process remotely
5. NtWriteVirtualMemory -> remotely patch the memory at the address in the address space of the target process
6. NtProtectVirtualMemory -> re-protect the memory back to the original memory access protection remotely

Make sure the address is right though. E.g. x86 address of LdrLoadDll for WOW64 process, not an x64 address for the x64 processes.

Method 2:
1. NtQuerySystemInformation -> find PID of target process
2. NtOpenProcess -> open a handle to the target process
3. NtAllocateVirtualMemory -> allocate memory for your code-cave buffer
4. NtWriteVirtualMemory -> write to the code-cave buffer
5. NtCreateThreadEx -> get a new thread to start executing at the address of the allocated memory (now containing your injected code)

Method 3:
Same as Method 2 but targeting threads of the target process and relying on NtQueueApcThread/NtQueueApcThreadEx (Asynchronous Procedure Calls instead of Remote Thread Creation). By the way, NtQueueApcThread is just a wrapper for NtQueueApcThreadEx internally in the Windows Kernel.

Method 4:
Same as Method 3 except instead of using NtQueueApcThread/NtQueueApcThreadEx, you hijack the EIP/RIP of the targeted thread via NtSetContextThread.

Method 5:
1. RCE (target csrss.exe for Windows 7 or lsass.exe for Windows 8+) and steal an open handle for the targeted process
2. Now do either Method 1 or Method 2 using the stolen handle

You can use code-cave as a "file-less" injection method (no DLL required) and within the injected code you could then remove the third-party memory patches on routines like LdrLoadDll. Alternatively, go for method 1 and do it remotely 100%.

Patching LdrLoadDll will stop traditional DLL injection via LoadLibraryA/W and remote thread creation or APC but it won't block the actual remote thread creation or APC operation which leaves the process still vulnerable to shell-code/code-cave injection... Only way to stop remote thread creation/APC via local patching would be patching a routine like LdrInitializeThunk and KiUserApcDispatcher, both of those ideas are not practical realistically and will cause problems.

Anyway, if you really wanted to you could manually map your DLL through a file-less loader (e.g. code-cave) and thus the LdrLoadDll code execution flow redirection would never be triggered for your API monitoring module in the first place.

Thank for you for the many solutions/ideas and the in-depth explanation. However, because I am looking to prevent this from happening in the future as well and because this malware can be in any form ( renamed, repacked, etc ) it is quite hard to identify it by PID or anything else.

Hard coding fixed names for the malware is not an options, neither signatures.

The only true solution I see here is injecting all the running processes, and do your "thing" there. This will prevent current version, future versions, and any other similar programs.

Because this program is "self-protecting", the only way I could inject it to perform a test of this idea was manual mapping. And I believe that would be an excellent solution to make "sure" you always injected the processes running so you can get a result.

The test resulted better than I expected, it is super easy to detect the functions called by the malware. Once you are inside it, you can see and do anything.

I would like go to on this "path" as a result. Considering my above questions if this is legal, well who doesn't do it really... almost all AV companies do it, even some VPN clients like CyberGhost, so why can't I

There are some form of terms and conditions that can be created/included to avoid legal problems for sure.

In order for me to obtain a stable and final result I need some help I'm afraid. Even though I know quite some stuff, there are more experienced people here I believe like you @Opcode.

I need some reliable examples of manual mapping injection, x32 and x64 ( XP => 10 ). I know it's not easy to provide an answer considering XP... but my software is running on XP as well.

I believe if I can get this part done, I have a strong solution against this problem and other people can learn/benefit how to protect their applications like so.