Looking for "Bad Stuff", pt III (Malware Detection)
So far, I've posted twice (see Resources below) on this subject, each time giving sort of a general overview of a process, but without getting down-and-dirty. One of the difficult things about putting together a process or a "best practice" is that very often, what's "best" for one person (or group) may not be "best" for another. So, with respect to malware detection (not analysis...at this point, we're still looking for the "bad stuff"), there several techniques you can use when going about this sort of process.
First, many times we may be looking for malware for different reasons. One reason would be that we suspect that a system may be infected with malware, while another may be that by looking for malware, we're attempting to nail down an intrusion or compromise (like following the trail of artifacts back to the original compromise vector), with the malware being a byproduct of the intrusion.
Another thing to keep in mind is that malware, in general, has four main characteristics:
1. An initial infection vector - how it got on the system in the first place; this can be through browser download (even on a secondary or tertiary level), email attachment, etc. Conficker, for example, can infect a system when the user opens Explorer on drive (USB thumb drive, mapped share, etc.) that has been infected. In some SQL injection compromises, I've seen malware placed on a system by the intruder sending tftp commands or creating and launching an FTP script, all via SQL injection. I've also seen the bad guy load the malware into a database table in 512 byte chunks, and then have the database reassemble the file in the file system so they could launch it.
2. Artifacts - what actions does the malware take upon infection and what footprints does it leave? Many time, we can determine these ourselves through dynamic malware analysis, but often its sufficient (and quicker) to use what's available from AV sites. Sometimes these "footprints" can be unique to a malware family (Conficker, for example). Also, these artifacts do not have to be restricted to a host; are there any network-based artifacts that you can use when analyzing logs?
3. Propogation Mechanism - How does the malware get about? Is it a worm that exploits a known (or unknown) vulnerability? Or is it like Conficker, infecting files at the root of drives and adding autorun.inf files? Understanding the propogation mechanism can help you fight the tide, as it were, or develop a mechanism to block or detect further infections.
4. Persistence Mechanism - As Jesse Kornblum points out in his "Rootkit Paradox" paper, malware likes to remain persistent, and the simple fact is that there are a finite number of ways to do that on a Windows system. The persistence mechanism can relate back to Artifacts; however, this would be an artifact specifically intended to allow the malware to survive reboots.
These characteristics act as a framework to help us visualize, understand, and categorize malware. Over the years, I have used these four characteristics to track down malware and help others do the same. In one instance in particular, after a customer had battled with a persistent (albeit fairly harmless) worm for over a month, I was told that they would delete certain files, reboot the system, and the files would be back. It occurred to me that they hadn't adequately tracked down the persistence mechanism, and once we found it, they were able to clean their systems!
Okay, so how can we go about tracking down malware, detecting its presence? I'm going to start with the idea that we have an acquired image, and we need to determine if there's malware on the system. I'm going to list several mechanisms for doing so, and these are not listed in order of priority. It will be incumbent upon you, the reader, to determine which steps work best for you, and in which order...that said, away we go!
Targeted Artifact Analysis
A lot of times, we may not know exactly what we're looking for, but if we know the persistence mechanism or other artifacts of malware, we can do a quick, surgical scan that malware. Tools such as RegRipper can make this a fast and extremely easy process (remember, for live systems, you can use RegRipper in combination with F-Response!). Take Conficker...while there are changes in artifacts based on the variant, the set of unique artifacts is pretty limited. As the variants have changed so as to obviate both AV scans and hash comparisons (at this point, everyone should be aware that hash comparisons for malware are marginally less effective than AV scanning with a single engine), artifacts have remained fairly static (Registry modifications) with some new ones (Scheduled Task) being added. The addition of unique artifacts helps narrow down the false positives.
Log Analysis
There are a number of logs on Windows systems that may provide some insight into malware detection. For example, maybe the installed AV product detected and quaratined a tertiary download...depending on the product, this may appear in the AV product logs as well as the Event Log. Or perhaps the AV scanner's real-time protection mechanism was disabled and the user ran a scan at a later time that detected the malware. Either way, check for an installed AV or anti-spyware product, and check the logs. Also, examine the Event Logs. And don't forget mrt.log!
Scans
Another way to go about detecting the presence of malware on systems is to scan for it using AV products. Yes, there are commercial AV products available, but as many have seen over the past couple of months, particularly with Conficker and Virut, sometimes using just one commercial AV product isn't enough. The key to running scans is to know what the scan is looking for so that you can better interpret the results.
For example, look at tools such as sigcheck and missidentify; both are extremely useful, but each tool looks for certain things. Another scanning tool that can be extremely useful is Yara, and anyone looking at using Yara should consider using the Yara-Scout Sniper release from the illustrious Don Weber! Yara can use packer rules (from the public PeID signatures) to detect packed files, and Don has added fuzzy hashing to Scout Sniper.
As a side note, while fuzzy hashing is obviously predicated on having a sample of the malware to hash, it is still a much preferable technique over "normal" hashing using MD5 or SHA-1 hashes. In one instance, I had two examinations about 8 months apart where I found files of the same name on both. Traditional (MD5) hashes didn't match, but using ssdeep, I was able to determine that the files were 99% similar.
So, other than scanning for not-normal files (with "normal" being somewhat amorphous), there are other ways to scan for possible malware infections. With the amount of malware that subverts Windows File Protection (WFP) in some manner, tools like wfpcheck can be used to determine if something on the system modified any of the "protected" files.
But again, keep in mind that scanning in general is a broad-brush approach and scans don't find everything. The idea is to have some idea of what you're looking for, and then selecting the proper tool (or tools) to build a comprehensive process. As part of that process, you'll need to document what you did, what you looked for, and what tools you used...because without that documentation, how to describe what you did in a repeatable manner, and how do you go about improving your process in the future?
Resources
Looking for "Bad Stuff", pt I and pt II
Claus's post on Portable AV tools
Free-av.com
Free AVG
PCTools
First, many times we may be looking for malware for different reasons. One reason would be that we suspect that a system may be infected with malware, while another may be that by looking for malware, we're attempting to nail down an intrusion or compromise (like following the trail of artifacts back to the original compromise vector), with the malware being a byproduct of the intrusion.
Another thing to keep in mind is that malware, in general, has four main characteristics:
1. An initial infection vector - how it got on the system in the first place; this can be through browser download (even on a secondary or tertiary level), email attachment, etc. Conficker, for example, can infect a system when the user opens Explorer on drive (USB thumb drive, mapped share, etc.) that has been infected. In some SQL injection compromises, I've seen malware placed on a system by the intruder sending tftp commands or creating and launching an FTP script, all via SQL injection. I've also seen the bad guy load the malware into a database table in 512 byte chunks, and then have the database reassemble the file in the file system so they could launch it.
2. Artifacts - what actions does the malware take upon infection and what footprints does it leave? Many time, we can determine these ourselves through dynamic malware analysis, but often its sufficient (and quicker) to use what's available from AV sites. Sometimes these "footprints" can be unique to a malware family (Conficker, for example). Also, these artifacts do not have to be restricted to a host; are there any network-based artifacts that you can use when analyzing logs?
3. Propogation Mechanism - How does the malware get about? Is it a worm that exploits a known (or unknown) vulnerability? Or is it like Conficker, infecting files at the root of drives and adding autorun.inf files? Understanding the propogation mechanism can help you fight the tide, as it were, or develop a mechanism to block or detect further infections.
4. Persistence Mechanism - As Jesse Kornblum points out in his "Rootkit Paradox" paper, malware likes to remain persistent, and the simple fact is that there are a finite number of ways to do that on a Windows system. The persistence mechanism can relate back to Artifacts; however, this would be an artifact specifically intended to allow the malware to survive reboots.
These characteristics act as a framework to help us visualize, understand, and categorize malware. Over the years, I have used these four characteristics to track down malware and help others do the same. In one instance in particular, after a customer had battled with a persistent (albeit fairly harmless) worm for over a month, I was told that they would delete certain files, reboot the system, and the files would be back. It occurred to me that they hadn't adequately tracked down the persistence mechanism, and once we found it, they were able to clean their systems!
Okay, so how can we go about tracking down malware, detecting its presence? I'm going to start with the idea that we have an acquired image, and we need to determine if there's malware on the system. I'm going to list several mechanisms for doing so, and these are not listed in order of priority. It will be incumbent upon you, the reader, to determine which steps work best for you, and in which order...that said, away we go!
Targeted Artifact Analysis
A lot of times, we may not know exactly what we're looking for, but if we know the persistence mechanism or other artifacts of malware, we can do a quick, surgical scan that malware. Tools such as RegRipper can make this a fast and extremely easy process (remember, for live systems, you can use RegRipper in combination with F-Response!). Take Conficker...while there are changes in artifacts based on the variant, the set of unique artifacts is pretty limited. As the variants have changed so as to obviate both AV scans and hash comparisons (at this point, everyone should be aware that hash comparisons for malware are marginally less effective than AV scanning with a single engine), artifacts have remained fairly static (Registry modifications) with some new ones (Scheduled Task) being added. The addition of unique artifacts helps narrow down the false positives.
Log Analysis
There are a number of logs on Windows systems that may provide some insight into malware detection. For example, maybe the installed AV product detected and quaratined a tertiary download...depending on the product, this may appear in the AV product logs as well as the Event Log. Or perhaps the AV scanner's real-time protection mechanism was disabled and the user ran a scan at a later time that detected the malware. Either way, check for an installed AV or anti-spyware product, and check the logs. Also, examine the Event Logs. And don't forget mrt.log!
Scans
Another way to go about detecting the presence of malware on systems is to scan for it using AV products. Yes, there are commercial AV products available, but as many have seen over the past couple of months, particularly with Conficker and Virut, sometimes using just one commercial AV product isn't enough. The key to running scans is to know what the scan is looking for so that you can better interpret the results.
For example, look at tools such as sigcheck and missidentify; both are extremely useful, but each tool looks for certain things. Another scanning tool that can be extremely useful is Yara, and anyone looking at using Yara should consider using the Yara-Scout Sniper release from the illustrious Don Weber! Yara can use packer rules (from the public PeID signatures) to detect packed files, and Don has added fuzzy hashing to Scout Sniper.
As a side note, while fuzzy hashing is obviously predicated on having a sample of the malware to hash, it is still a much preferable technique over "normal" hashing using MD5 or SHA-1 hashes. In one instance, I had two examinations about 8 months apart where I found files of the same name on both. Traditional (MD5) hashes didn't match, but using ssdeep, I was able to determine that the files were 99% similar.
So, other than scanning for not-normal files (with "normal" being somewhat amorphous), there are other ways to scan for possible malware infections. With the amount of malware that subverts Windows File Protection (WFP) in some manner, tools like wfpcheck can be used to determine if something on the system modified any of the "protected" files.
But again, keep in mind that scanning in general is a broad-brush approach and scans don't find everything. The idea is to have some idea of what you're looking for, and then selecting the proper tool (or tools) to build a comprehensive process. As part of that process, you'll need to document what you did, what you looked for, and what tools you used...because without that documentation, how to describe what you did in a repeatable manner, and how do you go about improving your process in the future?
Resources
Looking for "Bad Stuff", pt I and pt II
Claus's post on Portable AV tools
Free-av.com
Free AVG
PCTools