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.
Friday, August 11, 2006
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.
Saturday, April 29, 2006
Future Trends
Would I be remiss if I were to NOT discuss future trends in computer forensics?
Every now and then you see the curious posting questions about future trends and challenges in the computer forensics field, and invariably, the responses include something do to with the increase in the density of storage media. For example, information was recently leaked from Seagate regarding 750GB drives. But is this really a "future trend"?
Think about it. Not long ago, those tasked with performing computer forensics were facing 100 or 200 MB drives...yes, "megabyte", with an M. Even today, larger capacity with smaller form facter is just something we deal with. So...if this is something we've been dealing with from the beginning, does it really constitute a "future trend"?
Rather than sitting back and being driven by the course of events, IMHO, forensic analysts need to be the driving force in the future trends within the community. Specifically, there needs to be a greater level of education. I know that this is very easy for me to say, sitting here at oh-dark thirty, blogging away. However, I sincerely believe that this is the case. Let me provide some background and perhaps illuminate what I'm referring to...
Computer systems are becoming ever-more sophisticated. The bad guys are, too. Things that used to be done for fun are now being done for profit, or revenge. The face of computer crime itself is changing. While computer forensic analysis techniques are changing, they aren't being updated at anywhere near the same rate as the techniques used by those who end up becoming the focus of an investigation. There are still many folks out there, tasked with performing computer forensics, who firmly believe (through their initial training) that a computer forensics investigation begins with unplugging the affected system, securing it, and imaging the hard drive.
But what happens when you do this? Think of the massive amounts of data that are lost when power is removed from a system. Think of fraud or sexual harassment investigation, in which data was stored on the clipboard. Think about the malware that only exists in memory. Personally, I'm reminded of a case from 2000 in which someone else determined that the SubSeven Trojan was on a system via a file search...after power had been removed from the system. Sure, the MAC times on the files would give the investigator some information, but no one could say for sure if (a) the backdoor was running when the system was unplugged, or (b) if a bad guy were connected to the backdoor, or (c) if the "suspect" was using connecting to another infected system somewhere on our corporate network.
One of the main techniques still in use today by forensic examiners is the keyword search. Don't get me wrong...there's nothing wrong with this technique...in fact, it's proven to be quite useful. However, it should be a tool, not the tool, in the investigator's toolbox. Keyword searches across file systems and sectors can be fruitful, but not everything is stored on a system in ASCII or Unicode. Take a look at the Windows Registry...many important pieces of information are stored in binary format, or via Rot-13 "encryption". Both of these will cause simple keyword searches to fail.
Another thing to think about is disk encryption software. Unplug the power and what are you left with? Okay, now think about it this way...if you acquired the system live, what would you be left with?
Lets get right to the point...perhaps there really is no "future trend" in computer forensics, but rather, we're going to simply be revisiting the same old trends that we've faced in the past. IMHO, I don't see increased storage density as a new issue...it's something we've had to deal with for a while. HOW we deal with it is what's going to change the face of forensic computing...greater education and training will drive forensic investigators to include live response techniques (live acquisition, volatile data collection and analysis, etc) in their "bag of tricks", AND allow them to be able to testify about these techniques and data in court.
One final note...there are those who say that they would never perform a live investigation until there's case law and court decisions supporting the use of these techniques. Okay...we're back to the chicken or the egg argument. My response is to say that rather than waiting for the courts to make a change, the investigators need to start moving in that direction first, getting training and knowledge to not only perform live response but to also be able to present and explain that information in court. After all, many of us are already performing live response investigations, as well as Registry analysis, as a matter of course.
Thoughts?
Every now and then you see the curious posting questions about future trends and challenges in the computer forensics field, and invariably, the responses include something do to with the increase in the density of storage media. For example, information was recently leaked from Seagate regarding 750GB drives. But is this really a "future trend"?
Think about it. Not long ago, those tasked with performing computer forensics were facing 100 or 200 MB drives...yes, "megabyte", with an M. Even today, larger capacity with smaller form facter is just something we deal with. So...if this is something we've been dealing with from the beginning, does it really constitute a "future trend"?
Rather than sitting back and being driven by the course of events, IMHO, forensic analysts need to be the driving force in the future trends within the community. Specifically, there needs to be a greater level of education. I know that this is very easy for me to say, sitting here at oh-dark thirty, blogging away. However, I sincerely believe that this is the case. Let me provide some background and perhaps illuminate what I'm referring to...
Computer systems are becoming ever-more sophisticated. The bad guys are, too. Things that used to be done for fun are now being done for profit, or revenge. The face of computer crime itself is changing. While computer forensic analysis techniques are changing, they aren't being updated at anywhere near the same rate as the techniques used by those who end up becoming the focus of an investigation. There are still many folks out there, tasked with performing computer forensics, who firmly believe (through their initial training) that a computer forensics investigation begins with unplugging the affected system, securing it, and imaging the hard drive.
But what happens when you do this? Think of the massive amounts of data that are lost when power is removed from a system. Think of fraud or sexual harassment investigation, in which data was stored on the clipboard. Think about the malware that only exists in memory. Personally, I'm reminded of a case from 2000 in which someone else determined that the SubSeven Trojan was on a system via a file search...after power had been removed from the system. Sure, the MAC times on the files would give the investigator some information, but no one could say for sure if (a) the backdoor was running when the system was unplugged, or (b) if a bad guy were connected to the backdoor, or (c) if the "suspect" was using connecting to another infected system somewhere on our corporate network.
One of the main techniques still in use today by forensic examiners is the keyword search. Don't get me wrong...there's nothing wrong with this technique...in fact, it's proven to be quite useful. However, it should be a tool, not the tool, in the investigator's toolbox. Keyword searches across file systems and sectors can be fruitful, but not everything is stored on a system in ASCII or Unicode. Take a look at the Windows Registry...many important pieces of information are stored in binary format, or via Rot-13 "encryption". Both of these will cause simple keyword searches to fail.
Another thing to think about is disk encryption software. Unplug the power and what are you left with? Okay, now think about it this way...if you acquired the system live, what would you be left with?
Lets get right to the point...perhaps there really is no "future trend" in computer forensics, but rather, we're going to simply be revisiting the same old trends that we've faced in the past. IMHO, I don't see increased storage density as a new issue...it's something we've had to deal with for a while. HOW we deal with it is what's going to change the face of forensic computing...greater education and training will drive forensic investigators to include live response techniques (live acquisition, volatile data collection and analysis, etc) in their "bag of tricks", AND allow them to be able to testify about these techniques and data in court.
One final note...there are those who say that they would never perform a live investigation until there's case law and court decisions supporting the use of these techniques. Okay...we're back to the chicken or the egg argument. My response is to say that rather than waiting for the courts to make a change, the investigators need to start moving in that direction first, getting training and knowledge to not only perform live response but to also be able to present and explain that information in court. After all, many of us are already performing live response investigations, as well as Registry analysis, as a matter of course.
Thoughts?
Thursday, April 20, 2006
New ProScripts
The user forums at TechPathways were recently revamped and updated (WRT functionality). In the process, previous threads were lost. I've added a couple of ProScripts that you may find helpful...
One of the scripts parses through the Registry (the script makes the assumption that there is only one Windows image in the project, and only one Registry) and pulls out user SIDs. From there, it goes through the HKEY_USERS hive and parses out the UserAssist keys...you know, the ones with the values that are ROT-13 "encrypted". If possible, the script also pulls out timestamps from the value data. Here's an example of the output when I ran the script against the hacking case image:
UEME_RUNPATH:C:\Program Files\Cain\Cain.exe --> Fri Aug 27 15:33:02 2004
UEME_RUNPATH:C:\Program Files\Whois\whois.exe --> Thu Aug 26 15:13:57 2004
UEME_RUNPATH:C:\WINDOWS\System32\telnet.exe --> Thu Aug 26 15:05:15 2004
UEME_RUNPATH:C:\Program Files\Network Stumbler\NetStumbler.exe --> Fri Aug 27 15:12:35 2004
UEME_RUNCPL:"C:\WINDOWS\System32\appwiz.cpl",Add or Remove Programs --> Fri Aug 27 15:14:44 2004
UEME_RUNPATH:C:\Documents and Settings\Mr. Evil\Desktop\WinPcap_3_01_a.exe --> Fri Aug 27 15:15:08 2004
UEME_RUNPATH:C:\Documents and Settings\Mr. Evil\Desktop\ethereal-setup-0.10.6.exe --> Fri Aug 27 15:28:36 2004
UEME_RUNPATH:C:\Program Files\Ethereal\ethereal.exe --> Fri Aug 27 15:34:54 2004
So why is this important? Well, for one, it ties activity such as running executables to a specific user. This info is pulled right out of the NTUSER.DAT file, and is visible in ProDiscover under the HKEY_USERS hive.
This information can be correlated to the contents of the Prefetch directory (on XP systems, which perform application prefetching by default). I wrote a ProScript that would run through the Prefetch directory and list the .pf files. For each one, it retrieves and displays the last run timestamp and run count from the contents of the file. See the following excerpt from the output of the ProScript:
Name : CAIN.EXE-23D61279.pf
Last Run : Fri Aug 27 15:33:03 2004
Run Count : 2
Name : NETSTUMBLER.EXE-0BFEE568.pf
Last Run : Fri Aug 27 15:12:35 2004
Run Count : 1
Name : TELNET.EXE-24182D40.pf
Last Run : Thu Aug 26 15:05:15 2004
Run Count : 1
Name : WINPCAP_3_01_A.EXE-1E3EDEDC.pf
Last Run : Fri Aug 27 15:15:08 2004
Run Count : 1
Notice how the "Last Run" times from the .pf file correlate with the same time from the UserAssist key? So now, if we find an interesting .pf file in the Prefetch directory, we have a way to correlate it and tie it to a particular user. Of course, we can also use the Security Event Log for further correlation...if it is configured to audit logins.
Note that the Prefetch ProScript requires ProDiscover 4.642 (which should now be available) or greater. This is due to updates in one of the APIs.
Yet another ProScript copies the Event Log files out of the Windows\system32\config directory so you can use File::ReadEVT to pull out the data, collect statistics, etc. And I reposted the ProScript that parses V and F values out of the SAM file to determine user information and group membership.
One of the scripts parses through the Registry (the script makes the assumption that there is only one Windows image in the project, and only one Registry) and pulls out user SIDs. From there, it goes through the HKEY_USERS hive and parses out the UserAssist keys...you know, the ones with the values that are ROT-13 "encrypted". If possible, the script also pulls out timestamps from the value data. Here's an example of the output when I ran the script against the hacking case image:
UEME_RUNPATH:C:\Program Files\Cain\Cain.exe --> Fri Aug 27 15:33:02 2004
UEME_RUNPATH:C:\Program Files\Whois\whois.exe --> Thu Aug 26 15:13:57 2004
UEME_RUNPATH:C:\WINDOWS\System32\telnet.exe --> Thu Aug 26 15:05:15 2004
UEME_RUNPATH:C:\Program Files\Network Stumbler\NetStumbler.exe --> Fri Aug 27 15:12:35 2004
UEME_RUNCPL:"C:\WINDOWS\System32\appwiz.cpl",Add or Remove Programs --> Fri Aug 27 15:14:44 2004
UEME_RUNPATH:C:\Documents and Settings\Mr. Evil\Desktop\WinPcap_3_01_a.exe --> Fri Aug 27 15:15:08 2004
UEME_RUNPATH:C:\Documents and Settings\Mr. Evil\Desktop\ethereal-setup-0.10.6.exe --> Fri Aug 27 15:28:36 2004
UEME_RUNPATH:C:\Program Files\Ethereal\ethereal.exe --> Fri Aug 27 15:34:54 2004
So why is this important? Well, for one, it ties activity such as running executables to a specific user. This info is pulled right out of the NTUSER.DAT file, and is visible in ProDiscover under the HKEY_USERS hive.
This information can be correlated to the contents of the Prefetch directory (on XP systems, which perform application prefetching by default). I wrote a ProScript that would run through the Prefetch directory and list the .pf files. For each one, it retrieves and displays the last run timestamp and run count from the contents of the file. See the following excerpt from the output of the ProScript:
Name : CAIN.EXE-23D61279.pf
Last Run : Fri Aug 27 15:33:03 2004
Run Count : 2
Name : NETSTUMBLER.EXE-0BFEE568.pf
Last Run : Fri Aug 27 15:12:35 2004
Run Count : 1
Name : TELNET.EXE-24182D40.pf
Last Run : Thu Aug 26 15:05:15 2004
Run Count : 1
Name : WINPCAP_3_01_A.EXE-1E3EDEDC.pf
Last Run : Fri Aug 27 15:15:08 2004
Run Count : 1
Notice how the "Last Run" times from the .pf file correlate with the same time from the UserAssist key? So now, if we find an interesting .pf file in the Prefetch directory, we have a way to correlate it and tie it to a particular user. Of course, we can also use the Security Event Log for further correlation...if it is configured to audit logins.
Note that the Prefetch ProScript requires ProDiscover 4.642 (which should now be available) or greater. This is due to updates in one of the APIs.
Yet another ProScript copies the Event Log files out of the Windows\system32\config directory so you can use File::ReadEVT to pull out the data, collect statistics, etc. And I reposted the ProScript that parses V and F values out of the SAM file to determine user information and group membership.
Saturday, April 15, 2006
Reassembling an image file from a memory dump
Andreas Schuster posted a tutorial on his blog for reassembling the executable image of a process from a dump of physical memory a bit ago. As I've already got Perl code for parsing PE headers, why not automate the process?
So far, I've completed the first step in reassembling the image...parsing the PE headers. To do this, locate the PEB for the process (from the information located in the EPROCESS block...use lsproc and then lspd from my SourceForge site to get the necessary information) and from there, get the value for the ImageBaseAddress (a DWORD located at offset 0x08 within the PEB). Convert that virtual address to a physical offset within the dump file (done by the code) and, if the physical offset is "present", read in the 4K page located at that address. Now, the PE header isn't usually 4K (4096 bytes) in size, so most of the page will be zeros. However, we can parse out the information we need. For example, I ran some tests using the process named "nc.exe"...
The initial information looked good:
DOS header located.
e_lfanew = 128 (0x00000080)
NT Header = 0x4550
The "DOS Header" is "MZ", and the value for e_lfanew is something that we're going to use for several calculations. The NT Header is valid, as it translates to "PE". Next, we read the Image File Header and find that there are 4 sections, and the image has the following characteristics:
IMAGE_FILE_EXECUTABLE_IMAGE
IMAGE_FILE_LOCAL_SYMS_STRIPPED
IMAGE_FILE_RELOCS_STRIPPED
IMAGE_FILE_LINE_NUMS_STRIPPED
IMAGE_FILE_32BIT_MACHINE
From the Image Optional Header, we get:
Opt Header Magic = 0x10b
Subsystem : IMAGE_SUBSYSTEM_WINDOWS_CUI
Entry Pt Addr : 0x00004c00
Notice the value for the entry point address. This will be important later, particularly when we perform detailed analysis of the image file itself. Tools such as PeID use entry point analysis to determine things such as packers and encryption used on obfuscated binaries (mostly malware). If you know what you're doing, you can get a lot of information by determining not only the location of the entry point, but also the contents (first 100 bytes or so) of the entry point.
Moving on, we pull out the Image Data Directories:
Data Directory RVA Size
-------------- --- ----
ResourceTable 0x00000000 0x00000000
DebugTable 0x00000000 0x00000000
BaseRelocTable 0x00000000 0x00000000
DelayImportDesc 0x00000000 0x00000000
TLSTable 0x00000000 0x00000000
GlobalPtrReg 0x00000000 0x00000000
ArchSpecific 0x00000000 0x00000000
CLIHeader 0x00000000 0x00000000
LoadConfigTable 0x00000000 0x00000000
ExceptionTable 0x00000000 0x00000000
ImportTable 0x00012000 0x0000003c
unused 0x00000000 0x00000000
BoundImportTable 0x00000000 0x00000000
ExportTable 0x00000000 0x00000000
CertificateTable 0x00000000 0x00000000
IAT 0x000121a0 0x00000164
We see from this that the only data directories are the Import (Name) Table and the Import Address Table (IAT). Once we reassemble the image, we will be able to use this information to determine which DLLs the image accesses, and which functions from those DLLs it imports.
Finally, we look at the Image Section Headers:
Name Virt Sz Virt Addr rData Ofs rData Sz Char
---- ------- --------- --------- -------- ----
.text 0x00009770 0x00001000 0x00000400 0x00009800 0x60000020
.data 0x00005244 0x0000c000 0x0000a200 0x00003e00 0xc0000040
.idata 0x0000075c 0x00012000 0x0000e000 0x00000800 0xc0000040
.rdata 0x00000417 0x0000b000 0x00009c00 0x00000600 0x40000040
Remember, from the Image File Header, we found that there were 4 sections. Now we have more detailed information about those sections.
Using the code I have now, I took a look at the same process that Andreas used in his tutorial...dd.exe, PID 284. I extracted the same information he listed, down to the section headers. Now, to begin automatically reassembling the image, we simply need to follow the advice given by Andreas; specifically, given the information we've extracted from the PE header, go back into the physical dump file, extract those pages and reassemble them in order. The test will then be not only to view the complete PE header information, Import Table and resources of the file using something like File::ReadPE (or use tools such as pedump or PEView), but to also actually launch the image.
So far, I've completed the first step in reassembling the image...parsing the PE headers. To do this, locate the PEB for the process (from the information located in the EPROCESS block...use lsproc and then lspd from my SourceForge site to get the necessary information) and from there, get the value for the ImageBaseAddress (a DWORD located at offset 0x08 within the PEB). Convert that virtual address to a physical offset within the dump file (done by the code) and, if the physical offset is "present", read in the 4K page located at that address. Now, the PE header isn't usually 4K (4096 bytes) in size, so most of the page will be zeros. However, we can parse out the information we need. For example, I ran some tests using the process named "nc.exe"...
The initial information looked good:
DOS header located.
e_lfanew = 128 (0x00000080)
NT Header = 0x4550
The "DOS Header" is "MZ", and the value for e_lfanew is something that we're going to use for several calculations. The NT Header is valid, as it translates to "PE". Next, we read the Image File Header and find that there are 4 sections, and the image has the following characteristics:
IMAGE_FILE_EXECUTABLE_IMAGE
IMAGE_FILE_LOCAL_SYMS_STRIPPED
IMAGE_FILE_RELOCS_STRIPPED
IMAGE_FILE_LINE_NUMS_STRIPPED
IMAGE_FILE_32BIT_MACHINE
From the Image Optional Header, we get:
Opt Header Magic = 0x10b
Subsystem : IMAGE_SUBSYSTEM_WINDOWS_CUI
Entry Pt Addr : 0x00004c00
Notice the value for the entry point address. This will be important later, particularly when we perform detailed analysis of the image file itself. Tools such as PeID use entry point analysis to determine things such as packers and encryption used on obfuscated binaries (mostly malware). If you know what you're doing, you can get a lot of information by determining not only the location of the entry point, but also the contents (first 100 bytes or so) of the entry point.
Moving on, we pull out the Image Data Directories:
Data Directory RVA Size
-------------- --- ----
ResourceTable 0x00000000 0x00000000
DebugTable 0x00000000 0x00000000
BaseRelocTable 0x00000000 0x00000000
DelayImportDesc 0x00000000 0x00000000
TLSTable 0x00000000 0x00000000
GlobalPtrReg 0x00000000 0x00000000
ArchSpecific 0x00000000 0x00000000
CLIHeader 0x00000000 0x00000000
LoadConfigTable 0x00000000 0x00000000
ExceptionTable 0x00000000 0x00000000
ImportTable 0x00012000 0x0000003c
unused 0x00000000 0x00000000
BoundImportTable 0x00000000 0x00000000
ExportTable 0x00000000 0x00000000
CertificateTable 0x00000000 0x00000000
IAT 0x000121a0 0x00000164
We see from this that the only data directories are the Import (Name) Table and the Import Address Table (IAT). Once we reassemble the image, we will be able to use this information to determine which DLLs the image accesses, and which functions from those DLLs it imports.
Finally, we look at the Image Section Headers:
Name Virt Sz Virt Addr rData Ofs rData Sz Char
---- ------- --------- --------- -------- ----
.text 0x00009770 0x00001000 0x00000400 0x00009800 0x60000020
.data 0x00005244 0x0000c000 0x0000a200 0x00003e00 0xc0000040
.idata 0x0000075c 0x00012000 0x0000e000 0x00000800 0xc0000040
.rdata 0x00000417 0x0000b000 0x00009c00 0x00000600 0x40000040
Remember, from the Image File Header, we found that there were 4 sections. Now we have more detailed information about those sections.
Using the code I have now, I took a look at the same process that Andreas used in his tutorial...dd.exe, PID 284. I extracted the same information he listed, down to the section headers. Now, to begin automatically reassembling the image, we simply need to follow the advice given by Andreas; specifically, given the information we've extracted from the PE header, go back into the physical dump file, extract those pages and reassemble them in order. The test will then be not only to view the complete PE header information, Import Table and resources of the file using something like File::ReadPE (or use tools such as pedump or PEView), but to also actually launch the image.
Friday, April 14, 2006
Why Perl?
I haven't actually been asked this question yet, but I'm anticipating it...why Perl? Why am I using Perl for the RAM dump parsing tools, and not C, Java, or C#?
Well, first of all, Perl is pretty ubiquitous...it's everywhere. Perl is not only used for system administration, but for Web-based (CGI) interfaces, and a wide variety of other activities. Perl is used in security projects such as The SleuthKit, the MetaSploit Framework, and used extensively throughout my book and the Real Digital Forensics book.
Perl is great as a quick prototyping tool. Starting from scratch, or by using some code you've already got, you can put together a tool for performing a specific task, and run it quickly. If there are any errors (yes, I know I need to use "-w" more), you can quickly open the file up, locate the error and fix it. As Perl is an interpretted language, you don't have to rebuild/recompile the script...you can run it as soon as you make modifications and save them.
Perl is pretty easy to read...when compared to other languages. I like to comment my code, and will sometimes have more comments in a script than I have lines of code. Perl is also a great educational tool, as you can clearly walk through your script, and show were different things are done; open files, write to a file, access an API, close a file, etc.
One other thing I like about Perl is that because Perl is available on other (Mac, Linux, etc.) systems besides just Windows (yeah, imagine that!), with a little care (predominantly toward endianness) the script I write on Windows can be run on those other platforms. What this means is that a forensic analyst isn't restricted to performing analysis of a Windows system on a Windows system. So, if you dump the contents of physical memory to a file and you're analyzing that file on a Linux system (or if you're Jesse Kornblum, on a Mac), then you're not stuck and restricted to only tools written for that platform. The same is true if you're analyzing an image of a Windows system, and you're on Linux.
Now, if you are on Windows and don't want to install Perl, I try to provide standalone executables of the Perl scripts via Perl2Exe or PAR. These aren't really executables in the sense of a C/C++ file compiled in to a PE file, but more of the Perl script wrapped up the Perl interpreter. So, the EXE files will be larger than a "normal" EXE.
As with my last post, I hope this makes sense.
Well, first of all, Perl is pretty ubiquitous...it's everywhere. Perl is not only used for system administration, but for Web-based (CGI) interfaces, and a wide variety of other activities. Perl is used in security projects such as The SleuthKit, the MetaSploit Framework, and used extensively throughout my book and the Real Digital Forensics book.
Perl is great as a quick prototyping tool. Starting from scratch, or by using some code you've already got, you can put together a tool for performing a specific task, and run it quickly. If there are any errors (yes, I know I need to use "-w" more), you can quickly open the file up, locate the error and fix it. As Perl is an interpretted language, you don't have to rebuild/recompile the script...you can run it as soon as you make modifications and save them.
Perl is pretty easy to read...when compared to other languages. I like to comment my code, and will sometimes have more comments in a script than I have lines of code. Perl is also a great educational tool, as you can clearly walk through your script, and show were different things are done; open files, write to a file, access an API, close a file, etc.
One other thing I like about Perl is that because Perl is available on other (Mac, Linux, etc.) systems besides just Windows (yeah, imagine that!), with a little care (predominantly toward endianness) the script I write on Windows can be run on those other platforms. What this means is that a forensic analyst isn't restricted to performing analysis of a Windows system on a Windows system. So, if you dump the contents of physical memory to a file and you're analyzing that file on a Linux system (or if you're Jesse Kornblum, on a Mac), then you're not stuck and restricted to only tools written for that platform. The same is true if you're analyzing an image of a Windows system, and you're on Linux.
Now, if you are on Windows and don't want to install Perl, I try to provide standalone executables of the Perl scripts via Perl2Exe or PAR. These aren't really executables in the sense of a C/C++ file compiled in to a PE file, but more of the Perl script wrapped up the Perl interpreter. So, the EXE files will be larger than a "normal" EXE.
As with my last post, I hope this makes sense.
But...why?
When it comes to using dd.exe to dump the contents of physical memory from a Windows system, one thing that's been asked is...why? Why is any of this important? Why use dd.exe to dump the contents of RAM, and then why all the effort to write tools to parse through the resulting file? After all, if it really were important, wouldn't someone have done all of this already?
For a long time, the "normal" forensics steps that've been taken have been to document a scene, then remove power from the system before creating a forensic image of the hard drive. However, in recent years, there's been a realization, even among law enforcement, that there may be something of value found in the volatile memory of the system...perhaps even evidentary. For example, we know that the Clipboard occupies an area of memory designated by the system, and we can run a tool that will dump the contents of the Clipboard.
When I've talked to some law enforcement officers at conferences I've attended, I've asked them why they collect the contents of RAM, rather than say, run specific tools to get things like the contents of the Clipboard, memory used by specific processes, etc. In most cases, I'm simply told, "we want it all." When I ask, "what for?", I'm usually met with stares or responses like, "in case we need it."
Don't get me wrong...there may be something of value in memory that can be used to help further the investigation. Folks have found evidence of malware, passwords, etc., but most of the examination has been hit or miss...create the dump, then run strings on it to see what's there. At that point, you end up with a lot of output and you really have no way of tying what you found back to a particular process. Is that IP address or potential password you found in the output of strings from a malcode process, such as a backdoor, Trojan, or worm...or was it part of an email, or word processing document, or...? There's no way to know.
This is why I'm working on these tools. Not only because it's a challenge...and I have to thank several folks out there, particularly Andreas Schuster, for their help and assistance in moving this along. The other reasons are that (a) tools like this are needed...needed by folks who are working in the field and have a 512MB dump of RAM on their system, and no idea what to do next, and (b) knowledge of these things is needed. By talking to others, figuring things out, and presenting the information to more people, there might be a few people who get over that initial hurdle of "I don't know where to start", and start learning about this topic...and what we end up with is more folks with more knowledge, and we're all smarter.
I hope this makes sense.
For a long time, the "normal" forensics steps that've been taken have been to document a scene, then remove power from the system before creating a forensic image of the hard drive. However, in recent years, there's been a realization, even among law enforcement, that there may be something of value found in the volatile memory of the system...perhaps even evidentary. For example, we know that the Clipboard occupies an area of memory designated by the system, and we can run a tool that will dump the contents of the Clipboard.
When I've talked to some law enforcement officers at conferences I've attended, I've asked them why they collect the contents of RAM, rather than say, run specific tools to get things like the contents of the Clipboard, memory used by specific processes, etc. In most cases, I'm simply told, "we want it all." When I ask, "what for?", I'm usually met with stares or responses like, "in case we need it."
Don't get me wrong...there may be something of value in memory that can be used to help further the investigation. Folks have found evidence of malware, passwords, etc., but most of the examination has been hit or miss...create the dump, then run strings on it to see what's there. At that point, you end up with a lot of output and you really have no way of tying what you found back to a particular process. Is that IP address or potential password you found in the output of strings from a malcode process, such as a backdoor, Trojan, or worm...or was it part of an email, or word processing document, or...? There's no way to know.
This is why I'm working on these tools. Not only because it's a challenge...and I have to thank several folks out there, particularly Andreas Schuster, for their help and assistance in moving this along. The other reasons are that (a) tools like this are needed...needed by folks who are working in the field and have a 512MB dump of RAM on their system, and no idea what to do next, and (b) knowledge of these things is needed. By talking to others, figuring things out, and presenting the information to more people, there might be a few people who get over that initial hurdle of "I don't know where to start", and start learning about this topic...and what we end up with is more folks with more knowledge, and we're all smarter.
I hope this makes sense.
Thursday, April 13, 2006
Updated lsproc
I've updated lsproc with some small changes. For one, I made a small change to the detection portion of the script.
The other change I made was to output the creation time of the process rather than the FLink/BLink values. In doing so, I ran across some interesting output. Take a look:
Proc 156 176 winlogon.exe 0x01045d60 Sun Jun 5 00:32:44 2005
Proc 156 176 winlogon.exe 0x01048140 Sat Jun 4 23:36:31 2005
Proc 144 164 winlogon.exe 0x0104ca00 Fri Jun 3 01:25:54 2005
Proc 156 180 csrss.exe 0x01286480 Sun Jun 5 00:32:43 2005
Proc 144 168 csrss.exe 0x01297b40 Fri Jun 3 01:25:53 2005
Proc 8 156 smss.exe 0x012b62c0 Sun Jun 5 00:32:40 2005
Looking at the output, most of the processes seem to have been started on Sun, Jun 5...and yet there are a couple of processes that were started well before then. Definitely something to look into.
As with the other tools, the Perl source and a standalone executable for Windows are available in the archive.
The other change I made was to output the creation time of the process rather than the FLink/BLink values. In doing so, I ran across some interesting output. Take a look:
Proc 156 176 winlogon.exe 0x01045d60 Sun Jun 5 00:32:44 2005
Proc 156 176 winlogon.exe 0x01048140 Sat Jun 4 23:36:31 2005
Proc 144 164 winlogon.exe 0x0104ca00 Fri Jun 3 01:25:54 2005
Proc 156 180 csrss.exe 0x01286480 Sun Jun 5 00:32:43 2005
Proc 144 168 csrss.exe 0x01297b40 Fri Jun 3 01:25:53 2005
Proc 8 156 smss.exe 0x012b62c0 Sun Jun 5 00:32:40 2005
Looking at the output, most of the processes seem to have been started on Sun, Jun 5...and yet there are a couple of processes that were started well before then. Definitely something to look into.
As with the other tools, the Perl source and a standalone executable for Windows are available in the archive.
Prefetch files, revisited
I was listening to the latest CyberSpeak podcast (8 Apr) today, and picked up a little tidbit. With regards to those .pf files located in the Prefetch directory on Windows XP, Ovie and Bret stated that the DWORD located at offset 0x90 in the file records the number of times that particular application was launched, with the caveat that this does not apply to those applications autostarted (as via Registry entries). So this will tell you how many times the user launched that application.
Also, the guys said that the 2 DWORDs located at offset 0x78 is the FILETIME object for the time that the application was last launched. This should probably correlate with the last write time on the .pf file itself.
Anyone have any other tidbits like this that can be incorporated into a nice little Perl script? ;-)
Also, the guys said that the 2 DWORDs located at offset 0x78 is the FILETIME object for the time that the application was last launched. This should probably correlate with the last write time on the .pf file itself.
Anyone have any other tidbits like this that can be incorporated into a nice little Perl script? ;-)
Saturday, April 08, 2006
lspd posted
I've posted lspd (for "list process details") to the SourceForge site this morning.
First, I want to say that this is a tool written in Perl. The archive I posted includes the Perl source, as well as an executable compiled from the script using Perl2Exe (note: if you use this executable, you need to keep p2x587.dll with the exe at all times). If you don't want to use this executable, or want to modify the source and recompile it, take a look at the PAR module, which is available for Perl. PAR can produce either a portable package that you can run on other platforms (though this script does not use any additional modules), or an executable that is simply more portable.
I wanted to mention this up front, as you don't have to have just Windows to run the script...you can run it on any system that runs Perl. Well, take that with a caveat...I haven't actually tested this on some of the other platforms that run Perl, such as the Tivo.
So...on to the show.
lspd dumps the details of a process from a dd.exe-style dump file, such as those provided with the DFRWS 2005 Memory Challenge. The first thing you have to do is run the lsproc tool against the dump, and get the value of the offset for the process you're interested in.
For example, I ran lsproc against the first memory dump from the Memory Challenge, and found this:
Proc 1112 284 dd.exe 0x0414dd60 0x8046b980 0xff1190c0
From there, I ran the lspd.pl script against the dump file using he following command line:
C:\Perl>lspd.pl d:\hacking\dfrws-mem1.dmp 0x0414dd60
As you can see, lspd takes 2 arguements...the dump file, followed by the hex offset of the process you're interested in.
lspd ran very quickly, and dumped out process details, such as details from the EPROCESS block and process environment block (PEB), the command line used to launch the process, the Desktop name, the Window title, etc. lspd also extracts the modules and handles, if available.
Here's an example of the handles extracted for this process:
Type : File
Name = \Shells
Type : WindowStation
Type : WindowStation
Type : Desktop
Type : File
Name = \intrusion2005\audit.log
Type : File
Name = \intrusion2005\audit.log
lspd was also able to determine that the page located at the Image Base Address (from the PEB) contains a PE header. This will be addressed with another tool (tentative name: lspi, for "list process image").
One thing to keep in mind while using this tool...not all of the information that we're trying to extract is present in the physical memory dump file. When a virtual address is translated into a physical offset within the dump file, flags need to be checked to see if the 4K page is "present" (I put that in quotes b/c that's the name of the flag). Andreas Schuster has a very good tutorial about how this works, but I'm considering writing something specific to these tools, should I find the time to do so.
As always, if you have any comments or questions, please feel free to contact me.
First, I want to say that this is a tool written in Perl. The archive I posted includes the Perl source, as well as an executable compiled from the script using Perl2Exe (note: if you use this executable, you need to keep p2x587.dll with the exe at all times). If you don't want to use this executable, or want to modify the source and recompile it, take a look at the PAR module, which is available for Perl. PAR can produce either a portable package that you can run on other platforms (though this script does not use any additional modules), or an executable that is simply more portable.
I wanted to mention this up front, as you don't have to have just Windows to run the script...you can run it on any system that runs Perl. Well, take that with a caveat...I haven't actually tested this on some of the other platforms that run Perl, such as the Tivo.
So...on to the show.
lspd dumps the details of a process from a dd.exe-style dump file, such as those provided with the DFRWS 2005 Memory Challenge. The first thing you have to do is run the lsproc tool against the dump, and get the value of the offset for the process you're interested in.
For example, I ran lsproc against the first memory dump from the Memory Challenge, and found this:
Proc 1112 284 dd.exe 0x0414dd60 0x8046b980 0xff1190c0
From there, I ran the lspd.pl script against the dump file using he following command line:
C:\Perl>lspd.pl d:\hacking\dfrws-mem1.dmp 0x0414dd60
As you can see, lspd takes 2 arguements...the dump file, followed by the hex offset of the process you're interested in.
lspd ran very quickly, and dumped out process details, such as details from the EPROCESS block and process environment block (PEB), the command line used to launch the process, the Desktop name, the Window title, etc. lspd also extracts the modules and handles, if available.
Here's an example of the handles extracted for this process:
Type : File
Name = \Shells
Type : WindowStation
Type : WindowStation
Type : Desktop
Type : File
Name = \intrusion2005\audit.log
Type : File
Name = \intrusion2005\audit.log
lspd was also able to determine that the page located at the Image Base Address (from the PEB) contains a PE header. This will be addressed with another tool (tentative name: lspi, for "list process image").
One thing to keep in mind while using this tool...not all of the information that we're trying to extract is present in the physical memory dump file. When a virtual address is translated into a physical offset within the dump file, flags need to be checked to see if the 4K page is "present" (I put that in quotes b/c that's the name of the flag). Andreas Schuster has a very good tutorial about how this works, but I'm considering writing something specific to these tools, should I find the time to do so.
As always, if you have any comments or questions, please feel free to contact me.
Subscribe to:
Posts (Atom)