Websense Security Labs™ ThreatSeeker™ Network has detected a new Koobface campaign spreading on Facebook. The campaign is spreading via direct messages sent from compromised accounts. Websense customers have been protected against this attack with ACE.
Some observations on employed tactics by Koobface
One of the tactics employed by the Koobface gang is to attempt to obfuscate the malicious URL that is linked in each message. In message shown above, this is done by adding "hpPg" just before the valid URL link--an obvious attempt to avoid detection by security software and by the Facebook security team. The addition at the start of the URL makes it unclickable, but this is unlikely to stop determined users from copying and pasting the link directly into the browser. Another tactic is the use of open redirects on the facebook.com domain itself. This gives the URL a more credible look (social engineering), as well as helping it pass basic security checks. Usually, Facebook alerts users if they're about to browse to a link outside of its domains, but no alert is triggered in this case.
In the message above, the open redirect on facebook.com points to a bit.ly shortened link. The redirector at bit.ly points to a compromised Web site controlled by Koobface. The compromised site checks whether the request was referred from facebook.com. If it was, then it serves a dynamically generated script that further redirects to a malicious site. The malicious site requires "a missing Flash plug-in" in order to play a "video," a.k.a., a variant of the Koobface worm. At the time of writing, the variant had a 23% detection rate.
An example redirection chain:
There are some checks in place to make sure that the request came from Facebook. If the request at the first step of the redirection didn't originate from facebook.com, a fake Google News page is presented rather than further redirecting to the malicious fake video Web site.
[UPDATE] - One reader commented that the the redirection to the malicious page can take place if any URL (not just facebook.com variations) is as referrer field in the request header at the second stage request (the request to [removed].com/24uqy7e/?md5=f6d9f0efc395fc0f331028c23f9fa5b9&page=12263). This is correct and has been verified, also it seems that a valid browser user agent must also be set in the request header in order to redirect to the malicious page. If a referrer is not set at all, the response will not present a fake Google News page any more, but a fake Facebook page that requires a login, The page is set up for harvesting credentials, once a victim enters his/hers credentials in, they're redirected to facebook.com and attempted to automatically be logged in. It seems that Facebook detects that an invalid attempt was made to login to their platform and notify the user. Beware that if the correct credentials were entered to the phishing page then Facebook may have stopped a potential attack on the victim's account but the credentials are deemed to be stolen and should be changed immediately.