Redirection affection

A few months ago I highlighted the importance of control over user web traffic in today’s attacks [1]. Compromised web sites and spam messages containing URL links are the main ways today in which attackers get user traffic. Once they have this, they can deliver the payload of their choice.

Often the spam messages themselves do not link directly to a malicious site. Instead they link to content hosted on legitimate sites which then redirects the victim appropriately (an old trick to evade anti-spam security products). In this blog I will highlight two good examples of this which we have seen recently.

1. Email & Facebook spam, blog site redirection

A few weeks ago we spotted a fairly aggressive Facebook spam campaign enticing users to visit a site hosted on a popular free blogging site.


Subsequently, we have been seeing other spam (not Facebook) along much the same lines.


In either case, clicking on the link takes you to the blog page, which contains an embedded malicious Javascript (detected as Mal/Budcr-A). The heavily obfuscated script has a simple role in the attack – redirection. The user is redirected from the blog site to another site where the payload of the attack is delivered. For the Facebook spam, the payload is suspected to be a phishing scam (harvesting their Facebook credentials). For the email spam, the purpose of the attack appears to be selling online medications.

2. Email spam, image hosting site redirection

A second example of redirection was seen in an attack a couple of days ago. Large volumes of spam messages offering free XP and Vista updates were seen, each containing a link to malicious Flash (SWF) files hosted on a free image hosting service.


The purpose of the SWF (detected as Troj/SWFDlDr-F) was (you guessed it) redirection. Anyone clicking the link in the spam message would see the following:


Clicking on the ‘Run’ button would infect the victim with (drum roll…) fake alert malware (sigh). Thankfully, variants of this are detected as Mal/EncPk-EU.

These two examples are not unusual, or particularly unique. Just good examples of the tricks the attackers go to in order to evade detection, trick victims, and ultimately make money. The use of SWF files in the latter example is yet another indication of attackers adoption of Flash abuse.