Detecting reflective DLL injection

Question

In the past few years, malware (and some pen-test tools like Metasploit's meterpreter payload) have begun to use reflective DLL injection (PDF) to load a DLL into the memory of a process. The benefit is that the file is never written to disk and is difficult to detect. Many examples I've seen are based on Joachim Bauch's work.

However, at DEF CON 20 Andrew King demonstrated that he was able to detect DLL's injected using reflective DLL injection. His presentation was called "Detecting Reflective Injection". Unfortunately, he has not released the source code (which he certainly is under no obligation to do).

UPDATE: Apparently I missed it, but Andrew did open-source this work a couple years ago: https://github.com/aking1012/dc20

In addition, a tool called "Antimeter" can detect the meterpreter engine when loaded using reflective dll injection. Again, closed source.

I understand that Andrew King's tool and Antimeter are both written in Python and use pydbg/pydasm in order to enumerate the memory of running executables.

Does anyone have some general source code (in Python, C, Delphi, or otherwise) that they are willing to share that demonstrates how to detect reflective DLL injection? There are memory forensic tools that can analyze a memory dump and find this, but I'm looking to execute an application on a running system (like antimeter does) and find processes with reflectively injected DLL's.

If you are interested in understanding how reflective DLL injection works, there is some open-source code written in Delphi that shows how to do this.

UPDATE: I tested and I can reflectively inject DLL's without admin rights (and as a regular user), but of course as a USER I can only inject into processes running at the same integrity level (and in my session)...but that still covers applications like the Office suite, Internet Explorer, etc.

Answer 1

What about hooking the VirtualProtect API. Because DLLs that load itself will certainly set execute on its memory code range. This is because (as you mentioned) they use User access rights so they have to use the process userspace API.

NTSYSAPI NTSTATUS NTAPI ZwProtectVirtualMemory(     IN HANDLE ProcessHandle,     IN PVOID *  BaseAddress,     IN SIZE_T *     NumberOfBytesToProtect,     IN ULONG    NewAccessProtection,     OUT PULONG  OldAccessProtection  ); 

If you hook that at the very beginning of your program, you can filter out suspicious protection calls (the one that enable code execution). I would then scan for PE header or such in front of the requested pages to know that its a loadable module... note: i think this is not called for regular DLLs as LoadLibrary handles this inside the Kernel space. right? TODO: verify

Normally the PE header is located 0x1000 (4096) bytes or one page in front of the first executable code. So a VERY basic approach can be to scan for the "MZ" tag:

char* pe = ((char*)BaseAddress) - 0x1000; if ((NewAccessProtection == PAGE_EXECUTE || ... ) & pe[0] == 'M' && pe[0] == 'Z') {     // do checks here } 

If you need further info on API hooking just ask or read tons of articles on the net. Another hooking candidate is: FlushInstructionCache(...). But I think only Blizzard is using this for warden anti cheat modules as theres no reason on x86 architecture to call this.

... just a thought,

will