Threat Research

The case against URL blacklists

There's lots of talk these days about how URL based signatures are quickly becoming obsolete, but rarely you see real live proof of this.  Today I'll show you a couple quick examples to try to hammer the point home.

The malicious links mentioned below are intentionally broken.  Do not attempt to load them in a browser as you will be infected.

First up to bat is hxxp://www.hmall.com.  Alexa (http://www.alexa.com/data/details/main/hmall.com) reports this site as being ranked 8,055 worldwide, so a URL reputation database probably would have passed and exploit on this site through to your users.  Often times, when a site is hacked (like in the recent SQL injection worm), the hacker (or s-kiddie, really) sticks in a malicious iframe that does the actual exploiting.  A URL blacklist might possibly work in that case, but as we can see below, the hacker stuck the whole exploit on the hxxp://www.hmall.com webserver:

Hmall

As you can see, the whole exploit resided (yes, we always contact the site before we publish any data) on hxxp://dcx.hmall.com/css/index.htm, but the secondary download was on hxxp://222.233.53.126/H.exe (last warning: don't open that link!).  If you're curious, that malware is recognized by 9 out of 36 AV products on VirusTotal as NsAnti (http://www.virustotal.com/analisis/cd3883f02168cbafc8edf43797de9c5f).  A search for the exploit URL on GOOG turns up nothing - ditto for MalwareDomainList.  If you're curious about the FireEye detection internals, our appliance doesn't use signatures - we simply replay

network flows through local, sandboxed VMs, and observe the resultant OS changes and network behavior.

The next URL is/was hosted on hxxp://www.banneradz.net/xo/a.php.  As an aside, all the "/xo/" exploit pages I've seen in the last couple days appear to be down - DNS resolves but httpd isn't running.  What you see below was detected and recorded live at one of our deployments.  Here's a quick screenshot that shows the site from over the weekend attempting to exploit a host:

Banneradz

Again, Google turns up nothing on this domain, so it's unlikely that this is popular enough (even though we saw many unique instances of it over the weekend) to make it onto a URL blacklist.    In this case, the exploit is hosted right on the server.  An interesting note is the affiliate string in the URL, which is a pretty good indication that this exploit page was being rented by a party other than the guy doing the actual exploiting.

The last example I'll give today shows the ineffectiveness of URL categorizing.  As shown in the packet capture below, the site hxxp://www.woodmed.com/Osteopathic%20Medicine.htm was hacked and was redirecting to malware.  "Woodmed.com" appears to be some sort of legitimate medical site, and certainly something that would have been allowed by a standard URL categorizing device.  In this case, the server was directly hacked and a hard 302 redirect was added.  In all fairness, a URL category device would probably would have provided some protection as it would have caught the page to which you were redirected, but the hacker could simply have loaded the malware directly on the medical site, should he have so wished.

Woodmed

These three techniques are only a few by which blacklist based defenses are failing you.  Does this mean that you should throw out your BlueCoat box?  Of course not - security in depth and all that jazz.  Just don't believe for a second that a list-based solution can provide you adequate protection.

Alex Lanstein @ FireEye Malware Intelligence Labs

Comments/Questions to [email protected]