Polymorphic file-infectors have been around for a long time, with possibly the first one surfacing in 1990. This has proven to be an effective technique that malicious code authors have employed to give their code a better chance of survival in the wild. Since this type of threat showed up there has been a struggle between security vendors and malware writers. Every advance in antivirus prompted the malicious code authors to come up with new and imaginative ways to thwart these efforts and vice-versa.
Currently we are seeing an outbreak of a particularly sinister file-infector, known as W32.Virut.CF. This threat has already compromised corporate networks and is proving difficult to remove from infected networks. Once this threat infiltrates a network it can spread quite quickly using open network shares. So, what is it that sets this file-infector apart from the others and what makes it so difficult to remove?
Virut went through many revisions before the CF variant surfaced. This particular variant uses many advanced techniques to avoid detection and removal. None of the techniques are new, but have been used effectively within Virut. Some of the techniques employed include an advanced polymorphic engine, spaghetti code, and encryption.
There are two layers of encryption employed by Virut. The first layer encrypts the code using a weak encryption algorithm. This layer also uses spaghetti code and junk instructions to make white-box analysis more difficult and time consuming. The first layer is also optional, which helps to make detection more challenging. The second layer of encryption is more complicated. It uses checks such as checking CPU speed, illegal instructions, and API address manipulation to detect analysis. This layer uses a custom XOR encryption algorithm, which is also weak, but built in such a way that makes it trivial for the author to change. Each change makes Virut appear entirely different to casual analysis.
Once on the system the threat injects itself into multiple processes on the system and hooks the CreateFile API. This allows the threat to execute whenever any process opens a file on the system. Using this technique, Virut can infect many files on the host system or on remote systems over network shares. It will try to infect Portable Executable (PE), HTML, and ASP files among others.
And, if that’s not enough, the threat also uses Entry Point Obfuscation (EPO) to help evade detection. The infection routine will point to the entry point of the first or second layer of encryption mentioned earlier. Alternatively, the threat scans for certain APIs in Kernel32.dll and patches these to have its payload executed. This EPO not only makes analysis and detecting the threat more difficult, it also makes it significantly more difficult to safely repair the infected files.
One further/additional thing that makes this threat so difficult to remove is the wide variety of executable formats now available on Windows platforms. This threat was not designed to infect all of these but will attempt to do so anyway. This makes the results of infection very unpredictable and the task of removal more difficult. With file-infectors, the code only has to be good enough to infect a large amount of files—if it corrupts some files and renders them useless, it rarely affects the desired outcome or purpose of the threat. We have also seen malware becoming infected with Virut, which adds another layer of complexity in terms of detection and removal. Our engine attempts to detect and repair every sample infected with Virut, but because of the complications outlined above there are some exceptional cases where this is not possible.
All of this sounds quite grim, but this threat can be removed from infected networks by following best practices. The infected machines need to be isolated and then scanned with Symantec antivirus, preferably in “Safe Mode,” in order to remove the infected files. Scanning in safe mode allows us to repair files that may be in use (for example, system files). Additionally, the virus will not load in safe mode. Non-repairable files may need to be restored from backup. Remove network shares, or make them read only at a minimum so that the virus can’t spread to them. As a last resort, highly compromised machines may need to be reimaged.
The websites associated with this threat should also be blocked at the network boundary. See the W32.Virut.CF write-up for further details on this.
Firewall logs should be monitored for outgoing requests to those sites that can give a good indication of the location of any infected machines within the network. If possible, the affected machines should be re-imaged from trusted media. When the machines have been cleaned they should be reintroduced into production networks with caution.
Note: Big thanks to Piotr Krysiuk for his excellent analysis of this Trojan.