DeXRAY – Decrypting VBN files, Part 2

Posted on by

A few months back I posted about DeXRAY –  a generic script/file carver that tries to decrypt various Quarantine files + PE files hidden inside other files under a simple layer of a single-byte xor encryption.

Some time later, in one of my other posts I mentioned that newer VBN files used by Symantec Quarantine use a different encryption scheme; instead of using well-known xor with a 0x5A key, they now use 0xA5 key.

Turns out that I was right about it, but only partially as there is a twist to it – not only these files are encrypted, but they are also divided into chunks separated by a 5 byte ‘chunk divider’ in a form of 0xF6 0x?? 0x?? 0xFF 0xFF. So, to reconstruct the encrypted Quarantine files, one needs to decrypt them with 0xA5 first and then remove the chunk dividers.

Simple, isn’t?

I updated DeXRAY.pl to handle this (quick & dirty patch, but it should work). If you find some VBN files that don’t get decrypted at all or get corrupted after decryption, please let me know.

I bet Symantec guys added this to prevent accidental detection of Quarantine files by theirs and other AV companies’ scanners; the way I think it goes is that many AV companies use X-rays technique during scans (that is, they may find malware even if it is encrypted with a single byte xor) and they could potentially/accidentally decrypt and detect the Quarantine file during scans. That could potentially lead to some ‘funny’ results (recursive detection, etc.); introducing ‘chunk divider’ breaks the file format of the encrypted file and AV scans no longer can ‘understand’ the corrupted file structure (especially if it is an encrypted PE file).

Download a new version from here:  DeXRAY.pl

 

ZeroAccess death match with Shell_NotifyIconW

Posted on by

There is a lot of ZeroAccess analysis all over the place, so not sure if anyone documented it before, but oh well…  here it goes…

I have been recently looking at a new sample of ZeroAccess and spotted that at an early stage of the infection, it injects a small code into Windows Explorer:

The snippet is then executed via Asynchronous Procedure Call (NtQueueApcThread). Just looking at the size of the payload and the strings made me curious enough so I decided to have a quick look at the code.

Turns out, this little snippet doesn’t like Shell_NotifyIconW API very much and it patches it in a very clever and selective way.

The disassembled code of the main routine from the snippet looks like this:

The PatchShell_NotifyIconW function shown on the screenshot is responsible for allocating a small buffer in memory (via ZwAllocateVirtualMemory) that will hold a code of the function modifying the standard behavior of Shell_NotifyIconW API.

As per MSDN, the Shell_NotifyIconW function takes 2 arguments:

BOOL Shell_NotifyIcon(
  _In_  DWORD dwMessage,
  _In_  PNOTIFYICONDATA lpdata
);

The new function installed by ZeroAccess looks like this:

The 33333333h is an address (patched at run-time) to the old unpatched version of the function, so that once ZeroAccess modifies the function’s behavior it can pass the control back to the original function.

As you can see, the patch is simple – it only modifies a dwMessage value so that it is always equal to NIM_DELETE, which pretty much means that any attempts to add/modify/change status of an icon on the notification area (tray) will fail.

While I have not tested it as I don’t have any image with all these security settings on, it seems to be a simple trick to prevent the ‘annoying’  security notifications from happening while the malware is doing its evil thing. This is indirectly confirmed by the way the actual patch occurs. Instead of patching the entry code of Shell_NotifyIconW in a typical, process-global detour-like fashion, the malware walks through all DLLs loaded into Windows Explorer and finds addresses of Shell_NotifyIconW function only within the Import Address Tables  of two DLLs: ActionCenter.dll and wscntfy.dll. These hold the code responsible for the system/tray icon area notifications related to current security state of the system.

Quite frankly, I like this piece of code as it is very neatly written (it even self-removes itself from memory after it is executed) but more importantly, these popups are actually quite annoying! 🙂