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.and also a couple of reports regarding the initial connect IP addresses (Commented on my blog and also by @unixfreaxjp
— FireF0X (@hFireF0X) July 30, 2013
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.
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.
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
Post publish refernces:
Symantect - ZeroAccess Modifies Peer-to-Peer Protocol for Resiliency
