Archive for November, 2009

Koobface on Yuotube

Thursday, November 12th, 2009

The Koobface gang and their inability to spell is a giveaway for the latest of their trick pages. If you end up at a page that states “This content requires Adobe Flash Player 10.37. Would you want to install it now?”, and the title of the page is “YuoTube”, your spidey sense should start to tingle.

The latest Koobface trick includes thousands of accounts at Google Reader (many continue to be up). Here is a shot of what today’s Reader pages look like hosting phony YouTube videos:

GoogleReader

Of course, these Google Reader pages are not new, and are not particularly notable, as other groups have used the same scam in the past year to drive the same redirections to other sites that host the malware. Here is one that is up today, a giveaway is the Title of the page “YuoTube”, instead of “YouTube”:

YuoTube

At the same time, the older Koobface style of flash player update pages served by the same gang all over the web appear to be more attractive to users, and attract many more hits. They are up and fooling users as this post goes up, here is a representative page to look out for, which, if you read this blog, you’ve seen before:

OldStyle

The phony “setup.exe” codec installer (which is really the Koobface malware) and the scheme still tricks many users. Don’t get fooled.

Spamvertizing Social Networks and Why Legitimate Money Will Help Clean Them Up

Saturday, November 7th, 2009

Dennis Yu provides an experienced insider’s perspective on ad networks’ social networking monetization process. Fascinating details of major players within the ad networks and their practices. It’s amazing how difficult it can be to make money in a legitimate way online:

“I will walk you through how these online scams work on Facebook and other social networks – the mechanics of how the money is made, some of the people involved, and who is actually clicking on ads. If you’re reading this article, there is a good chance that you are not the type of person actually clicking on these spam ads, but are you curious as to who actually is?”

Zbot: Not Your Typical Malware

Wednesday, November 4th, 2009

The cybercriminal gangs developing and distributing Zbot have been highly active recently, as seen here and here, so let’s dig into the code again.

On a day to day basis, malware researchers locate a sample of interest, which can seem similar to isolating a grain of sand on a beach, and investigate it in the lab.  Some tools are utilized to capture information generated by the sample which typically include changes to what Windows runs at startup, browser default page settings, newly installed programs or libraries, generated network traffic, and, if neccesary, unpacked/decrypted copies of the sample.  With most samples, this information collection process is straight forward, but Zbot is smarter than your average malware.

These tools are very effective for analysis because it can be easy to determine which changes came from which programs.  After unpacking a regular malware sample, it is possible to control it using a debugger and walk through interesting sections of code to see how it works.  This ease of analysis is where Zbot separates itself from typical malware.

The first action recent zbot variants perform is to unpack themselves (sdra64.exe, F836BA2BA0CEE2B8F0CFEE31BB535515), and instead of performing any immediate botnet-related tasks, it injects this unpacked code into the winlogon.exe process and terminates itself.

This injection is interesting for two reasons. First, the winlogon process is very sensitive.  For instance, asking a tool like process explorer to terminate the winlogon process can cause a blue screen of death.  Even if an anti-virus scanner detects this payload in memory, it is tough remove because it has to be careful not to take down the winlogon process with it. So the selection of this process target in particular was carefully done.  Secondly, the payload of this injection requires running inside the actual winlogon process for initial activation.  The payload attempts to piggy-back off of a “non-IO worker” thread running uniquely within the winlogon process via the CreateTimerQueueTimer() function. If the payload is artificially injected into another process, the payload will not exhibit its malicious behavior. This runtime requirement makes it difficult to emulate the payload’s environment for research purposes.

A portion of the payload does not only execute from within the winlogon process, however. The activated code running within winlogon (described above) also injects a copy of itself into the first real svchost.exe process that it finds.  It uses the same thread piggy-backing techniques employed in the winlogon process.  One of the first tasks that this newly injected payload performs is the downloading of the encrypted configuration file.  Later, after this configuration fetching task is complete, it injects this same payload into all other processes, which then engage API hooks to intercept the victims’ online banking web traffic.

These injection and information stealing tasks are all coordinated with the payload residing in the winlogon process via named pipe inter-process communication mechanism.  The pipe is typically accessed via the file name “\\.\pipe\_AVIRA_2108″ and uses a mutex with the same name (_AVIRA_2108) to guard against simultaneous access to this resource by multiple payloads in other processes.  This named pipe is watched for a series of number commands which perform particular actions, some of which are listed below:

05: opens local.ds
06: closes local.ds
07: opens user.ds
08: closes user.ds
09: closes sdra64.exe
10: opens sdra64.exe
14: intentionally causes a NULL pointer dereference (crashes the winlogon process, resulting in a BSOD)

In the screenshot provided below, we can see a piece of code that executes immediately after downloading the encrypted configuration data.  It sends the command “6″ to the named pipe which tells the winlogon payload to close the “local.ds” data file, which resides in the %SYSTEM%\lowsec directory.  It then writes a fresh “local.ds” file to this directory, and instructs the winlogon payload to re-open this data file with the “5″ command.

Svchost Example Zbot Command

Svchost Example Zbot Commands

Separating the malware execution into code chunks that reside in different processes makes it difficult to analyze what this bot actually does. With each chunk camouflaged inside a real process, the separation also makes it difficult to properly clean off your system once infected, due to the infection being spread all over legitimate processes.