NBDServer

A project I read about a while back really caught my attention, but I hadn't had a good chance to try it out till recently. Jeff Bryner (@p0wnlabs) created NBDServer and describes it as a "A DFIR/forensic take on nbdsrvr by Folkert van Heusden."

In essence, NBDServer allows you to set up a server on a Windows machine (XP, Win 7, Win 2008) and then connect to it from a Linux client. The client configures the Windows server as a  read-only network block device, allowing you to mount the device on the client like a local disk, image it across the network or run other forensic tools on the device. It is also possible to use this tool in conjunction with the Volatility winpmem utility to image the Windows system RAM across the network to your client.

Running NBDServer is simple. There is no real setup, so all you have to do is download the ZIP file, extract the contents and place them on the Windows machine you wish to work with. You'll need to run the program from an Administrative command prompt (gasp! a command line program!) if using Windows Vista, 7, 2008, etc. I'll come back to the mechanics of running NBDServer in a moment, but first let's talk about setting up the Linux client.

The Linux half of this setup, known as nbd-client, available from it's page on Sourceforge and is apparently created and maintained by Wouter Verhelst. Download the nbd-client package (currently version 3.2) to your Linux workstation and install it using the typical ./configure && make && make install. I installed it to the new Kali Linux and didn't have to account for any missing dependencies, but your mileage may vary on a different distro. Once installed run "modprobe nbd" to initialize the new device prior to attempting to connect with the server.

To test the setup, I ran it from several different configurations. The first test used a Kali Linux virtual machine and a Windows XP Pro virtual machine on the same host. After that, I used two physical machines, being Kali Linux installed to hard drive on one pc and Windows 7, 64-bit on the other. Finally, I connected between the Windows XP Pro vm and the physical Kali Linux box. I tested the ability to connect and remain connected, as well as mounting remote drives and imaging disks and RAM via the network. I won't detail every result from each separately, as they were all essentially the same. I will cover imaging RAM separately a little later in this post.

To begin simulating a response to a Windows machine, I connected my Linux box to a network share which the subject Windows pc could also connect to. I copied the nbdserver.exe to a folder on the share and then opened the share on the Windows machine (x: drive on this machine) and copied the nbdserver to the desktop. On the Win 7 pc, I opened an Administrative command prompt and navigated to the nbdserver location. I reviewed the available options from the README which include:

Usage:

NBDServer.exe v3.0
 -c     Client IP address to accept connections from
 -p     Port to listen on (60000 by default)
 -f     File to serve ( \\.\PHYSICALDRIVE0 or \\.\pmem for example)
 -n     Partition on disk to serve (0 if not specified)
 -w     Enable writing (disabled by default)
 -d     Enable debug messages
 -q     Be Quiet..no messages
 -h     This help text

 -f option supports names like the following: 
  \\.\PHYSICALDRIVE0    raw drive partition access along with -n option
  \\.\C:                volume access (no need for -n option)
  \\.\HarddiskVolume1   volume access (no need for -n option)
  afile.dd              serve up the contents of 'afile.dd' via nbd.
  \\.\pmem              access the pmem memory driver from volatility

On the first attempt, I wanted to connect to the system drive on the Win 7 machine and mount it in Linux. The IP address for the Windows box was 192.168.2.157 and the Linux IP was 192.168.2.197. So, my command line was as such:

nbdserver.exe -c 192.168.2.197 -f \\.\PHYSICALDRIVE0 -n0

This instructs the server to connect to the client IP and serve up the first partition on drive 0. I hit enter and the program started, though all you see is the cursor drop to the next line and sit there flashing. No news is good news at this point.

I moved over to the Linux pc to start the client. You may need to use sudo when running it. The command for starting the client is as follows:

modprobe nbd

followed by

(sudo) nbd-client 192.168.2.157 60000 /dev/nbd0

This starts the client, tells it to look for the server on 192.168.2.157, use 

port 60000 and create the new network block device as /dev/nbd0.

Upon executing the above commands, the connection was successfully established as evidenced by messages displayed on both machines command lines. The Windows side just reports a successful connection to the client IP. The client showed the size of the new device in megabytes and bytes, as well as the block size.

I next ran the fls tool from the Sleuth Kit to generate a quick timeline on the new block device like this:

fls -f ntfs -m C: -r /dev/nbd0 > test.fls

This worked with no problem,  so my next test was to mount the device in Linux. I typed the following command:

mount -t ntfs-3g -o rw,show_sys_files,streams_interface=windows /dev/nbd0 /mnt/nbd

You may have noticed I included "rw" for read/write instead of "ro" for read-only. I wanted to test and make sure that nbdserver really was only giving me read-only access to the disk, regardless of how I mounted it. I created a text file using the touch command while in the mounted Windows user directory, then opened it and added some text to it. I save it and type ls, seeing it was listed among the files in the directory. I looked over to the real Windows machine to see if the file was there, but it wasn't. Back on the Linux side, I typed rm -rf * for everything in the current directory and typed ls, showing an empty directory. However, looking at the real folder on the Windows machine showed nothing was added and nothing was deleted.

I issued a umount command to unmount the device, then disconnected from the server with this command:

(sudo) nbd-client -d /dev/nbd0

A quick ctrl-C on the Windows side killed the server. I then re-connected and again mounted the system drive, finding all files were where they were supposed to be and no additional files had been created. The nbdserver/client setup appears to create and delete files on your command, but nothing actually changes.

Using the same methods described already, I also accessed a USB flash drive. I was able to mount and imag it across the network with no issues.

As I mentioned above, it's also possible to image RAM on the Windows system via the network with nbdserver. In addition to the server, you also need the latest version of winpmem from the awesome Volatility project. The current winpmem.exe version is 1.4.1.

Prior to starting the server, it is necessary to load the winpmem driver. You can do this manually, but there's really no need. The winpmem executable works very well and is invoked by typing:

winpmem_1.4.exe -l (that's a lowercase L, not a number 1)

If you see no errors after running that, you should be ready to continue. Start your nbdserver as before, but this time you'll change what you're telling the server to make available to the client. Your new command line will look something like:

nbdserver.exe -c 192.168.2.197 -f \\.\pmem

Over on the client, you can pretty much type the same thing you did before. You can add the -b option to designate the block size also. Here's an example:

nbd-client 192.168.2.157 60000 /dev/nbd1 -b 1024

You can then use your favorite version of dd, dc3dd, dcfldd, etc, to image the RAM device like this:

dc3dd if=/dev/nbd1 of=./physmem.raw (name it whatever you want)

From there, you can use Volatility to work with your RAM image. Just to make sure I got a good image, I ran the Volatility kdbgscan plugin on the ram image. It reported correct information, so I knew I was in good shape.

The only issue I ran into imaging RAM involved the 64-bit Win 7 machine. Imaging memory on the XP Pro machine worked without a hitch. However, I found the 64-bit machine would lock up and then spontaneously reboot when the imaging reached 3.5GB of the 12GB total. I plan to contact Volatility and let them know and will be happy to provide any sample data to help figure out what went wrong.

Overall, I would call this a huge success. Except for the 64-bit RAM imaging issue, I experienced no problems I couldn't attribute to user error. If you find yourself in need of a tool like this and don't have to money or time to obtain a commerical product like F-Response, I think you'll find you can accomplish what you need with NBDServer.

NOTE: Edited to remove some content I want to test further.

Forensic 4cast Awards

I wanted to let you all know that voting has begun for this years Forensic 4cast awards. I'm pleased to say this blog received a nomination for the Digital Forensic Blog of the Year. As happy as I would be to win, I must admit the two other nominees are far better choices and deserve your votes. I have a good time writing here, but this blog is not in the same league as Corey's Journey Into Incident Response blog or the Volatility Labs blog. Both of them devote a lot of time to research and blogging. I'm deeply appreciative for the nomination and I hope to produce something worth an award sometime, but I encourage you to vote for Corey or Volatility.

On another topic, I've been testing Jeff Bryner's NBDServer the last couple days. It's pretty cool, but I've got a couple issues to figure out. I've used it successfully between two virtual machines and also between one VM and the host system, but I'm having trouble getting it to work between two physical machines. I'll do a blog post about it once I get everything figured out.

Working Smarter, Not Harder

There are a couple reasons I enjoy blogging, although my lack of frequent posts would suggest I don't like it that much. Just the same, I do it because I enjoy writing and I find writing something down like this helps me remember it for the next time I need it. If this helps someone else in the process, then so much the better.

I've been working on an intrusion case recently, something I've previously done only in training. I have already started a separate blog post talking about it, but I'm not really ready to finish it yet. However, I wanted to post today about something I should have been doing all along. I've used such great tools as Volatility, Log2Timeline and the SANS Forensics SIFT Workstation on this case, as well as RegRipper. RegRipper is what I wanted to talk about today.

The developer of RegRipper, Harlan Carvey, made a new post on his blog recently about finding evidence of program execution on a system under investigation. As a police officer, most of my cases revolve around finding the porn, trying to figure out how it got there and if it's been viewed. Not terribly difficult, most of the time. I rarely have the need to determine whether or not a particular program has been run. Even in the case of investigating child exploitation video possession, I can usually determine if a video has been viewed through .lnk files, jump lists, recent docs, application history and so on. I was able to determine on a recent case that a particular video had been opened in RealPlayer by finding the .lnk file RealPlayer creates upon playing a file. That, along with timeline evidence and some application testing helped prove the case. But, I digress.

As I said, it's not often that program execution is that important to my cases. I found the need to do this, however, after discovering the intruders in this particular case had downloaded several things to the victim Windows 2008 system, including some hacking tools, a bulk email sender and several different web browsers. While I found ample web history to easily show the browsers had been used, I wanted to find out if the other programs had been only downloaded or actually used. Harlan's post helped me remember some steps I could take and taught me some new ones as well to help figure this out.

That was the set up, but here's the real point of this post. I found myself using RegRipper in my quest to determine program execution. I use the command line rip.exe probably as much, maybe more often than the RegRipper GUI. The problem is, I was using the program in a less than efficient manner. Instead of taking advantage of the ability to create a custom profile and running all the plugins I was interested in at once, I was typing them each in at the command line one at a time, looking at the output and then running another. This amounts to an inefficient use of  the fleeting time I have to work only on forensic cases. My job is such that I frequently get called out from my DFIR work to answer regular "routine" calls for service, car wrecks, domestic disputes, etc. Running one little command at a time instead of preparing a custom profile is just silly and creates unnecessary delay.

Harlan asked me what could be done to get users to run all needed plugins at once instead of doing one and then waiting to do the another later. I think the answer to that, at least in my case, is just reminding myself that there are better, easier ways to do things sometimes than the way I choose.

It's helpful to plan ahead what you may be interested in. The plugins available from the RegRipper Plugins site include the individual plugins applicable to each of the registry hives and a couple plugins that can be used against all the hives. Also included are "all" plugin profiles for each hive, such as one for ntuser-all, system-all and so on. These profiles have every included plugin listed in them and when run via RegRipper, will run every plugin listed in them against the hive file you've indicated. Running rip.exe -r ntuser.dat -f ntuser-all, for example, will run every ntuser.dat specific plugin against the ntuser.dat file.

Creating a custom profile for RegRipper and/or rip.exe is dead simple. The great thing about these profiles is they are just text files, easily edited in your favorite text editor. I decided to create a custom profile for this post and will tell you how I did it.

I used FTK Imager to grab the ntuser.dat file from this system and saved it to a test folder. I next selected at random several plugins in the plugins folder that are used to parse the ntuser.dat file for specific information. In my new blank text file, I typed the following:

#test custom plugin profile
#
userassist
domains
ccleaner

I closed my text file and saved it as kptest. You can call it what you want, I suppose, but that's what I used. Notice the plugins are listed in this profile without the .pl extension. Likewise, whether you run a single plugin at the command line or create a profile, you'll want to leave off the .pl. RegRipper takes care of adding that. That's it. It's that easy.

So, to try out my new test profile, I went to the command line and typed the following (in the same directory where my ntuser.dat copy was stored): rip.exe -r ntuser.dat -f kptest > test.txt. This ran only the plugins I defined in the "kptest" profile against the ntuser.dat file in that directory. This same test profile was available in the RegRipper GUI and produced the same results. The GUI also produces a log file in addition to the output.

So, why do this? Why not just run the included profiles? The answer to that is "information overload". The "all" profiles produce a lot of information, often more than you really need. Making your own profile on a case by case basis, based on your needs to that particular case will save you from sifting through lots of information you don't want or need. Sometimes you may discover you need to run other plugins after doing this and that's fine, but why not try to do as much as you can at one time and then follow up with others later if necessary?

As I said, I write this as much to help me remember it as I do to help others. If you gained something from this post, then I'm very happy about that.
I will be posting again soon about the same investigation I mentioned above. It has all sorts of "win" through the use of FOSS tools and I look forward to telling you about it.

And now for something completely different...HoneyDrive

For quite a while now, I've wanted to set up a honeypot and see what I can learn from it. I was happy to find out that the Ion at BruteForce Labs has put together a great "all in one" virtual machine with preconfigured honeypots. The virtual machine is called HoneyDrive. Upon learning about it, I decided this was as good a time as any to try out running a honeypot.

HoneyDrive makes it incredibly easy to get started. It includes Kippo, Dionaea, Honeyd and LaBrea honeypots, as well as lots of related software tools, including (from the website) "A full suite of security, forensics and anti-malware tools for network monitoring, malicious shellcode and PDF analysis, such as ntop, p0f, EtherApe, nmap, DFF, Wireshark, ClamAV, ettercap, Automater, UPX, pdftk, Flasm, pdf-parser, Pyew, dex2jar and more." As you can see, it's packed full of great stuff.

It is ready for download as a VirtualBox .ova file, so all you have to do is open VirtualBox, click File-Import Appliance and select the HoneyDrive .ova file. Once the import is finished, you will have a new, ready to run HoneyDrive vm available in your inventory. Then, just configure its settings and start it up.

I changed a few of the settings prior to first run. I changed the network settings to make sure it would bind to the correct network card, as I have more than one in the host machine and wanted to have it on the correct network. I also bumped up the ram for the vm a little. I won't go in to how to do these things, as they are pretty basic changes for anyone who has previously used VirtualBox.

After starting up the machine and verifying my networking was set up right, I was ready to get started. The next decision was, which honeypot would I try first? My good friend Leon van der Eijk has written on his blog and spoken about his work with the Kippo ssh honeypot. Likewise, Andrew Waite has posted quite a bit about Kippo and Dionaea on his InfoSanity blog. They are my "go to" guys when I have a honeypot question.

I decided to go with Dionaea to begin with, as I've been wanting to try a honeypot for the purpose of malware collection. Setup of Dionaea in HoneyDrive is quite easy, although I found it was unable to bind to port 80 at first. I discovered Apache webserver was running by default on HoneyDrive and it was interfering with Dionaea and port 80, so I shut down Apache and all worked well from there. Well, almost all.

As I said, my goal with Dionaea was to collect malware. Unfortunately, my Internet service provider apparently filters port 445 (SMB/CIFS), so I got no connections at all on that port and no files accordingly. I did get lots of connections on ports 80, 443, 1433 and 3306, however, so it wasn't a total loss. The majority of IP addresses connecting to those ports were from (big surprise) China. I left Dionaea running for a couple days and then decided I wanted to try out Kippo.

Kippo is an ssh honeypot. It has a fake filesystem, simulating a Debian Linux server and that is what the attacker sees on login. They can navigate around, but can't do any real damage. It is absolutely simple to get started in HoneyDrive and I saw almost immediate results. Ion has created some great ways to monitor your Kippo with custom made scripts and the ability to view your Kippo stats via web browser (see pics).

Above, you see the initial start screen for Ion's Kippo-Graph. The results aren't delivered in real-time, so you have to click "Generate The Kippo Graphs". What follows is incredibly detailed information. There is much more to Kippo Graph than you'll see in the following pictures, but they will at least give you a taste of what's available.

Kippo has only been running for about a day as of this writing, so there aren't lots of stats yet. Still, it appears some have shown some interest in trying to log in. A few of the logins are mine, just testing from various IP addresses, but the bulk of login attempts are from other countries.

One amazing thing about Kippo is the ability to play back "recordings" of logins. When someone logs in to the Kippo fake filesystem and tries to navigate around what they think is a server of some sort, Kippo records their every move and saves it to a log file. You may then use the playlog.py utility to replay the attacker's activity, just like you recorded it on your DVR. You can see every command they typed, seeing it just like you were watching them live at the console. Kippo will be sure to save a copy of any files they download to it. For whatever reason, no one has done more than attempt to log in so far, despite the simple password, so I have no log replays to show you right now. When I finally get a good one, I'll post it here so you can see how it works.

Tektip has some good videos on HoneyDrive and Kippo too. I recommend you watch them to get a greater feel for how all this works. I plan to try out some of the other honeypots in Honeydrive soon, but I'm currently enjoying working with Kippo. I'll probably try out Honeyd in the next couple days, however.

If you've always been curious about running a honeypot, I can't recommend HoneyDrive strongly enough. It is, without a doubt, the fastest and easiest way to get started. Congratulations and thanks to Ion for putting it all together. Thanks also to all the honeypot and other tool developers whose work is included in HoneyDrive.

The Value of Metadata in Digital Images

I'm excited to say I have a guest author on the Digital Forensics blog today! Simon has graciously offered to post this article on image metadata and its value to digital investigations. Thanks Simon!

This is my first article on digiforensics, so first of all, I'd like to thank Ken for the opportunity. I should probably introduce myself. I'm Simon and I'm currently studying Computer Forensics BSc at University. Recently, I received a lecture from a guy talking about cell site analysis and how so many cases these days involve mobile phones. So it got me thinking.

Firstly, it's hard to find anyone who doesn't own a mobile phone. Secondly, it's hard to find someone who doesn't upload pictures to social media sites such as Facebook, Twitter, Myspace (yes, people still use Myspace!) The average user doesn't realize the risks involved by simply uploading a picture from a smartphone onto the internet.

I use the term 'picture' rather than 'image' because an 'image' in the forensic sense

Is a bit for bit copy of a digital drive. Anyway, back on topic. Have you heard of John

McAfee? You should have. He's the brains behind the McAfee anti-virus software empire that

was founded way back in 1987.

In recent months, John McAfee was wanted by police regarding a murder investigation of

his neighbour. We'll use this as a mini case study. Let us pretend we have a serial killer

on the loose. Unless we find out the whereabouts of this guy, who knows what will happen.

What should we do? Search his computer? Search his house? Ok, that’s fine. But what about social media? Let’s look at his Facebook, his Twitter. Hell, if he has World of Warcraft, let’s look at his WoW chat logs. Well, it soon emerged that he had posted a picture of himself online. So it made me think. Can we find out where this guy is? Just by looking into the picture metadata?

Whilst this can be done on Windows using EXIF Viewer, however I find the Macintosh software 'File Viewer' is a great piece of software for this kind of thing. In order to find this guy, we need to analyse the photograph. Luckily for us, Mr. McAfee left his location on when he took his picture, meaning that his geographical location is embedded into the photographs metadata.

Simply dragging the photograph into the File Viewer presents us with the following screen:

If we look at the MAC  information (Modified, Last Opened/Accessed & Created) you’ll see that the data just shows when I opened it up on my laptop. So ignore this. This case study is just so you can see the concept behind it. I’m not really following the ACPO guidelines here guys.

It’s important to note the Tiff Metadata e.g DateTime, Make & Model of device that captured the picture. Notice this is the original time that the photo was taken. Now I scrolled down and found the geotag information (GPS metadata):

This clearly states the Latitude & Longitude the picture was taken. From here, we can simply use our web browser to go to www.maps.google.co.uk and insert the latitude & longitude using this syntax:

Latitude,-Longitude.

From here, we get a satellite view of where the picture was taken.

Needless to say, John McAfee was arrested in Guatemala earlier this month. [Source BBC.co.uk] 

http://www.bbc.co.uk/news/world-latin-america-20621271

I hope this article has been interesting and eye opening. I’m sure there are many people who are aware of this, but if not, it’s just nice to see that metadata can be an incredible source of information for an investigator.

No Partition Table? No Problem

Warning: Veteran forensics professionals probably already know this stuff. Posting for those newer to the field. All are welcome to read and comment, however.

So you've got a disk or maybe just the image of a disk and your forensic tools say there are no partitions on it. What now? Windows isn't going to mount it, so how do we see if any files are on the disk? Some Windows based forensic tools (X-Ways Forensics) will probably be able to identify any lost partitions on the disk, but you still can't mount it natively. Fortunately, there are still ways to get at the data, if it's there at all. Using skills I learned in SANS Forensics 508, I was successful in doing all I needed to do.

The hard drive I'm working with is from a friend's computer. He asked me to troubleshoot, or perhaps just shoot it as it had suddenly stopped booting up.  On Patch Tuesday, the installed Avast Antivirus flagged some files as rootkits and asked to remove them, which my friend allowed. Avast notified him to reboot in order to finish the disinfection. When rebooting, the computer stops after the POST screen and advises there is no boot device.

Windows Disk Management in the management console showed the entire disk as being unallocated. I made a raw image of the drive and am investigating the cause. As part of that, I wanted to mount the image in order to conduct antivirus scans, since Avast had reported rootkits.

Since my friend's computer was unable to find the operating system when trying to boot, I loaded the image into WinHex and navigated to byte offset 446 to look at the partition table. I found the entire table was gone, right down to the 55AA normally found at the end of the table at offset 510 and 511.

So, is all hope lost? Nope. I knew this to be a fairly new computer with Windows XP as the only operating system. In WinHex, I searched for NTFS to try to find the start of a partition. As expected, I found the formerly active partition at Sector 63.

I opened the SANS Forensics SIFT Workstation (ver. 2.14) in VMware Workstation and connected the disk my image was stored on to it through the Shared Folders option. The SIFT Workstation, for those who don't know, is a ready made forensic work environment in a VMware virtual machine. An .iso file to create a live CD is also available.

Knowing the partition started at Sector 63, I knew it should be easy to mount it in Linux and it was. At the command line, I navigated to the disk where my image was located like this:

cd /home/sansforensics/Desktop/VMware-Shared-Drive/disk

There I found my image, named image.001. Before attempting to mount, I decided to use the mmls tool from the Sleuth Kit to see if it could recognize a partition in the image. Even using the sector offset option, mmls still couldn't find any partition.

So, I decided it was time to attempt to mount the partition I knew was in the image. At the command line, I typed the following:

mount -t ntfs-3g -o loop,ro,show_sys_files,streams_interface=windows,offset=32256 ./image.001 /mnt/windows_mount

A few explanations of that command line are probably in order. For those unfamiliar with the mount command, it may seem odd I specified an offset of 32256 instead of 63. The mount command does not work with sectors. Rather, it works with bytes. Knowing each sector was most likely 512 bytes and that the partition started on sector 63, you must multiply the number of sectors times the bytes per sector: 512 x 63=32256.

Also, show_sys_files allows you to see all the Windows "meta" files.

The streams_interface=windows option allows you to view Alternate Data Streams in Linux using the ntfs-3g driver just as you would in Windows.

The mount location I specified, /mnt/windows_mount is a location already existing in the SIFT Workstation for mounting images. One of the great things about this is the /mnt folders and the /cases folder are all shared via the network and you can access them from your host machine as network locations.

Anyway, the procedure outlined above worked like a charm. The partition on the image mounted immediately and I found the filesystem within that partition was intact. I was able to navigate it in Linux, as well as accessing it through the network from my host Windows machine.

I mapped a drive letter on my host to the /mnt so I could easily access this partition from either the SIFT or run other Windows based tools on it from the host machine. The great thing about this is I was able to run log2timeline-sift in the SIFT environment on my image while scanning the mounted image with antivirus from the host Windows machine, all at the same time.

Now, as I said, there is no way to mount this disk (or image) natively in Windows, at least as far as I know. However, it can be done with other tools. I tried FTK Imager, since it is normally able to mount partitions within image files. However, it was unable to mount this one without the partition table being present. IMDisk, a fantastic free tool, allows you to mount images such as this and specify the byte offset of the partition, just like the Linux mount command. It is a Windows based GUI and is extremely easy to use. I tried it and it successfully mounted the image to an accessible drive letter. There are probably other tools that would work, but I didn't have any others to try.

My investigation into this computer is still ongoing. I will post later what, if anything, I find out. I hope I'm able to determine the cause of this incident and get it fixed. I hope this post made a little sense. I'm always happy to respond to questions, so feel free to comment below.

Malware Forensics Field Guide for Windows

I don't write many book reviews because I don't feel like I'm very good at doing them. However, I've been fortunate to read some very good books lately and wanted to tell you about them. First, I posted my review of Practical Packet Analysis a few days ago and now I want to tell you about another excellent book: Malware Forensics Field Guide for Windows Systems.

For those who like to cut to the chase, my recommendation is you should buy this book. Now. It's that good.

As readers of this blog know, I enjoy learning about malware investigation and forensics. I get excited anytime I hear a new book on malware investigation is coming out. I almost never pre-order books, preferring to just wait till they're actually available. This was one of those books I just knew was going to be good and I wanted it as soon as possible so, for a change, I actually pre-ordered.

Malware Forensics Field Guide for Windows was written by the authors of Malware Forensics, Investigating and Analyzing Malicious Code which came out in 2008. In both cases, the publisher is Syngress, one of my favorite publishers for tech books. As with the first book, this one is also written by Cameron H. Malin, Eoghan Casey and James M. Aquilina. Curtis W. Rose served as the technical editor.

This is not a "second edition" of the previous book. While it occasionally makes reference to the first book, it is it's own separate work. As it's name implies, this book is meant to take with you when you go out on the job and includes checklists, sample field notes and more. I'll say more about them later, but the checklists, field notes and guides are just outstanding.

The book has six chapters, which doesn't sound like much, but each chapter is pretty good sized and chock full of great information. Chapter One is Malware Incident Response. The authors do a great job of covering the collection of volatile data, process information and non-volatile data. What's nice here is they don't just tell you what you should do, they also tell you how to do it. Step by step guides in many cases guide the reader through important investigative processes. The authors are careful to guide you in scientifically sound means of investigation instead of just turning you loose with the tools.

My personal background is in dead disk forensics, not incident response, although I'd love to be involved in IR work. I found Chapter One very valuable to me as a relative newcomer to incident response. The included field notes and interview questions are a huge help to newcomer and veteran alike, helping you make sure you've "covered all the bases" in your response. The checklists are just great, reminding you of things you should always check during your assessment of a system, such as collecting volatile data, checking  Windows Prefetch files and so on.

Also included is a chapter on memory forensics. Many exciting things have occurred in the area of memory forensics as of late, led by the great Volatility Framework team, as well as Matthieu Suiche and his Moonsols company (win32dd, etc). Other cool software has come from the likes of Mandiant with its Redline tool and HBGary's Responder software. These days, a book like this couldn't be written without talking about memory forensics and the authors do an excellent job of covering the material. Use of the tools mentioned above and others is covered in great detail. As with most of the other chapters, this chapter ends with a Pitfalls to Avoid section, a checklist and interview questions section, a toolbox section (extra detail on the tools mentioned in the chapter) and a selected reading section directing the reader to more information on the topic of that chapter.

A chapter devoted to "traditional" post-mortem forensics is next. This chapter takes you through the investigation of a suspected victim computer, concentrating on disk based artifacts. Web history, OS and application logs, the Windows Registry and prefetch files are among the sources of possible evidence discussed. Other things like possible autostart locations and keyword searching are also talked about. Something I really liked about this chapter, as well as throughout the whole book, is the way the authors continue to stress the need to use a repeatable, scientific process to conduct your investigation and the need to document it. Further, throughout the book they talk about the importance of validating your results.

Legal considerations when conducting forensic investigations is covered in Chapter 4. I was glad to see this chapter included in the book, as I believe it's far too easy in the heat of the moment to just start doing the fun part (the investigation) without giving consideration to how the law views what you're doing. Federal wiretap laws, HIPAA, PCI, state laws and much more are covered in this chapter. It's nicely done and helps the reader to appreciate the potential legal pitfalls of this work. A very large book could be dedicated to just the legal concerns we face, so obviously not every possible legal topic is covered here, but the authors do a great job of getting the point across and helping the reader to have a good basic idea of the law, as well as giving the reader a better idea of what questions they should answer before proceeding with an investigation.

Next is File Identification and Profiling. I enjoyed the entire book, but this may have been my favorite chapter. Again, extensive note-taking and correlation of findings are stressed here. The focus of this chapter is on studying a suspect file, finding out what it is, what it does and so on. Hashing, file headers and file metadata are discussed, along with much more. The section on file obfuscation was very helpful to me, as it talked about various ways of hiding or obfuscating the functionality of files through the use of packing and encryption. The chapter wraps up with tips on profiling pdf, Microsoft Office and Windows .chm files.

Analysis of a malware specimen is the focus of the final chapter and wow, it is awesome. The authors provide a huge amount of great information on methods for performing static and dynamic analysis of specimen files. As in the other chapters, tools are suggested and step-by-step guidance is given for some. Also talked about are automated "sandbox" style testing using Buster Sandbox Analyzer, ZeroWine and online sandboxes like the ones available from GFI and Norman. Means of defeating file obfuscation are also given. There is far more to this chapter than I could possibly tell you about here.

As previously mentioned, each chapter (except the legal chapter) ends with sample field notes, interview questions, a toolbox (details about tools discussed in the chapter) and suggested reading. The notes and checklists are great, but there isn't much you can do with them in a book. Fortunately, you can go to the book's website and request electronic copies by clicking the Field Notes link at the top of the page. I received the five pdf files of notes and checklists by email after requesting them. The pdf's are in full color and very readable. They're an excellent resource and I know I'll use them.

In conclusion, I want to say I truly enjoyed reading this book and learned a lot from it. I truly only touched on highlights in this review. There is so much more to this book than I've mentioned. I strongly recommend it to anyone whose job entails responding to malware related incidents, as well as to all who simply have an interest in the subject. It is well written, easy to follow and chock full of information that I know I'll refer back to many times. I see the authors have another book, Malware Forensics Field Guide for Linux Systems, scheduled to come out soon. I guarantee I'll be buying that one too.