Security Ripcord

I was reviewing a hard drive the other day when I located several deleted Windows Event Log files.  A quick review showed that I could recover both files but I could only read one of them with the Event Viewer.  The second file produced an error and would not open.  A quick review using a Notepad++ displayed a long line of seeming random characters.  A quick review with the file command returned no results.  I began to wonder why this file had been named like an Event Log, why it had been deleted, and why did it contain random characters.  Dreams of finding the smoking gun started dancing through my head, but how could I know what this file contained if there was no decent file signature information.

Well, a quick review of my analysis tool answered all of my questions.  When I initially copied the file out I had noticed that it had been deleted, but I failed to notice that it had been overwritten.  Mystery solved, sort of.  I still didn’t know what was in that file, or to be more precise, what information was currently stored at the file’s old location.  As I stated, the data appeared to be random characters which initially lead me to believe that the new file was encrypted.  But how could I tell?  I began to wonder about character frequency and how I would be able to determine whether or not a file was encrypted and contained truly random character representation and how those files would compare to other files.

I decided to try and write a program that would show a plot of the number of times a character occurred in a file.  Truly random character representation, such as you would find in an encrypted file, should show an even distribution of characters.  Whereas a text file would, generally, show a greater concentration of characters with a byte representation less than 127 (printable characters) and those characters would vary according to the normal character representation of the English language (my language of choice).

Enter matplotlib, numpy, and Python(x,y).   Or, more precisely, Python(x,y) since I was doing this on a Microsoft XP system.  Python(x,y) provided a quick and easy Python installation which includes many powerful extras.  As this installation was designed for scientists it includes the Python math modules matplotlib and numpy, among others.  Matplotlib and numpy were what I required to show the frequency of the characters within a file by printing out a histogram.  After some trial and error I was able run the script and get a nice pop-up window with the histogram plotted with enough detail to determine differences between different file types.

The following examples show the graphed output of the script.  The first image is a histogram representation of a Microsoft Word document that I converted to text.  I would have used the MS Word document itself but the amount of NULL characters affects the frequency range represented on the Y-axis and therefore requires some adjustments.  The second image is a histogram representation of a file that has been encrypted with Truecrypt.  A big difference.

Now, I’m not going to string out this post by including a long list of histogram images of different file types.  Rather, I’m going to leave this post here but point you to the File Content Histograms page where I will be posting images of different file types.  You will also be able to find the script that I used to gather this information.  There is a Linux/Windows python script that will require Python and MatPlotLib and a Windows executable that should not have any requirements to function.

I would also like to say that this is wildly successful at identifying files but I am not going to do that.  You will see when you review the other images that certain files to have a distinguishable pattern, but some of them are so similar that it cannot be used to help with definitive answers.  It can help, however, to point the investigator in the right direction.  For instance, archived files have a similar pattern to executable files and even some image files.  All of this is understandable because these file types use a lot of similar techniques to compress the data.  Despite these similarities, histograms of media files are definitely different then the archived files.  I did find it interesting the the Truecrypt graph was different that the graph of the file encrypted with GnuPG.

Go forth and do good things,

Don C. Weber

Over the past couple weeks I have had a growing appreciation for the hard work that Harlan Carvey has put into his Windows Registry parsing tool RegRipper.  Although tools such as MiTeC’s RFV are still necessary when reviewing Windows Registry Hives, RegRipper provides an easy means to gather data into a text document for exporting into case notes and reports.

What really makes RegRipper worth while is that Harlan has gone out of his way to create a tool that is easily extensible. RegRipper pulls data out of Windows Registry Hives through the use of plugins.  Although he has created many plugins that are already included in RegRipper there are always going to be something else that would be useful to pull and document.

A good example is a recent case I was working on.  I needed to know how big a Windows Event Log was set to grow.  Through a little research I discovered the very useful Windows article, Eventlog Key, covering the subject.  Using the information in this article I was able to pull out the information using RFV.  Of course, I had already run RegRipper and determined that this information had not been pulled by an existing plugin.  I started thinking that this information would be useful in the future but I didn’t have time to write a plugin so I just exported the data by hand and drove on.

Later, in the same case, it became necessary to look for system and program crash dumps.  This meant that I needed to know whether the system had been configured to dump the contents of memory to a file when the operating system detected a crash.  Searching the output of RegRipper again showed that this information had not been pulled by a plugin.  After a little research I found Overview of memory dump file options for Windows Server 2003, Windows XP, and Windows 2000 and Dr Watson.  The first article explains the configuration settings for crash dumps that occur when a Windows system experiences the Blue Screen of Death (BSOD).  The second article details the Windows Registry configuration for Dr. Watson which “is a program error debugger that gathers information about your computer when an error (or user-mode fault) occurs with a program.”  Although I did have to pull the information by hand, this made me realize the creating a few RegRipper plugins might be worth while for future reports.

So, I did it.  I wrote three new plugins titled eventlog.pl, drwatson.pl, and crashdump.pl.  These plugins have been posted to the RegRipper Forum (registration required) where you can copy and include them in your plugin directory.  For now, if you want to run these plugins you will not be able to use them with the GUI version of the tool as they have only been tested by running them with rip.pl.  Your comments, updates, review, etc would be greatly appreciated.  Leaving your comments in the RegRipper Forum would be even better as everybody would benefit.

It is my understand that Harlan will include these, or at least his own version of these plugins as he will probably want the formating to remain consistent, in his next release.  Hopefully you find them useful.

NOTE: I just spoke with Harlan and there will be no need to update RegRipper to include these plugins.  Just grab them from the RegRipper forums, include them in your plugins directory, and you are off to the races.

Formatting, hmmm.  That brings up a good question.  Should there be an XML output for RegRipper?  Not that I know of any tools that would pull it in, but who knows what the future will bring.  But, it does sound like a good poll question.

n

Go forth and do good things,

Don C. Weber

I decided to follow up the *nux Live Acquisition Techniques post from a few days ago with a demonstration of image or file manipulation using DD and SPLIT.  This will help me get it all straight in my head while documenting it for prosterity, yours and mine.  Certainly there are other tools to do this, but knowing the basics is key to being good at anything.

Here is the scenario.

• Copy the swap partition using DD.  Get one big image and start manipulating it.  I could just copy swap every time, but as it continuously changes I will have a problem verifying some of the commands or techniques were successful.
• Get a hash of the image.
• Chop the image of the swap partition into smaller pieces using DD and the SPLIT.
• Pull the chunks back together using CAT.
• Verify that CAT successfully rebuild the image by checking the hash.
• Delete the last two chucks to simulate that the original copy, if it had been run using SPLIT, failed at some point for any reason.
• Chop the swap partition image again but this time skip the good chunks and only re-run the bad chunks.  This could end up saving A LOT of time in the imaging process.  Which, in turn, saves the customer money.
• Pull the new chunks together using CAT.
• Verify that the new chucks can be used to create a valid image by checking the hash.
• Stop SCRIPT, write post, grab beer (should have remembered to do this at the beginning).

In the following output I have added my notes while also bolding interesting pieces of output.  I did have a little glitch when trying to skip the good chunks, so be sure to watch for it and what I did to correct the problem.

user@cutsec:~$ script dd_stuff.txt <- Start SCRIPT so I don’t have to cut and paste
Script started, file is dd_stuff.txt
user@cutsec:~$ sudo -i <- Being root makes imaging swap easier. Plus, I like power!!
[sudo] password for user:
root@cutsec:~# cd /opt/Test
root@cutsec:/opt/Test ls
root@cutsec:/opt/Test dd if=/dev/sda5 of=./swap_orig.dd <- Copy an Image of the Swap Partition
2104452+0 records in
2104452+0 records out
1077479424 bytes (1.1 GB) copied, 96.2791 s, 11.2 MB/s
root@cutsec:/opt/Test ls -al
total 1053268
drwxr-xr-x 2 root root 4096 2008-10-01 22:19 .
drwxr-xr-x 3 root root 4096 2008-10-01 11:46 ..
-rw-r–r– 1 root root 1077479424 2008-10-01 22:20 swap_orig.dd
root@cutsec:/opt/Test md5sum swap_orig.dd <- Hash it for verification
9a63cfbea3005551f4021aac7c287997 swap_orig.dd
root@cutsec:/opt/Test dd if=swap_orig.dd | split -d -b 200m - swap_split.dd. <- Split the Partition Image into small chunks
2104452+0 records in
2104452+0 records out
1077479424 bytes (1.1 GB) copied, 105.6389 s, 10.2 MB/s
root@cutsec:/opt/Test ls -al
total 2106548
drwxr-xr-x 2 root root 4096 2008-10-01 22:26 .
drwxr-xr-x 3 root root 4096 2008-10-01 11:46 ..
-rw-r–r– 1 root root 1077479424 2008-10-01 22:20 swap_orig.dd
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.00
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.01
-rw-r–r– 1 root root 209715200 2008-10-01 22:26 swap_split.dd.02
-rw-r–r– 1 root root 209715200 2008-10-01 22:26 swap_split.dd.03
-rw-r–r– 1 root root 209715200 2008-10-01 22:26 swap_split.dd.04
-rw-r–r– 1 root root 28903424 2008-10-01 22:26 swap_split.dd.05
root@cutsec:/opt/Test cat swap_split.dd.0* >>./swap_cat.dd <- Pull them back together using the CAT command
root@cutsec:/opt/Test ls -al
total 3159808
drwxr-xr-x 2 root root 4096 2008-10-01 22:28 .
drwxr-xr-x 3 root root 4096 2008-10-01 11:46 ..
-rw-r–r– 1 root root 1077479424 2008-10-01 22:30 swap_cat.dd
-rw-r–r– 1 root root 1077479424 2008-10-01 22:20 swap_orig.dd
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.00
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.01
-rw-r–r– 1 root root 209715200 2008-10-01 22:26 swap_split.dd.02
-rw-r–r– 1 root root 209715200 2008-10-01 22:26 swap_split.dd.03
-rw-r–r– 1 root root 209715200 2008-10-01 22:26 swap_split.dd.04
-rw-r–r– 1 root root 28903424 2008-10-01 22:26 swap_split.dd.05
root@cutsec:/opt/Test md5sum swap_cat.dd <- Verify CAT worked properly
9a63cfbea3005551f4021aac7c287997 swap_cat.dd
root@cutsec:/opt/Test rm swap_split.dd.03 swap_split.dd.04 swap_split.dd.05 <- Remove chunks to simulate DD or SPLIT command failure
root@cutsec:/opt/Test ls -al
total 2721540
drwxr-xr-x 2 root root 4096 2008-10-01 22:33 .
drwxr-xr-x 3 root root 4096 2008-10-01 11:46 ..
-rw-r–r– 1 root root 1077479424 2008-10-01 22:30 swap_cat.dd
-rw-r–r– 1 root root 1077479424 2008-10-01 22:20 swap_orig.dd
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.00
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.01
-rw-r–r– 1 root root 209715200 2008-10-01 22:26 swap_split.dd.02
root@cutsec:/opt/Test dd if=./swap_orig.dd bs=200MB skip=3 | split -d -b 200m - swap_new_split.dd. <- Start copying by Skipping first 3 chunks of 200MB
2+1 records in
2+1 records out
477479424 bytes (477 MB) copied, 38.3604 s, 12.4 MB/s
root@cutsec:/opt/Test ls -al
total 3188300
drwxr-xr-x 2 root root 4096 2008-10-01 22:37 .
drwxr-xr-x 3 root root 4096 2008-10-01 11:46 ..
-rw-r–r– 1 root root 1077479424 2008-10-01 22:30 swap_cat.dd
-rw-r–r– 1 root root 209715200 2008-10-01 22:36 swap_new_split.dd.00
-rw-r–r– 1 root root 209715200 2008-10-01 22:37 swap_new_split.dd.01
-rw-r–r– 1 root root 58049024 2008-10-01 22:37 swap_new_split.dd.02 <- Note the size
-rw-r–r– 1 root root 1077479424 2008-10-01 22:20 swap_orig.dd
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.00
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.01
-rw-r–r– 1 root root 209715200 2008-10-01 22:26 swap_split.dd.02
root@cutsec:/opt/Test mv swap_new_split.dd.00 swap_split.dd.03
root@cutsec:/opt/Test mv swap_new_split.dd.01 swap_split.dd.04
root@cutsec:/opt/Test mv swap_new_split.dd.02 swap_split.dd.05
root@cutsec:/opt/Test ls -al
total 3188300
drwxr-xr-x 2 root root 4096 2008-10-01 22:40 .
drwxr-xr-x 3 root root 4096 2008-10-01 11:46 ..
-rw-r–r– 1 root root 1077479424 2008-10-01 22:30 swap_cat.dd
-rw-r–r– 1 root root 1077479424 2008-10-01 22:20 swap_orig.dd
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.00
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.01
-rw-r–r– 1 root root 209715200 2008-10-01 22:26 swap_split.dd.02
-rw-r–r– 1 root root 209715200 2008-10-01 22:36 swap_split.dd.03
-rw-r–r– 1 root root 209715200 2008-10-01 22:37 swap_split.dd.04
-rw-r–r– 1 root root 58049024 2008-10-01 22:37 swap_split.dd.05
root@cutsec:/opt/Test cat swap_split.dd.0* >>./swap_cat2.dd <- Pull new chunks together
root@cutsec:/opt/Test md5sum swap_orig.dd swap_cat.dd swap_cat2.dd <- Verify success
9a63cfbea3005551f4021aac7c287997 swap_orig.dd
9a63cfbea3005551f4021aac7c287997 swap_cat.dd
eec1975aed363dbd2254262594577da7 swap_cat2.dd <- FAIL!!
root@cutsec:/opt/Test rm swap_split.dd.03 swap_split.dd.04 swap_split.dd.05 <- Remove bad chunks
root@cutsec:/opt/Test ls -al
total 3803292
drwxr-xr-x 2 root root 4096 2008-10-01 23:02 .
drwxr-xr-x 3 root root 4096 2008-10-01 11:46 ..
-rw-r–r– 1 root root 1106625024 2008-10-01 22:42 swap_cat2.dd
-rw-r–r– 1 root root 1077479424 2008-10-01 22:30 swap_cat.dd
-rw-r–r– 1 root root 1077479424 2008-10-01 22:20 swap_orig.dd
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.00
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.01
-rw-r–r– 1 root root 209715200 2008-10-01 22:26 swap_split.dd.02
root@cutsec:/opt/Test dd if=./swap_orig.dd bs=200M skip=3 | split -d -b 200m - swap_new_split.dd. <- Try Skip again but this time use the proper bs, MB = 1024*1024 but M = 1000*1000
2+1 records in
2+1 records out
448333824 bytes (448 MB) copied, 39.6093 s, 11.3 MB/s
root@cutsec:/opt/Test ls -al
total 4241560
drwxr-xr-x 2 root root 4096 2008-10-01 23:03 .
drwxr-xr-x 3 root root 4096 2008-10-01 11:46 ..
-rw-r–r– 1 root root 1106625024 2008-10-01 22:42 swap_cat2.dd
-rw-r–r– 1 root root 1077479424 2008-10-01 22:30 swap_cat.dd
-rw-r–r– 1 root root 209715200 2008-10-01 23:03 swap_new_split.dd.00
-rw-r–r– 1 root root 209715200 2008-10-01 23:03 swap_new_split.dd.01
-rw-r–r– 1 root root 28903424 2008-10-01 23:03 swap_new_split.dd.02 <- Note the size, that looks better
-rw-r–r– 1 root root 1077479424 2008-10-01 22:20 swap_orig.dd
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.00
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.01
-rw-r–r– 1 root root 209715200 2008-10-01 22:26 swap_split.dd.02
root@cutsec:/opt/Test mv swap_new_split.dd.00 swap_split.dd.03
root@cutsec:/opt/Test mv swap_new_split.dd.01 swap_split.dd.04
root@cutsec:/opt/Test mv swap_new_split.dd.02 swap_split.dd.05
root@cutsec:/opt/Test ls -al
total 4241560
drwxr-xr-x 2 root root 4096 2008-10-01 23:05 .
drwxr-xr-x 3 root root 4096 2008-10-01 11:46 ..
-rw-r–r– 1 root root 1106625024 2008-10-01 22:42 swap_cat2.dd
-rw-r–r– 1 root root 1077479424 2008-10-01 22:30 swap_cat.dd
-rw-r–r– 1 root root 1077479424 2008-10-01 22:20 swap_orig.dd
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.00
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.01
-rw-r–r– 1 root root 209715200 2008-10-01 22:26 swap_split.dd.02
-rw-r–r– 1 root root 209715200 2008-10-01 23:03 swap_split.dd.03
-rw-r–r– 1 root root 209715200 2008-10-01 23:03 swap_split.dd.04
-rw-r–r– 1 root root 28903424 2008-10-01 23:03 swap_split.dd.05
root@cutsec:/opt/Test rm swap_cat2.dd
root@cutsec:/opt/Test cat swap_split.dd.0* >>./swap_cat2.dd <- Pull new chunks together
root@cutsec:/opt/Test ls -al
total 4213068
drwxr-xr-x 2 root root 4096 2008-10-01 23:08 .
drwxr-xr-x 3 root root 4096 2008-10-01 11:46 ..
-rw-r–r– 1 root root 1077479424 2008-10-01 23:09 swap_cat2.dd
-rw-r–r– 1 root root 1077479424 2008-10-01 22:30 swap_cat.dd
-rw-r–r– 1 root root 1077479424 2008-10-01 22:20 swap_orig.dd
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.00
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.01
-rw-r–r– 1 root root 209715200 2008-10-01 22:26 swap_split.dd.02
-rw-r–r– 1 root root 209715200 2008-10-01 23:03 swap_split.dd.03
-rw-r–r– 1 root root 209715200 2008-10-01 23:03 swap_split.dd.04
-rw-r–r– 1 root root 28903424 2008-10-01 23:03 swap_split.dd.05
root@cutsec:/opt/Test md5sum swap_orig.dd swap_cat.dd swap_cat2.dd <- Verify success
9a63cfbea3005551f4021aac7c287997 swap_orig.dd
9a63cfbea3005551f4021aac7c287997 swap_cat.dd
9a63cfbea3005551f4021aac7c287997 swap_cat2.dd <- Success!!
root@cutsec:/opt/Test logout
user@cutsec:~$ exit
Script done, file is dd_stuff.txt

There you have it.  The basics of using system commands to image a partition, chop it up, and pull it all back together.  Hopefully this is useful in some capacity.

Go forth and do good things,

Don C. Weber

Not all incident responses go according to plan.  This means that a responder has to have multiple methods for accomplishing tasks.  Harlan Carvey brings this up on his blog often and it is why Ed Skoudis created his famous WMIC Kung Fu write-up and turned it into a SANS Course: Windows Command-Line Kung Fu In-Depth for Info Sec Pros.

On a recent engagement this fact came into play.  I went on site knowing that I would have multiple types of Unix and Linux operating systems to potentially acquire.  From the customer’s description I also knew that I would be dealing with some older equipment but nothing from their descriptions seemed out of the ordinary.  Once I  got on site I reviewed the situation with the customer and everything seem normal.  As I was not worried about collecting volatile data from the system I requested the customer set up a maintenance window and temporarily take the systems off line in a manner that provided the least amount of impact to their operations.

All went well until the system administrator handed me the hard drive.  It all seemed fine at first until I tried to plug the drive into the adapter that was connected to my write-blocker.  The pins didn’t match up.  Although there were plenty of pins across, the layers were placed too close together.  It was fine for the blade server that it came out of, but none of my adapters could plug into this configuration.  At first I figured this was no big deal.  I decided to boot to a Linux boot disk and just copy the drive from there to a USB hard drive.  Well, there was two problems with that: 1. The blade server did not have a CD-ROM drive, and 2. the USB port was version 1.1 and would not recognize the external hard drive that I had purchased (no big deal because 12MB per second would not cut it either!!).  So, plan one == bust and plan two == bust.

So what was plan three?  Well, dump over NFS using native commands, of course.  Luckily the system administrator was well versed in NFS and the commands we were about to use.  So there was not a lot of explaining, I didn’t have to type commands, and my only real job (as it should be in this type of situation) was mindful and guided keystroke monitoring.  Here is what we did.

• To start off, please review this great guide on setting up NFS via the Ubuntu community wiki.  It does not dive deeply into NFS.  It just gives the basics on how to get it up and running on a live system or Live CD.  Of course, mileage may vary depending on distro, so beware.  Once it was all set up we navigated to the correct directories and prepared to acquire.  When all was done the system we were acquiring had a remote share mounted to /tmp/target.
• Before we started copying files we needed to keep track of everything we did.  Of course we could have done that as soon as we logged into the system, but as it was the system administrator performing the actions and this was not necessarily a “Live Acquisition” it was not completely necessary and we needed to have a good place, like an NFS mounted directory, to copy our files.  So we changed to the /tmp/target directory and ran the script command to record our actions and sent it to an appropriately titled file.
• Next we needed to record the system time.  Although we did note the BIOS time when the system was booting up, we need to record the time displayed by the operating system.  Running a quick date command proved enough.  No redirection was necessary as we were already recording everything into a file.
• We needed to know what type of system we were running our commands on.  A quick uname accomplished this.  Of course different distros also have different methods of providing version information about themselves.  Look to website for the distro you are working with to determine which file to check in and then cat that information so that it is displayed to the screen and thereby written to your script file.
• In order to get all of the system information written to the correct directory we needed several commands.  Unfortunately, if the system had been compromised and a rootkit had been deployed, there was the potential that critical information would not be copied.  To help alleviate some concern behind this issue we decided to run a few commands.  First we needed to know where each of our commands were located.  This was determined through a simple which command.  This let us know where the system thought the program was located and allowed us to call it directly as we did not want to rely on the $PATH environment variable.  Next we needed to get the versions for each command so that we knew which versions of the commands we were working with in case of any problems or other issues such as non-standard programs.  Most commands will take either a –version or -V and provide specific details about the command.  In this case we needed to know the version of md5sum, dd, and split that was provided by the system.  Once this information was displayed we had it recorded.  Next we took the md5sum of each of these commands just to be sure.  If necessary these outputs could be checked against known good versions from known good sources of the distro.  If really paranoid and the tools are available, other hashing tools could be used.  Although all of these tools could be “rooted” it is not very likely.  Plus, in this instance, we were not too worried about a rootkit, but you never know.
• Now were were ready to copy the information to our mounted directory.  The hard drive was recognized as hda by the operating system.  This means that we needed to copy /dev/hda using the dd command.  But since we were copying a large hard drive (80 GB +) we needed to use the split command to help with errors.  Now, I did not know this before we started, but I heard from one of my co-workers and it was confirmed by the system administrator, that copying large files (everything is a file in *nix) to a NFS mounted directory was not completely reliable.  To help control this I was told that copying to 2GB files would be the best way to handle it.  If something failed then it would be easier to pick up from the last good file and just calculate the proper offsets to start the copying process from  that point instead of the beginning.  Here is the command we ended up running: /bin/dd if=/dev/hda | /usr/bin/split -d -b 2000m - /tmp/target/server_name.dd. Although you can review the split man page to understand the full command, I will point out two things.  The dash “-” is necessary because it tells the command to use the STDIN from the pipe as the input file.  The “.” at the end of the command is also necessary because it is what split uses to number the files it creates.
• Depending on the system this will run for quite a while.  But before you run off for coffee and donuts or to analyze another system you’ll want to run one more command.  That command is the date command.  To do this just type date and press enter.  This will automatically run the date command once the previous command has completed running.  This time and date gets recorded into the script and the full run time is recorded for use in reporting and future efforts.

Although all of this took some effort to do, the end result was that I had acquired the system in a manner that I could use multiple tools to evaluate the information.  Once this was all complete I moved onto the second webserver where we had similar issues with acquiring the hard drive as the system was running on the same blade server.  I would love to tell you that I just followed my previous steps and that all went well.  Unfortunately I cannot.  We did perform all of the steps but as soon as we hit enter on the dd command the system virtually locked up.  This came as quite a surprise as the previous system did not take a significant performance hit during the acquisition.  We stopped the command and did quick review of the logs on this new system.  The log was full of I/O errors and we could only assume that the hard drive was slowly failing.  Therefore, plan three == fail.  That is where the system administrator came to my rescue.  As the system did not have any problem backing up every night we decided to just tar the operating system over to the NFS mounted directory.  Although this would not get everything off of the drive, it would at least get some of the information and some is better than none, at least at this point. Here how the tar was accomplished.

• Follow all of the previous steps to get the information about the system and the commands.
• Next you need to understand the version of tar provided by the distro you are working with.  Read the man page just to be sure you have the options determined correctly.  Because of the way that tar interacts with NFS (thank you, schism) it is probably going to be necessary to use the “–one-file-system” option.  This means that you will have to acquire each of your mounted directories separately.  For instance, if you have one partition mounted at /, one at /boot, and one at /home the “–one-file-system” command will not follow down the mounted directories.  You will have to do each separately.  The following command worked like a charm and then repeated for each mount point.  /bin/tar –one-file-system -cvf /tmp/target/server_name_root.tar /

So, after four tries I had all of the information that I needed to start my analysis.  Well, at least for these systems.  This simple acquisition really threw me for a loop initially.  Not only did I have to pull out multiple acquisition techniques it also affected my time on site.  That might not seem like much, but these extra step meant that I was on site for an additionally two days.  No small impact on the customer.  But, it could have been a lot worse.  If I had not been prepared with fall back alternatives, then I could have spent even more time on site.  Not only would this have impacted the customer’s pocket book but it would have also sewn the seeds of doubt into my capabilities.  This could have, in turn, jeopardized their view of the results of the analysis as well as the potential for the continuation of a forensic, or any other, business relationship.

Go forth and do good things,

Don C. Weber

So far my first real week with IBM ISS ERS has been uneventful.  I am currently awaiting on my new gear and for the opportunity to shadow one of the team members.  Sometimes you want to say “Somebody get hacked already.”  But that would be irresponsible……right?

Right now I am just spinning up on tools and methods by following some of Harlan’s directions:

• Images to play with
• Getting started, or forensic analysis on the cheap

So far his recommendation of getting to know ProDiscover has been worth it.  Easy to use and get to know.  I also got the chance to work with his RegRipper for the first time.  It quickly gave me the information I needed from the registry, although I do wish it would have worked in Linux.  I only say that because I started my analysis for the NIST Hacking Case images working with Autopsy.  Autopsy worked fine until I had to review the registry and I could not find a Linux-based solution.  My first instinct was to jump back onto Windows for RegRipper since I was fairly certain it would work.  This doesn’t mean there are not Linux-based Registry analysis solutions out there, I just didn’t find them in under five minutes.  Autopsy might also have a way to accomplish this as well, but all I could figure out was how to review the Registry in ASCII (virtually unreadable), HEX (readable but hard to search), and ASCII Strings (always seemed to be missing some critical information).

I have a feeling that in the future I am going to make many such decisions.  There are so many tools developed by so many people the proper tool could potentially be on any OS and/or programming language.  This is what, I believe, Harlan was hinting about in his post: Forensic Analysis Applications.

Go forth and do good things,

Don C. Weber