November 25, 2009Blog Staff By Blog Staff

Fakealerts: Building a Better Mousetrap

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

In general, the use of fakealerts — those bogus warnings that look like your PC has started some sort of antivirus scan on its own, then predict imminent doom if you don’t buy some snake oil product right this minute — is on the rise. Fakealerts constitute a particularly effective social engineering trick, earning the makers of bogus, ineffective “antivirus” programs millions of dollars (and the scorn of victims) in the process. So it should come as no surprise that the fakealerts themselves have gone through some technological advances in the past year.

In the past few months, the fakealert-makers have slowly been migrating their techniques to a new platform: The browser. As recently as six months ago, the majority of fakealerts we saw were generated by small Trojan Horse applications running on a victim’s PC. Today, most fakealerts we see simply reshape the browser to mimic the appearance of a generic antivirus application.

It makes good economic sense for the creators of fakealerts to do this. The Windows application fakealerts only run on Windows (obviously). Like all Windows software, fakealert apps subject to being blocked by both the operating system (which, like the fakealerts themselves, prompts users with warnings in dialog boxes), by real-time detection mechanisms in legitimate antivirus software, and/or by savvy users themselves.

One typical load-sequence for the components of a scripted fakealert

Using a scripting technology such as Javascript to reproduce the “fakealert experience” is a natural extension of the success of fraudulent, rogue antivirus products. After all, a fakealert is no more than an elaborate performance for the targeted victim — the goal of the fakealert is simply to convince the victim to download and run a file, typically a rogue antivirus product. Javascript can run in virtually every browser and operating system (save for special cases, like the Firefox browser with the NoScript Add-On installed).

Scripts such as these bypass most traditional malware protection because, in essence, there is no malware installed until the victim installs it his- or herself. Unlike a static binary executable, the contents of a script can be tweaked, on the fly, to maximize effectiveness (or just to change the name of the fraudulent product). And the scripts themselves which make up the Web fakealert experience are highly obfuscated, which makes them more challenging for automated systems to block.

In the course of researching a new malware sample unrelated to fakealerts — an installer of Trojan-Downloader-Dermo on a page purportedly offering an update to Windows Media Player — I observed one common fakealert script as it ran soon after the testbed PC was infected. I was able to reconstruct its modus operandi.

Trojan-Downloader-Dermo installers closely correlate with infections from a spy we call Adware-Sabotch. That was true in this case, as well: Dermo downloaded Sabotch, which in turn opens a hidden IE browser session and periodically loads online ads from legitmate ad serving companies. In this capacity, Sabotch is a tool to engage in clickfraud. But occasionally, it also loads pages known to host various browser exploits. This morning, Sabotch happened to visit a drive-by fakealert page, so I followed that rabbit hole to see where it would lead.

The initial fakealert page loaded two script files and contained more than 41KB of what looked like garbage. This was the first chunk of obfuscated script.

Luckily for me, the authors provided all the clues I needed to decode the contents: The two script files contained the scripts that (a) decrypted text that was encrypted using the TEA encryption algorithm, and (b) decoded the result, which was base64-encoded text. They even helpfully included the password, “test.” Thanks, guys.

It turns out that this large chunk of encoded text contains the stylesheet and some of the HTML code used to engineer the look and feel of the fakealert page. Along with the scripts, the fakealert uses a few image files that contain all of the visual elements the fakealert displays on what the fakealert creators call the Central Landing page. The stylesheet defines portions of these image files that contain the desired icon or user interface element. Here’s what some of these elements and icons look like:

According to the text, this flavor-of-the-week rogue is named Windows Web Security. It even includes the following helpful (sic) description for some of its fake results:

“Spyware is software, which can gather information from user’s computer throught Internet connection and send them to its creater. Gather information can be passwords, e-mail adresses and all that data, which is important for you.”

Glad we cleared that up.

Most importantly, that script contains the URL of the download link to the rogue installer.

When a victim clicks anywhere within the page, the script will push that file at the user. It also loads yet another script, called scn3.js — and as you can guess by the filename, that script contains the bogus text of the “scan results” that appear when you permit the script to run.

The scan script was also obfuscated in a different way, but it just decodes itself on the fly, so it isn’t hard to turn incomprehensible gobbledegook like this:

Into slightly more comprehensible gobbledegook, like this:

This is the “results” box that the script pops into the middle of the page after the “scan” is complete. It looks naked because the script populates the contents of the box with text from the scn3.js script:

And in the end, it puts it all together into a very compelling, customized interactive movie. The final result looks something like this:

One wonders what good the coders who contrived this farce could have done if they had only turned their skills to helping people, instead of defrauding them.

wordpress blog stats

Share Button