Monday, April 23, 2012

Updates and Links

Malware Detection
Jamie posted an MBR Parser recently.  You're probably thinking, "Yeah...and???"  Well, in her post regarding the code that she released, she does reference Chad's graphic regarding MBR malware, which illustrates the increase of MBR infectors over time.  Jamie's code not only disassembles the instructions, but parses the partition table, as well. Yes, I know that there are other tools out there that parse the partition table, but I think that what Jamie provided is a means for gathering more information about systems when conducting analysis. 

For example, let's assume that you're given a system and told, "We think this system was infected with malware", and nothing else.  What do you do at that point?  In most cases, I'm sure that an AV scan (or three) is run against the required image, but what else?  As an analyst, do you specifically look for MBR infectors?

I've posted several times regarding the need to check for MBR infectors when you're working a "we think this system may be infected with malware" engagement.  Mebroot can infect a system as a result of a browser drive-by; often times, I tend to think that we don't hear more about this sort of malware simply because analysis of infected systems isn't being done, or the MBR infectors aren't being effectively considered during analysis.

The code I wrote to help me detect MBR infectors parses the initial sectors of the acquired image; many time (albeit not always...), the first sector (sector 0) of a physical image contains the MBR, and sector 63 may be where the first partition is located.  What the script does is read through the intermediate sectors and identify those that do not contain all zeros; many (again...not all) MBR infectors will copy the original MBR to one or more sectors before laying down the infection.

Note: I did, at one point, release the MBR infector detection script publicly, but I took it down, as I don't think that some of the analysts who were running the code really understood what they were doing.  I was told by one person that they didn't understand why the code wasn't parsing MFT records, and another person ran the script against a Windows memory dump.  It just got too time consuming to provide support for analysts who weren't using the code properly; however, I still use it as part of my malware detection process.

Where Jamie's code can be extremely valuable is when collecting information in preparation for your analysis.  Let's say that you're collecting this information as part of your regular analysis, and you find that a system is, in fact, infected with an MBR infector.  Now you have a means for identifying artifacts (or "IoCs") associated with that infection.  This is another piece of information you can provide, another bit of intel that you can share, particularly when you're able to compare it not only to other systems you've examine before, but if the particular MBR infector is one of the variants that makes a copy of the original MBR, you can use that as a comparison.  This can, in turn, help you and others more quickly identify indications of similar infections in the future.

I really think that the code that Jamie provided is not only very useful in and of itself (and as previously described), but also serves to illustrate the power of open source.  Someone with some skill and interest sits down and provides a capability that previously didn't exist, or wasn't easily accessible to the majority of the community.    Jamie produced this code of her own accord; another great example of how new capabilities come about was illustrated when Corey had an idea, and this guy brought it to life.

Resources
MBR Reference
WikiPedia: MBR
"The Standard MBR"

Malware Analysis
Speaking of malware (or "mall-wear"), there is an excellent analysis of malware over on the System Forensics blog.  It's so nice sometimes to see analysis of malware that involves something more than just running strings on the file; in this case, a number of tools are used, including Dependency Walker, PeID, Resource Hacker, and CaptureBAT.  If this is your kind of thing, take a look...it's a great walk-through on how to get some good intelligence about a malware sample, as well as an excellent example of what you can discover about an executable file beyond running strings on it.

Breaches and Sharing Intel
BankInfoSecurity recently posted an interview with the Heartland CEO, where breach response was the topic of discussion.  Very early in the interview, Carr says that "information sharing is key", and he's right...some bad guys might be in other people's systems.  Even if it isn't the same group or individual, techniques and tools may be similar, and sharing of information and intel may lead to a much more effective response, because you're not starting over, or starting completely from square 1...you've got something of a leg up.

Not long ago, I blogged about the Need for Analysis in an Intel-Driven Defense.  That post referenced Dan Guido's paper on the same topic, and what I was pushing for in my post was the need to look at the analysis function within organizations, and how actually performing analysis would lead to more intel being available.

Something that Dan mentioned in his paper...specifically, the number of possible vulnerabilities versus those that are actually exploited...recently came up again, this time via the MMPC site; specifically, via a post about analysis of the Eleonore exploit pack shellcode.  Remember, Dan had said that there were over 8000 vulnerabilities tracked last year...and it appears that the exploit pack in questions uses a grand total of...seven.  Understanding and sharing this kind of information, as well as the indicators of a compromise, will provide responders and analysts with a means for a more effective response.  Now all that needs to happen is that we need more posts like Corey's great exploit artifact posts.

As Dan pointed out in his paper, looking at the hard numbers (how very Deming-esque of him to say that...), we see where we need to focus our efforts.  Within a large organization, would it be more advantageous to staff for the 8000+ possible vulnerabilities, or to beef up the analysis capability, so that (a) analysis actually gets done, and (b) it gets done in a timely (timely enough to be useful) and accurate manner?

In order to get the intel we need to defend our infrastructure, we need to conduct analysis.  If this isn't being done, we need to take a hard look at why it isn't being done?  Do we not have sufficient staff?  Is our staff not sufficiently trained or do they not have sufficient capability?  What can we do to improve that?  If we're not collecting intel, then what can we share with others, so that everyone can better protect themselves?

I'd suggest that the single biggest thing you can do is get senior management recognition and support for the need for intel.

6 comments:

Corey Harrell said...

Excellent points you made in the post. The same concept of narrowing the focus on which vulnerabilities to patch can be used to improve analysis except the focus could be on the applications containing the vulnerabilities. I've been using the Contaigo Exploit Pack Overview as a guide to picking exploits to research. Mila's spreadsheet outlines all of the vulnerabilities targeted by exploit packs and the listing of the applications targeted is pretty small. Analysis within an organization could be improved just by understanding how the attacks against those applications look on a system. I've looked at a number of exploits going after different vulnerabilities in an application (i.e. Java). The artifacts of the application being exploited are pretty much the same regardless of the vulnerability targeted. A basic understanding about some of the most common attacks and how they look on a system will not only improve an analysis knowing how the system got hit but can help rule out certain avenues of attacks.

Anonymous said...

Great information! It has been an educating experience reading your blog.

It would be great if you could teach a "Malware Detection" course for interested people. Maybe at some conference?

H. Carvey said...

I do have such a course...I taught it to the WA HTCIA group about 2 yrs ago. There simply hasn't been interest in it since then.

H. Carvey said...

@Corey, definitely. I completely agree...

Jim Steele said...

"I did, at one point, release the MBR infector detection script publicly, but I took it down, as I don't think that some of the analysts who were running the code really understood what they were doing"

As I read this and then thought about it, I believe we are seeing the true emergence of "forensic script kiddies". There has always been those who are dependent on the the tools - the "Nintendo Forensics" practitioners but now there are those who are firing the code and tools of others without any clue as to the end goal or why to leverage one tool vs. another.

Is it due to a heightened awareness or just more people being pressed into doing DFIR without the background or training?

H. Carvey said...

I think you may be right about that, but I also think that this may be something of the "nature of beast", as it were.

I think that we have a good number of folks being "pressed into service" without training, but we also have a number of "old timers" (or those who consider themselves as such) who are simply not willing to help in any way, and demand that everyone learn the same way that they did...but having to dig into the hex from the beginning. This is simply untenable...not everyone can do this.

There are a great many folks within the community who are simply unwilling to share or to even ask a question. Of those who have some kind of voice within the community, a good number of those are more than willing to say something, but unwilling to share. Not everyone has to be able to create something...a program, a script, whatever...but as a community, we're very intolerant of those who don't know as much as we do.