Analyzing code injectors
Increasing numbers of malware are injecting code into other processes whether to stay better hidden or to hook some vital functionalities. When debugging these for analysis things get tricky when you might have to be debugging two different processes. On top of that, if you’ve ever debugged something that injects into lsass.exe or other critical processes and the code sucks so much it bluescreens your whole computer you feel the sting when you lose valuable time due to reboot and redebugging.
So, what can be done? The method I prefer is creating a decoy process :) Basically it’s just a program that sit’s in the tasklist doing nothing but sleeping (sounds nice, eh? I wish real life work would be that easy) . The program looks like this:
start: ; The CODE entry point to the program
_loop:
push 1000
call Sleep
jmp _loop
exit
Now, let’s say we have a program that injects a piece of itself into say explorer.exe, quite a common approach in malware these days. You can guess by the imports (OpenProcess, VirtualAllocEx,WriteProcessMemory, CreateRemoteThread etc.) how it does the injecting. Set a breakpoint to the needed API’s.
When the OpenProcess breakpoint fires, the stack in OllyDbg should look something like this:
The ProcessId in the above belongs to explorer.exe, and we’ll change it to point to our decoy.exe:
Now let the wheels roll and when you break at CreateRemoteThread, top of the stack should look something like this:
3B3B77 is the entrypoint of the remote thread in this case. Write it up :) Now you can fire up your favourite dumper, and look at the allocated regions inside the decoy.exe. In my case they looked like this:
003b0000 00001000 comm prv PAGE_READONLY
003b1000 0001a000 comm prv PAGE_EXECUTE_READWRITE
00400000 00001000 comm img PAGE_READONLY (decoy.exe)
Comparing the regions with a snapshot of earlier state revealed nicely that the blocks 003B0000-003b1000 and 003B1000 - 003CB000 were the result of code infection. Dump the regions into a file, and set the entrypoint at the value used at the CreateRemoteThread APIcall, 3B3B77 in my case.
Now you are ready to continue the debugging or analyze the injected code safely without worry that the crappy piece of malicious code spanks you high and low.