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.
No comments:
Post a Comment