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.

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?

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

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

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.

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.

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:

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

A word about the tools you use...be sure to review the licensing for each. Some tools have no licensing, but others do. Some that do allow you to use them freely on the systems you own (personally, or as a sysadmin for a company/corporation), but not use them as a consultant.

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.

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.