Archive for the ‘Spyware’ Category

A Zbot Botnet Dubbed The “Kneber” Botnet

Thursday, February 18th, 2010

Zeus is an extremely effective bot builder kit designed and developed to be sold in underground markets as a cybercrime kit, enabling buyers to easily build identity theft related spyware that evades many security solutions. The writers have been known to do custom work as well, all for a price.

The bots produced by the kit were in turn called ”Ntos” and ”Zbot” by major software security vendors. We’ve kept on top of its activity over the past couple of years, describing its distribution as a part of other attacks, drive by attacks, and spam blasts. The ThreatExpert blog maintains posts here and here. ThreatFire is one of the most effective, if not the most effective, products on the market at detecting and preventing the Zbot variants on user systems. It detects them clearly as “Spyware.Zbot”. Because one gang of the bot distributors have been so determined and successful at distributing the malware to high-value targets over the past couple of years, an individual zbot botnet currently made up of a reported 74,000 zbot infected systems is being renamed as the “Kneber Botnet“, based on the username this Zbot variant uses.

We have posted a dozen times about Zbot over the past couple of years, including stats on Zbot-downloading Bredolab variants being run on user’s systems. Locations of the tens of thousands of systems on which users have run Zbot itself over only the past six months vary across globe, but here are a recent top ten from the ThreatFire community.

GlobalStats

These Zbot hits are the malware that get through spam filters, mail AV scanners, etc, and Zbot actually was run on the user’s system and then prevented by ThreatFire. It’s also interesting to know that over 70% of ThreatFire users are running another security solution on their system (indicating that ThreatFire is first and only to detect and prevent in a startling number of incidents). ThreatFire protected all of our users that were tricked into running Zbot, and it’s a good thing. The vast majority of these variants were configured to steal banking credentials, in addition to other valuable user data.

Note – the Dns domains registered to “Hilary Kneber” from which the attacking web sites served the zbot spyware (which cleverly must helped in naming the botnet), maintained the Zbot executables as “bot.exe” from a couple of different directories. One would think that this filename may be a giveaway to security monitors. On victim systems where the malware was run, it seems that the file was downloaded and renamed to both “svchost.exe” and random names like “58e.tmp” so as to camoflage its purpose. It predictably then would attempt to copy itself to c:\windows\system32\sdra64.exe.

Bredolab Downloading a Different Banking Password Stealer

Wednesday, January 27th, 2010

As a followup to our early Jan Bredolab email blast warning, this post presents technical details and functionality about the payload accompanying the delivery notice + invoice attachment. While past posts have described the downloader’s windows api hook overwrite functionality, related social engineering techniques, its Zbot and FakeAv downloads, this post identifies a different injection and banking password stealing payload.

The Bredolab downloader variant repeats the same exploits to bypass security apps and perform “hook overwrites”. It abuses the same exploits as our previous variant; MS07-017, MS08-025, CVE-2004-2339. These hook overwrites are performed across the dropper threads and all injected threads (within explorer.exe and svchost.exe) with a simple comparison and copy: rep movs dword ptr es:[edi], byte ptr ds:[esi].

After the injection into explorer, the malcode reports its installation and retrieves info at dollardream .ru, dropping a tmp file to disk and running it. Following the connection with dollardream. ru, the new process creates a directory under users\application data\microsoft\windows and the mspdp<number>.dll, making the dll a persistent presence on the system with an AppInit_dlls registry entry. After the dll and reg key have been created, it deletes itself and calls InitiateSystemShutdown, restarting the system.

Because this DLL maintains an entry under the AppInit_DLLs registry key, it reliably will load into each process running on the victim system’s, including all web browser processes. At dll load time within Internet Explorer, for example, it hooks a dozen different windows API prologues. The malicious code is precisely placed to be reliably notified when data important enough to be encrypted is being sent off of the machine. It intercepts and examines all user data prior to encryption.  When data being sent over http is examine, the code first performs a hash comparison on the HTTP headers to identify “interesting” Urls. These approximately 25 “interesting” Url strings are all banking and financial account related, except for a couple social networking and photo share web sites. Here is a view of the code locating content within the raw packet data, after a user has typed their username/pass and clicked on “Login”:

bank_01

Once the malcode parses the data stream and identifies interesting locations within the stream, it retrieves the input data (i.e. banking user names and passwords), and immediately writes the sensitive data out to file. The file is placed in the same subdirectory as the dll itself, in our lab example: “all users\application data\Microsoft\Windows\Network\Network\mspdb80.dll”. This “.dll” file extension and name choice mimics that of a legitimate file distributed with Visual Studio, and instead contains the stolen login data in plain text. This content is gathered and sent off the system to a server hosted in Russia in the 109.196.143.xx range…

Bank_login

As you can see, it is very important to pay attention to the attachments that you attempt to open, and whether or not they are malicious executables or just look like a harmless spreadsheet.

 

Update (2/10/2010): appears that other researchers are interested in alerting the public as well, only their February writeup includes interesting details that ACH and wire transfer institutions are targeted by the dll, in addition to what was posted above.

One Big Invalid Pointer Reference 0Day

Friday, January 15th, 2010

The Google compromise in China story builds interest as Microsoft released an advisory and blog post on the relevant Internet Explorer browser vulnerability, crediting “details” to Google, Mandiant and others. A number of factors are unfolding a dramatic story here, with the detection of a 20-year old Stanford student’s computer targeted and attacked (it seems to be no surprise that a regional coordinator of Students for a Free Tibet would be another target), and mention of Sergey Brin’s own Russian refuge background reported “The source told the Guardian the company’s decision was largely influenced by the experiences of Sergey Brin’s Russian refugee background.”

The 0day Google hack attacked a invalid pointer reference within Internet Explorer. It seems that malicious web links were visited by Google employees, resulting in FUD spyware installations on their workstations. Over the past couple of decades, this type of vulnerability has been exploited and sometimes resulted in hugely prevalent and successful exploits on the web, such as the infamous createTextRange Internet Explorer mshtml.dll hole.

Update: Google China employees seem to have been given an early holiday, according to Tech Crunch IMers.

The trojan itself has been analyzed and described on our ThreatExpert blog here and more information from Symantec on the attacks here.