Koobface is a well-discussed computer worm that tries to infect users using social engineering attacks. Koobface mainly abuses popular social-networking websites such as Facebook, Twitter, Bebo and Myspace.
In this post I’ll describe another, less discussed, distribution tactic of this malware – using SEO techniques. In this scenario, the malware automatically creates BlogSpot accounts and populate it with the latest news using Google news feed. It means that the trap-site contains up-to-date content with some of the most popular search terms.
The blog shown above is an example of such an account that was automatically created by Koobface. In addition to the news feed, the malware also adds a script that redirects the victim to a malicious website that tries to install the Trojan.
Following is a code snippet of the malicious script:
The user is redirected to a fake Facebook page:
http://mi[--REMOVED--]09.com/go/fb.php
In order to see the video, the user is asked to “Upgrade” his Flash Player. Needless to say, any click on this page will dupe the user to download the malware…
Once the malware is downloaded, it tries to create new accounts in various websites. To do that, it needs to overcome a security mechanism called CAPTCHA (“Completely Automated Public Turing test to tell Computers and Humans Apart”) that is present on many websites and is designed to prevent computer programs from performing certain sensitive actions such as creating new accounts.
Following are the actions created by the malware
The Koobface tactic for bypassing the CAPTCHA test is simple – it challenges its infected users with this test by presenting the window showing below. The user is prompted to enter the word(s) in the image or his machine will shut down. The CAPTCHA image is sent to the victim by the C&C server.
The virus darkens the background and leaves the user no other option than to insert the code in the CAPTCHA within 3 minutes or else it will shut down his computer (we tested it: it doesn’t shut down the machine:)).
Does this CAPTCHA look familiar? Let me give you a hint….
Indeed, the above shown CAPTCHA picture is taken from Twitter’s account creation form. Several other popular websites, such as Bebo, Gmail, and Blogger are being abused in similar manner.
Here is another example. This time, the CAPTCHA is part of a Gmail account creation:
Koobface, installed on the victim machine, gets a CAPTCHA challenge by Gmail:
The virus sends the CAPTCHA to the C&C server:
The process might take several seconds, depending how fast the person on another infected machine is inserting the code of the CAPTCHA.
The malware keeps asking the C&C for the code, until it receives it:
Once the code is retrieved, the process continues and the new account is created:
As can be seen in the Fiddler dump above, the malware used the retrieved code from the C&C to successfully create the Gmail account. I can even log into the account using the credential above…
The malware continues working and it is going to create its own blog post using the email it created. It is now going to open a blog on Blogger.com:
Firstly, as can be seen in Fiddler dump, it accesses to:
http://news.google.com/?output=rss
The virus takes the latest news results from Google which will be used to create the blog post.
Following that, it accesses Blogger.com to create a new blog post.
Shown here is the blog post that the malware created just like the one we have seen at the beginning of this post.
The cybercriminals use a webservice to collect some statistics. Below you can see the number of unique users who reached these pages in the last couple of days:
As can be seen in the Referrer statistics above, the users are reaching the malware webpage from different websites, while each URL is using a different social engineering technique to trick the user.
There is no doubt that the technique works – more than 150,000 users reached the malware webpage in just 2 days!
Posted by Daniel Chechik
Posts Tagged ‘Gmail’
Flash cross domain games
By Anonymous • November 15th, 2007 • Cybercrime Malware VulnerabilitiesLately a couple of research papers related to the Flash cross-domain ability have been published.
A) Cross-Domain Data Access via Flash [CDDAF] Reference by Cenarius (available in Russia only ![]()
B) Cross Domain Hole Caused By Google Docs by Billy (BK) Rios
Both researchers demonstrated relatively new attack vectors using flash.
In a nutshell, this attack exploits the cross domain functionality of Flash applications, in order to conduct a CSRF attack. Exploiting this technique is done by uploading a “crossdomain.xml” file to a domain/sub-domain that the hacker wants to attack, and then accessing this file through the loadPolicyFile(policyFile:String) method in a flash application run by the victim.
Looking at the examples provided in the above articles, we can see that an attacker can potentially steal emails from Gmail (It’s the downside in being big and successful). In order to do so, the attacker would need to upload a crossdomain.xml file to the Gmail (mail.google.com) domain.
The easiest way to upload a file to Gmail is by sending an email with attachment, of course.
(Using Google Docs is not good enough, because it’s another sub-domain docs.google.com instead of mail.google.com). Ok. We send a crossdomain.xml to the mail recipient and now try to construct an HTTP request in order to access it (look for an example in article A). And what do we get? Surprise… Google transfers an attachment to googlemail.com domain. Oops. It means, that we can’t perform a “loadPolicyFile” from the mail.google.com sub-domain. Hmmm… Ok, let’s try other file types…
After some testing, we discovered that image files are not transferred to the googlemail.com domain, but rather are stored on mail.google.com. Excellent, it’s exactly what we need.
From now our attack vector is absolutely clear:
1) We send an email with a JPEG file as attachment to the victim. Actually the “image” is our old friend – crossdomain.xml
2) The mail also includes a link to our crafted page with flash movie.
3) Flash expands the sandbox using our crafted attachment.
4) Now we can execute a CSRF attack on mail.google.com sub-domain (e.g. steal mails)
Now, this was all true and working until a few weeks ago. If you are looking for googlemail.com you are in for a surprise. Google has been diligent in working out the problems in a lot of the authentication and access mechanisms on their services (look out for more on this from us…), and have fixed the issue from the ground up. Access to attachments is now much harder if not done in the “right” way of going through the email itself as the paths in mail.google.com and the parameters needed to access them are much more random and have to go through the original message. 2 points for Google on the REAL fix instead of some half-baked patch. Keep up the good work!
Posted by Vadim Pogulievsky


