You just need to find the right point. Breakpoint, that is.
We’ve had a couple of recent posts that record the use of an injection technique quite commonly used by ITW malware. It has been used for years to evade personal firewalls. New code utilizing the same technique for a variety of solutions (grey, black, or white hat) continues to be posted. Proper prevention for this injection technique has a heightened longevity because of its popularity, and it underscores the usefulness of behavioral based security products. Let’s take a look at some of the low level activity of the subject of yesterday’s post.
Using a variety of monitoring tools, we can see that the software creates an Internet Explorer process in a suspended state. Eventually, that process is started and sends yahoo messenger spam off of the system and performs a variety of tasks. Let’s use one of our favorite debuggers, Ollydbg, to identify the hijacking activity.
The dropper overwrites the entire code section of iexplore.exe process after it starts the browser in a suspended state. We’ll throw the first executable, up.exe, into one of our favorite debuggers, Ollydgb. We search its list of imports, set a breakpoint on CreateProcessA and run the executable. These listings show the unusual command-line parameter and provided to CreateProcess:
The stack shows the CREATE_SUSPENDED state of the new process:
The ProcessInfo structure that is passed back out of this call provides handles to both the process ID (PID) and the main thread ID (TID) of the newly created Internet Explorer process. These handles will be re-used later in the routine. For now, the hijacker will call GetThreadContext to copy out all of the values held in the registers of the currently suspended iexplore main thread. They will be used when the thread’s execution is resumed:
We see the entire .text section of iexplore mercilessly overwritten and extended with a loop that calls WriteProcessMemory and VirtualProtect on ten separate occasions. It’s a lot of work to hijack IE successfully!
In effect, this work completely overwrites Microsoft’s code, making Internet Explorer just a shell for the injection code to work within:
Now that the executable code has been tediously copied into IE, the context of the suspended thread is set back to its original environment (actually, a small trick is used and just the context defaults are used) and the newly overwritten thread’s execution is resumed:
What looks like a familiar browser process is not a browser at all.
If your security solution doesn’t already stop an old habit like this one, you might want to find out why not.
