Analysis of drive-by attack sample set

Published: 2012-06-21. Last Updated: 2012-06-21 22:05:01 UTC
by Russ McRee (Version: 1)
2 comment(s)

I thought I'd subtitle this diary more humorously as The Twelve Ways of Pwnmas in celebration of June-uary here in the Seattle area, where it really does rain all the time.

I am priviliged to be party to a wide variety of data and telemetry for malfeasance and evil. One source in particular in use at Microsoft is a list of drive-by attack URLs discovered via detection technology utilized by MSRC Engineering.
From this feed I selected twelve (with me here on the theme?) unique URLs detected as drive-by exploit delivery vehicles bountiful in malicious JavaScript. Unfortunately the reporting for the tool is currently limited only to a basic yes or no response regarding a URL's maliciousness. As such I wanted to dig in to learn more about the attributes of these attacks and share them with you here. To do so I used a specifically configured VM and copied the appropriate obfuscated content between <script> tags and ran it through tools such as Malzilla, Burp's decoder, and JSUNPACK. Obfuscation methods included UTF-16 and HEX encoding, amongst others.

Please note: all URLS herein mentioned should be considered hostile and dangerous. Should you choose to explore, please do so at your own risk with the appropriate prophylactic measures. I will post domains here but not full exploit URLs; I'm glad to do so by request. I'm also glad to share samples as requested.

Such a story is better told with pictures, in keeping with the depth of my analysis skills, but  first some notes of interest:

  1. While the likes of the JS/Mult family indicates malicious JavaScript written to exploit multiple vulnerabilities (Adobe, Java, etc.), almost all these exploits universally favor exploiting Internet Explorer vulnerabilities such as CVE-2010-0249, CVE-2010-0806, and CVE-2009-0075. CVE-2010-0249, aka "HTML Object Memory Corruption Vulnerability" was used during Operation Aurora. If you followed Aurora closely back in the day, you'll likely find the country of origin statistics below of no surprise. CVE-2010-0806 was addressed in MS10-018 and and CVE-2009-0075 was addressed in MS09-002 to correct Internet Explorer issues described as unitialized memory corruption vulnerabilities. For what are vulnerabilities where updates were issued as much as three years ago, clearly enough unpatched systems remain to warrant such common exploitation.
  2. Six of twelve samples exhibit signs of exact code reuse (Exploit:JS/AdoStream), and a seventh is a very slight variant (Exploit:JS/Mult.EA). Additional reference reading for the samples detected: Exploit:JS/AdoStream

The details on the domains of nefariousness are as follows:

 

Domain Analysis Links VT detections (of 42)
www.kasuidojo.com.ar Exploit:JS/AdoStream 32
www.ascororadea.ro Exploit:JS/AdoStream 32
www.suportemetrocard.com.br Exploit:JS/AdoStream 31
pacoaraujodesign.com.br Exploit:JS/AdoStream 30
www.czgtgj.com Exploit:JS/CVE-2010-0806.B 30
www.stubllanet.com Exploit:JS/AdoStream 30
elnido.realtyworldphils.com Exploit:JS/AdoStream 29
mj.zhuhai.gd.cn Exploit:JS/CVE-2010-0806.gen!A 27
www.meydanoptik.com Exploit:JS/Mult.EA 26
voteforomega.info Exploit:JS/Cripac.A 13
space.argstorm.com Exploit:JS/Mult.CR 9
fedeteniselsalvador.com Mal/JSBO-Gen 5

Because infographics are all the rage:

 

These samples also presented a great opportunity to use an ISC Handler favorite. When you suspect code reuse or matching, Jesse Kornblum's ssdeep is an ideal tool with which to validate your assumption. As seen above, I stated that the malicious JS from six of the twelve URLs was identical. Comparing the sample (Exploit:JS/AdoStream) from Germany against the sample from Brazil proved to be a 97% match.

 The Exploit:JS/Mult.EA sample was also noted as a slight variant of Exploit:JS/AdoStream. Using the German sample to compare against the slight variant from Turkey showed a 94% match.

I found it interesting that the very slight difference in JS resulted in four less detections by AV vendors. Here's the VT detection for www.meydanoptik.com sample (Exploit:JS/Mult.EA) versus the VT detection for  www.stubllanet.com sample (Exploit:JS/AdoStream).

The diff between the two files as seen below shows only that the www.meydanoptik.com sample sets a cookie while www.stubllanet.com does not.

 

You get the idea. There are clearly commonalities in vulnerabilities targeted, methods used for exploitation, and even country of origin.

Hopefully you've found this relevant and interesting. Please share any related insight or experience you may have via comments.

Cheers.

 

Russ McRee | @holisticinfosec

 

 

2 comment(s)

Comments

Any actionable takeaways short of don't click on any links, keep your systems patched, and update AV ?
@EVVJSK in this drive-by scenario browser counter-measures (e.g. Firefox's noscript) would be effective in limiting the impact. While the browser would execute code injected on trusted websites, these are typically redirects to actual exploit sites, where the noscript would then come into play. Not fool-proof, not a silver bullet, but raises the bar for the attacker.

Diary Archives