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.
Another benefit to host-based analysis is that it can provide more context about the malware and where it was found than an AV report could ever provide. Most AV reports use the shotgun approach for security improvement recommendations. Turn on firewall, update software, be careful opening attachments, use caution clicking links on webpages, use strong passwords, put your users in a bubble... The reason being AV companies don't know the environment where the samples came from so it seems like they are covering their bases. Host based analysis on the other hand will tell you exactly what security recommendations to make since it will reveal the technical breakdown that allowed the malware onto the system. I know my comment sounds more like an echo chamber to your point about intelligence-driven defense; it is an excellent point and should be repeated.
ReplyDeleteCorey,
ReplyDeleteExcellent points. What good is it to have your users change their passwords when the initial infection vector (IIV) was via the user context, used an exploit for privilege escalation (or didn't even have to), and moved on from there?
That's an excellent way to tie things back to intel-driven defense. While I agree that much of what the AV (and other) vendors state are overall best practices, sometimes we have to be careful about where we put our efforts.
Sometimes stuff just needs to be said again...
Thank you for the mention! I'm still amazed you read my blog.
ReplyDeleteI'm putting your course on my wish list. Hopefully it will be on the corporate budget sometime in the future. It sounds amazing!
Keep an eye on Twitter, this blog, LinkedIn, etc....I'll be sure to let you know when we're having another course.
ReplyDelete