Ever wondered what was going on with a system while it was running? Have you ever been looking at an image in your analysis-tool-of-choice and thought that you'd get a lot more info if you could only boot this puppy?
Now, you can do that...well, at least for Windows systems. Check out LiveView, a Java-based tool from CMU that promises to let you boot your system image in VMWare. It looks very interesting, and I'm itching to give it a try.
If you do decide to try it out, remember this...send feedback in to the guys who produced the tool. Telling them it doesn't work isn't very useful; instead, give them as much information as you can, so that they can improve the tool and make it more useful to everyone.
Addendum: I downloaded an installed LiveView, and everything went pretty smooth. The Java Runtime Environment (JRE) 5.0 was installed, as was the VMWare DiskMount utility. I happen to have an image available that I downloaded, so I ran LiveView and pointed it toward the image, accepting most of the defaults in the UI. I opted to have the resulting VM automatically run, and interestingly enough, it started right up! This is somewhat different from Richard's experience, but I didn't have any binaries that had been modified. I'm using VMWare Workstation 5.5.2, so I let the VM go through it's "found new hardware" shenanigans, and then installed the VMWare Tools. I then rebooted the image and updated the display settings. The image I'm working with is an XP system that seem to have been set with no password. I'll need to see how effective the NTPasswd disk is on systems like this. Either way...it's very cool. I can see what the running system looked like, and I can snapshot the system prior to installing tools or performing any analysis on it. In the end, I still have the dd image, as well.
Oops! Okay, I wanted to see if I could, in fact, snapshot the VM I was running, and the choices were greyed out on the menu bar. So I figured I would suspend the VM, and then see what's going on in the resulting .vmem file. I chose Suspend...and VMWare bombed. I restarted the VM and tried it again, and was able to get it to work, although it didn't seem to go as smoothly as a "normal" VM session does. Anyway, I got the .vmem file I was looking for, and it's about the right size. Now I have something to work with and run my tools against.
Word of warning...I wasn't able to modify the settings on the VM session, such as increase RAM from 256 MB to 512 MB. This is something to think about if you're setting up a system this way.
Tuesday, August 29, 2006
Monday, August 28, 2006
Interesting Event IDs
Every now and then, when I analyze a Windows box, the Event Logs end up being pretty important to the issue at hand, and not just because there's login information there. One of the things I tend to look for is Dr Watson events, indicating that there was a crash dump generated.
So, what other interesting things are there in the Event Log?
Steve Bunting has a great article on event IDs that correspond to changes in system time. You could correlate this to information found in the UserAssist key, as well. So, keep your eyes open for the event IDs 520 and 577, particularly if Privilege use is being audited.
Also, I recently exchanged email with a LEO, discussing the various event IDs associated with USB devices being connected to Windows systems. Win2K, for example, has event ID 134 for "arrival" events and ID 135 for "removal" events. This changed for XP, with a possible explanation here. Specifically, at the bottom of the KB article, it says, "After you install the hotfix, Netshell no longer listens for Plug and Play device arrival notifications. Therefore, you are not notified about new devices." Ah...okay.
What're some good ways to go about quickly locating these interesting event IDs in a .evt file?
I like to use the Perl module that I wrote called File::ReadEvt (I've blogged out it before). This module makes it really easy to gather statistics on what's in a .evt file, and it does so without using the MS API...yep, it can be run on a Linux or Mac OS/X box. It parses through the binary file and extracts information based on what it finds there.
The archive that contains the module includes a couple of scripts that allow you to either gather statistics about the .evt file in question, or simply dump the contents into something readable. This is particulary useful if you're following the methodology of loading the .evt file into the Event Viewer on a live machine...sometimes you may encounter an error message saying that the .evt file is "corrupt". Run the script against it, any you'll be able to pull out the information.
One cool thing about scripts like this is that I've used them in the past to locate event records that the MS API did not recognize, and didn't see. This kind of thing is pretty neat, and may be useful in the course of an investigation.
The module doesn't, however, correlate the data from an event to the message strings located in the message library (DLL file on disk). But that's not really an issue, because you can get a subscription to EventID.net and find out more than you ever wanted to know about a particular event ID.
Okay, so, like, how do I tell, from an image, like, what was being audited while the system was running?
Well, to answer that, we need to go to the MS KB article that addresses this issue exactly. This KB article is specifically for NT 4.0, but there's a blog post here that shows things pretty much stayed the same up through XP. As it happens, I have an image from a Windows system that I downloaded and like to use to test things out. I extracted the Security file from the image, and ran my offline Registry parser against it. The odd thing was this...the KB article never tells you what the data type (binary, dword, string, etc.) the value is; regp.pl told me that the type is "REG_NONE". Okay, so I made a quick modification to the script and reran it, and got the data for the value we're looking for:
01 17 f5 77 03 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00 03 00 00 00 00 00 00 00 03 00 00 00 09 00 00 00
What does this tell us? Well, first off, auditing was enabled...that's the "01" at the beginning. The next three bytes (17 f5 77) mean...well, I don't know at this point. The last octet specifies how many different fields there are...you'll notice that between the first and last DWORD (ie, 4-byte values) there are 9 DWORDs. From there we can map the different audit sections, and the auditing set for that section corresponds to 1 = success auditing, 2 = failure auditing, and 3 = both.
The blog article linked above provides a great way to perform some live testing, and you can use auditpol.exe (if anyone has a credible link to this tool, please share it) to verify this, as well.
So, what other interesting things are there in the Event Log?
Steve Bunting has a great article on event IDs that correspond to changes in system time. You could correlate this to information found in the UserAssist key, as well. So, keep your eyes open for the event IDs 520 and 577, particularly if Privilege use is being audited.
Also, I recently exchanged email with a LEO, discussing the various event IDs associated with USB devices being connected to Windows systems. Win2K, for example, has event ID 134 for "arrival" events and ID 135 for "removal" events. This changed for XP, with a possible explanation here. Specifically, at the bottom of the KB article, it says, "After you install the hotfix, Netshell no longer listens for Plug and Play device arrival notifications. Therefore, you are not notified about new devices." Ah...okay.
What're some good ways to go about quickly locating these interesting event IDs in a .evt file?
I like to use the Perl module that I wrote called File::ReadEvt (I've blogged out it before). This module makes it really easy to gather statistics on what's in a .evt file, and it does so without using the MS API...yep, it can be run on a Linux or Mac OS/X box. It parses through the binary file and extracts information based on what it finds there.
The archive that contains the module includes a couple of scripts that allow you to either gather statistics about the .evt file in question, or simply dump the contents into something readable. This is particulary useful if you're following the methodology of loading the .evt file into the Event Viewer on a live machine...sometimes you may encounter an error message saying that the .evt file is "corrupt". Run the script against it, any you'll be able to pull out the information.
One cool thing about scripts like this is that I've used them in the past to locate event records that the MS API did not recognize, and didn't see. This kind of thing is pretty neat, and may be useful in the course of an investigation.
The module doesn't, however, correlate the data from an event to the message strings located in the message library (DLL file on disk). But that's not really an issue, because you can get a subscription to EventID.net and find out more than you ever wanted to know about a particular event ID.
Okay, so, like, how do I tell, from an image, like, what was being audited while the system was running?
Well, to answer that, we need to go to the MS KB article that addresses this issue exactly. This KB article is specifically for NT 4.0, but there's a blog post here that shows things pretty much stayed the same up through XP. As it happens, I have an image from a Windows system that I downloaded and like to use to test things out. I extracted the Security file from the image, and ran my offline Registry parser against it. The odd thing was this...the KB article never tells you what the data type (binary, dword, string, etc.) the value is; regp.pl told me that the type is "REG_NONE". Okay, so I made a quick modification to the script and reran it, and got the data for the value we're looking for:
01 17 f5 77 03 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00 03 00 00 00 00 00 00 00 03 00 00 00 09 00 00 00
What does this tell us? Well, first off, auditing was enabled...that's the "01" at the beginning. The next three bytes (17 f5 77) mean...well, I don't know at this point. The last octet specifies how many different fields there are...you'll notice that between the first and last DWORD (ie, 4-byte values) there are 9 DWORDs. From there we can map the different audit sections, and the auditing set for that section corresponds to 1 = success auditing, 2 = failure auditing, and 3 = both.
The blog article linked above provides a great way to perform some live testing, and you can use auditpol.exe (if anyone has a credible link to this tool, please share it) to verify this, as well.
Thursday, August 24, 2006
The State of IR
I blogged recently about an InformationWeek article in which Kevin Mandia was quoted; part of that article and one of his quotes is:
One of the worst things users can do if they think their systems have been compromised by a hacker is to shut off their PCs, because doing so prevents an investigator from analyzing the contents of the machine's RAM...
Like others in the IR arena, I'm sure Kevin and his guys are seeing this more and more...the IR activities performed by the on-site IT staff is often very knee-jerk, and little thought is given ahead of time to the questions that need to be answered when you've been compromised or p0wned. Whether the IT folks are doing wide-spread scanning (and filling log files), local scanning at the console (with destructive A/V scans), or simply killing processes and deleting files, these activities are making it difficult for follow-on IR/CF work to be effective.
Not being one to simply say, "hey, you're wrong!", and not offer some alternative or solution, here's my take on what needs to be done...
First, and most importantly, senior management needs to take security (in general, and IR/CF specifically) more seriously...and not just on paper. Back in the day when I was doing mostly vulnerability assessments and pen tests, some organizations actually had IR policies in place and wanted to test them. So they'd contact my employer and have a pen test scheduled...without telling the IT staff. That way, you could see how they'd react.
Right now, senior management (CEO, Board of Directors, shareholders, etc.) are primarily focused on uptime and accessibility...after all, without those, where does revenue come from? Now, let's assume that when planning for these, they brought security folks in at the ground floor so that not only was everything accessible and available, but more secure, as well? Okay, that's not reality...but guess what? Security doesn't have to break stuff. No, really. Honest. Measures can be put in place to prevent and detect issues (to include security incidents) without breaking your current system setup.
Also, senior management should invest in their IT staff, through training, job progression, etc. I've seen some really bright, conscientious folks leave the IT arena because they were tired of being the back-office behind-the-scenes folks who got none of the credit and all of the blame. Along those lines, if you send some of your folks off to training, get them certified, and don't provide any avenue for advancement, they'll find someone who will. That's kind of a wasted investment, isn't it? I saw this in the early '90s at a trucking company that first trained some of the IT staff in SmallTalk, and as soon as the project they were on was completed, they all migrated to the local bank, advancing their positions and salaries. When I was involved in the Java training in the mid-90s, the same exact thing happened.
Second, to paraphrase Agent Mulder, "the tools are out there." The licenses for many of the available freeware tools state that you can run the tools as much as you want, as long as you own or administer the systems (be sure to check, either way). So, grab a CD, put the tools and a simple batch file on it, and include one argument...the directory to send the output of the tools to. This can be a thumb drive, USB-connected external HDD, or mapped drive. When something happens, fire up the batch file, and capture that valuable volatile data.
Don't know what tools to use, or where to get them? Check out my first book, or look for my next one coming this spring. Or watch this blog.
Don't know what the data you've collected is telling you? Check out my first book, or look for my next one coming this spring. Or watch this blog.
The bad guys are getting more and more sophisticated, so the level of training and knowledge of the good guys needs to narrow the gap.
One of the worst things users can do if they think their systems have been compromised by a hacker is to shut off their PCs, because doing so prevents an investigator from analyzing the contents of the machine's RAM...
Like others in the IR arena, I'm sure Kevin and his guys are seeing this more and more...the IR activities performed by the on-site IT staff is often very knee-jerk, and little thought is given ahead of time to the questions that need to be answered when you've been compromised or p0wned. Whether the IT folks are doing wide-spread scanning (and filling log files), local scanning at the console (with destructive A/V scans), or simply killing processes and deleting files, these activities are making it difficult for follow-on IR/CF work to be effective.
Not being one to simply say, "hey, you're wrong!", and not offer some alternative or solution, here's my take on what needs to be done...
First, and most importantly, senior management needs to take security (in general, and IR/CF specifically) more seriously...and not just on paper. Back in the day when I was doing mostly vulnerability assessments and pen tests, some organizations actually had IR policies in place and wanted to test them. So they'd contact my employer and have a pen test scheduled...without telling the IT staff. That way, you could see how they'd react.
Right now, senior management (CEO, Board of Directors, shareholders, etc.) are primarily focused on uptime and accessibility...after all, without those, where does revenue come from? Now, let's assume that when planning for these, they brought security folks in at the ground floor so that not only was everything accessible and available, but more secure, as well? Okay, that's not reality...but guess what? Security doesn't have to break stuff. No, really. Honest. Measures can be put in place to prevent and detect issues (to include security incidents) without breaking your current system setup.
Also, senior management should invest in their IT staff, through training, job progression, etc. I've seen some really bright, conscientious folks leave the IT arena because they were tired of being the back-office behind-the-scenes folks who got none of the credit and all of the blame. Along those lines, if you send some of your folks off to training, get them certified, and don't provide any avenue for advancement, they'll find someone who will. That's kind of a wasted investment, isn't it? I saw this in the early '90s at a trucking company that first trained some of the IT staff in SmallTalk, and as soon as the project they were on was completed, they all migrated to the local bank, advancing their positions and salaries. When I was involved in the Java training in the mid-90s, the same exact thing happened.
Second, to paraphrase Agent Mulder, "the tools are out there." The licenses for many of the available freeware tools state that you can run the tools as much as you want, as long as you own or administer the systems (be sure to check, either way). So, grab a CD, put the tools and a simple batch file on it, and include one argument...the directory to send the output of the tools to. This can be a thumb drive, USB-connected external HDD, or mapped drive. When something happens, fire up the batch file, and capture that valuable volatile data.
Don't know what tools to use, or where to get them? Check out my first book, or look for my next one coming this spring. Or watch this blog.
Don't know what the data you've collected is telling you? Check out my first book, or look for my next one coming this spring. Or watch this blog.
The bad guys are getting more and more sophisticated, so the level of training and knowledge of the good guys needs to narrow the gap.
Thursday, August 17, 2006
Report Writing
I was responding to an email this morning, discussing what I'm including in my next book (or could include) with someone, and he brought up a subject that I hadn't thought of...there are no resources out there for writing reports. And we all know how much technical nerds and security geeks love to write reports.[/sarcasm mode=off]
My first thought on this was, well, everyone has different requirements. I mean, an internal security guy in an FTE position has different requirements for his reports than a consultant does (I've done both), and those are different from LE requirements.
As I started to think more about that, it occurred to me that there are some commonalities in how reports can/should be written, and that perhaps by addressing and discussing them, maybe we can clear up some of the mystery behind the topic.
Before we start, let me give you a bit of context. I started "learning" to write in the military, and the most consistent thing I wrote there were personnel reviews. I had to do a thesis in graduate school, and in addition to reports I've written as a consultant and in FTE positions, I've written numerous articles and a book. However, this does NOT make me an expert, so I don't claim to be. Based on my experience, I have developed a style of writing, and when I'm writing a report for a client, I'm still going to feel better if I have someone review it.
That being said, there are a couple of general guidelines I follow when writing my reports.
Follow the KISS principle
Does this mean you should put on a wild, skin-tight suit, paint your face with black and white makeup, and present your report to the client in heavy metal? No. KISS = Keep It Simple, Stupid. This is a well-known, and yet oft-overlooked principle. Julius Caesar followed this principle...what's simpler than "Veni. Vidi. Vici."? I mean...really. How much more simple can you get?
An slight modification of this principle was passed down to me by a commanding officer. He held regular meetings, and as the CommO, I represented a technical discipline. He told me that when it was my turn to talk about issues in my department, if I couldn't summarize the issue on a 3x5 card in 3 (but no more than 5) bullet statements, then I didn't know the issue well enough. And you know something...15 yrs later, that's still true.
Keep the audience in mind
Remember who you're going to be talking to. I've found this to be an extremely valuable thing to remember, whether I was doing pen tests, vulnerability assessments, or now, when I perform forensic analysis. IT guys are usually pretty technical but the thing about consultants is that many times, we're less general than IT guys. Forensic analysts can be even more technically focused, so spilling our grey matter out onto paper isn't going to do much more than confuse some IT guys...what do you think it will do to the IT managers?
I'm not saying IT guys are dumb...that's not the case at all. However, the reason guys like us (consultants, LEs, etc.) get called on-site is usually because the client doesn't have the skill set, nor do they have the time, to perform the work they're asking/paying us to do. So performing the work is only half the battle...the real challenge is to communicate the results (of an assessment or analysis) to the client in a way they can understand and use.
If you're sitting at home playing BuzzWord Bingo right now, put a marker over "value add".
That's our job as professionals. We provide "value add". Sure, we can image systems and dump spreadsheets and analysis in the client's lap, but why not simply tell them what we found?
Don't overwhelm the reader with technical information
This is a follow-on to the previous item. In knowing your audience and who's going to be reading the report, you don't want to overwhelm them with technical detail. For example, you can say "between these dates, these systems were subject to [un]successful XX attacks." You might even add "...a total of n times." That's much better than dumping a spreadsheet in the client's lap, with all of the data.
A good method of implementing this is to include an executive summary, something that someone at the management or senior management level can quickly read, and get an understanding of what went happened. The executive summary is best kept short, no longer than a page (unless absolutely necessary), and to the point. Follow that up with some technical detail, describing what happened, and the order in which it happened. Remember, when performing analysis, timeframes add context to what we do and see. The same thing is true for the client. Now, you don't need to give away your whole bag of tricks in this section, but you can and should provide some level of detail, so that your report has credibility. Finally, if you must provide the real down-in-the-weeds technical stuff, put it in a tabbed appendix, ordered by relevance.
If you don't know, and can't prove it, say it
This goes right along with Avoid speculation and too much interpretation, so I'm just going to combine the two. A lot of the reports I've read over the years having included too much of what can be referred to as "artistic license". A lot of really, really smart guys (every time I see this sort of thing, it's come from a guy, not a woman) like to show how smart they are, and many times will do so in their report. I'll give you an example. I've seen reports that will say things like, "the attacker was Russian." Well, how do you know that? Sure, you see in the logs that the attack came from an IP address assigned to the Russian Federation, and you may have found a binary file with Cyrillic characters in the name or strings in the file...but is that definitive? Do these two facts combine to make the original statement true? No, they don't.
One thing we're seeing a lot of in the media is the loss of sensitive data. In his BlackHat presentation, Kevin Mandia mentioned that clients are asking the question, "was sensitive data copied from the system?" Well, if you're looking at an image of a hard drive, what is your answer? In most cases, it's "we don't know, because there isn't enough information." Yes, you may see the sensitive data on the drive, and the last access times on the file(s) may correspond to when the intruder was on the system...but is that definitive proof that the data was actually taken?
Just this summer, the Veteran's Administration announced that they'd recovered a laptop that had been stolen...a laptop that contained a great deal of sensitive information. Media reports stated that the FBI had analyzed the laptop and determined that the data had not been compromised, yet the backlash in the public forums regarding this statement was incredible...and to some degree, correct. There are several ways, of varying technical sophistication, that could be used to copy the data from the hard drive without leaving obvious forensic artifacts.
So the point is, if you can't connect the dots, don't. There's an old saying that goes something like this..."it's better to keep your mouth shut and be thought a fool, than to open your mouth and remove all doubt." You may be able to fully justify your thought processes to yourself, and you may become indignant when a co-worker, team member, or even your boss calls you on them, but what do you think will happen when the defense attorney does it?
Well, I hope these meager thoughts have been helpful. What hints, tidbits, or pointers do you use when writing reports?
My first thought on this was, well, everyone has different requirements. I mean, an internal security guy in an FTE position has different requirements for his reports than a consultant does (I've done both), and those are different from LE requirements.
As I started to think more about that, it occurred to me that there are some commonalities in how reports can/should be written, and that perhaps by addressing and discussing them, maybe we can clear up some of the mystery behind the topic.
Before we start, let me give you a bit of context. I started "learning" to write in the military, and the most consistent thing I wrote there were personnel reviews. I had to do a thesis in graduate school, and in addition to reports I've written as a consultant and in FTE positions, I've written numerous articles and a book. However, this does NOT make me an expert, so I don't claim to be. Based on my experience, I have developed a style of writing, and when I'm writing a report for a client, I'm still going to feel better if I have someone review it.
That being said, there are a couple of general guidelines I follow when writing my reports.
Follow the KISS principle
Does this mean you should put on a wild, skin-tight suit, paint your face with black and white makeup, and present your report to the client in heavy metal? No. KISS = Keep It Simple, Stupid. This is a well-known, and yet oft-overlooked principle. Julius Caesar followed this principle...what's simpler than "Veni. Vidi. Vici."? I mean...really. How much more simple can you get?
An slight modification of this principle was passed down to me by a commanding officer. He held regular meetings, and as the CommO, I represented a technical discipline. He told me that when it was my turn to talk about issues in my department, if I couldn't summarize the issue on a 3x5 card in 3 (but no more than 5) bullet statements, then I didn't know the issue well enough. And you know something...15 yrs later, that's still true.
Keep the audience in mind
Remember who you're going to be talking to. I've found this to be an extremely valuable thing to remember, whether I was doing pen tests, vulnerability assessments, or now, when I perform forensic analysis. IT guys are usually pretty technical but the thing about consultants is that many times, we're less general than IT guys. Forensic analysts can be even more technically focused, so spilling our grey matter out onto paper isn't going to do much more than confuse some IT guys...what do you think it will do to the IT managers?
I'm not saying IT guys are dumb...that's not the case at all. However, the reason guys like us (consultants, LEs, etc.) get called on-site is usually because the client doesn't have the skill set, nor do they have the time, to perform the work they're asking/paying us to do. So performing the work is only half the battle...the real challenge is to communicate the results (of an assessment or analysis) to the client in a way they can understand and use.
If you're sitting at home playing BuzzWord Bingo right now, put a marker over "value add".
That's our job as professionals. We provide "value add". Sure, we can image systems and dump spreadsheets and analysis in the client's lap, but why not simply tell them what we found?
Don't overwhelm the reader with technical information
This is a follow-on to the previous item. In knowing your audience and who's going to be reading the report, you don't want to overwhelm them with technical detail. For example, you can say "between these dates, these systems were subject to [un]successful XX attacks." You might even add "...a total of n times." That's much better than dumping a spreadsheet in the client's lap, with all of the data.
A good method of implementing this is to include an executive summary, something that someone at the management or senior management level can quickly read, and get an understanding of what went happened. The executive summary is best kept short, no longer than a page (unless absolutely necessary), and to the point. Follow that up with some technical detail, describing what happened, and the order in which it happened. Remember, when performing analysis, timeframes add context to what we do and see. The same thing is true for the client. Now, you don't need to give away your whole bag of tricks in this section, but you can and should provide some level of detail, so that your report has credibility. Finally, if you must provide the real down-in-the-weeds technical stuff, put it in a tabbed appendix, ordered by relevance.
If you don't know, and can't prove it, say it
This goes right along with Avoid speculation and too much interpretation, so I'm just going to combine the two. A lot of the reports I've read over the years having included too much of what can be referred to as "artistic license". A lot of really, really smart guys (every time I see this sort of thing, it's come from a guy, not a woman) like to show how smart they are, and many times will do so in their report. I'll give you an example. I've seen reports that will say things like, "the attacker was Russian." Well, how do you know that? Sure, you see in the logs that the attack came from an IP address assigned to the Russian Federation, and you may have found a binary file with Cyrillic characters in the name or strings in the file...but is that definitive? Do these two facts combine to make the original statement true? No, they don't.
One thing we're seeing a lot of in the media is the loss of sensitive data. In his BlackHat presentation, Kevin Mandia mentioned that clients are asking the question, "was sensitive data copied from the system?" Well, if you're looking at an image of a hard drive, what is your answer? In most cases, it's "we don't know, because there isn't enough information." Yes, you may see the sensitive data on the drive, and the last access times on the file(s) may correspond to when the intruder was on the system...but is that definitive proof that the data was actually taken?
Just this summer, the Veteran's Administration announced that they'd recovered a laptop that had been stolen...a laptop that contained a great deal of sensitive information. Media reports stated that the FBI had analyzed the laptop and determined that the data had not been compromised, yet the backlash in the public forums regarding this statement was incredible...and to some degree, correct. There are several ways, of varying technical sophistication, that could be used to copy the data from the hard drive without leaving obvious forensic artifacts.
So the point is, if you can't connect the dots, don't. There's an old saying that goes something like this..."it's better to keep your mouth shut and be thought a fool, than to open your mouth and remove all doubt." You may be able to fully justify your thought processes to yourself, and you may become indignant when a co-worker, team member, or even your boss calls you on them, but what do you think will happen when the defense attorney does it?
Well, I hope these meager thoughts have been helpful. What hints, tidbits, or pointers do you use when writing reports?
Wednesday, August 16, 2006
Artifacts
I attended an excellent presentation on IM Forensics at the recent GMU2006 conference, and that got me to thinking...are there resources out there that list forensic artifacts for various IM applications? I know that folks on the LE side dig into this quite often, but when I see/hear it discussed, it usually starts out with "...I read somewhere...". Hhhhmmm. I've thought that with the recent releases of AIM Triton and a new version of Yahoo, I'd take a look at these and document forensic artifacts. Of course, there are other IM applications out there (GAim, Trillian, etc.), so I'd like to start by compiling a list of sites that provide credible information on older versions.
I'd also like to see if there are any resources (sites, blogs, papers, etc.) regarding forensic artifacts for P2P applications, as well. I've looked at LimeWire in the past, but now and again I see questions regarding Bearshare, etc.
Finally, while we're on the topic of artifacts, I'm also interested in talking to (or hearing from) anyone who's willing to share information on artifacts regarding exploits and compromises. One of the questions I get very often is, "what do I look for if I suspect someone has used this exploit?" Sometimes we can determine this sort of thing through testing, and other times we can look at anti-virus web sites to get artifacts for worms and backdoors. Still other times, we stumble across these things by accident.
I'll give you an example of what I'm talking about. Take cross-site scripting and SQL injection attacks against IIS web servers. Sometimes during analysis (it really depends on the situation) I'll run a keyword search for xp_cmdshell across the web server logs. If I get hits, I then use Perl scripts to extract the information from the logs into an easy to manage format.
This is the sort of things I'm interested in...mostly because I know others are interested, as well, because I hear the questions. Besides looking at Registry and file system artifacts, this might be an interesting avenue to pursue in Windows memory analysis, as well.
I'd also like to see if there are any resources (sites, blogs, papers, etc.) regarding forensic artifacts for P2P applications, as well. I've looked at LimeWire in the past, but now and again I see questions regarding Bearshare, etc.
Finally, while we're on the topic of artifacts, I'm also interested in talking to (or hearing from) anyone who's willing to share information on artifacts regarding exploits and compromises. One of the questions I get very often is, "what do I look for if I suspect someone has used this exploit?" Sometimes we can determine this sort of thing through testing, and other times we can look at anti-virus web sites to get artifacts for worms and backdoors. Still other times, we stumble across these things by accident.
I'll give you an example of what I'm talking about. Take cross-site scripting and SQL injection attacks against IIS web servers. Sometimes during analysis (it really depends on the situation) I'll run a keyword search for xp_cmdshell across the web server logs. If I get hits, I then use Perl scripts to extract the information from the logs into an easy to manage format.
This is the sort of things I'm interested in...mostly because I know others are interested, as well, because I hear the questions. Besides looking at Registry and file system artifacts, this might be an interesting avenue to pursue in Windows memory analysis, as well.
Blogs and Podcasts
I'm familiar with the Cyberspeak podcasts, and various security-related blogs such as TaoSecurity, etc.
What are some other podcasts out there that are related to forensics? I'm familiar with some of the more general-IT-oriented podcasts, but was wondering if there are others out there that cover topics in forensics.
The same is true with blogs...I'll do searches for blogs related to security and find quite a lot, but I'm interested in those focused on forensics.
Finally, don't forget webinars and even groups, such as the Windows Forensic Analysis group.
Thanks!
What are some other podcasts out there that are related to forensics? I'm familiar with some of the more general-IT-oriented podcasts, but was wondering if there are others out there that cover topics in forensics.
The same is true with blogs...I'll do searches for blogs related to security and find quite a lot, but I'm interested in those focused on forensics.
Finally, don't forget webinars and even groups, such as the Windows Forensic Analysis group.
Thanks!
Where to start?
Ever have one of those days when you load up an image, check your notes...and simply have no clue where to begin? I'm not talking about your general brain cramp...no, you simply have no idea where to start. Kind of like when someone hands you a drive and tells you to find "all the bad stuff". Oy.
Many times, simply looking into the file system may get you started...what applications are installed (based on the directory structure), what users are there and seem to be active, etc. However, this sort of meandering may only get you so far, and it you're on an hourly clock, it's also going to get you in hot water with the boss (be it your boss-boss, or your customer/boss).
So, what do you do? The approach I generally take is to try and narrow down the time window for the incident, either by interviewing the client, or reviewing their incident report. Look for things that within the report (or via the interview) that narrow down the time frame...when did you first notice something? Some folks have monitoring software on their network and/or systems that logs or emails them alerts...these generally have a time stamp of some kind. This is a good place to start, but one HUGE caveat is this...do not think that this sort of thing is the cornerstone of your analysis. I have seen time and time again where something will happen that makes the client think they've been compromised, and once you start your analysis, you see clearly that the system had really been compromised much earlier, perhaps even multiple times.
I know a lot of folks who check the "usual suspects" when it comes to Registry keys, primarily looking for recently viewed documents and checking autostart locations. Also, running searches of the Registry and file system, using keywords derived from process names and application pop-ups is a good idea.
One thing that I've found to be a really good step to add to my methodology is to go into the Registry and sort the Services subkey in the appropriate ControlSet, based on the LastWrite times of the keys. Most of the keys will show times from when the OS was installed, but I've used this several times to successfully locate backdoors and even rootkits.
Another thing I like to do is use the File::ReadEvt Perl module to generate statistics about the Event Logs. The module ships with two scripts, one to get simple statistics, and another to simply output the event records to STDOUT. Over time, I will be posting additional scripts (based on what I've developed for various analysis tasks), and I will also be including them in my next book. Another thing that's very helpful with parsing and analyzing the contents of the Event Logs is a subscription to EventID.net. Besides things like logins, etc., another event you may want to look for is Dr. Watson...many times, this may be an indication of an exploit being run.
Gotchas - when working with times, a big GOTCHA is accounting for time zones. One thing that can throw you is how your analysis tool displays the times...ProDiscover gets the UTC/GMT times from Windows FILETIME objects, and displays them using the time zone settings of the analysis workstation. Many of the tools (Perl scripts, as well as ProScripts) I've written display times in UTC/GMT format. One of the things on my personal TO-DO list is to update tools that display times so that the ActiveTimeBias can be retrieved from the Registry and passed as an argument (in the case of ProScripts, retrieve this value automatically). Also, many text based logs (IIS, A/V tools, etc.) write times to ASCII text files using the current settings on the system, including the time zone settings. If I have an image of hard drive from, say, the Pacific Standard Time (PST) time zone, and I'm in EST, and some of my tools are displaying the times in UTC/GMT...while the times themselves are "accurate", they still need to be translated.
So what do you do when you're stuck? What are some tips you have for getting out of a rut when analyzing an image of a Windows system?
Many times, simply looking into the file system may get you started...what applications are installed (based on the directory structure), what users are there and seem to be active, etc. However, this sort of meandering may only get you so far, and it you're on an hourly clock, it's also going to get you in hot water with the boss (be it your boss-boss, or your customer/boss).
So, what do you do? The approach I generally take is to try and narrow down the time window for the incident, either by interviewing the client, or reviewing their incident report. Look for things that within the report (or via the interview) that narrow down the time frame...when did you first notice something? Some folks have monitoring software on their network and/or systems that logs or emails them alerts...these generally have a time stamp of some kind. This is a good place to start, but one HUGE caveat is this...do not think that this sort of thing is the cornerstone of your analysis. I have seen time and time again where something will happen that makes the client think they've been compromised, and once you start your analysis, you see clearly that the system had really been compromised much earlier, perhaps even multiple times.
I know a lot of folks who check the "usual suspects" when it comes to Registry keys, primarily looking for recently viewed documents and checking autostart locations. Also, running searches of the Registry and file system, using keywords derived from process names and application pop-ups is a good idea.
One thing that I've found to be a really good step to add to my methodology is to go into the Registry and sort the Services subkey in the appropriate ControlSet, based on the LastWrite times of the keys. Most of the keys will show times from when the OS was installed, but I've used this several times to successfully locate backdoors and even rootkits.
Another thing I like to do is use the File::ReadEvt Perl module to generate statistics about the Event Logs. The module ships with two scripts, one to get simple statistics, and another to simply output the event records to STDOUT. Over time, I will be posting additional scripts (based on what I've developed for various analysis tasks), and I will also be including them in my next book. Another thing that's very helpful with parsing and analyzing the contents of the Event Logs is a subscription to EventID.net. Besides things like logins, etc., another event you may want to look for is Dr. Watson...many times, this may be an indication of an exploit being run.
Gotchas - when working with times, a big GOTCHA is accounting for time zones. One thing that can throw you is how your analysis tool displays the times...ProDiscover gets the UTC/GMT times from Windows FILETIME objects, and displays them using the time zone settings of the analysis workstation. Many of the tools (Perl scripts, as well as ProScripts) I've written display times in UTC/GMT format. One of the things on my personal TO-DO list is to update tools that display times so that the ActiveTimeBias can be retrieved from the Registry and passed as an argument (in the case of ProScripts, retrieve this value automatically). Also, many text based logs (IIS, A/V tools, etc.) write times to ASCII text files using the current settings on the system, including the time zone settings. If I have an image of hard drive from, say, the Pacific Standard Time (PST) time zone, and I'm in EST, and some of my tools are displaying the times in UTC/GMT...while the times themselves are "accurate", they still need to be translated.
So what do you do when you're stuck? What are some tips you have for getting out of a rut when analyzing an image of a Windows system?
Friday, August 11, 2006
Week in Review, plus some
I spent this past week at GMU2006...well, not all week, just parts of the days...mostly the mornings. I was originally scheduled for five presentations...an opening session, and two rounds each of Tracking USB Devices and Windows Memory Analysis. I later found out that I had also been scheduled for Windows Live Response, give twice on Friday morning.
Overall, I think the GMU2006 conference was good...like most conferences, you get out of it what you put in. It was a great opportunity for me to see some old faces, meet some new folks, and put faces to names. To my surprise, I got to meet AAron Walters, who came to down twice. AAron's a bright guy with a lot of really good ideas.
The downside of a conference like this is that while I'm presenting, a lot of good presentations are going on at the same time. I got to sit in on IM Forensics by Charles Giglia, but missed his MySpace Forensics presentation. I missed other presentations by folks like Jesse Kornblum, Cynthia Hetherington, and Terri Gudaitis. However, in my presentations, I got some good comments and questions, and had a couple of really good side conversations with some folks.
If you're the GWU student who talked to me on Friday morning...drop me a line. I'm always happy to help.
Anyway, I made a couple of comments during my opening session talk, and during my presentations that cybercrime is increasing in sophistication, and that there's a widening gap between what "we" (forensic analysts, first responders and sysadmins) do or are capable of doing, and what the bad guys do. I can't say that there was a strong reaction either way, but this morning I read this article, where Kevin Mandia was quoted. In the article, Kevin talks about the increased/ing sophistication of cybercrime, and the widening gap between the good guys and bad guys.
As I mentioned, I presented on Windows Memory Analysis, and interestingly this appeared in the article:
One of the worst things users can do if they think their systems have been compromised by a hacker is to shut off their PCs, because doing so prevents an investigator from analyzing the contents of the machine's RAM, which often contains useful forensic evidence, Mandia said.
The paragraph that followed this one also provided some interesting insight. This shows that this sort of thing is being done (ie, RAM is being collected and analyzed), it's being done by some smart folks, and valuable information is being used to solve cases. More importantly, the traditional approach most folks use doesn't include collecting this information.
If you have any questions about the conference, my presentations, or about anything...drop me a line.
Addendum, 17 Aug: During my presentations at GMU2006, I talked about live response...in some of the presentations, the discussion was tangential, but in the actual Windows Live Response presentation...and the need for live response. One of the reasons for conducting live response is that downtimes of systems aren't measured in minutes, but in dollars per minute. For the most part, it sort of looks like I'm making this up...I really don't have anything to reference, other than professional experience. Well, I found a link to an article at DarkReading this morning that talks about the cost of a hack. One of the bullet statements in the article references a Yankee Group survey that indicates that some companies measure downtime in thousands of dollars per hour.
Overall, I think the GMU2006 conference was good...like most conferences, you get out of it what you put in. It was a great opportunity for me to see some old faces, meet some new folks, and put faces to names. To my surprise, I got to meet AAron Walters, who came to down twice. AAron's a bright guy with a lot of really good ideas.
The downside of a conference like this is that while I'm presenting, a lot of good presentations are going on at the same time. I got to sit in on IM Forensics by Charles Giglia, but missed his MySpace Forensics presentation. I missed other presentations by folks like Jesse Kornblum, Cynthia Hetherington, and Terri Gudaitis. However, in my presentations, I got some good comments and questions, and had a couple of really good side conversations with some folks.
If you're the GWU student who talked to me on Friday morning...drop me a line. I'm always happy to help.
Anyway, I made a couple of comments during my opening session talk, and during my presentations that cybercrime is increasing in sophistication, and that there's a widening gap between what "we" (forensic analysts, first responders and sysadmins) do or are capable of doing, and what the bad guys do. I can't say that there was a strong reaction either way, but this morning I read this article, where Kevin Mandia was quoted. In the article, Kevin talks about the increased/ing sophistication of cybercrime, and the widening gap between the good guys and bad guys.
As I mentioned, I presented on Windows Memory Analysis, and interestingly this appeared in the article:
One of the worst things users can do if they think their systems have been compromised by a hacker is to shut off their PCs, because doing so prevents an investigator from analyzing the contents of the machine's RAM, which often contains useful forensic evidence, Mandia said.
The paragraph that followed this one also provided some interesting insight. This shows that this sort of thing is being done (ie, RAM is being collected and analyzed), it's being done by some smart folks, and valuable information is being used to solve cases. More importantly, the traditional approach most folks use doesn't include collecting this information.
If you have any questions about the conference, my presentations, or about anything...drop me a line.
Addendum, 17 Aug: During my presentations at GMU2006, I talked about live response...in some of the presentations, the discussion was tangential, but in the actual Windows Live Response presentation...and the need for live response. One of the reasons for conducting live response is that downtimes of systems aren't measured in minutes, but in dollars per minute. For the most part, it sort of looks like I'm making this up...I really don't have anything to reference, other than professional experience. Well, I found a link to an article at DarkReading this morning that talks about the cost of a hack. One of the bullet statements in the article references a Yankee Group survey that indicates that some companies measure downtime in thousands of dollars per hour.
Thursday, August 03, 2006
What is "forensically sound"?
Mike Murr over on the Forensic Computing blog posed an interesting question yesterday, surrounding the definition of "forensically sound". Mike made some interesting points...I suggest you read through them and ponder the idea for a bit.
This was also picked up by Richard Bejtlich at TaoSecurity.
My thoughts on this is that it's an important and timely question really...what is "forensically sound" evidence? Given that potential sources of evidence no longer consist of simply hard drives, but now also include volatile memory, the network, and non-hard drive sources such as cell phones, PDAs, thumb drives, digital cameras, etc., maybe it's about time for another definition.
I'm not usually a big fan of massive cross-posting, but this is an important issue...the current definition doesn't bode well for live response and acquisitions. So, if you're so inclined, read up and add a comment.
Addendum, 4 Aug: It looks like we may be closer to a definition. I'm copying and pasting this definition from a comment I made on the TaoSecurity blog:
"A forensically sound duplicate is obtained in a manner that does not materially alter the source evidence, except to the minimum extent necessary to obtain the evidence. The manner used to obtain the evidence must be documented, and should be justified to the extent applicable."
The second sentence in bold is something I added. Having been in the military, I'll just say that the placement of "must" and "should" were purposeful and intended.
Thoughts?
This was also picked up by Richard Bejtlich at TaoSecurity.
My thoughts on this is that it's an important and timely question really...what is "forensically sound" evidence? Given that potential sources of evidence no longer consist of simply hard drives, but now also include volatile memory, the network, and non-hard drive sources such as cell phones, PDAs, thumb drives, digital cameras, etc., maybe it's about time for another definition.
I'm not usually a big fan of massive cross-posting, but this is an important issue...the current definition doesn't bode well for live response and acquisitions. So, if you're so inclined, read up and add a comment.
Addendum, 4 Aug: It looks like we may be closer to a definition. I'm copying and pasting this definition from a comment I made on the TaoSecurity blog:
"A forensically sound duplicate is obtained in a manner that does not materially alter the source evidence, except to the minimum extent necessary to obtain the evidence. The manner used to obtain the evidence must be documented, and should be justified to the extent applicable."
The second sentence in bold is something I added. Having been in the military, I'll just say that the placement of "must" and "should" were purposeful and intended.
Thoughts?
NoVA Sec Founded
Richard Bejtlich recently started NoVA Sec, billed as "Pure technical gatherings for security professionals in the northern Virginia area. Check your certifications at the door." Sounds cool. One of the folks who commented made reference to the 2600 meetings that used to occur in the area.
Unfortunately, yours truly is disqualified for admission, beginning with the very first meeting. According to the announcement, "The price of admission is a laptop running something other than Microsoft Windows."
Oh, well. Can someone tell me how the meeting goes? Thanks.
Addendum, 4 Aug: Okay, it looks like the definition of "running" isn't as explicit as I originally thought. I'll try to come up with something exotic and show up...
Unfortunately, yours truly is disqualified for admission, beginning with the very first meeting. According to the announcement, "The price of admission is a laptop running something other than Microsoft Windows."
Oh, well. Can someone tell me how the meeting goes? Thanks.
Addendum, 4 Aug: Okay, it looks like the definition of "running" isn't as explicit as I originally thought. I'll try to come up with something exotic and show up...
Looking at IR Tools
When performing incident response (most notably in a live situation), I find myself thinking, "There's gotta be an easier way." I've faced some of the very same situations you have...a multitude of systems that are physically/geographically distributed, but I can reach them via the network, Windows servers configured with no NetBIOS so you can't log into them remotely, etc. In all situations, however, the basic requirements are the same...the systems have to be examined live, can't be turned off, and you have to find out what, if anything, is going on. Basically, play "Where's Waldo" with malware.
The question has been...how best to do so? Well, I originally put together the FSP for this purpose. I wanted something that could be put together, was flexible and easy to use, and minimized the impact on the system. With the FSP, an investigator can put together a distribution CD, send it out to remote locations (or a first responder can download the files and burn them to CD), and the client will connect to the server over a TCP/IP connection to transfer the data that it collects.
What about other distribution methods, such as collecting information over the network? Well, if you're able to login remotely to Windows systems, you can use a combination of tools such as psexec.exe and WMI to collect information remotely. In fact, some of the tools I've created for use with the FSP use Perl to implement WMI.
Recently, I took a look at other tools that are available in this space. Let me start by saying a couple of things. First, what I'm going to say is based only on my initial impressions, not on extensive testing. When I began looking at these tools, I didn't have a set of criteria to evaluate them against. Rather, I wanted to get familiar with them, see how they were set up, how they functioned, etc. More extensive testing will come after I have a better understanding of the tools themselves. Part of the reason is that while the tools generally fit into the IR space, they are all different...different capabilities, functions, deployment options, etc.
Second, I do not make any claims that this is a complete list of the tools that are available. These are just the ones I'm aware of. If you find others, please don't hesitate to comment here, or drop me a line.
Finally, when I set out on this exercise, my notional testing infrastructure consisted of an XP Home SP2 laptop running VMWare Workstation 5.x and a Windows 2000 SP4 VM client. This gives me a semblence of a "network".
Now, let's take a look at the tools:
Mandiant's First Response - When I first downloaded First Response, I was concerned by the size...23+MB, plus an additional 22MB for the .NET framework. That's a lot of code, but it gets installed on one system, from which the agent files are distributed. Setting things up was relatively easy, and I was presented with a nice GUI (hey, I'm a fan of the command line, but I have no allusions that in order to penetrate the market, you NEED a GUI). I created the agent files with no trouble, and then copied them to a thumb drive. I had taken some time to puruse the Mandiant forums and seen how Steve Bunting had posted about an issue with distributing the FRAgent files. In a nutshell, the tool uses SSL to encrypt the data it sends, and creates individual keys for each system - so if you run the tools from a thumb drive on one system, you have to then "clean up" some of the files written to the thumb drive prior to running the agent on another system (from the thumb drive). This is inherent to the current version of First Response, and Dave Merkel indicated that this may change in the future. So, I copied the agent files to a directory on the Windows 2000 "guest" and attempted to install the agent (it installs as a Win32 service on the system...something to keep in mind); I say "attempted" because I received an error message about not being able to find a DLL that was clearly visible in the PATH.
Hhhhmmm. Okay, I then installed the agent files on the XP Home SP2 host system, and used the console to connect to the FRAgent running on 127.0.0.1. Things ran fine at that point, and I told the console to perform a "General Audit". After a bit, I could view all of the information that was collected...which was a lot. First Response grabs a pretty comprehensive set of information (Processes, Ports, Registry, file info, etc.) during a General Audit, and everything can be stored locally, and even exported to other formats (.cvs, .txt, etc.).
I think that First Response is best used if installed prior to an incident. The agent can be installed and running on servers, and if an incident occurs, the administrator can collect information from all of the systems, and then archive it and send it to someone for analysis.
Now, I should point out something very odd that I found. When I ran the General Audit on localhost, I noticed a connection in the Ports report...fragent.exe was connecting to an IP address off of my network, at nLayer/Akamai Technologies, via port 80. I posted this to the Mandiant forums, and will see if I can replicate this behaviour. At Matt Pepe's suggestion, if I see this again, I'll attempt to verify it with other tools, including WireShark.
Nigilant32 - Nigilant32 is a nice little tool from Agile Risk Management LLC...and I do mean little. It's a GUI tool, but still weighs in at under 1MB when you download the archive and unzip it. You can copy Nigilant32 to a thumb drive, and walk it around to various systems, launch the GUI, snapshot the system, save the retrieved data to the thumb drive, and move on.
The snapshot of data collected by Nigilant32 is comprehensive, but not easily parsed. Opening the snapshot in Notepad, you don't easily see all processes in relation to each other (due to how the information is formatted) and you have to go to another section of the file to see what ports are open.
Something nice about Nigilant32 is that you can dump the contents of RAM. I did that, and ran the dump through lsproc.pl and got the basic information about all the processes in RAM...very nice.
The one thing I didn't like about Nigilant32 is that when you launch the app, you're presented with a splashscreen. In my experience, the splashscreen should be visible as the app loads, or just for a couple of seconds. However, with Nigilant32, you have to click on the splashscreen to access the GUI. Annoying, but the Nigilant32 is still simple and easy to use, but one still needs some means of performing data reduction and correlation.
RPIER - This is an interesting little tool I came across from Intel, available on SourceForge. Unfortunately, I wasn't able to test it...I unzipped the archive and tried to run it, and the app complained that it couldn't find "mscoree.dll". I checked the archive, and didn't find any such file. I used Dependency Walker to verify that the EXE file did indeed rely on that DLL. The funny thing was, Mandiant's tool ships with a file by that name.
Looking at the files in the archive, it seems that RPIER is similar to the FSP, in that it uses and launches external tools to collect at least some of the information. Reading through the documentation on RPIER, it's a bit more mature than FSP, in that it has a GUI interface, comes pre-assembled, and the files can be uploaded to a properly configured web server, whereas the FSP doesn't write any files to the system being examined (it sends the information it collects out over a TCP/IP socket to the waiting server).
I've emailed one of the authors to see about resolving the issue...I'll test it out when the DLL issue is sorted out.
ProDiscover IR - This is the only non-free tool I looked at, and I'll tell you right up front...I've had a license for PD since around version 3.x. In fact, in the past year, I've been using it quite a bit, and it's my favorite tool for forensic analysis of images, by far. I've even gone so far as to convert EnCase files from their native format to dd-format so I can open them in ProDiscover.
PD/IR comes with an incident response capability...basically, an agent that can be either pushed out (via remote login) or distributed on CD, thumb drive, etc. Using the GUI to collect information can be complicated, but ProDiscover comes with the ProScript/Perl scripting language that allows you to automate sending the agent, collecting information, and then deleting the agent from the remote system. With multiple distribution methods and the ability to automate distribution and data collection, ProDiscover is the most flexible tool that I looked at.
Also, like Nigilant32, you can use ProDiscover IR to collect the contents of RAM from the remote system...only with PD, you can do it over the network.
In a nutshell, most of the tools I looked at have their uses and strong points. The one commonality amongst all of the tools is the lack of data reduction and correlation capabilities. However, that's not a bad thing...it's something that will come along as people use the tools, and as the tools mature. Collecting data is easy...analyzing the data is the hard part, and requires some skill and dedication. Like most incident responders, I've seen experienced administrators (and experienced responders, as well) look at the exact same data I'm looking at, and not see anything "unusual", or focus on the wrong thing simply because they aren't familiar with it. Data reduction and correlation tools can be crafted pretty easily...my preference and experience in doing so is with Perl...but at some point, a person needs to review the data and decide what's what. For example, if you're using any of these tools in a pretty static environment, such as a server farm or data center, you can pretty easily build a simple database (using mySql or SqlLite) of known-good processes, ports, etc. That way, after you run your collection tool(s), you can run the data through a parsing mechanism that filters out the known-good stuff...data reduction...leaving things that you need to look at (and may end up adding to the known-good list).
Again, please keep in mind that this "review" of the tools is just an initial blush, and I haven't explored all of the capabilities of each of them.
As always, comments/questions are welcome.
Addendum, 3 Aug: I was informed that I'd missed a tool that should have been included, WFT, which seems to have gained it's notariety through SANS. I downloaded it from the web site, and at first blush it's very similar to the FSP, in that you have to go out and get the tools you want to use with it. I wasn't able to easily locate anything in the zipped archive or at the web site that indicated where you can go to get some of the tools...some are obvious to me (such as those from SysInternals.com), while others aren't. There is one...mac.exe...that looks familiar (in name only), and may be one I wrote a while back, as according to the WFT configuration file, it was "compiled" with Perl2Exe.
I haven't run the tool yet, but from presentations and screenshots available on the web site, it looks like WFT reports it's output in a nice HTML format, in addition to saving the raw output of the commands that are run. Something like this is very useful, and is a step up from a simple batch file...WFT generates/verifies MD5 checksums of the tools listed in the configuration file.
All of these tools collect a good deal of information...some more than others. Tools such as WFT and FSP allow the user to configure how much information is collected (like the FSP, WFT is capable of using other configuration files besides the default), but the issue of data reduction, correlation, and analysis remains.
PSS: Okay, looking around, I've found other first response/IR toolkits; one at FIRST, and one called IRCR.
The question has been...how best to do so? Well, I originally put together the FSP for this purpose. I wanted something that could be put together, was flexible and easy to use, and minimized the impact on the system. With the FSP, an investigator can put together a distribution CD, send it out to remote locations (or a first responder can download the files and burn them to CD), and the client will connect to the server over a TCP/IP connection to transfer the data that it collects.
What about other distribution methods, such as collecting information over the network? Well, if you're able to login remotely to Windows systems, you can use a combination of tools such as psexec.exe and WMI to collect information remotely. In fact, some of the tools I've created for use with the FSP use Perl to implement WMI.
Recently, I took a look at other tools that are available in this space. Let me start by saying a couple of things. First, what I'm going to say is based only on my initial impressions, not on extensive testing. When I began looking at these tools, I didn't have a set of criteria to evaluate them against. Rather, I wanted to get familiar with them, see how they were set up, how they functioned, etc. More extensive testing will come after I have a better understanding of the tools themselves. Part of the reason is that while the tools generally fit into the IR space, they are all different...different capabilities, functions, deployment options, etc.
Second, I do not make any claims that this is a complete list of the tools that are available. These are just the ones I'm aware of. If you find others, please don't hesitate to comment here, or drop me a line.
Finally, when I set out on this exercise, my notional testing infrastructure consisted of an XP Home SP2 laptop running VMWare Workstation 5.x and a Windows 2000 SP4 VM client. This gives me a semblence of a "network".
Now, let's take a look at the tools:
Mandiant's First Response - When I first downloaded First Response, I was concerned by the size...23+MB, plus an additional 22MB for the .NET framework. That's a lot of code, but it gets installed on one system, from which the agent files are distributed. Setting things up was relatively easy, and I was presented with a nice GUI (hey, I'm a fan of the command line, but I have no allusions that in order to penetrate the market, you NEED a GUI). I created the agent files with no trouble, and then copied them to a thumb drive. I had taken some time to puruse the Mandiant forums and seen how Steve Bunting had posted about an issue with distributing the FRAgent files. In a nutshell, the tool uses SSL to encrypt the data it sends, and creates individual keys for each system - so if you run the tools from a thumb drive on one system, you have to then "clean up" some of the files written to the thumb drive prior to running the agent on another system (from the thumb drive). This is inherent to the current version of First Response, and Dave Merkel indicated that this may change in the future. So, I copied the agent files to a directory on the Windows 2000 "guest" and attempted to install the agent (it installs as a Win32 service on the system...something to keep in mind); I say "attempted" because I received an error message about not being able to find a DLL that was clearly visible in the PATH.
Hhhhmmm. Okay, I then installed the agent files on the XP Home SP2 host system, and used the console to connect to the FRAgent running on 127.0.0.1. Things ran fine at that point, and I told the console to perform a "General Audit". After a bit, I could view all of the information that was collected...which was a lot. First Response grabs a pretty comprehensive set of information (Processes, Ports, Registry, file info, etc.) during a General Audit, and everything can be stored locally, and even exported to other formats (.cvs, .txt, etc.).
I think that First Response is best used if installed prior to an incident. The agent can be installed and running on servers, and if an incident occurs, the administrator can collect information from all of the systems, and then archive it and send it to someone for analysis.
Now, I should point out something very odd that I found. When I ran the General Audit on localhost, I noticed a connection in the Ports report...fragent.exe was connecting to an IP address off of my network, at nLayer/Akamai Technologies, via port 80. I posted this to the Mandiant forums, and will see if I can replicate this behaviour. At Matt Pepe's suggestion, if I see this again, I'll attempt to verify it with other tools, including WireShark.
Nigilant32 - Nigilant32 is a nice little tool from Agile Risk Management LLC...and I do mean little. It's a GUI tool, but still weighs in at under 1MB when you download the archive and unzip it. You can copy Nigilant32 to a thumb drive, and walk it around to various systems, launch the GUI, snapshot the system, save the retrieved data to the thumb drive, and move on.
The snapshot of data collected by Nigilant32 is comprehensive, but not easily parsed. Opening the snapshot in Notepad, you don't easily see all processes in relation to each other (due to how the information is formatted) and you have to go to another section of the file to see what ports are open.
Something nice about Nigilant32 is that you can dump the contents of RAM. I did that, and ran the dump through lsproc.pl and got the basic information about all the processes in RAM...very nice.
The one thing I didn't like about Nigilant32 is that when you launch the app, you're presented with a splashscreen. In my experience, the splashscreen should be visible as the app loads, or just for a couple of seconds. However, with Nigilant32, you have to click on the splashscreen to access the GUI. Annoying, but the Nigilant32 is still simple and easy to use, but one still needs some means of performing data reduction and correlation.
RPIER - This is an interesting little tool I came across from Intel, available on SourceForge. Unfortunately, I wasn't able to test it...I unzipped the archive and tried to run it, and the app complained that it couldn't find "mscoree.dll". I checked the archive, and didn't find any such file. I used Dependency Walker to verify that the EXE file did indeed rely on that DLL. The funny thing was, Mandiant's tool ships with a file by that name.
Looking at the files in the archive, it seems that RPIER is similar to the FSP, in that it uses and launches external tools to collect at least some of the information. Reading through the documentation on RPIER, it's a bit more mature than FSP, in that it has a GUI interface, comes pre-assembled, and the files can be uploaded to a properly configured web server, whereas the FSP doesn't write any files to the system being examined (it sends the information it collects out over a TCP/IP socket to the waiting server).
I've emailed one of the authors to see about resolving the issue...I'll test it out when the DLL issue is sorted out.
ProDiscover IR - This is the only non-free tool I looked at, and I'll tell you right up front...I've had a license for PD since around version 3.x. In fact, in the past year, I've been using it quite a bit, and it's my favorite tool for forensic analysis of images, by far. I've even gone so far as to convert EnCase files from their native format to dd-format so I can open them in ProDiscover.
PD/IR comes with an incident response capability...basically, an agent that can be either pushed out (via remote login) or distributed on CD, thumb drive, etc. Using the GUI to collect information can be complicated, but ProDiscover comes with the ProScript/Perl scripting language that allows you to automate sending the agent, collecting information, and then deleting the agent from the remote system. With multiple distribution methods and the ability to automate distribution and data collection, ProDiscover is the most flexible tool that I looked at.
Also, like Nigilant32, you can use ProDiscover IR to collect the contents of RAM from the remote system...only with PD, you can do it over the network.
In a nutshell, most of the tools I looked at have their uses and strong points. The one commonality amongst all of the tools is the lack of data reduction and correlation capabilities. However, that's not a bad thing...it's something that will come along as people use the tools, and as the tools mature. Collecting data is easy...analyzing the data is the hard part, and requires some skill and dedication. Like most incident responders, I've seen experienced administrators (and experienced responders, as well) look at the exact same data I'm looking at, and not see anything "unusual", or focus on the wrong thing simply because they aren't familiar with it. Data reduction and correlation tools can be crafted pretty easily...my preference and experience in doing so is with Perl...but at some point, a person needs to review the data and decide what's what. For example, if you're using any of these tools in a pretty static environment, such as a server farm or data center, you can pretty easily build a simple database (using mySql or SqlLite) of known-good processes, ports, etc. That way, after you run your collection tool(s), you can run the data through a parsing mechanism that filters out the known-good stuff...data reduction...leaving things that you need to look at (and may end up adding to the known-good list).
Again, please keep in mind that this "review" of the tools is just an initial blush, and I haven't explored all of the capabilities of each of them.
As always, comments/questions are welcome.
Addendum, 3 Aug: I was informed that I'd missed a tool that should have been included, WFT, which seems to have gained it's notariety through SANS. I downloaded it from the web site, and at first blush it's very similar to the FSP, in that you have to go out and get the tools you want to use with it. I wasn't able to easily locate anything in the zipped archive or at the web site that indicated where you can go to get some of the tools...some are obvious to me (such as those from SysInternals.com), while others aren't. There is one...mac.exe...that looks familiar (in name only), and may be one I wrote a while back, as according to the WFT configuration file, it was "compiled" with Perl2Exe.
I haven't run the tool yet, but from presentations and screenshots available on the web site, it looks like WFT reports it's output in a nice HTML format, in addition to saving the raw output of the commands that are run. Something like this is very useful, and is a step up from a simple batch file...WFT generates/verifies MD5 checksums of the tools listed in the configuration file.
All of these tools collect a good deal of information...some more than others. Tools such as WFT and FSP allow the user to configure how much information is collected (like the FSP, WFT is capable of using other configuration files besides the default), but the issue of data reduction, correlation, and analysis remains.
PSS: Okay, looking around, I've found other first response/IR toolkits; one at FIRST, and one called IRCR.
New Hashing
I blogged the other day regarding Jesse Kornblum's "fuzzy hashing" technique...I can't wait until Tuesday next week to see his presentation at GMU2006. I think this would be very useful in cases in which you're able to use tools such as lspi.pl to extract a binary image from a Windows memory dump.
Andreas posted last night on "authenticating" a reconstructed binary by hashing the immutable sections separately. This, too, is a good idea, but as with Jesse's technique, it changes how things are done now with regards to hashing. Right now, there are lists of file names, metadata, and hashes made available through various sources (NIST, vendors, etc.) that are used as references. There are lists of known-bad files, known-good files, malware, etc. These lists are good for static, old-school data reduction techniques (which is still valid). However, as we continue moving down the road to more sophisticated systems and crimes, we need to adapt our techniques, as well. Tools and techniques such as "fuzzy" hashing and "piecewise" hashing (on a by-section basis, based on the contents of the PE headers) will only help us.
Andreas posted last night on "authenticating" a reconstructed binary by hashing the immutable sections separately. This, too, is a good idea, but as with Jesse's technique, it changes how things are done now with regards to hashing. Right now, there are lists of file names, metadata, and hashes made available through various sources (NIST, vendors, etc.) that are used as references. There are lists of known-bad files, known-good files, malware, etc. These lists are good for static, old-school data reduction techniques (which is still valid). However, as we continue moving down the road to more sophisticated systems and crimes, we need to adapt our techniques, as well. Tools and techniques such as "fuzzy" hashing and "piecewise" hashing (on a by-section basis, based on the contents of the PE headers) will only help us.
Tuesday, August 01, 2006
All hail the FATKit!
It's times like this that I really need icons for my blog entries...while many would rate a nice Homer Simpson icon, this one rates an icon of Bender from "Futurama" (here's another good one).
Aaron Walters and Nick Petroni have put together something called the FATKit: The Forensic Analysis Toolkit. I've known about the site for a while, and while it looks interesting, there hasn't been a lot of stuff up there...until now. Aaron posted a whitepaper that among other things, gives us a view of what the FATKit is all about...and to be honest, it looks AWESOME!
Something like this is incredibly useful, providing a layer of abstraction for the analyst while maintaining the integrity of the underlying data. Very cool...these guys have done a lot of great work. If you get a chance, take a look at the paper and either comment here, or send your comments directly to Aaron and Nick.
As you can see from the bottom of the page, Aaron will be at DFRWS, and is putting together a BoF with Andreas Schuster...makes me wish I could go! I only hope that someone attends, and sends in a write up on how things went.
Aaron Walters and Nick Petroni have put together something called the FATKit: The Forensic Analysis Toolkit. I've known about the site for a while, and while it looks interesting, there hasn't been a lot of stuff up there...until now. Aaron posted a whitepaper that among other things, gives us a view of what the FATKit is all about...and to be honest, it looks AWESOME!
Something like this is incredibly useful, providing a layer of abstraction for the analyst while maintaining the integrity of the underlying data. Very cool...these guys have done a lot of great work. If you get a chance, take a look at the paper and either comment here, or send your comments directly to Aaron and Nick.
As you can see from the bottom of the page, Aaron will be at DFRWS, and is putting together a BoF with Andreas Schuster...makes me wish I could go! I only hope that someone attends, and sends in a write up on how things went.
GMU2006 Presentations Posted
I've posted my presentations for GMU2006, which starts next week. I'm posting them so that anyone attending can get a look at the presentations ahead of time, and so that those folks who aren't attending can see the same thing. One word of warning, though...I'm not a huge proponent of "death by PowerPoint"...meaning that my entire script isn't on the slides. However, there should be more than enough there to give you a really good idea of what's going to be said. Also, I tend to be very interactive, discussing topics with the attendees rather than at them.
So, the archive contains my presentations on Windows memory analysis and tracking USB devices across Windows systems. There is a third presentation, as well, that is for the opening session...the folks running the conference asked me late last week to speak, and I thought I'd fill the time talking about issues we're facing as a community.
If you download the presentations and have questions or comments, please feel to share them here, or with me directly.
Addendum 1 Aug: Okay, here's my speaking schedule for the conference:
Mon, 7 Aug: Opening session, 9:30 - 10:30AM
Tues, 8 Aug: "Tracking USB Devices", 10AM
Wed, 9 Aug: "Windows Memory Analysis", 10AM
Thu, 10 Aug: "Tracking USB Devices", 8AM
Thu, 10 Aug: "Windows Memory Analysis", 10AM
In addition, there are a lot of great presentations going on...Cynthia Hetherington is a fantastic speaker, and Terri Gudaitis is giving her "Cybercrime Profiling" presentation again - it's always a winner. Also, I just spoke with Jesse Kornblum and he's only going to be on-site for his presentation on "Fuzzy Hashing" at 8am on Tues - boys and girls, Jesse's presentation on "Fuzzy Hashing" is a MUST SEE, even if you've listened to his Cyberspeak podcast interview!
I'd suggest buying Jesse a beer, but I don't know how he feels about imbiding that early in the day. I, however, am of the firm belief that it's 5 o'clock somewhere. ;-)
So, the archive contains my presentations on Windows memory analysis and tracking USB devices across Windows systems. There is a third presentation, as well, that is for the opening session...the folks running the conference asked me late last week to speak, and I thought I'd fill the time talking about issues we're facing as a community.
If you download the presentations and have questions or comments, please feel to share them here, or with me directly.
Addendum 1 Aug: Okay, here's my speaking schedule for the conference:
Mon, 7 Aug: Opening session, 9:30 - 10:30AM
Tues, 8 Aug: "Tracking USB Devices", 10AM
Wed, 9 Aug: "Windows Memory Analysis", 10AM
Thu, 10 Aug: "Tracking USB Devices", 8AM
Thu, 10 Aug: "Windows Memory Analysis", 10AM
In addition, there are a lot of great presentations going on...Cynthia Hetherington is a fantastic speaker, and Terri Gudaitis is giving her "Cybercrime Profiling" presentation again - it's always a winner. Also, I just spoke with Jesse Kornblum and he's only going to be on-site for his presentation on "Fuzzy Hashing" at 8am on Tues - boys and girls, Jesse's presentation on "Fuzzy Hashing" is a MUST SEE, even if you've listened to his Cyberspeak podcast interview!
I'd suggest buying Jesse a beer, but I don't know how he feels about imbiding that early in the day. I, however, am of the firm belief that it's 5 o'clock somewhere. ;-)
Monday, July 31, 2006
Extracting Executable Images from RAM Dumps
In his Cyberspeak podcast interview, Jesse Kornblum mentioned the tool I'd recently released called Lspi.pl, for LiSt Process Image.
As of this morning, SourceForge.net shows that it's been downloaded 32 times. If you're reading this, and you're one of the folks who downloaded and has tried it, I'd greatly appreciate any comments you may have.
As of this morning, SourceForge.net shows that it's been downloaded 32 times. If you're reading this, and you're one of the folks who downloaded and has tried it, I'd greatly appreciate any comments you may have.
"Genius" Kornblum on fuzzy hashing
Jesse Kornblum was recently interviewed by the CyberSpeak podcast guys with regards to his "fuzzy hashing" paper to be presented at DFRWS.
Jesse, the author of hashing tools such as md5-, tiger-, and whirlpooldeep, has come up with something called "fuzzy hashing" which can be used to combat the approach that's being taken to obfuscate files by making small changes, as with Word documents (intellectual property crime) and images ('nuff said).
Jesse clearly explains the concept behind "fuzzy hashing" in his interview...in a nutshell, if you have two similar bitstreams (ie, JPEGs, GIFs, etc.) that have small changes, his tool (dubbed "SSDeep") will be able to tell you if they are similar...whereas tools like MD5Deep will tell you if the tools are exactly the same via a mathematical algorithm.
So what are the applications of something like this? Well, first off, it's not meant to find evidence; instead, it's an awesome data reduction tool. One of the examples Jesse used in his interview is Word documents that are printed out. When you print out a Word document, the time that the document was last printed is modified within the document itself...so an MD5 hash generated for the original document will not match the one generated for the printed document. The bitstreams are essentially the same, with some small modifications, and Jesse says that his tool will let you know that the two files are similar.
There are many other applications for this tool, to include image identification, intellectual property theft, etc. So, go on over to Cyberspeak and give the podcast a listen. If you see Jesse at DFRWS or GMU2006 or HTCIA, say hi, and buy him a beer!
Interestingly, Jesse is presenting on Windows memory analysis at HTCIA (end of Oct)...I'll be presenting on the subject at GMU2006. Jesse's also presenting at GMU2006.
BTW...Jesse, if you're reading this...thanks for the shout-out in your Cyberspeak interview!
Jesse, the author of hashing tools such as md5-, tiger-, and whirlpooldeep, has come up with something called "fuzzy hashing" which can be used to combat the approach that's being taken to obfuscate files by making small changes, as with Word documents (intellectual property crime) and images ('nuff said).
Jesse clearly explains the concept behind "fuzzy hashing" in his interview...in a nutshell, if you have two similar bitstreams (ie, JPEGs, GIFs, etc.) that have small changes, his tool (dubbed "SSDeep") will be able to tell you if they are similar...whereas tools like MD5Deep will tell you if the tools are exactly the same via a mathematical algorithm.
So what are the applications of something like this? Well, first off, it's not meant to find evidence; instead, it's an awesome data reduction tool. One of the examples Jesse used in his interview is Word documents that are printed out. When you print out a Word document, the time that the document was last printed is modified within the document itself...so an MD5 hash generated for the original document will not match the one generated for the printed document. The bitstreams are essentially the same, with some small modifications, and Jesse says that his tool will let you know that the two files are similar.
There are many other applications for this tool, to include image identification, intellectual property theft, etc. So, go on over to Cyberspeak and give the podcast a listen. If you see Jesse at DFRWS or GMU2006 or HTCIA, say hi, and buy him a beer!
Interestingly, Jesse is presenting on Windows memory analysis at HTCIA (end of Oct)...I'll be presenting on the subject at GMU2006. Jesse's also presenting at GMU2006.
BTW...Jesse, if you're reading this...thanks for the shout-out in your Cyberspeak interview!
Thursday, July 20, 2006
LiSt Process Image upload
I've uploaded lspi 0.4 to my SourceForge site, and if you use lsproc or want to be able to automatically extract process image files from RAM dumps (of Windows 2000 systems, at this point), then you definitely want to check this out! This is the "automatic binary extractor" that Andreas mentioned a while back.
This code (the archive contains the Perl script and a Windows EXE "compiled" using Perl2Exe...be sure to keep the included DLL with the EXE at all times) makes use of some of the RAM dump file parsing code from tools like lsproc and lspd, as well as the code from my File::ReadPE module. Like the other tools, this one relies on the output of lsproc for it's input...specifically, the offset to the process in question. It uses pretty much the same method as Andreas mentioned in his first blog entry on reassembling binaries, for no other reason than it just makes sense. After all, why not use the "map" provided to you in the PE headers to reassemble the executable image file.
Let's take a look at an example, focusing on the same process that Andreas looked at...dd.exe with a PID of 284, from the first memory dump from the DFRWS 2005 Memory Challenge. The output of lsproc gives us:
Proc 1112 284 dd.exe 0x0414dd60 Sun Jun 5 14:53:42 2005
Very cool. So, using the offset to the process within the dump file, we can then launch lspi with the following command line:
C:\Perl>lspi.pl d:\hacking\dfrws-mem1.dmp 0x0414dd60
What we get as output is:
lspi - list Windows 2000 process image (v.0.4 - 20060721)
Ex: lspi
Process Name : dd.exe
PID : 284
DTB : 0x01d9e000
PEB : 0x7ffdf000 (0x02c2d000)
ImgBaseAddr : 0x00400000 (0x00fee000)
e_lfanew = 0xe8
NT Header = 0x4550
Reading the Image File Header
Sections = 4
Opt Header Size = 0x000000e0 (224 bytes)
Characteristics:
IMAGE_FILE_EXECUTABLE_IMAGE
IMAGE_FILE_LOCAL_SYMS_STRIPPED
IMAGE_FILE_RELOCS_STRIPPED
IMAGE_FILE_LINE_NUMS_STRIPPED
IMAGE_FILE_32BIT_MACHINE
Machine = IMAGE_FILE_MACHINE_I860
Reading the Image Optional Header
Opt Header Magic = 0x10b
Subsystem : IMAGE_SUBSYSTEM_WINDOWS_CUI
Entry Pt Addr : 0x00006bda
Image Base : 0x00400000
File Align : 0x00001000
Reading the Image Data Directory information
Data Directory RVA Size
-------------- --- ----
ResourceTable 0x0000d000 0x00000430
DebugTable 0x00000000 0x00000000
BaseRelocTable 0x00000000 0x00000000
DelayImportDesc 0x0000af7c 0x000000a0
TLSTable 0x00000000 0x00000000
GlobalPtrReg 0x00000000 0x00000000
ArchSpecific 0x00000000 0x00000000
CLIHeader 0x00000000 0x00000000
LoadConfigTable 0x00000000 0x00000000
ExceptionTable 0x00000000 0x00000000
ImportTable 0x0000b25c 0x000000a0
unused 0x00000000 0x00000000
BoundImportTable 0x00000000 0x00000000
ExportTable 0x00000000 0x00000000
CertificateTable 0x00000000 0x00000000
IAT 0x00007000 0x00000210
Reading Image Section Header information
Name Virt Sz Virt Addr rData Ofs rData Sz Char
---- ------- --------- --------- -------- ----
.text 0x00005ee0 0x00001000 0x00001000 0x00006000 0x60000020
.data 0x000002fc 0x0000c000 0x0000c000 0x00001000 0xc0000040
.rsrc 0x00000430 0x0000d000 0x0000d000 0x00001000 0x40000040
.rdata 0x00004cfa 0x00007000 0x00007000 0x00005000 0x40000040
Reassembling image file into dd.exe.img
Bytes written = 57344
New file size = 57344
Most of this is the PE header being parsed and displayed.
Now, a couple of caveats...first, this code ONLY works for RAM dumps from Windows 2000 systems (yes, I have been getting a lot of questions about that). Second, this does not take PAE into account. Nor does it take special cases into account, such as UPX compressed executables.
However, the code does check for things like pages that are paged out to the pagefile. Sounds kind of circular, I know, but basically, the pages in RAM that aren't being used can be paged out to pagefile.sys...since we're just dealing with a memory dump, we're assuming at this point that the pages in the pagefile aren't available.
Also, you will notice that the resulting executable image, once renamed to an .exe, does not run the way the original does. This is due to the fact that once the various sections are loaded into memory, some of the values in the different sections will change as the code is being run.
So, how is something like this useful? Well, if you're into malware analysis, or if you're performing incident response against an as-yet-unknown bit of code, this would be helpful.
Of course, there are things that need to be added to this code, as it performs only parsing. For example, some actual analysis would be in order...like analyzing the code at the entry point address, performing some analysis of the sections, extracting the import address (or name) tables, etc.
As always, comments are welcome...
This code (the archive contains the Perl script and a Windows EXE "compiled" using Perl2Exe...be sure to keep the included DLL with the EXE at all times) makes use of some of the RAM dump file parsing code from tools like lsproc and lspd, as well as the code from my File::ReadPE module. Like the other tools, this one relies on the output of lsproc for it's input...specifically, the offset to the process in question. It uses pretty much the same method as Andreas mentioned in his first blog entry on reassembling binaries, for no other reason than it just makes sense. After all, why not use the "map" provided to you in the PE headers to reassemble the executable image file.
Let's take a look at an example, focusing on the same process that Andreas looked at...dd.exe with a PID of 284, from the first memory dump from the DFRWS 2005 Memory Challenge. The output of lsproc gives us:
Proc 1112 284 dd.exe 0x0414dd60 Sun Jun 5 14:53:42 2005
Very cool. So, using the offset to the process within the dump file, we can then launch lspi with the following command line:
C:\Perl>lspi.pl d:\hacking\dfrws-mem1.dmp 0x0414dd60
What we get as output is:
lspi - list Windows 2000 process image (v.0.4 - 20060721)
Ex: lspi
Process Name : dd.exe
PID : 284
DTB : 0x01d9e000
PEB : 0x7ffdf000 (0x02c2d000)
ImgBaseAddr : 0x00400000 (0x00fee000)
e_lfanew = 0xe8
NT Header = 0x4550
Reading the Image File Header
Sections = 4
Opt Header Size = 0x000000e0 (224 bytes)
Characteristics:
IMAGE_FILE_EXECUTABLE_IMAGE
IMAGE_FILE_LOCAL_SYMS_STRIPPED
IMAGE_FILE_RELOCS_STRIPPED
IMAGE_FILE_LINE_NUMS_STRIPPED
IMAGE_FILE_32BIT_MACHINE
Machine = IMAGE_FILE_MACHINE_I860
Reading the Image Optional Header
Opt Header Magic = 0x10b
Subsystem : IMAGE_SUBSYSTEM_WINDOWS_CUI
Entry Pt Addr : 0x00006bda
Image Base : 0x00400000
File Align : 0x00001000
Reading the Image Data Directory information
Data Directory RVA Size
-------------- --- ----
ResourceTable 0x0000d000 0x00000430
DebugTable 0x00000000 0x00000000
BaseRelocTable 0x00000000 0x00000000
DelayImportDesc 0x0000af7c 0x000000a0
TLSTable 0x00000000 0x00000000
GlobalPtrReg 0x00000000 0x00000000
ArchSpecific 0x00000000 0x00000000
CLIHeader 0x00000000 0x00000000
LoadConfigTable 0x00000000 0x00000000
ExceptionTable 0x00000000 0x00000000
ImportTable 0x0000b25c 0x000000a0
unused 0x00000000 0x00000000
BoundImportTable 0x00000000 0x00000000
ExportTable 0x00000000 0x00000000
CertificateTable 0x00000000 0x00000000
IAT 0x00007000 0x00000210
Reading Image Section Header information
Name Virt Sz Virt Addr rData Ofs rData Sz Char
---- ------- --------- --------- -------- ----
.text 0x00005ee0 0x00001000 0x00001000 0x00006000 0x60000020
.data 0x000002fc 0x0000c000 0x0000c000 0x00001000 0xc0000040
.rsrc 0x00000430 0x0000d000 0x0000d000 0x00001000 0x40000040
.rdata 0x00004cfa 0x00007000 0x00007000 0x00005000 0x40000040
Reassembling image file into dd.exe.img
Bytes written = 57344
New file size = 57344
Most of this is the PE header being parsed and displayed.
Now, a couple of caveats...first, this code ONLY works for RAM dumps from Windows 2000 systems (yes, I have been getting a lot of questions about that). Second, this does not take PAE into account. Nor does it take special cases into account, such as UPX compressed executables.
However, the code does check for things like pages that are paged out to the pagefile. Sounds kind of circular, I know, but basically, the pages in RAM that aren't being used can be paged out to pagefile.sys...since we're just dealing with a memory dump, we're assuming at this point that the pages in the pagefile aren't available.
Also, you will notice that the resulting executable image, once renamed to an .exe, does not run the way the original does. This is due to the fact that once the various sections are loaded into memory, some of the values in the different sections will change as the code is being run.
So, how is something like this useful? Well, if you're into malware analysis, or if you're performing incident response against an as-yet-unknown bit of code, this would be helpful.
Of course, there are things that need to be added to this code, as it performs only parsing. For example, some actual analysis would be in order...like analyzing the code at the entry point address, performing some analysis of the sections, extracting the import address (or name) tables, etc.
As always, comments are welcome...
Monday, July 17, 2006
Automatic binary reassembly from a RAM dump
A bit ago, Andreas Schuster posted to his blog about reconstructing executable images from a RAM dump (1, 2, 3). The first method listed not only made the most sense to me at the time, but was also easy to implement, as it dovetailed right off of some code I'd written to parse PE file headers. As I blogged about earlier, getting the PE header information from the ImageBaseAddress offset is just the beginning.
I'm posting now to say that I recently got the code for automatic reassembly of executable images working. My results are identical to those shown in Andreas's first blog post. I suspect that Andreas may be correct in his third post that the reassembled binary won't run correctly due to changes in code as the program runs. However, there are other conditions to consider...for instance, what if pages from the image have been paged out to the pagefile?
After extracting the binary image for dd.exe from the first RAM dump used in the DFRWS 2005 Memory Challenge, I ran a script to extract the PE header info, and compared that to the PE header info for the original copy of the executable, retrieved from George Garner's site. Visually, the headers are identical. I've since used Jesse Kornblum's md5deep tool to verify that the .rsrc sections from both files (original and reconstructed) are identical.
More testing needs to be done, and the code needs to be cleaned up and brought in line with the other code already available. Once I've completed this, I'm going to redesign the format of the tools to be better suited to identifying the OS of the RAM dump, and then progressing on from there. At this point, like the other tools currently available, this code only works for RAM dumps from Windows 2000 systems.
You may be saying to yourself..."Yeah...and?" Some folks ask me why this kind of thing is important. Well, for one, if you're performing live response and suspect that there may be malware or a rootkit, you may want to actually get the executable for analysis. This may also be useful during dynamic analysis of malware, in which obfuscated malware is decompressed/decrypted when in memory.
I'm posting now to say that I recently got the code for automatic reassembly of executable images working. My results are identical to those shown in Andreas's first blog post. I suspect that Andreas may be correct in his third post that the reassembled binary won't run correctly due to changes in code as the program runs. However, there are other conditions to consider...for instance, what if pages from the image have been paged out to the pagefile?
After extracting the binary image for dd.exe from the first RAM dump used in the DFRWS 2005 Memory Challenge, I ran a script to extract the PE header info, and compared that to the PE header info for the original copy of the executable, retrieved from George Garner's site. Visually, the headers are identical. I've since used Jesse Kornblum's md5deep tool to verify that the .rsrc sections from both files (original and reconstructed) are identical.
More testing needs to be done, and the code needs to be cleaned up and brought in line with the other code already available. Once I've completed this, I'm going to redesign the format of the tools to be better suited to identifying the OS of the RAM dump, and then progressing on from there. At this point, like the other tools currently available, this code only works for RAM dumps from Windows 2000 systems.
You may be saying to yourself..."Yeah...and?" Some folks ask me why this kind of thing is important. Well, for one, if you're performing live response and suspect that there may be malware or a rootkit, you may want to actually get the executable for analysis. This may also be useful during dynamic analysis of malware, in which obfuscated malware is decompressed/decrypted when in memory.
Wednesday, July 12, 2006
Forensics Magazine
A bit ago, I blogged about cool technical e-zines that are available. Since then, CheckMate really seems to have come along, and I've also found some well-written content in the CodeBreakers Journal (be sure to check out the Magazine, as well).
While most of these e-zines are technical in nature, there don't seem to be many specific to forensic analysis. My first question is...is there any interest in such a thing? My thoughts are that such an e-zine would cover more than just forensic analysis of Windows systems, and would include topics in live response, legal issues, as well as (potentially) case studies, how-tos, etc.
Now, I know that there are several journals out there now, such as the DIJ and the IJDE, but I'm thinking of something a little more practical, down-and-dirty (though the article on iPod forensics from the IJDE is a lot like what I'm thinking of). If you're not familiar with it, check out SysAdmin Magazine. I like the format of this magazine because a lot of times, the articles don't simply refer to something being done...they actually provide the tools (be it a link to an executable, a shell script, etc.) to accomplish the task, and enough explanation for the reader to customize the script/process.
So...is there interest? If so, what would you like to see in such an e-zine? Or do you think that there's already enough magazines, journals and e-zines out there, and the last thing you want to see is another one?
While most of these e-zines are technical in nature, there don't seem to be many specific to forensic analysis. My first question is...is there any interest in such a thing? My thoughts are that such an e-zine would cover more than just forensic analysis of Windows systems, and would include topics in live response, legal issues, as well as (potentially) case studies, how-tos, etc.
Now, I know that there are several journals out there now, such as the DIJ and the IJDE, but I'm thinking of something a little more practical, down-and-dirty (though the article on iPod forensics from the IJDE is a lot like what I'm thinking of). If you're not familiar with it, check out SysAdmin Magazine. I like the format of this magazine because a lot of times, the articles don't simply refer to something being done...they actually provide the tools (be it a link to an executable, a shell script, etc.) to accomplish the task, and enough explanation for the reader to customize the script/process.
So...is there interest? If so, what would you like to see in such an e-zine? Or do you think that there's already enough magazines, journals and e-zines out there, and the last thing you want to see is another one?
Tuesday, July 11, 2006
Have you seen...?
I'm looking for a couple of things before I get started down the road in collecting my own data regarding forensic artifacts, so I thought I'd turn to the community at large to see what's already out there...
Specifically, I'm looking for credible sources regarding P2P application artifacts, including evidence of installation, searches, downloads, etc., within the Windows file system and Registry.
I'm also interested in forensic artifacts on Windows systems for popular steganography tools.
Has anyone seen any credible sites out there regarding these two areas?
Specifically, I'm looking for credible sources regarding P2P application artifacts, including evidence of installation, searches, downloads, etc., within the Windows file system and Registry.
I'm also interested in forensic artifacts on Windows systems for popular steganography tools.
Has anyone seen any credible sites out there regarding these two areas?
Book FAQ
In putting together my next book, one of the things I've put a lot of thought into is providing examples, as well as exercises. For example, I haven't found it very effective to say "run tool X against file Y"...instead, I'll provide a detailed walk-through (sort of like a mini case study) on how to do something, and then provide sample files that the reader can then run the tools/process against.
One thing that's been pretty consistent since my first book came out is folks wanting to know how to do specific tasks; how do I find movie files?, or how do I do X? For some of these specific, fairly frequent questions, I've been considering providing a FAQ in the book to answer/address them.
If you have questions like this, that you'd like see addressed, drop me a line and let me know. Please keep the questions specific to the forensic analysis of Windows systems...live or post-mortem.
One thing that's been pretty consistent since my first book came out is folks wanting to know how to do specific tasks; how do I find movie files?, or how do I do X? For some of these specific, fairly frequent questions, I've been considering providing a FAQ in the book to answer/address them.
If you have questions like this, that you'd like see addressed, drop me a line and let me know. Please keep the questions specific to the forensic analysis of Windows systems...live or post-mortem.
Thursday, June 22, 2006
New Forensics Book
I've found a publisher who wants to publish my second book. I've got a contract on my desk
right now. Our goal is to have this book on the shelves in late spring 2007.
This book will cover a variety of topics specific to information collection and analysis under live response and post-mortem conditions,
specifically for Windows systems. However, with the tools and techniques presented in this book, the analyst will
not be restricted solely to Windows as the analysis platform (many of the tools I created for this book
have been successfully testing on Windows, Linux, and Mac OS/X platforms).
This book will not cover topics that are not specific to Windows, such as imaging procedures, etc.
I've included a brief, conceptual outline below. My goal is to make this a valuable resource, full of
explanations, examples, and exercises. This will include sample memory captures, and links to images.
Some have suggested including sample system images on DVDs with the book, but in order to do so, I'd have to
include several DVDs. Talking with the publisher, most publishing systems are set up to press a single CD or
DVD for inclusion with the book...including additional media will drive the price of the book out of the range
of the intended audience.
I'd appreciate your input/comments on this, as well.
Some of the comments I've received from other sources include:
- Cover mobile devices: I'd love to...but I'm a one-man shop. I can't afford to purchase
mobile devices just for testing, nor can I afford the software to image such devices.
- Steganography: while not specific to Windows, it is definitely worth mentioning...but I'd
like to get some input from folks as to what needs to be addressed/discussed.
------------------------------------------------
Outline
------------------------------------------------
Chapter 1 – Introduction
- Purpose of the book, intended audience, what the book does/does not address
*Live Response section
Chapter 2 – Collecting Volatile Data
- Address live response, volatile data collection (ie, what to collect, how to collect it)
Chapter 3 – Analyzing Volatile Data
- How to understand what you've collected; data reduction/correlation techniques for volatile data
Chapter 4 – Windows Memory Analysis
- Description of \\.\PhysicalMemory, how to dump it, how to parse\analyze it.
*Post-Mortem section
Chapter 5 – Registry Analysis
- An explanation/description of the Windows Registry, how to locate information, etc. This chapter will
have many subsections covering specific areas, such as USB removable storage devices, etc.
Chapter 6 – Log/File Analysis
- Covers descriptions of files maintained by Windows for logging, etc. Covers several directories, explaining why/how they're used.
Chapter 7 – Malware analysis for Administrators
- PE file analysis for Administrators/investigators. This is not a debugger/disassembler training guide.
Chapter 8 – Rootkits and rootkit detection
- Descriptions of rootkits, detection techniques, etc.
right now. Our goal is to have this book on the shelves in late spring 2007.
This book will cover a variety of topics specific to information collection and analysis under live response and post-mortem conditions,
specifically for Windows systems. However, with the tools and techniques presented in this book, the analyst will
not be restricted solely to Windows as the analysis platform (many of the tools I created for this book
have been successfully testing on Windows, Linux, and Mac OS/X platforms).
This book will not cover topics that are not specific to Windows, such as imaging procedures, etc.
I've included a brief, conceptual outline below. My goal is to make this a valuable resource, full of
explanations, examples, and exercises. This will include sample memory captures, and links to images.
Some have suggested including sample system images on DVDs with the book, but in order to do so, I'd have to
include several DVDs. Talking with the publisher, most publishing systems are set up to press a single CD or
DVD for inclusion with the book...including additional media will drive the price of the book out of the range
of the intended audience.
I'd appreciate your input/comments on this, as well.
Some of the comments I've received from other sources include:
- Cover mobile devices: I'd love to...but I'm a one-man shop. I can't afford to purchase
mobile devices just for testing, nor can I afford the software to image such devices.
- Steganography: while not specific to Windows, it is definitely worth mentioning...but I'd
like to get some input from folks as to what needs to be addressed/discussed.
------------------------------------------------
Outline
------------------------------------------------
Chapter 1 – Introduction
- Purpose of the book, intended audience, what the book does/does not address
*Live Response section
Chapter 2 – Collecting Volatile Data
- Address live response, volatile data collection (ie, what to collect, how to collect it)
Chapter 3 – Analyzing Volatile Data
- How to understand what you've collected; data reduction/correlation techniques for volatile data
Chapter 4 – Windows Memory Analysis
- Description of \\.\PhysicalMemory, how to dump it, how to parse\analyze it.
*Post-Mortem section
Chapter 5 – Registry Analysis
- An explanation/description of the Windows Registry, how to locate information, etc. This chapter will
have many subsections covering specific areas, such as USB removable storage devices, etc.
Chapter 6 – Log/File Analysis
- Covers descriptions of files maintained by Windows for logging, etc. Covers several directories, explaining why/how they're used.
Chapter 7 – Malware analysis for Administrators
- PE file analysis for Administrators/investigators. This is not a debugger/disassembler training guide.
Chapter 8 – Rootkits and rootkit detection
- Descriptions of rootkits, detection techniques, etc.
Tuesday, June 20, 2006
RCFG/GMU2006
I'm due to present at the RCFG GMU2006 conference in August, on two topics. I'll be presenting on "Tracking USB Devices on Windows Systems" on Tues and Thu (download the agenda), and on "Windows Memory Analysis" on Wed and Thu - the agenda currently says that the second presentation will be "Windows File Metadata", but I've asked the conference coordinator to change it.
Are you planning to attend? If you're considering it, you should see who else is presenting. Jesse Kornblum will be there (check out one of his Cyberspeak podcast interviews), as will Cynthia Hetherington. Other topics include wireless and Mac forensics, as well as cybercrime profiling, presented by Terry Gudaitis.
See you there?
Are you planning to attend? If you're considering it, you should see who else is presenting. Jesse Kornblum will be there (check out one of his Cyberspeak podcast interviews), as will Cynthia Hetherington. Other topics include wireless and Mac forensics, as well as cybercrime profiling, presented by Terry Gudaitis.
See you there?
Friday, June 16, 2006
Case Issues
Sitting in my own little microcosm, my own little piece of the world, I tend to wonder sometimes if folks run into the same issues I do during a case, and if so, what they do about it...or, if not, what issues they do run into. I know lots of folks, in particular LEOs, don't usually discuss their cases, for fear of revealing too much information about the case...but for those willing to share bits and pieces of problems and solutions, I think that we could all benefit.
So, what are the issues you run into during live response (if you do live response)? Is it being surprised and unprepared? Is it not having the tools you need, either for collecting or analyzing evidence?
How about post-mortem investigations? What issues do you run into with regards to Windows systems?
One of the biggest things is that each case is different somehow...but I can guarantee you that somewhere, someone else has run into the same issues, and possibly come up with a solution.
As always, questions, comments, and concerns are welcome...
So, what are the issues you run into during live response (if you do live response)? Is it being surprised and unprepared? Is it not having the tools you need, either for collecting or analyzing evidence?
How about post-mortem investigations? What issues do you run into with regards to Windows systems?
One of the biggest things is that each case is different somehow...but I can guarantee you that somewhere, someone else has run into the same issues, and possibly come up with a solution.
As always, questions, comments, and concerns are welcome...
Monday, June 12, 2006
Malware update: Rootkit that uses NTFS ADS
Wow, two of my favorite subjects, in one bit of malware...neat! Rustock (a la Symantec's nomenclature) was discovered on 1 June (the Symantec page was updated on 9 June), and reportedly uses rootkit techniques to hide the files and Registry keys it creates.
Section 2 of the technical report says that this malware uses "hidden data streams". Interesting use of terminology, as by default, NTFS alternate data streams are hidden. Take a look at chapter 3 of my book, specifically page 83, for more info on ADSs...but the short version is that since MS does not provide any native tools for Windows for viewing or locating arbitrary ADSs, they are essentially "hidden".
I've located other references to this malware, but they all point back to the Symantec page...
Section 2 of the technical report says that this malware uses "hidden data streams". Interesting use of terminology, as by default, NTFS alternate data streams are hidden. Take a look at chapter 3 of my book, specifically page 83, for more info on ADSs...but the short version is that since MS does not provide any native tools for Windows for viewing or locating arbitrary ADSs, they are essentially "hidden".
I've located other references to this malware, but they all point back to the Symantec page...
I need your help...
...with two things, both with respect to the FRUC/FSPC.
The first thing I need your help with is based on a comment/request I received recently regarding launching the FSPC. Sometimes you may need to walk away from your forensics server system and you will want to launch the FSPC when you're ready, so having something accessible via a web browser might be useful. So what I'm looking for is someone who can put together some PHP or something that will allow you to not only launch the FSPC via a browser, but to shut it down when you're done. This should require authentication, and allow for all of the available switches to be set when launching the server component, and run on popular web servers (IIS 5/6, Apache, etc.). If you want to discuss requirements, or need some information, or need me to make changes/modifications to the FSPC, email me.
What I'd like to do is include several of the working submissions in my next book (I'm currently talking to a publisher), and for each submission that I include, provide the author with a free copy of my next book once it's published. The only things I would ask are that the submissions are fully documented, and there are no weird licensing issues.
The second thing I'd like your help with is circulating INI files. If you've put together an INI file that you use with the FRUC, and are willing to share it, please do so...email it to me, post a link, or whatever works for you.
The first thing I need your help with is based on a comment/request I received recently regarding launching the FSPC. Sometimes you may need to walk away from your forensics server system and you will want to launch the FSPC when you're ready, so having something accessible via a web browser might be useful. So what I'm looking for is someone who can put together some PHP or something that will allow you to not only launch the FSPC via a browser, but to shut it down when you're done. This should require authentication, and allow for all of the available switches to be set when launching the server component, and run on popular web servers (IIS 5/6, Apache, etc.). If you want to discuss requirements, or need some information, or need me to make changes/modifications to the FSPC, email me.
What I'd like to do is include several of the working submissions in my next book (I'm currently talking to a publisher), and for each submission that I include, provide the author with a free copy of my next book once it's published. The only things I would ask are that the submissions are fully documented, and there are no weird licensing issues.
The second thing I'd like your help with is circulating INI files. If you've put together an INI file that you use with the FRUC, and are willing to share it, please do so...email it to me, post a link, or whatever works for you.
FRUC and FSPC Cyberspeak Interview
The latest Cyberspeak podcast includes my interview regarding the latest version of the Forensic Server Project components. The interview was intended to be a "go-by" so listeners could follow along while playing with the tools.
If you've never listened to the Cyberspeak podcasts, give it a shot...very entertaining and very informative. Ovie and Bret do a fantastic job with the podcasts. If you enjoy the podcasts (or don't) or find something interesting, be sure to leave a comment.
If you've never listened to the Cyberspeak podcasts, give it a shot...very entertaining and very informative. Ovie and Bret do a fantastic job with the podcasts. If you enjoy the podcasts (or don't) or find something interesting, be sure to leave a comment.
Friday, June 09, 2006
Setting up the FRUC INI file
Now that the Forensic Server Project has been posted, I should take a moment to post something specifically about the First Responder Utility and the INI file used to configure it.
The First Responder Utility , or FRUC (the "C" stands for "command line"), is intended to make data collection from systems more efficient. We accomplish this in part by minimizing the interaction that the first responder has with the system. Have you ever tried typing the same 5 commands over and over again? How about at 2:30am, when you've already been up for almost 24 hrs, and you're under pressure to get many more machines done? As you can well imagine, this can lead to mistakes, which can have disasterous results. So, why not sit down ahead of time, when you have the time and you're not tired, and decide what tools you want to run? Then, put those tools in the order you want to run them. That way, the tools you want to run get run for you, and are essentially self-documenting (more on that later).
I included a sample INI file with the FRUC archive, so you can follow along looking at that while I go through the components of the file. The INI file is a standard Windows ini file and consists of four sections:
Configuration
This section allows you to designate certain settings for the FRUC, specifically the server to connect to and the port. These settings are overridden by whatever you enter at the command line.
Commands
This section is very important. This is where you enter the commands you want to run on the system, in the order you want to run them. Each of the tools you want to run must be in the same directory (usually on a CD) as the FRUC itself. The syntax of the lines containing the commands is as follows:
I will be releasing tools that you can use with the FRUC, as well as a list of tools/URLs that I would recommend. My current list of tools is available in chapter 5 of my book.
Registry Values
This section allows you to tell the FRUC which Registry values you're interested in. For example, you can use the Registry Reference spreadsheet posted on the SourceForge site to list specific Registry values of interest, and the FRUC will retrieve the data associated with those values. Please note the format used: a number designating the order of collection, and equals sign (=), the Registry key path (the hive can be abbreviated), a semi-colon, and the value name.
Registry Keys
This section allows you to designate the Registry keys that you would like to collect value names and data from. For example, you can put a reference to the ubiquitious Run key here, for both the HKLM and HKCU hives (using the correct path, of course). Whichever key you list, the FRUC will locate that key, and return the value names within that key and their data. The syntax for this section is simply a number designating the order, an equals sign, and the path to the key of interest. As with the Registry values, the hive can be abbreviated.
Note that throughout the INI file, comments are preceeded by semi-colons (ie, lines that begin with a semi-colon are ignored).
That's it. The INI file is pretty much just a script that tells the FRUC what to do, and in what order. The neat thing is that you can create and use multiple INI files, and even run an INI file from an alternate location...as long as the tools are on the CD/DVD along with the FRUC, you're golden.
The First Responder Utility , or FRUC (the "C" stands for "command line"), is intended to make data collection from systems more efficient. We accomplish this in part by minimizing the interaction that the first responder has with the system. Have you ever tried typing the same 5 commands over and over again? How about at 2:30am, when you've already been up for almost 24 hrs, and you're under pressure to get many more machines done? As you can well imagine, this can lead to mistakes, which can have disasterous results. So, why not sit down ahead of time, when you have the time and you're not tired, and decide what tools you want to run? Then, put those tools in the order you want to run them. That way, the tools you want to run get run for you, and are essentially self-documenting (more on that later).
I included a sample INI file with the FRUC archive, so you can follow along looking at that while I go through the components of the file. The INI file is a standard Windows ini file and consists of four sections:
Configuration
This section allows you to designate certain settings for the FRUC, specifically the server to connect to and the port. These settings are overridden by whatever you enter at the command line.
Commands
This section is very important. This is where you enter the commands you want to run on the system, in the order you want to run them. Each of the tools you want to run must be in the same directory (usually on a CD) as the FRUC itself. The syntax of the lines containing the commands is as follows:
- A number to designate the order you want to run the commands. Personally, I like to go sequentially, because its just easier to read
- An equals (=) sign
- The command line you want to run
- A double-colon (::) delimiter - this is important, as it separates the command you want to run from the file that will be created on the server to hold the output of the command. I ended up choosing a double-colon because tools like psloglist allow you to choose a delimiter such a semi-colon or even a colon as a delimiter for the output, and that would confuse the FRUC. Rather than using complicated logic to sort it out, I opted for something simpler.
- The name of the file you want the output to be placed in on the server. The FRUC will tell the FSPC to create a file based on this name, prepended by the system name. So, when I run the FRUC on my home system for testing, all of the files are prepended with "ENDER".
I will be releasing tools that you can use with the FRUC, as well as a list of tools/URLs that I would recommend. My current list of tools is available in chapter 5 of my book.
Registry Values
This section allows you to tell the FRUC which Registry values you're interested in. For example, you can use the Registry Reference spreadsheet posted on the SourceForge site to list specific Registry values of interest, and the FRUC will retrieve the data associated with those values. Please note the format used: a number designating the order of collection, and equals sign (=), the Registry key path (the hive can be abbreviated), a semi-colon, and the value name.
Registry Keys
This section allows you to designate the Registry keys that you would like to collect value names and data from. For example, you can put a reference to the ubiquitious Run key here, for both the HKLM and HKCU hives (using the correct path, of course). Whichever key you list, the FRUC will locate that key, and return the value names within that key and their data. The syntax for this section is simply a number designating the order, an equals sign, and the path to the key of interest. As with the Registry values, the hive can be abbreviated.
Note that throughout the INI file, comments are preceeded by semi-colons (ie, lines that begin with a semi-colon are ignored).
That's it. The INI file is pretty much just a script that tells the FRUC what to do, and in what order. The neat thing is that you can create and use multiple INI files, and even run an INI file from an alternate location...as long as the tools are on the CD/DVD along with the FRUC, you're golden.
Thursday, June 08, 2006
FSPC and FRUC posted
I've finally uploaded the FRUC v 1.2 (client component of the Forensic Server Project) and the FSPC 1.0c (server component of the Forensic Server Project) to my SourceForge site. These are vastly updated versions over what was included on the CD that accompanied my book.
Now, I'd like to take a moment to explain their use...
FSPC is the server component, which resides on your forensic workstation. This system will be where all of the data you collect is stored and managed, and then eventually analyzed. Getting started, type "fspc" or "fspc -h" at the command prompt and you'll see:
FSPC [-d case dir] [-n case name] [-p port] [-i investigator]
[-l logfile] [-c] [-v] [-h]
Forensic Server Project (CLI) v.1.0c, server component of the
Forensics Server Project
-d case dir....Case directory (default: cases)
-n case name...Name of the current case
-i invest......Investigator's name
-p port........Port to listen on (default: 7070)
-l logfile.....Case logfile (default: case.log)
-v.............Verbose output (more info, good for monitoring
activity)
-c.............Close FSP after CLOSELOG command sent (best used
when collecting data from only one system)
-h.............Help (print this information)
Ex: C:\>fspc -d cases -n testcase -i "H. Carvey"
C:\>fspc -n newcase -p 80
copyright 2006 H. Carvey
Most of what you see listed has default settings, as detailed in the syntax shown above. The easiest way to run the FSPC is using the first example. To see more information at the command prompt, add the "-v" switch.
The "-d", "-n", and "-i" switches are used primarily for case management. The "-d" switch is a subdirectory beneath the directory the FSPC resides in, and is the main holding area for information collected from systems. The "-n" switch is the name of an additional subdirectory where the case-specific files are kept. The "-i" switch is the name of the investigator (if spaces are included in the name, such as "keydet 89", then the name needs to be quotes) which is added to the case log file (denoted by the "-l" switch).
Finally, the "-p" switch tells the FSPC which port to listen on...the default is 7070.
FRUC is the client component, used to collect data from "victim" system. Download the zipped archive, and extract all of the files (2 EXE files and several DLLs) into a directory, add your third party tools, update your INI file (the default is "fruc.ini") appropriately, and then burn everything to a CD (or copy it to a thumb drive). Then you're ready.
Launch the FRUC with the "-h" switch and you'll see...
FRUC v 1.2 [-s server IP] [-p port] [-f ini file] [-h]
First Responder Utility (CLI) v.1.2, data collection utility
of the Forensics Server Project
-s system......IP address of Forensics Server
-p port........Port to connect to on the Forensics Server
-f file........Ini file to use (use other options to
override ini file configuration settings)
-v.............Verbose output (more info, good for monitoring
activity)
-h.............Help (print this information)
Ex: C:\>fruc -s -p -f
copyright 2004-2006 H. Carvey
As you can see from the syntax information, using FRUC is pretty simple. Many of the settings are set as defaults in the INI file (or can be), but those settings can also be overridden by the switches. For example, in the example INI file that ships with the archive, the default server IP address is set (as is the default port), but that can be overridden, as demonstrated by the example command line.
Okay...so here's what happens. FRUC is almost completely automated, minimizing the interaction that the first responder has with the program and the system. Besides efficiency and speed, FRUC also provides a modicum of validation, as commands do not have to be repetitively typed...if you're like me, this can lead to mistakes, forgotten commands, etc. So, basically, FRUC contacts the FSPC with a verb, telling the server what to expect. It then sends the output of the commands that are run to the server, where they are written to the server, hashed, and logged. Yes, the whole thing includes logging! And with timestamps!
The INI file for the FRUC has three main sections; external commands you want to run, specific Registry values you're interested in, and Registry keys that you just want to dump the values from. All this information is collected and shipped off to the FSPC over a socket, without writing to the local hard drive.
Each of these tools is provided as Perl source code, as well as a Windows compiled EXE. This is intended to make the FSP more accessible. Now, some folks have expressed concern about the use of Perl2Exe to "compile" tools such as this for use in an incident response (and potentially computer forensics) environment. If no switches or the "-small" switch are used when compiling the tools, additional modules are included in the resulting EXE and must be extracted to a temp directory before being used. Once your program has completed, the modules/DLLs are then deleted. This activity can be seen using tools like FileMon.
When I compiled FRUC, I used the "-tiny" switch, so that all required modules are "compiled" into DLLs that are separate from the main EXE. I've run FileMon in a few simple tests and found no Writes or Deletes. This help supports the tenet of computer forensics to minimize the impact on the "victim" system. However, I encourage you to run your own validation tests.
Please keep in mind, though, while doing your testing and using the tools in a live response situation, as well, that changes will be made to the system. These changes occur due to how the system and the shell react to programs being run; entries are added to several Registry keys (ie, UserAssist keys in particular), as well as files being added to the Prefetch directory on XP.
Another option is to not compile the tools at all, but instead install Perl on your system with all of the necessary modules, add the scripts, and then copy the entire installation to a CD. I outlined how to do this in my book. Again, though, I wanted to make this framework accessible.
Finally, in the spirit of "we eat our own dog food", I've used these tools (the FRUC is actually an updated version) myself and been very happy with the results. I do need to add an analysis suite, and that's something I'll be working on. Along with that, I'd like to post a more detailed user guide, as well as validation tests and results.
Your comments, questions, input and suggestions are always welcome.
Now, I'd like to take a moment to explain their use...
FSPC is the server component, which resides on your forensic workstation. This system will be where all of the data you collect is stored and managed, and then eventually analyzed. Getting started, type "fspc" or "fspc -h" at the command prompt and you'll see:
FSPC [-d case dir] [-n case name] [-p port] [-i investigator]
[-l logfile] [-c] [-v] [-h]
Forensic Server Project (CLI) v.1.0c, server component of the
Forensics Server Project
-d case dir....Case directory (default: cases)
-n case name...Name of the current case
-i invest......Investigator's name
-p port........Port to listen on (default: 7070)
-l logfile.....Case logfile (default: case.log)
-v.............Verbose output (more info, good for monitoring
activity)
-c.............Close FSP after CLOSELOG command sent (best used
when collecting data from only one system)
-h.............Help (print this information)
Ex: C:\>fspc -d cases -n testcase -i "H. Carvey"
C:\>fspc -n newcase -p 80
copyright 2006 H. Carvey
Most of what you see listed has default settings, as detailed in the syntax shown above. The easiest way to run the FSPC is using the first example. To see more information at the command prompt, add the "-v" switch.
The "-d", "-n", and "-i" switches are used primarily for case management. The "-d" switch is a subdirectory beneath the directory the FSPC resides in, and is the main holding area for information collected from systems. The "-n" switch is the name of an additional subdirectory where the case-specific files are kept. The "-i" switch is the name of the investigator (if spaces are included in the name, such as "keydet 89", then the name needs to be quotes) which is added to the case log file (denoted by the "-l" switch).
Finally, the "-p" switch tells the FSPC which port to listen on...the default is 7070.
FRUC is the client component, used to collect data from "victim" system. Download the zipped archive, and extract all of the files (2 EXE files and several DLLs) into a directory, add your third party tools, update your INI file (the default is "fruc.ini") appropriately, and then burn everything to a CD (or copy it to a thumb drive). Then you're ready.
Launch the FRUC with the "-h" switch and you'll see...
FRUC v 1.2 [-s server IP] [-p port] [-f ini file] [-h]
First Responder Utility (CLI) v.1.2, data collection utility
of the Forensics Server Project
-s system......IP address of Forensics Server
-p port........Port to connect to on the Forensics Server
-f file........Ini file to use (use other options to
override ini file configuration settings)
-v.............Verbose output (more info, good for monitoring
activity)
-h.............Help (print this information)
Ex: C:\>fruc -s -p -f
copyright 2004-2006 H. Carvey
As you can see from the syntax information, using FRUC is pretty simple. Many of the settings are set as defaults in the INI file (or can be), but those settings can also be overridden by the switches. For example, in the example INI file that ships with the archive, the default server IP address is set (as is the default port), but that can be overridden, as demonstrated by the example command line.
Okay...so here's what happens. FRUC is almost completely automated, minimizing the interaction that the first responder has with the program and the system. Besides efficiency and speed, FRUC also provides a modicum of validation, as commands do not have to be repetitively typed...if you're like me, this can lead to mistakes, forgotten commands, etc. So, basically, FRUC contacts the FSPC with a verb, telling the server what to expect. It then sends the output of the commands that are run to the server, where they are written to the server, hashed, and logged. Yes, the whole thing includes logging! And with timestamps!
The INI file for the FRUC has three main sections; external commands you want to run, specific Registry values you're interested in, and Registry keys that you just want to dump the values from. All this information is collected and shipped off to the FSPC over a socket, without writing to the local hard drive.
Each of these tools is provided as Perl source code, as well as a Windows compiled EXE. This is intended to make the FSP more accessible. Now, some folks have expressed concern about the use of Perl2Exe to "compile" tools such as this for use in an incident response (and potentially computer forensics) environment. If no switches or the "-small" switch are used when compiling the tools, additional modules are included in the resulting EXE and must be extracted to a temp directory before being used. Once your program has completed, the modules/DLLs are then deleted. This activity can be seen using tools like FileMon.
When I compiled FRUC, I used the "-tiny" switch, so that all required modules are "compiled" into DLLs that are separate from the main EXE. I've run FileMon in a few simple tests and found no Writes or Deletes. This help supports the tenet of computer forensics to minimize the impact on the "victim" system. However, I encourage you to run your own validation tests.
Please keep in mind, though, while doing your testing and using the tools in a live response situation, as well, that changes will be made to the system. These changes occur due to how the system and the shell react to programs being run; entries are added to several Registry keys (ie, UserAssist keys in particular), as well as files being added to the Prefetch directory on XP.
Another option is to not compile the tools at all, but instead install Perl on your system with all of the necessary modules, add the scripts, and then copy the entire installation to a CD. I outlined how to do this in my book. Again, though, I wanted to make this framework accessible.
Finally, in the spirit of "we eat our own dog food", I've used these tools (the FRUC is actually an updated version) myself and been very happy with the results. I do need to add an analysis suite, and that's something I'll be working on. Along with that, I'd like to post a more detailed user guide, as well as validation tests and results.
Your comments, questions, input and suggestions are always welcome.
Saturday, May 27, 2006
What's in YOUR wallet?
By "wallet", I'm referring to your CD wallet, or more specifically, your toolkit.
What tools do you use during Windows IR/CF activities?
What are your favorite/most relied upon tools for Windows Incident Response?
What tools to you use, in addition to the popular forensic suites (FTK, EnCase, PyFlag, ProDiscover, TSK, etc.) when analyzing a Windows system image, regardless of platform?
Finally, what tools would you like to see? What are some of the tools that you'd like to have that you just can't find? What are you trying to accomplish, specific to Windows IR/CF analysis, that you simply cannot find a tool to help you?
Think of this as a Windows IR/CF Top 75 Tools list. I'll accumulate responses here, and any I receive via email, and post the list.
What tools do you use during Windows IR/CF activities?
What are your favorite/most relied upon tools for Windows Incident Response?
What tools to you use, in addition to the popular forensic suites (FTK, EnCase, PyFlag, ProDiscover, TSK, etc.) when analyzing a Windows system image, regardless of platform?
Finally, what tools would you like to see? What are some of the tools that you'd like to have that you just can't find? What are you trying to accomplish, specific to Windows IR/CF analysis, that you simply cannot find a tool to help you?
Think of this as a Windows IR/CF Top 75 Tools list. I'll accumulate responses here, and any I receive via email, and post the list.
SF updates info
Folks, I just wanted to point out a couple of things regarding the tools I have posted, and will be posting, to the SF site.
First off, I still have some tools up on CPAN that I thought may be of interest. I'll have to bring those down, and include them in some capacity within the SF toolset. I have to say that I've found the File::ReadEvt module and associated scripts to be pretty handy, particularly the evtstats.pl script. It's pretty handy for pulling statistics on the event log records out of the .evt file quickly. If you're looking for certain types of statistics, it's easy to modify, as well. I also used the File::ReadPE module recently to examine the headers of several PE files.
The second thing I wanted to mention is updates to the tools. Every now and then I get requests to modify the functionality, either b/c the tool didn't respond the way the user expected, or b/c of something I didn't anticipate in my development and testing. If the tool and most users would greatly benefit from the update and it isn't a major rework/redesign of the tool, I'll update it. Requests for updates that are a bit out there usually take a bit longer.
If you have any questions regarding the use of the tools, or would like to see updates to the functionality...how the output is formatted, what's listed in the output, etc...please don't hesitate to let me know. Sometimes the thing that you think is little and doesn't matter will end up being extremely useful to someone else. Also, the feedback is important for providing useful tools to the community.
First off, I still have some tools up on CPAN that I thought may be of interest. I'll have to bring those down, and include them in some capacity within the SF toolset. I have to say that I've found the File::ReadEvt module and associated scripts to be pretty handy, particularly the evtstats.pl script. It's pretty handy for pulling statistics on the event log records out of the .evt file quickly. If you're looking for certain types of statistics, it's easy to modify, as well. I also used the File::ReadPE module recently to examine the headers of several PE files.
The second thing I wanted to mention is updates to the tools. Every now and then I get requests to modify the functionality, either b/c the tool didn't respond the way the user expected, or b/c of something I didn't anticipate in my development and testing. If the tool and most users would greatly benefit from the update and it isn't a major rework/redesign of the tool, I'll update it. Requests for updates that are a bit out there usually take a bit longer.
If you have any questions regarding the use of the tools, or would like to see updates to the functionality...how the output is formatted, what's listed in the output, etc...please don't hesitate to let me know. Sometimes the thing that you think is little and doesn't matter will end up being extremely useful to someone else. Also, the feedback is important for providing useful tools to the community.
Thursday, May 25, 2006
Forensic Analysis Issues
I ran across something recently that I had researched before, and hadn't thought a lot about, so I thought I'd blog about it.
You're analyzing the image of a system that turns out to be a Windows XP system. You notice that several files of interest are referenced in the RecentDocs Registry key for a particular user, however, searches of both the "active" file system and the deleted files turn up nothing. You've dumped the contents of the UserAssist keys for that user and you don't see anything that would indicate that the user ran a privacy tool. Looking at the contents of the Prefetch directory, you find entries for the defrag tool.
Checking the dates on Registry keys (application/system MRU lists, etc.) and files (MAC times, as well as the dates maintained within the Prefetch files themselves) you see that the Recycle Bin was emptied after the files were opened/viewed, and the defrag tool was run after the Recycle Bin was emptied...not immediately after, but within a day or two.
So...what's going on? Well, it seems that part of the user "eXPerience" that is XP includes the Prefetch functionality, ostensibly to speed up the loading/launching of frequently used applications. Where does the defrag come in, you ask? Read this. Right beneath figure 1 is an explanation of the defrag activity, and while it isn't a full defrag, it happens, and could cause deleted files that you would normally expect to find to be overwritten.
This is definitely something to keep in mind during your analysis, as well as something to look for/document.
What are some of the issues that you've run into?
You're analyzing the image of a system that turns out to be a Windows XP system. You notice that several files of interest are referenced in the RecentDocs Registry key for a particular user, however, searches of both the "active" file system and the deleted files turn up nothing. You've dumped the contents of the UserAssist keys for that user and you don't see anything that would indicate that the user ran a privacy tool. Looking at the contents of the Prefetch directory, you find entries for the defrag tool.
Checking the dates on Registry keys (application/system MRU lists, etc.) and files (MAC times, as well as the dates maintained within the Prefetch files themselves) you see that the Recycle Bin was emptied after the files were opened/viewed, and the defrag tool was run after the Recycle Bin was emptied...not immediately after, but within a day or two.
So...what's going on? Well, it seems that part of the user "eXPerience" that is XP includes the Prefetch functionality, ostensibly to speed up the loading/launching of frequently used applications. Where does the defrag come in, you ask? Read this. Right beneath figure 1 is an explanation of the defrag activity, and while it isn't a full defrag, it happens, and could cause deleted files that you would normally expect to find to be overwritten.
This is definitely something to keep in mind during your analysis, as well as something to look for/document.
What are some of the issues that you've run into?
Tuesday, May 23, 2006
Sourceforge updates
Okay, I know I haven't blogged in a while, but work's been busy.
On a positive note, I updated the contents of the WindowsIR Sourceforge site tonight, revamping the structure of the project itself. I've uploaded the lsproc, lspd, lspm, and RAMDump tools. If you remember, RAMDump is a GUI wrapper around George Garner's dd.exe, allowing the user to dump the contents of physical memory from a Windows 2000/XP system.
The rest of the tools are specific to Windows 2000 systems. That is to say, lsproc will parse through a dd.exe-style dump of physical memory from a Windows 2000 system and locate EPROCESS blocks. Lspd will extract process details based on the output of lsproc, and lspm will dump the memory used by a process based on the output of lsproc. Each of these three packages contains Perl source code, a Windows EXE compiled using Perl2Exe, and a required DLL.
Again...these three utilities are in the Windows2000 release because they work on memory dumps from Windows 2000 systems.
I will be posting other tools on this site over time, ranging from live response/IR tools to utilities meant for CF analysis.
Besides work (which I won't be posting about) I've been doing a lot of thinking with regards to live response, and I will be posting my thoughts.
Addendum: I uploaded the Offline Registry Parser, regp.pl, to the SF site, as well. The archive contains the Perl code, a Windows EXE compiled with Perl2Exe (you can use PAR, as well), and a required DLL.
On a positive note, I updated the contents of the WindowsIR Sourceforge site tonight, revamping the structure of the project itself. I've uploaded the lsproc, lspd, lspm, and RAMDump tools. If you remember, RAMDump is a GUI wrapper around George Garner's dd.exe, allowing the user to dump the contents of physical memory from a Windows 2000/XP system.
The rest of the tools are specific to Windows 2000 systems. That is to say, lsproc will parse through a dd.exe-style dump of physical memory from a Windows 2000 system and locate EPROCESS blocks. Lspd will extract process details based on the output of lsproc, and lspm will dump the memory used by a process based on the output of lsproc. Each of these three packages contains Perl source code, a Windows EXE compiled using Perl2Exe, and a required DLL.
Again...these three utilities are in the Windows2000 release because they work on memory dumps from Windows 2000 systems.
I will be posting other tools on this site over time, ranging from live response/IR tools to utilities meant for CF analysis.
Besides work (which I won't be posting about) I've been doing a lot of thinking with regards to live response, and I will be posting my thoughts.
Addendum: I uploaded the Offline Registry Parser, regp.pl, to the SF site, as well. The archive contains the Perl code, a Windows EXE compiled with Perl2Exe (you can use PAR, as well), and a required DLL.
Subscribe to:
Posts (Atom)