Investigating Malicious Website Reports

Published: 2010-09-04. Last Updated: 2010-09-04 17:18:28 UTC
by Kevin Liston (Version: 1)
1 comment(s)

This morning we received a report from Holger about a website that was triggering alerts in Google and his anti-virus applications. I wanted to share my response process.

 

My first step is selecting the right "responder music." You can't have a good incident reponse montage without your jams.

 

Next, it's a bit of domain analysis. There are a number of helpful sites that host whois and dns details about a suspected site. I use domaintools.com, others swear by robtex.com. In this particular case, the domain was registered in 2004. As a generalization, long-lived domains like that do not raise red flags, but the domain expired 30-AUG-2010 (just a few days ago) which could indicate a window of opportunity for a criminal to acquire a nice bit of "respectable" internet real-estate.

 

If you want to interact with the suspected website, you should use something safe. It's a little harder to determine which tool-set is safest when dealing with malicious websites since you don't reliably know what they're targeting most of the time. I went with an OSX image that was pretending to be a windows box.

 

Malware authors are catching on to the old wget-with-a-spoofed-user-agent trick. I've taken to synthesizing victim behavior by first starting with some google-searches so that I can build a convincing referer URL. Googleing for the domain turned up mainly the main website and a lot of traffic analysis of the domain from places like Alexa and trafficestimate. I added the "inurl:" google syntax in the hopes of finding examples where an attacker may have been spamming out links to forums and such to drive attacks to the exploit site. The search didn't turn up many results (something that also didn't raise any red flags,) but when I tried to have Google translatethe site for me (a risky move but I can easily restart the image) I received the Google warning that Holger reported. At this point I have what I need to grab a copy of the potential-exploit. I still use wget, and spoof the user-agent to look like an IE request, and use the referer link from the Google search.

 

The request worked, but URL that allegely pointed to a .JPG returned HTML. That's a bit unexpected. By glancing through the HTML results the obfuscated javascript jumps out. A handfull of Math.* calls and document.write statements are a pretty solid flag that something odd is going on. In this case its intent was to create a pop-up to an ad-server.

 

The owners of the website claim that the Google and AV alerts about the site are false. I will grant that the intent behind the obfuscated script wasn't overtly criminal in this case, but I wouldn't call it a false-positive result. I would urge the advertising network to be up-front about what they're advertising and where they're advertising it from. There's no reason to use document.write games to set up your javascript calls to your ads.

1 comment(s)

Comments

A lot of legitimate websites, including some of the MAJOR news sites, have had advertisements that served up fake antivirus and other malware (from other servers). This has been going on for perhaps 18 months off and on. It is a major problem when you cannot go to a legitimate site because their advertisements are from untrustworthy servers.

Most major sites seem to have taken notice and have gotten better at not accepting ads from shady orgs, but a lot of other legitimate sites are still struggling with this.

Diary Archives