Parasitic Infector Analysis

Parasitic file infectors aren't a trend anymore, but we still get some new ones from time to time, and this is what I choose to present for the malcode of the week. I have seen it regularly, sometimes appended to very common worms.

This virus isn't very complex but it has a few interesting features such as an IRC component. Our malcode will connect to a hard-coded IRC server and join a random channel. It will then wait for commands passed in query. The main command is used to download a file from a web server, and can be used to install a trojan/rootkit on the infected machine.

Since this is a parasitic virus, it uses a delta offset to find its own data. In order to make analysis easier, here is a very useful trick one can use. We first need to find the delta offset value by disassembling or debugging our sample:

Once we have calculated our delta offset, we need to load our file manually inside IDA. And we need to subtract the delta offset from the original image base:

Note: With this trick, you no longer need to calculate pointers to find out what the virus code is trying to access. If it tries to access a string, then you will see a string reference (DATA XREF) in IDA Pro, if it tries to save DWORDs, you can rename them directly, and you will have them nicely placed in your disassembly, every time this memory location is used.

Code Snippets from the virus

A few programming tricks are used by this file infector, some of them might be attempt to fool simple heuristic scanners or new reverse engineer. For instance, in order to get the kernel32 image base, it first starts using the well known stack trick. When a process starts, it has a kernel32 pointer onto the stack, because of the way processes are being started by Windows. Therefore, the virus uses it and start scanning for IMAGE_DOS_HEADERS and IMAGE_NT_HEADERS. Usually most of the virus I have seen use either plaintext/encrypted "PE" or "MZ" for this.

Our virus is actually looking for a string present in the IMAGE_DOS_HEADER. It's looking for the first word of "This application cannot be run in DOS Mode", in other word: "This".

Note: If for some reason, it changed even by one byte in a newer windows version, the virus would fail.

Part of the virus is encrypted, and it uses a static key to decrypt the rest of its code. It uses this static key to make a new one for every byte.. The algorithm is very simple and weak, as usual:

To get the decrypted code, I used Chris Eagle x86 CPU emulator inside IDA Pro. It is possible to write an IDC script, but it is just faster for such trivial algorithm to emulate the decryption code:

Most of the code isn't original at all, but I found an "interesting" area where the virus gets the NTsyscalls in memory and overwrite its code to use them later with int 2Eh.

Then comes the IRC backdoor code. The code just connects on some IRC server:

Where it waits for command:

The virus creates an event to make sure multiple instances aren't running at the same time on the infected machine. This virus will only infect .EXE and .SCR files. His Parasitic infection is rather standard. The last section of the file is enlarged, and the virus is appended. The viruses use an infection mark to prevent already infected files to be infected twice.

This mark is 0x20202020 and somewhere in the IMAGE_DOS_HEADER. The last section characteristics are also modified, so the virus can execute and decrypt itself without triggering any access violation.

Finally, the virus filters the files to infect. It checks a few criteria, such as file name, and some PE header information:

Overall, nothing very complex in this PE infector. There were a few interesting piece of code, especially compared to most boring high level malwares ;-). Unlike simple trojans (where you only need to delete a couple files and a registry key), PE infectors append themselves to your files, and the end-user cannot easily remove them on their own

Researcher: Nicolas Brulez, Websense Security Labs