In addition to its dynamic systems, WebPulse™ also has a number of background processes that take a deeper look for suspicious and malicious content. One of these is a PDF scanner, which keeps an eye out for exploits that involve malicious payloads hidden in Adobe's popular document format.
A couple of days ago, we began investigating a set of interesting domains that were serving malicious PDFs. What made them especially interesting is where the victims were coming from: the referring domains included a variety of news and media sites. Interestingly, when I went back through the list I captured yesterday, there were two main geographical concentrations: New Jersey (e.g., mycentraljersey.com, app.com, dailyrecord.com) and India: (financialexpress.com, expressindia.com, screenindia.com), with a few more general interest sites scattered in. (I only looked at one of our data centers, which probably skewed the list somewhat.)
There were also quite a few instances where the referring page was ad.yieldmanager.com. and that caught my attention -- it's a big ad-serving network, and I wondered if a rogue ad server was the common thread linking these attacks.
Unfortunately, I wasn't able to conclusively reconstruct the chain of events between a call to yieldmanager.com and the malicious server. Fortunately, I had better luck on one of the news sites, and here's how the attack was structured:
- The victim browses to a favorite local news site (screenindia.com, in this case).

- One of the background links on the page is to doubleclick.net (another big ad network).
- That server replies with some JavaScript linking to daniton.com (apparently a trusted third-party ad provider).

(That blue line above is showing my browser requesting data from pubads.g.doubleclick.com; the next green line is doubleclick's reply, which includes the link to daniton.com; the next green line is my browser requesting the payload from daniton.com.)
- daniton.com does serve a banner ad, but it also includes a heavily encrypted JavaScript payload (at least on my first visit; on subsequent visits it only served the banner ad).

- That JavaScript decrypts itself into an instruction to inject a hidden iFrame tag into the original host page.
- The iFrame instructs the victim's browser to silently call a malware server in the background (yesterday it was gllftcptfelu.com), eventually resulting in the PDF exploit file being downloaded.
In this case, the actual exploit payload was readily recognized by many AV programs: 16 out of 39 scanners recognized the sample I tested at VirusTotal.com, for example.
Using one of the malware names from VT, I did a Google search, and traced that exploit name back to a post on Adobe's site, where they talk about releasing a patch for Acrobat Reader to fix the vulnerability it targeted: http://www.adobe.com/support/security/bulletins/apsb09-04.html (That was about a year ago, so anyone running an up-to-date version of Reader should be safe from this payload; however, I did not do an exhaustive investigation to see if this was the only payload it tried to download.)
The daniton.com site appears to have been registered back in January, and I could only find one site that mentions it with any connection to malware -- and that just mentions it in passing. Accordingly, my best guess is that the Bad Guy behind daniton.com probably spent some time carefully building up a clean reputation as an ad server, so that it would be trusted by the bigger ad networks -- and then he threw the switch to start serving the malware.
Outbreaks of "malvertising" (ad networks serving malicious ads) are not uncommon, and they illustrate a problem with the modern Web: a trusted site won't knowingly host malware, and if it were hacked, it would likely spot the attack and clean up the damage fairly quickly. But, when it outsources its advertising to multiple networks, which in turn farm out some of the ads to yet other sites, things get too complicated for the news site to really keep an eye on. (After all, the whole point of farming out all that advertising is to reduce the cost of running their site...)
In this case, BCWF customers are safe, since we're blocking the malicious ad server, and the domains that host its malware payloads, and keeping an eye out for more.
--C.L.