I have a DLL injector - say injector.exe - that uses the Reflective DLL Injection technique. When executed, all the steps until VirtualAllocEx and WriteProcessMemory run perfectly (I put up debug print statements which show up in the cmd indicating the flow of execution). But, when it comes to the step of executing the DLL using CreateRemoteThread, an AV called ‘eScan’ is blocking the injector.exe. I have tried using RtlCreateUserThread and NtCreateThreadEx instead of CreateRemoteThread, but to no avail.
You can either look for suspicious modules in the memory space (e.g. Avast has modules named aswhookx.dll or similar) or you can check each function’s beginning bytes and look for instructions that correspond to software interrupts or jumps to suspicious locations (e.g. a WinAPI function that jumps to an address space that is marked as executable but has no name).
You can either look for suspicious modules in the memory space (e.g. Avast has modules named aswhookx.dll or similar)
I have used EnumProcessModules to list loaded modules and there are no suspicious modules, they are all trusted windows DLLs.
or you can check each function’s beginning bytes and look for instructions that correspond to software interrupts or jumps to suspicious locations (e.g. a WinAPI function that jumps to an address space that is marked as executable but has no name).
I need to get the entrypoint to the imported functions (like VirtualAllocEx, WriteProcessMemory, createRemoteThread) to check their beginning bytes, right? How do I get the entrypoint to these imported functions?
Pardon me if my doubts are too obvious or silly. I’m a beginner.
I will document all of these learnings in a blog post for posterity.
The disassembly does not look like anything I am familiar with, but can you check the corresponding NtXxx functions of those? e.g. WriteProcessMemory is NtWriteVirtualMemory. Also, is your architecture x86 or x64? You can also try extracting the disassembly in a debugger if that’s easier or more convenient.
I am using either CreateRemoteThread, RtlCreateUserThread, NtCreateThreadEx depending on a commandline argument. All 3 are caught by the AV at realtime, when they are being executed. Say, if there are no AV hooks on these functions and no AV-related DLLs loaded in my process, what other trick by the AV could be at play?
The AV detecting this injection on my VM is QuickHeal. In a QuickHeal blog post, they discuss how malware uses ‘CreateRemoteThread’ and API such as, ‘VirtualAlloc’, ‘VirtualAllocEx’, ‘WriteProcessMemory’, and ‘ReadProcessMemory’.
I think it’s fair to assume that they do check for the execution of these functions to detect injection. If yes, then how else could they be doing it?
It could be possible that your process is getting triggered within the kernel using a driver belonging to the AV via PsSetCreateThreadNotifyRoutine to detect creation of new threads which might also stop any other standard DLL injection method (maybe they could still work, I’m not 100% sure). Is your payload malicious? If it is, perhaps try using a non-malicious payload and see if the results are the same. Or perhaps you could deobfuscate your payload on runtime after injection.
Oh wow, that actually sounds incredibly unstable to me. I’ve never even attempted something like this fearing that the process will just break.
I’m not sure about how your keylogger works so I cannot comment on anything about that. Of course, if the process has some sort of GUI and the thread that handles the Windows messages does not operate correctly, it may cause the “Not Responding” message.
Have you tried what I previously suggested? Using APC or SetWindowsHookEx DLL injection.
I don’t think this is the case. From what I can understand, you are just completely hijacking a thread by setting the instruction pointer at the entry point of your DLL without returning execution back to it. It wouldn’t be surprising that something goes wrong with the process.