Archive for March, 2008

Not all that funny (continued)…

Monday, March 31st, 2008

A few other sources of information have stated that there isn’t much that has changed with these binaries. That may not be completely true.

The packer itself has changed. So much, in fact, that AV detection for these binaries is non-existent. Is the “Tibs” packer not being used? What is so different about this one that is causing problems for signature-based solutions?

First off, let’s look at the static characteristics of the newest executables: two sections, .text and .rdata are present. Instead of nonsensical lists of outdated, disjointed and unused api calls in its import directory, this one contains four imports from kernel32.dll, like a number of other packers commonly used by legitimate packers.
Here is a screenshot of the import nonsense that packed Storm executables exhibited in the middle of last year, based on an executable used for our Virus Bulletin 2007 presentation:

And here is the tight listing of imports for this new Storm variant:

Frank Boldewin provided a great paper on the Storm packer/cryptor algorithms used in previous Storm executables’ unpacking stubs. He even provides visual aides to demonstrate the runtime flow:
1. First stage xor decrypter (or decoder)
2. Second stage TEA decrypter
3. TIBS unpacker

But not only has this set of unpacking steps changed, the executable payload doesn’t include kernel level components anymore. A dll (testdll_f.dll) is unpacked within the downloaded executable’s process space, which then drops a copy of the aromis.exe executable to the windows directory, and adds the executable path to the Windows firewall exception list — something Storm attacks previously evaded with kernel mode injection into services.exe. There is no file mapping based driver infections, this variant simply adds a value to the current user’s run registry key. We’ll have to look into this one further, it is a stripped back variant as far as autostart sophistication goes.

This code has changed quite a bit from what we would expect from Storm. More details to follow.

Not all that funny

Monday, March 31st, 2008

Another holiday, another round of Storm.

This time, the gang is sending around email attachments associated with an April Fool’s Day theme.
If you click on a link in an email with an “All Fool’s Day” message, you may arrive at a site with an image like this one. DO NOT download and run the file:

The sites are offering downloads like “funny.exe”, “ecard.exe”, “foolsday.exe” and “kickme.exe”. One of its first chores is to copy itself to “aromis.exe” in the c:\windows directory. Then, it sets a firewall exception rule and attempts to “phone home” on various outgoing ports. This first set of steps is unusual for Storm, but is consistent in the samples we are observing.

Always exercise caution and do not just click on random links sent to your account via email. Exercise even more caution when that random link is attempting to provide an executable to your system!

Common Hijack Habits Are Hard to Break

Thursday, March 20th, 2008

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.