[ISN] Windows Forensics and Incident Recovery

[InfoSec News]

http://books.slashdot.org/books/04/11/09/202220.shtml

[ http://www.amazon.com/exec/obidos/ASIN/0321200985/c4iorg  - WK]

Author: Harlan Carvey 
Pages: 460 
Publisher: Addison Wesley 
Rating: 9 
Reviewer: Mark McKinnon 
ISBN: 0321200985 
Summary: Forensic analysis and incident recovery on a live Microsoft 
Windows is explained for the system administrator, security 
administrator and knowledgeable home user. 

The intended audience, according to the author, is "anyone with an
interest in Windows security, which includes Windows system and
security administrators, consultants, incident response team members,
students and even home users." The author assumes the reader is
familiar with basic networking (including TCP/IP) and has some Windows
administration skills. Some programming ability, though not actually
required, will help out greatly with reading and understanding the
many examples provided, and will let you make your own modifications
(this is encouraged by the author throughout the book).

The chapter on data hiding was a real eye-opener -- it's amazing the
things Microsoft has implemented as part of the operating system (and
included applications) that can be used to hide things. Discovering
the hidden information is talked about, as well how it is hidden.  
Sample topics include file attributes, alternate data streams, OLE and
stenography. This is an excellent chapter with many examples; I found
myself stopping after each subject to try out each of the discussed
techniques.

The next chapter delves into incident preparation. Carvey addresses
some of the things that administrators can do to harden their systems.  
He goes over the application of security policies in general, as well
as intelligent assignment of file permissions. He then covers Windows
File Protection and how it is implemented, and includes a perl script
to implement your own file watcher. He touches briefly on patch
management and anti-virus programs, then moves into monitoring. He
provides quite a few scripts, and discusses other means by which you
can monitor your system.

The next chapter describes tools that can be used in incident
response. This chapter has quite a lot of information and took me the
longest to get through, because of all the tools mentioned that I had
to download and check while I was reading the book. Carvey uses a
mixture of his own perl scripts and programs that can be downloaded
from places like Sysinternals, Foundstone, DiamondCS and others. All
of the tools used are open source (or are at least freely available).  
That equips the reader with a low-cost toolkit, especially important
to the home user or small business owner who cannot afford to buy the
commercial equivalent. Carvey does acknowledge, though, that there are
quite a few commercial tools with great functionality out there.

The first part of the incident-response tools chapter deals with the
collection of volatile information (processes, services, etc.); this
is a vital part of live analysis. The second part deals with the
collection of non-volatile information (the content of the Windows
registry, file MAC times and hashes, etc.) and tools for analyzing
files. Carvey also shows how some of the tools complement each other,
and that there is not one almighty tool that will find all the data
you need. (This is also proven by example in a later chapter when he
talks about rootkits.)

The next chapter deals with developing a security methodology, and
it's handled differently than in most books: the author presents the
material as a series of dreams that a Windows system administrator
has, showing how an individual can come up with and fine tune a
methodology as incidents happen. Carvey has used this approach before
in a series of articles entitled "No Stone Unturned" for
SecurityFocus.com, and the creative approach appeals to me. As he
moves from dream to dream, you can relate to the admin's circumstances
(and mistakes), and how be and becomes better at responding to
different incidents.

The next chapter talks about what to usefully look for with the tools
the book has introduced. It discusses infection vectors, types of
malware and rootkits, and demonstrates tools and techniques for
detecting them. This is where the author makes a clear point of why
you would need to run several different tools, even if some overlap.  
His example uses an installed rootkit; running a particular program
from a previous chapter, he shows that it fails to find that anything
untoward is running -- it takes another program from the same chapter
to actually reveal the rootkit's presence. By cross referencing the
output for both programs, you can see why you should run more then one
type of analysis tool for certain areas to make sure you are not
missing anything.

Finally, the author dedicates an entire chapter to his own Forensic
Server Project, a two-pronged approach to live forensic analysis which
uses two machines simultaneously. The first piece, the Forensic Server
Module, is the listener software; this runs on a clean PC where the
data will be sent from the compromised system. The other piece, called
the First Responder Utility, runs several of the programs and scripts
from the incident tools chapter on the compromised system . After
installing everything needed for both parts of this system, I followed
the author's instructions on how to run it. What a slick tool! I ran
it from a couple of PCs on my home network and was able to get a lot
of the information that was described in the book as well as hash
values for each log file that was produced, and a general log of
everything the First Responder Unit did. The whole principle of this
is that when you have an incident there will be very little
interaction with the compromised system, since everything is scripted
to begin with.

The framework that this software constitutes is very flexible. I was
able to add two new features to the Forensic Server Module and the
First Responder Utility with very little code. The first addition I
made was to mark all the logs as read-only on the file system after
they were written from the Forensic Server module. The next addition I
made was to add a perl script to scan the c:\ drive of the PC that the
First Responder Utility was running on. After I made both additions, I
tested everything out, and it worked great. I had my extra log files
and they were all read-only. My hat goes off to the author for coming
up with and including this in the book, a really nice piece of
software.