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

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