Malware Characteristics
Initial Infection Vector
How did the malware initially get on the system? Some malware may be a secondary or tertiary download, so the IIV may not appear to be related. IIVs can include USB devices, malicious JavaScript in HTML pages, a SQL injection attack, email attachment, etc.
Propagation Mechanism
How does the malware move about and get on other systems? For secondary and tertiary infections, this may appear to be the IIV. Some means may be USB devices, the use of psexec.exe (or similar code), etc.
Artifacts
Indicators of the infection; similar to seeing ripples in a pond to know that a stone was dropped into it. These can be Registry keys/values, network traffic (i.e., DNS queries), unusual atx.job files listed in the SchedLgu.txt file, unusual files (PE files located in the user profile, including "Local Settings\Temp", etc.)
There are a number of techniques used to minimize the artifacts. For example, some SQL injection strings include "sp_password"...not to change the password, but the use of the string also tells the SQL server to NOT log the transaction. The use of the "Content-control: no-cache" tells systems (including the Windows API) to not cache content; artifacts won't appear in the index.dat or browser cache. Another technique is to use the DLL search order to ensure that malicious DLLs get loaded before the legitimate one. In these cases, the key to analysis is to understand the system to the point where you can identify something that should be there but isn't.
Persistence Mechanism
This is a unique artifact, with the specific purpose of maintaining persistence on the system, allowing the malware to survive reboots and logins. Most often this consists of Registry keys/values, but can include file system artifacts (i.e., putting programs in the %UserProfile%\Start Menu\Programs\Startup folder, taking advantage of the DLL search order, etc.). For example, one of the observed persistence mechanisms for Ilomo/Clampi (see the Trend Micro write up below) appears to be a copy of "uninstall.exe" in the %UserProfile%\Start Menu\Programs\Startup folder for multiple users.
Write-ups
Zeus Analysis - http://www.fortiguard.com/analysis/zeusanalysis.html
Ilomo/Clampi - http://us.trendmicro.com/imperia/md/content/us/trendwatch/researchandanalysis/ilomo_external.pdf
Malware Detection
One of the issues that I've run into time and again is being provided a drive or image, and being told, "we think this system had malware on it, we need you to find it." While this could ultimately turn up a lot of stuff, most often I have also been told, "we think this system was infected with Zeus/Zbot...". What I've done is pulled together a process for examining a system for indications of malware. Most of these steps occur after I've mounted the image read-only as a volume on my analysis system.
Log file analysis -Examine the system to determine what, if any, AV products were installed/run on the system prior to acquisition, and see if log files can be found. Most (albeit not all) AV scanners will write their logs to the Application Event Log, but keep in mind that these roll over; look for the AV scanner's logs, as well.
Also, be sure to look at MS products, such as MRT and Defender.
AV Scans -Once I've determined which AV scanners may have been installed/run on a system, I will scan the mounted image using disparate AV scanners. A number are freely available (ClamWin, AVG, Avast!, etc.) and some have trial versions available.
Don't forget microscanners, such as McAfee Stinger. Spyware scanners will also be a good idea, but remember that these tend to scan the live Registry (which is on your analysis system).
And yes...I have seen where analysts have scanned the mounted image with the exact same scanner engine and DAT file versions as was installed on the system. If it didn't find it the first time...
Registry Analysis - RegRipper comes with a number of plugins that check for specific keys/values, and I've also written a number of plugins that can be easily used to check for published indicators of malware.
Digital Signatures - Scanning for digitally signed files is still a good idea, even in the face of StuxNet (used legitimate, albeit stolen, certs).
WFP Check - The folks at Mandiant have talked about sens.dll in a number of presentations; the idea is that files "protected" by WFP are often modified, but the one in the dllcache directory isn't; by hashing the files in the dllcache directory and comparing those to other files on the system, you might find one of these instances. It's a scan that you can run that will only take a few minutes; even if you don't find anything, that's still a finding and worth doing.
Packed files - Sometimes bad guys pack/compress their files; again, scans are easy.
PE file "compile time" check - This one is good to check for timestomped files; if the compile time is significantly after the creation date on the system, it might be worth checking. Also, look for compile times of 0.
Be aware that you may get false positives with this; MS updates will replace critical system files, but file system tunneling may have the file retain the original file system metadata. As such, you may have a critical system file with a compile time of 2010, but the file system metadata says it was created on the system in 2008.
ADSs - The legitimate use of NTFS alternate data streams on Windows systems is limited; PoisonIvy has an option to use ADSs. 'nuff said.
Other - There are a number of other artifacts that I look for in my process; for example, if the LocalService or Default User profile contains Internet browser history, this can indicate a process with System-level privileges (above Administrator) communicating using the WinInet APIs. Other indicators include PE files in the user profile Temp directory(ies), and Event Log records with ID = 7035, and a full user SID (as opposed to a service SID).
MBR infectors - Most of the published, publicly available write-ups on MBR infectors indicate that when the original MBR is infected, other sectors between 1 and 62 (the first volume/partition usually starts at sector 63) may contain copies of the original MBR, code, etc. I wrote a script that will parse these sectors out, looking for those that are not full of zeros, and pull them out. Again, like other steps, not definitive in isolation, but automating it makes it easy, and putting in my checklist means it gets done.
I have put together a checklist of these items, along with tools to use; this makes completing it, documenting it, and writing the report REALLY easy. Keep in mind that this is a process, and no one step is intended to find the malware; most often, it's a combination of steps, as each one is meant as data reduction, winnowing down your data set into something a bit more manageable.
