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.
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.