Key summary points :


- the IFRAME injection entirely relies on the lack of input validation within their search engines, making executable code possible to submit and therefore automatically execute upon accessing the cached page with a popular search query
- many other domains have been introduced within the IFRAMEs, a complete list of which you can find in this post, several directly hosted within RBN's network


- given the high page ranks of the current and the previous targets, it is evident that the malicious parties are prioritizing based on the possibility to abuse input validation on high page rank-ed sites, presumably in an automated fashion


hcc.cc.gatech.edu
buffalo.edu
uninews.unimelb.edu.au
uvm.edu
jurist.law.pitt.edu
bushtorrent.com
torrentportal.com


f3w.info (74.54.95.242)
gmjett.info (75.125.181.89)
egkjnx.info (75.125.208.242)
qxdprq.info (75.125.181.113)
mqghrd.info (75.125.181.82)
ecwrhk.info (75.125.181.86)
stysqf.info (75.125.181.67)
prnprn.info (75.125.181.106)
fami4ka.net (217.20.127.217)
my-ringtones.org (78.108.182.164)
leohin.com (58.65.239.10)
89.149.220.85

search-vip.org/pharmacy/search.php?q= (195.225.178.19)
vip-pharmacy.org (195.225.178.19)

The malware is loading from gift-vip.net/images/index1.php (195.225.178.19) where upon loading another IFRAME pointing to e.pepato.org/e/ads.php?b=3029 (58.65.238.59) which is using HostFresh proving hosting, dns services courtesy of INTERCAGE-NETWORK-GROUP, or the The Russian Business Network in all of its netblock diversity. It seems that pepato.org, currently hosted on one of RBN's netblocks, also made an appearance at malware embedded attack at a .gov site recently.

File Size : 16643 byte
SHA1 : 89a04c4d06f51aa6d6cb54925a2c84d2bbdba06b

Several more currently active internal pages serving variants :
e.pepato.org/e/ads_nl.php?b=1006
e.pepato.org/e/adsr.php?t=0
e.pepato.org/e/e1004.html

Monitoring these connected incidents will continue, particularly the RBN connection, and other high profile sites' susceptibility to their attack methods.

Related embedded malware research :
Embedding Malicious IFRAMEs Through Stolen FTP Accounts
Yet Another Massive Embedded Malware Attack
MDAC ActiveX Code Execution Exploit Still in the Wild
Malware Serving Exploits Embedded Sites as Usual
Massive RealPlayer Exploit Embedded Attack
Syrian Embassy in London Serving Malware
Bank of India Serving Malware
U.S Consulate St. Petersburg Serving Malware
The Dutch Embassy in Moscow Serving Malware
U.K's FETA Serving Malware
Anti-Malware Vendor's Site Serving Malware
The New Media Malware Gang - Part Three
The New Media Malware Gang - Part Two
The New Media Malware Gang
A Portfolio of Malware Embedded Magazines
Another Massive Embedded Malware Attack
I See Alive IFRAMEs Everywhere
I See Alive IFRAMEs Everywhere - Part Two

Related RBN research :
RBN's Phishing Activities
RBN's Puppets Need Their Master
RBN's Fake Account Suspended Notices
A Diverse Portfolio of Fake Security Software
Go to Sleep, Go to Sleep my Little RBN
Exposing the Russian Business Network
Detecting the Blocking the Russian Business Network
Over 100 Malwares Hosted on a Single RBN IP
RBN's Fake Security Software
The Russian Business Network

This currently ongoing malware embedded attack aimed at ZDNet Asia and TorrentReactor is very creative at the strategic level, whereas the IFRAME-ing tactic remains the same. The sites' search engines seem to have been exploited to have the IFRAME injected, not embedded, within the last 24 hours, redirecting to known Russian Business Network's IPs and ex-customers in the face of rogue anti-virus and anti-spyware applications. For the time being, zdnetasia.com has 11,200 cached pages loading the IFRAME, and torrentreactor.net - 29,300 cached pages loading the IFRAME. Even worse, the IFRAME embedded search results hosted on their sites, are appearing between the first ten to twenty search results, thanks to the sites high page ranks. Sample search queries :

jamie presley
risa coda

"The advantage gained by faking the Referer field is nullified when pages use client-side cloaking to distinguish between fake and real Referer field data by running a script in the client’s browser to check the document.referrer variable. Example 1 shows a script used by the spam URL naha.org/old/tmp/evans-sara-real-fine-place/index.html. The script checks whether the document.referrer string contains the name of any major search engines. If successful the browser redirects to ppcan.info/mp3re.php and eventually to spam; otherwise, the browser stays at the current doorway page. To defeat the simple client-side cloaking, issuing a query of the form “url:link1” is sufficient. This allows us to fake a click through from a real search engine page."

So the malicious parties are implementing simple referrer techniques to verify that the end users coming to their IP, are the ones they expect to come from the campaign, and not client-side honeypots or even security researchers. And if you're not coming from you're supposed to come, you get a 404 error message, deceptive to the very end of it. Sample redirects upon visiting the IFRAME-ed pages at ZDNet Asia with the right referrer :

scanner.spyshredderscanner.com (77.91.229.106)

porn-tubecodec20.com (195.93.218.43)

Scanner results : 11% Scanner (4/36) found malware!

MD5 : 6b325c53987c488c89636670a25d5664

Fortinet - Suspicious

Prevx - TROJAN.DOWNLOADER.GEN

Even more interesting is the fact that literally minutes before posting this, another such campaign got launched at ZDNet Asia, this time having just 24 pages locally cached, and loading another IFRAME to 89.149.243.201/a redirecting to cialis2men.com/product/61 (92.241.162.154).