Host-Based Analysis
I came across an article on malware 'licensing' the other day that caught my attention. When I read this, I thought to myself, "wow, what is this going to do to dynamic malware analysis?" Seriously...what are some of the common approaches to malware analysis? Get a sample, and either send it off to the AV vendor you're paying, upload it to VirusTotal, or, if you have the in-house capability, perform some form of dynamic analysis (i.e., actually run it to see what it does). No, I'm not saying that this all that's done...there are some extremely knowledgeable and capable reverse engineers out there who use their RE-fu. But the fact is that a lot of folks who "do" malware analysis don't exactly break out the debugger and set break points as their first order of business...although some do.
What I am saying is that, in my IR experience, a common approach to "malware analysis" is (a) get a copy and give it to the AV vendor, (b) deploy the .dat, and (c) wipe and reinstall the infected box(es). Or, someone will load a sample up into a VM and run it with some monitoring tools to see what it does.
Overall, it seems to me that this malware 'licensing' really drives the need for host-based analysis, particularly if you want to collect intel from which to build your defense, or to just address an issue. One benefit of host-based analysis is that you can determine artifacts of an infection or compromise that you might not see in AV vendor write-ups, specifically when the question isn't "what could the malware do", but instead, "what did the malware do?"
So why isn't this something that we normally do? Because...it takes too long? Well, with training and education, we can achieve that targeted, "sniper" approach that Chris talks about, allowing us to perform more efficient, timely, and comprehensive analysis, if we understand the nature of what we're looking for (goals), as well as the systems we're analyzing.
Shameless plug: It's exactly this knowledge and some of the analysis techniques that we'll be discussing in our training.
As a bit of a tangent, here are some links to some excellent blog posts that may be of assistance to analysts, in helping them to get from "I've heard of that" to "I've done that"...
SecurityBananas - From Hibernation file to Malware Analysis with Volatility
Willi Benethin's DFIROnline video, showing how to take advantage of INDX records
Girl, Unallocated - Report writing cheat sheet
Cheeky4n6Monkey - looking for a better way to manage massive amounts of image EXIF data? This would also work with documents, as well.
A final note on host-based analysis...one of the things I try very hard to avoid when performing malware detection is to start looking for malware based on file names alone. We are all aware that files can be named anything on Windows systems; remember the ntshrui.dll issue? Many times, if I go searching within an image for a file name, it's due to an entry in the Run key, or more recently, something interesting in the AppCompatCache data (yes, Virginia, I do use a RegRipper plugin for that, as well as many others). Corey went back and took a look at some older exams, and found some very interesting information; I've included it in every exam that I do in which I'm even remotely interested in determine indications of program execution.
What I am saying is that, in my IR experience, a common approach to "malware analysis" is (a) get a copy and give it to the AV vendor, (b) deploy the .dat, and (c) wipe and reinstall the infected box(es). Or, someone will load a sample up into a VM and run it with some monitoring tools to see what it does.
Overall, it seems to me that this malware 'licensing' really drives the need for host-based analysis, particularly if you want to collect intel from which to build your defense, or to just address an issue. One benefit of host-based analysis is that you can determine artifacts of an infection or compromise that you might not see in AV vendor write-ups, specifically when the question isn't "what could the malware do", but instead, "what did the malware do?"
So why isn't this something that we normally do? Because...it takes too long? Well, with training and education, we can achieve that targeted, "sniper" approach that Chris talks about, allowing us to perform more efficient, timely, and comprehensive analysis, if we understand the nature of what we're looking for (goals), as well as the systems we're analyzing.
Shameless plug: It's exactly this knowledge and some of the analysis techniques that we'll be discussing in our training.
As a bit of a tangent, here are some links to some excellent blog posts that may be of assistance to analysts, in helping them to get from "I've heard of that" to "I've done that"...
SecurityBananas - From Hibernation file to Malware Analysis with Volatility
Willi Benethin's DFIROnline video, showing how to take advantage of INDX records
Girl, Unallocated - Report writing cheat sheet
Cheeky4n6Monkey - looking for a better way to manage massive amounts of image EXIF data? This would also work with documents, as well.
A final note on host-based analysis...one of the things I try very hard to avoid when performing malware detection is to start looking for malware based on file names alone. We are all aware that files can be named anything on Windows systems; remember the ntshrui.dll issue? Many times, if I go searching within an image for a file name, it's due to an entry in the Run key, or more recently, something interesting in the AppCompatCache data (yes, Virginia, I do use a RegRipper plugin for that, as well as many others). Corey went back and took a look at some older exams, and found some very interesting information; I've included it in every exam that I do in which I'm even remotely interested in determine indications of program execution.