Decrypting encrypted strings in Zeus

There are a few strings in the latest Zeus bot that are stored in an encrypted format. When a function needs one of them, it calls another function to decrypt the string and store it in a buffer on the stack. There are only about 50 of these encrypted strings, and as I found out, they aren't very interesting. They aren't exposing any hidden functionality - I suspect they were just included to make reversing the bot a little bit harder.

The strings are referenced by a table where each entry has a structure that looks like this:

struct {
  ushort XorKey;
  ushort Length;
  char *EncryptedString;
} encrypted_string;

In IDA, the table looks like this at first:

To figure out what these strings were, I first reverse-engineered the decryption routine. There were actually two separate routines - one that returns the strings as ASCII and the other as wide characters. This is the decryption routine for returning ASCII data:

It's very simple - each encrypted character gets the string length subtracted from it, then XOR'd with an 8-bit key which is different for each string.

To get a decrypted string, a function will put the requested string's index into EAX and put pointer to hold the decrypted string in EDI (ESI is used for the wide character version), then call the function I labeled GetEncryptedString(). The actual code used by the bot will PUSH a 32 bit immediate value and then POP it into EAX:

To make it easier to understand the disassembly, I wrote an IDC script that will first decrypt and label the strings in the encrypted string table, then search the code for references to the GetEncryptedStringA() and GetEncryptedStringW() functions to add comments to those.

Here's the script:

After running the script, the string table now looks like this:

And code that calls the GetEncryptedStringA/W functions looks like this:

This makes reading and annotating the disassembly a little easier.

How Zeus finds the base address of kernel32.dll

I found this function in the new version (v1.4) of the Zeus/Zbot data stealing trojan:

This function uses the PEB (Process Environment Block) of the current process (stored at fs:[30h]) to locate a linked list of loaded modules. The PEB contains a member called Ldr that is a pointer to a PEB_LDR_DATA structure. This structure contains a set of LIST_ENTRY structures that point to linked lists of LDR_DATA_TABLE_ENTRY structures. The InMemoryOrderModuleList linked list is used to enumerate the loaded modules by the order that they're loaded in memory.

For each module in the list, it does a simple hash of the first 24 bytes (or 12 Unicode characters) and checks the hash against a certain value (0x6A4ABC5B). This value happens to be the hash for "kernel32.dll". Once this module is located, the base address is returned in the EAX register.

The technique of enumerating the loaded modules using the PEB is commonly used by malware to locate the base address (which is also the module handle) of certain DLL files to avoid using the GetModuleHandle API call. There are a few reasons to do this:

1. Some malware auto-analysis tools and generic unpackers hook calls to GetModuleHandle

2. The address of GetModuleHandle may be unknown - this can happen if the code doesn't know what context it's running in, for example in shellcode and injected threads

3. To make static analysis of the code more difficult

After some Googling, I found out that this code was originally created by Stephen Fewer of Harmony Security in June of 2009 and described in his blog post. It was intended for use in Win32 shellcode, and it's no surprise that malware authors are now using it.

Of course, I didn't bother with the Googling until after I fully analyzed the function... I could have saved some time if I just searched for 0x6A4ABC5B like a good malware analyst generally does when finding a function with a hardcoded value... Lesson learned!

Other than Zeus, this code is also used in the Win32.Annunaki virus according to this Chinese analysis from ByteHero.com