Sunday, February 17, 2013

Zeroaccess analysis part I - Network traffic

I have seen quite a lot zeroaccess lately. I got curious and had too look more into what this piece of malware was up to. This first part will cover network traffic stuff mainly. I will post details on other stuff later...

6. Now lets keep our P2P address lists up to date:

The "fingerprint" of Zeroaccess. calling supernodes on UDP port 16464 once every second.
The bot here requests updated IP lists from it's peers. XORED 4 Bytes at a time with the iniyial key "ftp2" and then bitwise ROL for each XOR operation.
payload of the request packet:
encrypted: b8:14:35:fe:28:94:8d:ab:c9:c0:d1:99:85:95:6f:3f
Decrypted: 8a6441984c746567000000001614cc0c
decr ascii: dALteg??????Ì?

Byte 4-7: command -> getL for get updated List

The supenode will then answer(with an XORED payload like the request):
encrypted:
3b:bb:d0:88:28:94:8d:be:c9:c0:d1:99:83:81:a3:33:f8:fd:ba:99:4c:06:8e:ce:57:f2:e1:63:33:19:38:3a:d8:cc:8d:8a:cc:64:e0:e8:2f:37:3d:2f:33:93:81:a3:d3:d8:fe:b9:ce:4c:06:8e:3b:67:f1:e2:3a:33:19:38:f3:98:cf:8e:e8:cc:64:e0:9c:77:12:9d:a3:33:93:81:03:84:c6:67:8e:ce:4c:06:68:56:49:49:38:3a:33:19:11:1c:6d:bb:e0:e8:cc:64:ad:b1:b8:47:81:a3:33:93:26:4e:b3:a8:06:8e:ce:4c:c6:5b:18:b3:19:38:3a:33:42:18:b9:fd:64:e0:e8:cc:11:3c:e2:b1:93:81:a3:33:25:03:47:67:4d:06:8e:ce:e8:57:36:a3:93:1a:38:3a:c8:97:49:05:05:cc:ea:c7:7d:c1:2c:89:7b:22:2f:1c:5d:67:9b:3b:33:b9:66:cf:ab:8b:ff:ff:24:fd:6d:15:59:be:19:2d:0a:4b:cf:c8:5a:5d:e4:4d:a9:0d:06:20:38:a7:de:ec:25:21:d4:14:ca:51:05:3d:c6:33:15:70:6b:07:71:e1:2d:59:31:5f:80:a2:5e:55:18:6c:70:e4:8b:3a:e2:50:7e:6a:26:20:c2:6f:66:f1:3d:a9:06:25:74:e3:7b:73:0e:1f:25:2e:96:81:a9:48:9b:0b:27:70:70:33:9c:ff:d4:c5:8f:c6:8b:1c:66:1b:d2:6c:fd:9e:66:32:70:f4:61:67:5e:d5:99:e7:c0:d1:dc:7c:59:96:17:d0:0a:1f:7b:bd:9d:a1:af:6b:20:63:c2:26:e0:19:3f:3c:19:9d:ee:38:d7:60:73:4c:3c:21:6a:6d:d8:01:cd:50:55:2a:59:43:8b:49:80:0c:18:24:ad:d6:dd:92:54:02:f9:85:db:21:a7:91:9f:72:ea:29:97:7e:b1:c0:b0:54:83:33:06:8b:e1:8b:1c:cd:21:d9:13:1f:49:95:9e:5a:44:d7:21:25:49:ba:ff:c5:3f:ab:3c:e3:d8:3f:50:1a:db:0e:bf:d9:6c:c0:fc:1f:5d:62:67:c3:c2:a1:fe:1f:1f:83:48:14:d1:50:24:d5:d0:b4:f8:93:81:23:e8:31:93:7a:ce:18:06:8e:ff:a2:32:5f:08:52:77:7b:15:6f:da:dc:9c:53:55:27:cb:2c:91:f7:32:ff:97:aa:ee:d0:82:9c:6a:b0:19:24:b1:96:17:f6:a3:34:48:f8:a4:ba:bb:71:a3:77:cf:1c:fc:76:f0:d9:60:d1:0d:26:c0:65:6f:11:1e:de:31:b1:6b:12:11:d3:dc:e5:cf:be:fa:27:24:86:86:c4:40:ae:33:18:22:8c:ff:d3:3a:4a:ea:ef:20:80:9a:af:82:14:31:b1:36:ff:ac:90:e8:e2:9a:80:1f:86:9e:8f:ae:93:af:29:dc:4c:73:34:c8:48:67:1b:9e:d0:d7:8a:be:ee
decrypted:
09cba4ee4c7465720000000010000000defefdfe00000000cefefdfe00000000befefdfe00000000b6fefdfe00000000b4fefdfe00000000a6fefdfe0000000087fefdfe000000004deedb5d0000000044e3e0640000000074cbd0450000000061680b89000000006d60218e000000002509d48e00000000ca47852a000000007068cd9b00000000d8fc3328000000000300000001000000715b2a3ea0030000aea53971c9a80a2fe408ec5848b1aebf3a41987cfdf560413612f3e31ece742d2dd82b5de287ab288bc42d8d0a3e95a17fc0f8efabef9812d6cc9c31fe0926691b7317d3cdb1fd3b4073c79c99cf4377887d857678e4e86cce73fb6824913c1646930f156affcde25f4178d1088a84435630db9898c3010812107a86e175c5a400000080ad03be3d002e0000efefd83570f60958b5f19b2f32f22c7ff815f9214b5a2bed06f4b380a2d5f5e1c95e4b808a377329d78dc74f9c91812895ecee8b24769fb73bc96bf55fa373e016dd8253b313e41500052fc710d1bc400a2773a6ac2a30b145c5a1763605ee32af627b0c76199c69f3dfe20e651341ff54dafa9b982d6ff7847031b8bd1c1065cb0000808f17903d00540000623b3e4332616e436109e8ac749f31c71ab5583791cc042ba9b7a49fe47e5522ad0b8efa9b0e7be1d4cedd43439f03783ca76910e1723eb5c32208371850fffd670e8c4ac5ddf58dc85750e0e224a862fad8f3156c529979ccec67e7d6a90cdaa8bd2a629f89d0d8fcb26ff252eb4e7b36e01c9d40a749eb003d9d9719c6b860

I am trying to replicate your steps for analysis. i am stuck at the ROL bitwise. I XORed the packet with the key LONG "4c 4f 4e 47" but then the ROL is not giving me the same result as you have here. any tips will be appreciated

Hard to tell from so little info what is the issue. I guess you know the difference between bitwise rotate and bitwise shift.

As I do not know which packet you are looking into my second guess is that the first XOR failed too and became: aedecfbc (initial port 53 packets)which should decode a5dfceb7. If that is a correct assumption. Just reverse the encrypted string before XOR.

Thank you for analysis. If we for example take the getL command: "8a6441984c746567000000001614cc0c" then the first four bytes represent the crc32 checksum of the whole packet, as sophos says, whereby the checksum is zero before calculation, so if i calculate "crc32(000000004c746567000000001614cc0c)" i should get "8a644198" as checksum shouldn't i ? Unfortunately i do not, has anyone an idea ?

Working now ! Great, thank you for this one, but still got one question according the point "First data packet from server(50.137.49.12) to bot:payload length 928", the RC4 encrypted DLL. I want to decrypt and analyze that exemplary stream you gave. The key is actually the MD5 Hash of the file header information itself, so the request isn't it ? So adapting the endianness i use this key to decrypt the stream. What i am getting is "00000001" which is an dll file. Did you decrypt this, too ? I got an output but neither don't know if it is right decrypted nor how to check if it is the plugin i want, without the need or reverse engineering. Just want to be sure i got the right decrypted file.