Among viruses that have made the headlines since the beginning of the year, we can find a new variant of . This is a polymorphic PE file (.exe and .scr) infector, connecting to an IRC server waiting for commands. This latest version also infects HTML, PHP and ASP files on the system with an iframe pointing to a malicious page trying to exploit known vulnerabilities in Internet Explorer and Adobe Reader/Acrobat. Since analysis of the and versions have already been done, let’s concentrate on the efficiency of some removal tools against this threat.

Such tools are quite useful during incident response missions. They make it available to scan a system without installing software on the system, and in some cases may detect viruses that were not spotted by the corporate antivirus.

In this post, we are going to work on a particular sample of Virut, which is currently by almost every AV vendor:

However, the few removal tools we tested were disappointing. Some of them didn’t detect anything, some detected the virus in memory but not the infected files, and some detected the infected files but were not able to disinfect them. One of the tools requires that the system be rebooted in Safe Mode, which may not be feasible, especially if servers are infected. One of the tools even have a default mode which deletes infected files instead of disinfecting them, which is quite a funny behaviour when dealing with a PE infector…

These results are a bit surprising considering that, as shown above, antivirus products from the same vendors detected the sample correctly.

Dr.Web’s CureIt! is the tool that worked best on our sample. It didn’t detect the virus in memory, but detected the infected file and disinfected it:

The file was given back its original size of 70 656 bytes. Now, let’s check that the file has correctly been disinfected. Here are the main modifications induced by the infection:

• a marker was added in the Reserved field of the MZ header, to prevent reinfection

• in the PE header, SizeOfImage was increased and Checksum zeroed

• the .rsrc section was enlarged and its characteristics were modified to allow writing and execution, needed for in place depacking

• the payload was added at the end of the file in the .rsrc section, from offset 0×11400 to 0x15dff (virtual addresses 0×1014000 to 0x10189ff)

Only 4 bytes of code were modified at offset 0x68e5 (virtual address 0x10074e5):

They correspond to the overwrite of a call to GetStartupInfoA by a jump to 0×1014369:

This virtual address corresponds to the offset 0×11769 in the file and points in the middle of the payload.

Now, let’s have a look at how Dr.Web disinfected our file. It deleted the payload from offset 0×11400 and patches 5 bytes:

• 1 byte to decrease the size of the .rsrc section from 0xda00 to 0×9000 (RawSize field)
• 4 bytes from offset 0x68e5 to replace the jump to the payload by the original call to GetStartupInfoA

We can therefore conclude that our sample has successfully been disinfected (beware that this is only a specific case, several infection methods can be used by the virus). However, the tool was not able to detect the malicious iframe in HTML, PHP and ASP pages, which may be a real problem if a web server has been infected.