Black Coal for Koobface this Season

Malware often just isn’t pleased to be running on ThreatFire protected systems. To gather data for the intelligence built into ThreatFire and BehaviorGuard for evaluating system events (which proves to be the best at blocking malware), ThreatFire blends into the Windows system itself. Some of the changes it makes may be unappealing to malware, although legitimate applications won’t notice. This difference is because of the complicated manner in which malware continues to be written, in order to evade various types of security products.

Sometimes, it’s easy to misunderstand the cause and effect of this sort of error. Since it is difficult for customers and even testing groups to quickly understand crashes that they may see on their system, this variant deserves some space: Koobface crashes on the most recent ThreatFire protected systems. It’s much better than the alternative.

As posted previously and discussed in major publications, Koobface is an extremely active family of malware. Victims consistently fall for web pages that appear to be serving up codecs from links that are posted on their friends’ social networking pages. So the links and phony codecs seem all the more trustworthy, and victims are left with the Black Spot. Let’s dive into some of the technical details.

The latest version of Koobface maintains an unpacking stub using code that legitimate software does not contain. Instead of calling the documented and well known GetProcAddress function to dynamically resolve needed addresses of functions exported by kernel32 and other dll system modules (one of the most common, documented functions at process-load on Win32 systems), the phony Koobface unpacking stub implements a custom and somewhat bizarre address resolution routine. First, it searches for the start of the kernel32 module in its process’ virtual memory space and then performs an unusual comparison to find the beginning of the function that it is interested in, in this case VirtualProtectEx. The comparison works like this:

Locate and verify Kernel32 within the process memory space

Loop through Kernel32 one byte at a time, gathering four bytes of data for comparison

Bitwise “AND” the current four bytes of data with the next four bytes in memory

Compare the results to the hardcoded value “5181045″

Once “5181045″ is found (which is first found in VirtualProtectEx within the kernel32 address space), perform another comparison, looking for the function prologue. If it’s a match, FOUND IT!, and call into this VirtualProtectEx memory location.

The related disassembly implementing the “logic” above constains these instructions…

Now, ThreatFire makes some slight modifications to blend into the system at runtime. These modifications may cause one of Koobface’s odd GetProcAddress custom replacement routine’s checksums to fail (again, legitimate applications using “GetProcAddress” succeed at resolving their imports on ThreatFire-protected systems just fine). With this change, the Koobface unpacking stub cannot find 0×55 (push ebp), 0x8B (mov ebp) until it reaches GetSystemTimeAsFileTime, which is the incorrect function (just using the documented GetProcAddress function would work fine here). GetSystemTimeAsFileTime receives unexpected data passed in as a parameter and exception occurs.

Unfortunately, the Koobface binary may be left on the desktop because it has not performed anything malicious and ThreatFire won’t see any further behavior from the executable in question. It’s for this reason that defense in depth is always recommended — with the PC Tools Internet Security Suite, the system scanners kick in and can identify the file itself, and the Site Guard can protect your browsers from visiting malicious Koobface sites in the first place. Its layers of protection raise system protection to levels that users can be confident in.