Something new, something old…
and something obese? A while back I received a sample on a file infecting virus. AV detection is quite scarce, with Symantec detecting it as W32.kakavex, PrevX detecting it as Covert.Sys.Exec and few others detecting it as W32.Expiro. Kakavex is quite an obese compared to its brethen like Virut; it adds about 110kb to the host file’s size!
So, let’s take a little sneak-a-peek inside to see what it has swallowed. All strings are encrypted, so no useful information can be dug out that way. A cursory glance on the entrypoint looks like this:
There’s nothing really interesting straight at the entrypoint. It pushes registry values into the stack, calls a function and then restores the registers and jumps to another section. The interesting things happen inside that sub_428c77-function.
First the start of the image is located:
After the imagebase and the PE header have been located, kakavex digs up the offset to the import directory:
It then checks for the size and proceeds to resolving the imports. First it resovles functions from kernel32.dll, and after that it resolves CRTDLL.dll, both of the resolutions done in separate functions. I guess the author didn’t think too much of space issues when coding the virus. After resolutions are done, kakavex calls OpenMutexA with the following details:
What’s weird is that kakavex calls OpenMutexA dozens of times in a row, with the exact same parameters, for some reason.
Kakavex launches a separate thread to do it’s main dastardly business, and the main thread will go into an eternal loop calling Sleep();
When the thread launches, it will call quite a many separate functions to resolve imports from various dll’s:
After the imports are loaded kakavex will decrypt a large chunk of it’s body in a tight xor-loop. Next, kakavex starts iterating files under C:\Documents and Settings\<username>\Start Menu\Programs\
When it finds exe files it will call sfc_os.SfcIsFileProtected to see whether the file is protected by Windows File Protection. If the file is unprotected, kakavex jumps into the part of the body it previously unxorred. It will open an handle to file, gets it size, allocates memory for the file, and reads it in.
Kakavex will then locate the offset to the PE header of the freshly loaded file. Then a check is made for the defined subsystem of the file (PE header +5Ch). If the defined subsystem is 3 (Windows CUI aka console), the infection routine is skipped. Another check is made on the MajorImageVersion: If the version equals 0Dh, infection routine is bypassed. I reckon kakavex keeps track this way what it has infected to avoid reinfection. AppBaseOfImport is read and saved into memory. After that sections are parsed and new section added to infect the file.
Since the virus is really big, I didn’t go through it all. I’m usually more interested in the stubs than other parts. What I don’t understand is why the author(s) has made such a huge virus? Maybe they thought it doesn’t matter, or maybe they just didn’t know better :)