W32/Winemmem – Know Your Enemy

Do you remember what the first goal of file infector distribution is? It is demand. Without demand, infected files may never be downloaded by end users. What is the second goal? To stay undetected by most AV products. A week ago we found a new file infector that fits the bill.

Nowadays, instead of relying on mass mailing, malware authors are specifically attacking individual companies producing popular software. We’ve been contacted by several software development companies with a similar issue – suspected malware on their machines. Somebody noticed that hashes calculated for setup installers and packages distributed to million of customers were different from what they should have originally been.

Brief reference – “Setup package installer application creates executable installation wizard of windows program without changing software functionality and data file integrity. Advanced setup creator tool generates program setup self extracting file by adding company name, version, setup name, desktop icon, copyright text, start menu icon, installation folder path and license agreement. Setup generator program includes multiple application files into single executable .exe setup with full install and uninstall feature.”

Packages (executable files) were self protected using strong integrity checks, some were digitally signed. This is common for professional setup builder tools producing self extracting executables; to check integrity of the installer before uncompressing and extracting data in order to protect the product and make sure it is not damaged or modified. Checksums and similar protection features are implemented in every popular self extracting archives (WinRar, WinZip), installers (NSIS, Astrum, InstallShield), and software protection systems (ASProtect, Themida or Armadillo). If anything happens to the installer, e.g. any single byte is modified – the end user will be notified with an error message. But in this particular case none of the users reported any problems while running packages / installers, no warnings were raised by any AV products either.

We’ve received about 5 different samples. All executables were created with either commercial or open source setup builders, were packed, and contained overlay (extra data at the end of the file) where installers typically keep compressed and/or encrypted data. Upon execution, samples did not perform any visible and unexpected activity, extracted files were clean (majority of executables were digitally signed and had a valid signature). Since the files inside the installers are not modified, the only way malware can be distributed is by modifying the installers themselves, so Avert Labs Research Team was notified to take a closer look on suspicious files.

Within about 30 minutes, a new generic signature “W32/Winemmem” was added to the database to detect a new file infector and clean the virus body in order to remove the detected virus from the file, so that the file can be used safely.

Let’s go ahead and follow the virus logic to understand what it does and see how it was possible to infect installers and bypass self integrity checking. W32/Winemmem infects packages, installers, and self-extracting archives (files with extra data, so called “overlay”). It rewrites the code section of the original application (1) and relocates a random size block of code from the beginning of code section and OEP (2) to the end of the file (3 and 4 below accordingly), increasing the size of extra data. This Virus does not create new sections; it does not modify the PE header. In order to gain control when an infected file is run the Virus rewrites the original code located at entry point:

Once an infected executable is executed, the virus hooks the CreateFileA() API. W32/Winemmem gains control and searches for Windows PE executables in the Program Files folder. It then parses the Import Table and searches for system dynamic link libraries (DLL) associated with executables (EXE). Next, the virus copies the found DLL to the same folder that contains the found EXE file and infects the copied DLL by modifying code at the Entry-Point and appending the virus body to the end of last section, so that malicious code is executed every time any of the infected EXE files are run. Upon execution of any “infected” files in Program Files folder, virus hooks the WS2_32.dll Send() API and performs malicious activity the first time an infected application calls it. It may infect files on removable drives by searching the entire drive for suitable executables, or download and execute files from remote hosts.

So, since the original setup installer is modified, code section and file sizes are changed; why doesn’t the application perform self integrity checking; why aren’t users warned? Once an infected file is executed, the virus restores the original application on disk by rewriting data from the beginning of code section and OEP back to file. In order to prevent the classic interceding update scenario, Windows locks the file and it is not possible to write to it. In order to bypass that, the virus drops a kernel-mode rootkit (MD5: CE769EAE2F1A7A4ED622C15E715D851E) and hooks a kernel-mode API located in ntoskrnl.exe (the function name is concealed for a security reasons). According to our research, this routine is called by the file system before deleting or opening any file for write access. All the rootkit needs to do is to hook the API and check for input parameters. That’s exactly what it does – patches the first 8 bytes to return 1 in all the cases, by rewriting the beginning of the API with two instructions:

8 bytes and you can delete any file on disk no matter whether it is running executable, loaded dynamic link library, or any other file locked by some process. While testing it, I managed to delete entire Windows folder without any errors or questions from secure operating system.

But what is the purpose of hooking the ExitProcess() and ExitWindowsEx() API’s? Since the original file on disk does not contain the virus body anymore (remember, the virus is in memory and the file on disk was fixed in order to bypass integrity checks), W32/Winemmem needs to infect the file again once user tries to close the installer (ExitProcess) or reboot the system (ExitWindowsEx).

Ok, what about second goal I mentioned in the beginning – is it invisible for AV products? Even though it is not polymorphic, a majority of AV vendors, except for a few (not listed here that catch dropped rootkit) do not currently detect the Virus (as of 07/04, as seen in these VirusTotal results):

Btw, this variant of W32/Winemmem keeps all the information necessary to restore original file at the constant offset unencrypted. If you are writing cleaning for this one, check the table located at OEP + 0×159. It contains VA’s and sizes for the stolen bytes.