Last week, I noticed an odd-looking URL in the WebPulse logs, so I plugged it into my test browser. I was rather surprised to see a fake AV attack “scanner” page pop up. Not because these kinds of attacks are rare (they aren’t; they’re one of the most common attack forms), but rather because it’s rare these days for a researcher to be able to see the attack right off — you “have to hold your mouth right” as my Dad would tell me when I’d ask why he was catching fish and I wasn’t…
(This is because, as malware attacks have evolved, the Bad Guys have typically added several layers of “snoop detection” to throw investigators off the track. Which doesn’t really work, as those layers of snoop detection themselves become fodder for the malware hunters. But that’s another story.)
Anyway, there were a couple of interesting things about this attack, but let’s not get ahead of ourselves. First, I celebrated the occasion by grabbing a few screenshots of the Fake AV attack as it progressed. No real surprises here, unless it’s that the Bad Guys still haven’t got their English right, even after how many years now?
Then
Hmm… I’m not sure what a “System ooofov” is supposed to be, but otherwise it looks pretty convincing…
Time for some more bad English:
And finally
Note that the malware domain serving the attack payload appeared to change two or three times a day. Earlier examples before thesaxaxp.com included mywzxxp.com and sxzzgroupxp.com. Looks like our Bad Guy has a thing for X’s and Z’s…
Fortunately for WebPulse users, the logs showed we’d been automatically recognizing these EXE payloads as malware. So the “warhead” in this attack turned out to be a dud. (As a side note, this payload was actually better recognized than most: 8 out of 43 AV engines at VirusTotal.com recognized it as malicious, although several were “early stage” less confident diagnoses. It’s still rather sad that I consider 8/43 to be moderately good detection.)
At this point, however, the story got more interesting, at least for me. Normally, big Fake AV attacks are driven by Search Engine Poisoning, and this looked like a big attack, and I had been planning to do some in-depth research into the current world of SEP… So I dug into the logs and started tracing back…
The attack domains were being fed by a network of dedicated relay sites (again, no surprise there). It was one of these URLs that had initially caught my attention. They looked like this:
hxxp:// t1g2mj2q.velsev.com /index2.php?q=EahLubow0T7sd5u5ukvf7FxJHDr81W3URvMzs1DJZ4urV52JkfF2RclbxNambDNFv dbMM6doS7MKLTFS&s=146/
In addition to velsev.com, sibling sites included andrides.com, evcadia.com, agladio.com, awelian.com, sonmel.com, etc. All of the URLs used similar random-looking subdomains, with similar looking query strings. The next step was to trace back and find the search engine links that the users had clicked on…
…except that I didn’t hit search engines. I hit Web ads. Interesting.
It turned out that there is a network of rogue ad servers, busily relaying users into this malware network (I tweeted [@bc_malware_guy] this list out Friday evening as I wrapped up the research, since I didn’t want to take time to write up a long blog post on a Friday night!):
- adcimp.net
- adonmax.com
- adsclickserver.com
- adclickservice.net
- adquicknetwork.com
- expapress.com
- figiserver.com
- fmdserver.com
- media-bc.com
- media-bc.net
- qwestat.net
- zohomedia.net
These domains, using pages with normal ad-looking names (banner.php, image.php, rotator.php, etc.), were indeed serving up normal-looking banner ads:
 |
 |
 |
|
 |
|
 |
|
 |
|
Malvertising attacks always present an interesting challenge for a malware researcher: When you identify a particular ad server as having served a link to malware along with its ad, a question arises: “Is this an innocent ad server that’s been hacked, or is it a malicious server that’s fooled the ad networks into trusting it?”
To answer this, I first tried to find any evidence that anyone had already outed these rogue ad servers, but all that my Google searches came up with was the normal background noise that any basically unknown domain name would yield. So I’d have to rely on my own judgement here (but I’m used to being Judge, Jury, and Sheriff…)
So, let’s review the evidence:
First, all of these ad server domains were registered just a few weeks ago (May and June this year). Whoever was doing the registration took pains to cover their tracks: the registrations were done at a number of different registrars (and not just the “usual suspect” shady ones). Likewise, they are hosted on different IP addresses, with a variety of hosting services. Suggestive, but inconclusive.
Next, every URL for a particular ad server used the exact same code — in other words, you’d expect a real ad server to serve more than one ad, right? Yeah, me too. I forgot to mention that each of those ad images above came from a specific ad server; each server running only its own ad. (Although I didn’t exhaustively check every URL from every server.)
So we’ve got a bunch of recently registered ad server domains (oh, nearly all of those registrations are anonymized; forgot to mention that), showing up in hundreds of relays into a malware network. Always a single image from each ad server….
Guilty.
One last thing to think about: none of these ad servers appeared by name in any of the dozens of host pages I checked. In other words, the victimized sites were not directly using these ad servers. They most likely don’t even know they exist. Instead, these sites have trustingly outsourced their advertising to one or more of the “big boys”. And it was those mainstream Web Ad companies that got fooled by these. (I hope they read the blog…)
–C.L.
Leave a reply
