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
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!