Remember my earlier post about parsing the output of handle.exe? Well, I received the output of this tool from a customer with a system that, in all likelihood, was infected with W32.Virut.CF. Using the Perl script from my earlier post, I found a mutant named 'l0r8' within the winlogon.exe process.

An interesting item about this malware is that it doesn't appear to use autostart locations within the Registry or file system in order to maintain persistence; rather, it achieves persistence as a file infector...some of the files infected get run on a regular basis, so the infection remains persistent across reboots. A list of files infected by at least one variant of Virut can be seen here. Here's a nice write-up on another variant of Virut, and here's an informative blog post from Fortinet.

So, when examining a system that may be infected with Virut, don't expect to find a process running or a Registry entry that will point to an executable file. From a post-mortem analysis perspective, look for the artifacts in the write-ups available, in particular an odd entry in the hosts file, an entry in the Registry allowing outbound connections through the firewall (AuthorizedApplications\List in the DomainProfile or StandardProfile...the fwconfig.pl RegRipper plugin can help you here), and a value being added HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer key.

One important aspect of forensic analysis when it comes to malware infections is that customers are asking the question, how did it first get on the system? This malware doesn't float around on its own, and it doesn't install itself as an executable, launching from a Registry key, so we'll have to find another way to determine when and how the system was first infected. One way to do this is check the last modification time on some of the files that were infected, and correlate those to the Registry artifacts listed with some of the variants. If you're not sure which files to check for (some variants may infect different files), there's another means of determining some of the files you can look at; some of the write-ups on the malware state that it patches sfc_os.dll in memory, disabling Windows File Protection, presumably to infect 'protected' files. Therefore, we can use a tool such as WFPCheck in order to determine infected files, and from there, determine the last modification time of the files.

Don't forget to check the contents of the host file, and if the described artifacts are present, check the last modification time, as well.

Now, one thing to keep in mind is this...what happens when an infected system is rebooted? When the system starts back up, infected EXE files are launched and the activity indicative of the malware occurs again...but are the EXE files re-infected? If so, the last modification time of the files should be shortly after the last reboot...something we can correlate with other system artifacts. So the question becomes, are the Registry and file system artifacts the result of only the first infection instance, or are they reproduced each time the system is rebooted and the infected files are run again?

Now, if you have a Windows XP or Vista system, you may be able to use existing Restore Points or Volume Shadow Copies (respectively) to narrow down (to an approximate window) when the system was infected.

Once you have a timeframe to focus on, use timeline analysis of system and user activity to attempt to determine the original infection vector...via web browsing activity, email attachments, or possibly connection of USB removable storage devices or connections to network shares.

One of the things that really bothers me sometimes about the AV industry is the lack of information that's available with respect to a great deal of the malware that's out there.

Take Virut, for example. Microsoft's Malware Protection Center had a post here about a new variant being available, and there's information here regarding the Virut virus family (info about the latest variant, Virut.BM, is here).

Of course, the various AV vendors also provide some modicum of information about either the Virut family or a specific variant, all with varying levels of information. Some, like McAfee, provide more information than others, so that if the AV product itself isn't picking up the virus (due, in part, to its polymorphic nature) then maybe you can look for artifacts (modification to the hosts file, Registry keys/values, etc.) that may help you narrow down not only the infection, but also help you identify other infected systems.

One interesting aspect of all of this, and glaringly obvious in its absence, is any discussion of Windows File Protection, or WFP. While WFP is not mean to be a security mechanism, per se, the fact of the matter is that if Virut infects all EXEs on a system, then it would stand to reason that protected system files that are infected would be replaced by WFP...IF it were not disabled. Since there seem to be no discussions about this at all (at least not since Dec 2007), then it would stand to reason that the virus does, somehow, disable WFP.

So...does anyone have any thoughts on why Microsoft isn't letting its customers know about this?

Addendum: First, per the comments to this post, the MMPC listing for the virus was updated to include information on the method used to disable WFP/SFP while this post was being written.

Now, in yet another example of the massive disconnect between AV vendors and their customers, McAfee has a post on W32/Virut.n that refers to "Registry entries", without specifying whether the entries are Registry keys or values. Symantec, on the other hand, calls the data added to the Registry an "entry" in their W32.Virut.CF post, but provides enough information to indicate that it's a value.

How is this a disconnect? Many customers of these AV vendors have enterprise-wide infrastructures, and need to determine other systems that may be infected. MS's WMI provides a fantastic capability to quickly determine this...and yet, without clear, concise, and correct information, customers are left struggling.

Is it really that hard? I mean, you've done the analysis, and have the information. What's the issue? Also, why is MS the only vendor that I've found so far to make any mention of WFP being disabled?