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.
Thursday, June 22, 2006
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)