Journey Into Incident Response

Review of Windows Forensic Analysis 3rd Edition

2012-02-26T21:49:00.006-05:00

Last week I finished reading Windows Forensic Analysis 3rd Edition by Harlan Carvey. I think WFA 3/e will be a welcomed addition to anyone’s Digital Forensic and Incident Response (DFIR) library. The book has a lot to offer but the content about Windows 7 and processes is why I’m glad it’s in my library.

All about Windows 7

When thinking about references we have available when performing digital forensic examinations on a Windows 7 system there aren’t a lot that come to mind. We have some great presentation slides (cough cough Troy Larson cough), a few blog posts, and the paper SWDGE Technical Notes on Microsoft Windows 7. However, there isn’t a DFIR book who’s main focus is about Windows 7 until now. WFA 3/e comes out of the gates talking about Windows 7 in Chapter 3. The chapter goes into great detail about volume shadow copies (VSCs). What VSCs are, how to access VSCs, different methods to examine VSCs, and different tools available to use against VSCs. The Windows 7 theme continued into Chapter 4 File Analysis with topics such as event logs and jumplists (a new artifact showing user activity). Rounding out the forensic nuggets about Windows 7 was Chapter 5 Registry Analysis. At first I was worried about reading the same information I read in Windows Forensic Analysis 2nd Edition or Windows Registry Forensics but my worries were unfounded. The author has said numerous times WFA 3/e is not a rewrite to his other books and is a companion book. The registry analysis chapter showed how true the statement is because it focused on what information can be pulled from Windows 7 registry hives. The author also highlighted the differences between Windows 7 and previous Windows operating systems. If anyone is going to be encountering Windows 7 systems then WFA 3/e will be one of the references to have within reaching distance.

Process, Process, Process

WFA 3/e discusses numerous Windows artifacts and different tools capable of parsing those artifacts. The book also provides context about the artifacts and tools by discussing the DFIR processes behind them. Right off the bat the author lays the foundation by discussing Analysis Concepts in Chapter 1. There is even a section about tools versus processes. A quote I liked was “analysts can find themselves focusing on specific tool or application rather than the overall process”. I see a lot of DFIR discussions focus on tools instead of the overall process on how those tools could be used. I even fell into this trap earlier in my career. Whenever I read a DFIR book or any analysis book for that matter I want to see the author explain the overall process because it makes it easier for me to translate the information over to my work. WFA 3/e did an outstanding job discussing processes which can be seen in various chapters. The two chapters I wanted to mention specifically are 6 and 7.

Chapter 6 Malware Detection was dedicated to how the author goes about to finding malware on a system. The author lays out the overall process he follows (a checklist accompanies the book) and then goes into detail about what he is looking for and what tools he uses to carry out the process. The same approach is used in Chapter 7 Timeline Analysis. The author discusses his process for performing timeline analysis including: how he approaches timelines, how he builds timelines, and how he examines timelines.

It’s nice to see the processes someone else uses and the case experiences shared by the author helped reinforced why the process is important. WFA 3/e doesn’t disappoint because the author not only provides tools to do DFIR work but he lays out a process that others can follow.

Don’t Overlook the Materials Accompanying the Book

The author made the supporting material to WFA 3/e available online (on this Google page) and this is a welcomed feature for those of us who bought the book’s electronic version. Similar to the author’s previous books I already mentioned, the materials accompanying his book are full of DFIR goodies such as ….

        * jumplist parser (jl.pl): the author wrote a script to parse jumplists. This is the only command-line tool I know of that can parse jumplists. I tested script against jumplists inside VSCs and the results were impressive.

        * Malware detection capability: there are different scripts to help with detecting malware including mbr.pl to find mbr infections and wfpchk.pl to check the contents of the dllcache.

        * Checklists: there are a few different checklists that may be useful references during an examine.

        * Source code: the source code is provided to all the scripts. I’m teaching myself Perl so being able to read the code helps me get a better understanding about not only knowing how the script works but how the author puts scripts together.

Clarification about ShadowExplorer

There were no significant improvements I could suggest to make WFA 3/e better. I could make a couple minor suggestions but there isn’t anything glaring. However, there was something I wanted to clarify. Chapter 3 Volume Shadow Copies Analysis mentions using ShadowExplorer to access and browse VSCs. The author mentioned that ShadowExplorer will only show the VSCs available within the volume or drive on which the program is installed on. That ShadowExplorer has to be reinstalled on the drive in order to view its VSCs. The section I’m referring to is on Kindle page 1,366. I might have misunderstood this statement and if I did then please ignore this section to my book review.

ShadowExplorer only needs to be installed on your forensic workstation and it can be used to view any volume’s VSCs mounted to the workstation. The drop down menu next to the drive letter lets you select any drive letter on the workstation to view that volume’s VSCs. I’ve used ShadowExplorer in this manner to view VSCs for drives connected to my system through USB docks and to view the VSCs inside a mounted forensic image. It's a nice way to preview VSCs.

Overall Five Star Review

Overall I give WFA 3/e a five star review (Amazon rating from 0 to 5 stars). The book has a lot to offer from Windows 7 artifacts to DFIR processes to better understanding the artifacts we encounter. As I said in the beginning to the post, the book is a welcomed addition to anyone’s DFIR library and it’s a great companion book to the author’s other books about digital forensics on Windows systems.

I wanted to say how humbling it was to see the author mention my blog. Before I became more active online I lurked in the shadows following a lot of people in the DFIR community. Harlan is one of those people. Every time I see someone mention me I am still taken back. I wanted to say thank you Harlan for the recognition and including an earlier version to my Regripper VSC batch script in your materials. (an updated version to the script can be found here).

Examining VSCs with GUI Tools

2012-02-22T17:58:00.000-05:00

Over the past few posts I’ve been discussing how to examine data while it’s still inside Volume Shadow Copies (VSCs). I refer to the approach as Ripping VSCs because the concept behind it is to extract data from a system/forensic image as fast as possible so an examiner can start their analysis. This allows an examiner to start analyzing data within seconds instead of having to wait minutes in order to gather the information to analyze. The two different methods to rip VSCs are the Practitioner and Developer methods. Both methods don’t necessary use tools with Graphical User Interfaces (GUIs) because these types of tools are not great for automation. However, GUI tools are viable options for parsing data inside VSCs and they shouldn’t be overlooked.

To run a GUI tool against a VSC requires the that VSC is accessed a certain way. As I mentioned in a previous post chapter 3 in Harlan Carvey’s WFA 3/e shows how to create a symbolic directory to a VSC. The other method I saw in Troy Larson’s slide deck where he exposes a VSC as a network share. Before I show how Harlan and Troy access VSCs I wanted to share my own failure in figuring this out so others know what didn’t work for me.

When I first started working with VSCs I created symbolic links to VSCs using the /j switch with mklink. The /j switch creates a Directory Junction which worked well for my needs since I was running command-line tools against it. However, I was unable to get GUI tools to traverse through a directory junction and this limited the tools I could use to parse VSCs’ data. To get it to work I knew the VSC had to be exposed like a folder or drive but my attempts were unsuccessful. I tried DiskShadow (I did get this to work in Windows 7 by leveraging the DLL search order vulnerability) and vshadow (included in the SDK) but neither program can mount a persistent VSC to a folder. The VSCs on Windows 7 and Vista systems are persistent so at that point I didn’t have a way to expose them for GUI tools to work. That was until I saw what Harlan and Troy were doing.

Exposing VSCs as Symbolic Folder

I already discussed how Harlan was creating a symbolic directory to a VSC in the Practitioner Method post. If anyone wants more information than what I’m providing here I’d recommend you check out the post. The mklink command was used with the /d switch to create a symbolic directory to a VSC. The following command creates a symbolic directory named vsc1 pointing to C volume’s first VSC and the picture shows the result:

mklink /d c:\vsc1 \\?\GLOBALROOT\Device\HardDiskVolumeShadowCopy1\

Any GUI tool can then browse the VSCs or parse any data inside. Side note, to automate creating and removing symbolic links to VSCs I put together the access-vsc.bat script located here. See the following pictures for some examples:

Windows Explorer Browsing VSC

Mitec WFA Analyzing Prefetch Files

FTK Imager Browsing VSC

Exposing VSCs as a Network Share

I could never do justice trying to explain the information Troy provides in his slides. That’s why I won’t even try to summarize anything and I recommend to anyone reading my post who hasn’t seen the presentation I’m referencing to check it out (here’s the link again). Slide 53 shows how to expose a VSC as a network share and I reposted the command below.

net share testshadow=\\.\HarddiskVolumeShadowCopy18\

After the command is ran then the share testshadow points to VSC 18. To make things easier for browsing with GUI tools I’d map the share to network drive. The command below creates a mapped drive using drive letter K.

net use K: \\127.0.0.1\testshadow

Similar to the symbolic directory, any GUI tool can browse the VSC or parse data inside VSCs. See the following pictures for some examples:

Windows Explorer Browsing VSC

MalwareBytes Scanning VSC

Ripping VSCs Summary

The majority of my casework involves Windows XP operating systems so I rarely encounter VSCs. The few cases I did have involving Windows Vista and 7 VSCs played a critical role in my examinations since they allowed me to see how data evolved overtime. As more organizations begin the migration from Windows XP to Windows 7 or 8 then examining VSCs will become a common occurrence. Knowing the different approaches for examining VSCs will be vital for a successful examination. One of those approaches is to parse data while it’s still stored inside VSCs. The different methods to accomplish that include: the Ripping VSCs Practitioner and Developer methods as well as manually using any GUI tool of choice.

Ripping VSCs – Developer Examples

2012-02-14T21:10:00.006-05:00

The previous post, Ripping VSCs – Developer Method, provided a detailed explanation about how data can be parsed directly inside Volume Shadow Copies (VSCs). Unlike the Practitioner Method, the Developer Method accessed data directly thereby bypassing the need to go through a symbolic link. The previous post explained how and why it’s possible to programmatically access files in VSCs. Ripping VSCs – Developer Examples picks up where the last post left off by demonstrating how existing scripts can be used to parse data inside VSCs.

The Ripping VSCs – Developer Method made two key points that need to be understood about accessing data in VSCs. The first take away is that to read or parse data directly requires a handle to be opened to the object using the full UNC path. The line below shows how to open a handle to the IE9_main.log file in Volume Shadow Copy 18:

open FILE, \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy18\WINDOWS\IE9_main.log or die $!;

The second take away is that to query information by executing commands against a folder/file's path requires a handle to the object to be opened into a variable. The line below shows how to open a handle to the IE9_main.log file in Volume Shadow Copy 18 into the variable $file:

open ($file, \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy18\WINDOWS\IE9_main.log) or die $!;

To modify or write a script to parse data inside a VSC means one of the handles above has to be used. The easiest way I found to change existing scripts is to identify the points where the script is interacting with an external file. Then change that code to use either a handle or make it avoid executing commands against a file/directory path. This is how I aproached the three scripts discussed in this post.

The scripts I wanted to try to get to work against VSCs are ones I’ve used a lot in the past. I knew what results I should expect so it made things easier to identify any issues I caused. One script already worked against VSCs which was Kristinn Gudjonsson’s read_open_xml_win.pl (parses Office 2007 metadata). I picked two other scripts to modify because the changes reinforce the two take aways from the The Ripping VSCs – Developer Method post. These scripts were Harlan Carvey’s RegRipper (parses registry hives) and lslnk.pl (parses Windows link files). I’m discussing the scripts starting with the one requiring no modifications then progressing to the more difficult changes.

Disclaimer: the modifications being made to these scripts are to demonstrate how they can be altered in order to support examining VSCs. As such, my recommendations for anyone wanting to make these changes for actually casework would be to reach out to Kristinn and Harlan (the authors) for feedback on the best way to alter their scripts.

read_open_xml_win.pl against VSCs

read_open_xml_win.pl is a script to read metadata from Microsoft Office 2007 documents. The script has no options and only takes the file path to the office document. At the time I wrote this post the current version was 0.1 and by default it was able to parse files directly inside VSCs. The picture below shows the script parsing a Word document in VSC 18.

Reviewing the script and identifying where the code interacts with an external file brings you to line 92.

92. # read the parameter (the document)
93. $doc = $ARGV[0];
94.
95. # create a ZIP object
96. $zip = Archive::Zip->new();
97.
98. # read the Word document, that is the ZIP file
99. $zip->read( $doc ) == AZ_OK or die "Unable to open Office file\n";

As the code shows, the file path entered on the command-line is stored in the $doc variable (line 92) and is then read into the ZIP object (line 99). Looking at the module doing this work says “the Archive::Zip module allows a Perl program to create, manipulate, read, and write Zip archive files”. My research identified opening a handle using the IO::File module but the read_open_xml_win.pl script shows other modules that open files can access VSCs as well.

RegRipper against VSCs

RegRipper is a tool to perform registry analysis in examinations. There is a command-line version (rip.pl) as well as a version with a GUI. The two switches I’m using in this post are: -r to specific the registry hive and –p to specify a single plugin (note: -f specifies a plug in file). At the time I wrote this post the current version of Regripper was 20090102 and by default it was unable to parse registry hives directly in VSCs. The picture below shows RegRipper failing to parse the UserInfo key in an ntuser.dat hive in VSC 18.

The error reported by RegRipper was that the ntuser.dat registry hive was not found. Opening rip.pl in a text editor and identifying the point where it interacts with a registry hive brings you to lines 89 and 170. I copied and pasted sections of the code below.

89. if ($config{file}) {
90. # First, check that a hive file was identified, and that the path is
91. # correct
92.      my $hive = $config{reg};
93.      die "You must enter a hive file path/name.\n" if ($hive eq "");
94.      die $hive." not found.\n" unless (-e $hive);

170. if ($config{plugin}) {
171. # First, check that a hive file was identified, and that the path is
172. # correct
173.      my $hive = $config{reg};
174.      die "You must enter a hive file path/name.\n" if ($hive eq "");
175.      die $hive." not found.\n" unless (-e $hive);

The first section (lines 89 to 94) appears to be for when a plugin file is ran (-f switch) while the second section (lines 170 to 175) is for a single plugin file (-p which was ran). Looking at lines 94 and 175 shows the error that appeared when RegRipper failed (ntuser.dat not found). Those two lines are performing an error check to see if the registry hive is present. The issue is the check is performed against a path inside a VSC. Remember the file size issue in the previous post? Commands can’t execute against a path to a VSC since they fail (at least in all my testing). To make RegRipper work with VSCs just make a change to lines 94 and 175. One option is to comment out those lines completely and another option is to remove the –e switch (worked in my testing). For demonstration purposes I commented the lines out. The changed lines are below:

94. # die $hive." not found.\n" unless (-e $hive);

175. # die $hive." not found.\n" unless (-e $hive);

The picture below shows the command is now successful; the modified RegRipper successfully rips the ntuser.dat hive in VSC 18.

Lslnk.pl against VSCs

Lslnk.pl is a script included with WFA 2/e to parse Windows link files. This was the first script I changed to work with VSCs and it was the most difficult one to figure out. The picture below shows lslnk.pl failing to parse a link file (Receipt-#4-Walmart-shredder.docx.lnk) in VSC 18.

Looking at the code to see how it interacts with link files shows three areas of interest. The first is the portion where the file entered on the command line is stored in the $file variable (line 16) and a check is performed to see if the file is present (line 17).

16. my $file = shift || die "You must enter a filename.\n";
17. die "$file not found.\n" unless (-e $file);

The second portion is where the stat command is executed against the file path stored in the $file variable (line 65) and then the file path is printed before the file size (line 66)

64. # Get info about the file
65. my ($size,$atime,$mtime,$ctime) = (stat($file))[7,8,9,10];
66. print $file." $size bytes\n";

The third section is where the file stored in the $file variable is opened into the FH filehandle.

71. # Open file in binary mode
72. open(FH,$file) || die "Could not open $file: $!\n";

Those three sections need to be modified in order for lslnk.pl to parse VSCs directly. The first change is to comment out line 72 because the filehandle needs to be opened in the beginning of the script. Remember to parse files inside VSCs a handle needs to be used? Here is the line commented out and I added my own comment explaining it.

# (corey) Had to move to first in script to access file in VSC
#open($file,$file) || die "Could not open $file: $!\n";

Continuing with the first change the handle needs to be opened before any actions are taken against the external link file. The script uses the $file variable throughout it so the easiest thing to do is to create a new variable (I picked $file_path). The second change is to comment out the error check against the file path while the third change is to open the file into the $file variable. Below are my changes made to the beginning of the script.

use strict;

# (corey) created variable to store file path. (without it this line won't work print $file." $size bytes\n";)
my $file_path = shift || die "You must enter a filename.\n";

# (corey) line below is not needed because of the line above
# my $file = shift || die "You must enter a filename.\n";

# (corey) added and changed the open command so handle is inside a variable
open(my $file,$file_path) || die "Could not open $file_path: $!\n";

# (corey)Line below caused error even though file opened
#die "$file not found.\n" unless (-e $file);

# Setup some variables

The last change is for reporting purposes. The line printing the file size contains the $file variable. This will cause it to print out a glob of characters instead of the file’s path. My $file_path variable contains the file’s path so it can be used with the print command as shown below.

# (corey) had to change the variable in the line below to print the path to the file
#print $file." $size bytes\n";
print "$file_path"." $size bytes\n";

In summary, the changes made were to make lslnk.pl open a file handle into a variable in order to access a file inside a VSC. The other changes were to avoid executing a command against the file’s path (error check) and to change a variable to show the file path. The end result; lslnk.pl is now to able successfully parse the link file (Receipt-#4-Walmart-shredder.docx.lnk) in VSC 18.

Next and Last Post in Series: Examining VSCs with GUI Tools

Ripping VSCs – Developer Method

2012-02-12T21:23:00.012-05:00

For the past couple of weeks I’ve been talking about the Ripping VSCs approach to examining Volume Shadow Copies (VSCs). I started using the approach out of necessity because it allowed me to parse data while it was still inside VSCs. In the Ripping VSCs - Introduction post I mentioned there were two different methods to Ripping VSCs and I already covered the first one which was the Practitioner Method. The second method is the Developer Method and this post will explain it in detail.

As I mentioned before, I’ve been using the Practitioner Method for some time now. I had a lot of time to work and improve the approach which is why it is fully working solution to examining VSCs. I provided in-depth information about the method, working scripts for automation, detailed documentation for the scripts, and even a video demonstrating how to examine VSCs. Anyone can read about the Practitioner Method, grab the scripts, and starting examining data on their cases right away. Unfortunately, the Developer Method is not as polished as the Practitioner Method. In fact, it was about a month and half ago when I figured this method out. I’m releasing my research early on the Developer Method not only to make the Ripping VSCs series well rounded but to share it with the coders and tool developers in the DFIR community. I think they could leverage the information I’m sharing to improve their tools or develop new ones better than I could (so far I read 2.5 books about Perl).

Developer Method Overview

The Practitioner Method accessed VSCs data by traversing through a symbolic link. This method has worked flawlessly for me but a more efficient method would to be to access the data directly. This would avoid the need to make and remove the symbolic links pointing to VSCs. The Developer Method is able to programmatically access the data directly inside VSCs as can be seen in the picture below.

Unlike the Practitioner Method, to use the Developer Method one must know a programming language. The approach is broken down into two steps:

        1. Accessing VSCs
        2. Ripping Data

Both of those steps can be combined into the same script or tool. However, for clarity I will discuss them separately.

Accessing VSCs

There is one similarity between the Practitioner and Developer Methods in how they both access VSCs. Both methods only work on mounted volumes (thus online VSCs) and both require VSCs full paths to be identified. VSCs paths start with \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy# and each VSC will have a unique number. The way to accomplish identifying a volume’s VSCs will be dependent on the person writing the code but I'm currently researching a way to do this without using the vssadmin command. The need to identify the VSCs is where the similarities ends between the two methods. That’s because how the VSCs are accessed is drastically different.

Quick note: I tested accessing VSCs directly using Perl (more specifically Perl v5.12.4 on Windows 7 Ultimate 64 and 32 bit versions). My assumption is this method should work with other programming languages as well because they should be using the same underlying Windows API function calls.

In Perl (and different sections in the Windows System Programming book I’m reading) to read a file or directory a handle must first be created to that object. When Perl interacts with an external file, “Perl labels the connection (not the file itself) with a label called a "filehandle”. The following line shows the path stored in the $file_path variable being opened into a filehandle: open (FILE, $file_path). In this case, the filehandle is named FILE and whatever Perl wants to do with the external file is done so against the FILE label. The simple script below will print to the standard output a file’s contents entered on the command-line.

        $file_path = shift || die "You must enter a filename.\n";
        open FILE, $file_path or die $!;
        print <FILE>;

First I’ll explain the script before showing what it does. The first line is storing the filename entered on the command line into the variable $file_path. I already explained the second line so the last line is what prints the file (notice print executes against the filehandle). ~~note: FILE should be enclosed in the less than and greater than signs but Blogger keeps stripping them out.~~

To see how the script works I ran it against a random log file I found in the Windows folder on my laptop. The screenshot below highlights the script and the filename entered on the command-line and the picture also shows the resulting output.

I went into so much detail explaining how a file is opened in Perl because it works the same way when dealing with VSCs. Opening a filehandle is done the same way whether the file is located in system’s Windows folder or a VSC’s Windows folder. To illustrate, I’ll run the same script against the same file with the one exception, I’m pointing it at a VSC that was created on February 4, 2012 (in case anyone has trouble seeing the screenshot the full path I’m using is \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy18\WINDOWS\IE9_main.log).

To access data directly inside VSCs the only thing that has to be done is to use the full UNC path to the file. Other than that, the data can be treated as if it was stored anywhere else on a system. Then once a handle is opened to a file or directory then it can be read or parsed.

As Sticky Fingaz from ONYX would say “but but but but wait” there’s more. At times a file or directory’s attributes are queried for information about it. One example is obtaining a file’s size. In these instances, a filehandle isn’t used because the commands are executed against the file/directory’s path. There is an issue with executing commands directly against paths to data inside VSCs. To see this issue I’ll use a script (listed below) to print a file’s size that’s entered on the command-line.

        $file_path = shift || die "You must enter a filename.\n";
        ($size) = (stat($file_path))[7];
        print " $size bytes\n";

The script works fine when files are located on a system but doesn’t execute properly against files inside VSCs. The screenshot below shows the script displaying the file IE9_main.log’s size located in the Windows folder but failing against the one in VSC 19.

There is a way to get around this issue; just open a filehandle into a variable. Below shows a slight modification to the script above so it can open a filehandle into a variable (I highlighted in red the changes).

        $file_path = shift || die "You must enter a filename.\n";
        open ($file,$file_path) or die $!;
        ($size) = (stat($file))[7];
        print " $size bytes\n";

The screenshot below shows how the script now works properly.

        Ripping Data

A friend of mine who is a coder always says “a loop is a loop”. He says this in reference to doing different things in programming because when it comes down to it all that is occurring is just loops being written in different ways. The Practitioner Method automated ripping data from VSCs by executing the same command in a loop inside a batch file. To rip data with the Developer Method a loop can be leveraged as well. Adding a loop to the file size script can show the file’s size in different VSCs. Below shows one way to accomplish this:

        @vscs = (9..18);
        $file_path = \\\\?\\GLOBALROOT\\Device\\HarddiskVolumeShadowCopy;
        foreach $num (@vscs) {
                open ($file,"$file_path$num\\WINDOWS\\IE9_main.log");
               ($size) = (stat($file))[7];
               print "VSC$num IE9_main.log size: $size bytes\n";
               close($file);
        }

The screenshot shows the file’s size being ripped from 10 different VSCs.

Research behind Ripping VSCs – Developer Method

Treating files/directories inside VSCs the same as data stored on a system may seem obvious after the fact. For me to come to this conclusion took a lot of research and testing. In my previous posts I didn’t discuss any research but I wanted to follow-up the Developer Method post with the testing I did to shed light on why VSCs can be accessed directly.

At the time, I was working with the Practitioner Method for some time and it never occurred to me to access VSCs directly. Things changed when I read PaulDotCom’s article Safely Dumping Hashes from Live Domain Controllers back in November. There was one line in the article that jumped out to me and I pasted it below.

copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy[X\windows\system32\config\SYSTEM

I was parsing registry hives inside VSCs on live systems by traversing through symbolic links but the command in the article was copying files directly from shadow copies. I tried the Windows copy command myself and I got the same results. It copied data directly from a VSC. I thought if a file could be copied then it could be parsed but I didn’t get around to researching the idea until the following month.

First I wanted to get a better idea about how copy was able to access VSCs directly. I fired up Process Monitor and executed the copy command against a file inside VSC 19. The exact command I ran was:

copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy19\windows\aksdrvsetup.log

I examined Process Monitor’s output to see exactly what copy was doing at the point when the file aksdrvsetup.log was accessed. The screenshot below shows copy calling different function calls such as CreateFile, QueryDirectory, ReadFile, and Closefile. These calls are part of Windows File Management Functions.

If a file could be copied then I wondered what else could be done against a file. I reviewed the built-in Windows commands until I came across one that queries information about files. The attrib command "displays, sets, or removes the read-only, archive, system, and hidden attributes assigned to files or directories". I executed attrib against a file in a VSC to not only see if it would work but to also identify any similarities with the copy command. The command I ran is listed below:

attrib \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy19\windows\aksdrvsetup.log

Looking at Process Monitor’s output showed attrib using the same File Management Functions that copy used as shown below.

At that point I identified two different built-in Windows commands using the same function calls to access files directly inside VSCs. I concluded to rip data directly against VSCs I had to use the same calls. At the time I wasn’t that knowledgeable about system calls so I reached out to my coder friend and asked if those calls could be replicated through programming. He let me know they were just lower level API calls and they can be called when programming. After some research I found the Win32API::File module which provides low-level access to Win32 system API calls for files/dirs in Perl. I was able to put together a script using the module to directly access files in VSCs. However, I was only partially successful in my attempt when I tried to print a logfile to the screen. The output was only the first line from the log file. I was able to print the entire file using a loop but this wasn’t a feasible option for parsing files. I was about to look into what I was doing wrong using the module when I saw that Win32API::File can be used like an IO::File object.

IO::File is a core module in Perl and its purpose is to create filehandles to objects. I wanted to see what function calls Perl used when accessing files on a system so I put together the script that prints a file's contents I referenced earlier. The Process Monitor output showed that Perl used the same File Management Functions as copy and attrib as shown in the picture below. As a result, I never circled back to figuring out what I did wrong with the Win32API::File module because it wasn’t necessary to interact with VSCs’ files at such a low level.

At that point I knew files could be read inside VSCs but I wanted to confirm if they could be parsed as well. I made some modifications to Harlan’s lslnk.pl script so it parse files directly in VSCs. The modifications included the information I discussed in the Accessing VSCs section and the changes enabled lslnk.pl to directly parse link files inside VSCs. The picture below shows the same link file (one was recovered from VSCs while the other was inside VSCs) being parsed. The picture on the left is the unmodified lslnk.pl script parsing a file on the system while the one on the right shows the modified lslnk.pl script parsing the same file in a VSC. The outputs from both scripts were exactly the same; thus validating examining data in this manner produces the same results.

Next Up: Ripping VSCs - Developer Examples

Ripping VSCs – Practitioner Examples

2012-02-08T20:49:00.003-05:00

The previous post, Ripping VSCs – Practitioner Method, provided a detailed explanation about the Practitioner Method for ripping Volume Shadow Copies (VSCs). The method executes programs against data inside VSCs by traversing through symbolic links and the previous post provided a simple batch script to automate this. The practitioner method examples discussed was parsing registry hives using the program Regripper and one simple loop showed how to automate parsing the Software hives across numerous VSCs. Ripping VSCs – Practitioner Examples picks up where the last post left off by demonstrating how to rip various data from VSCs using different free tools.

The Practitioner Method doesn’t leverage any programs with a Graphical User Interface (GUI). I’m not bias against tools with GUIs; heck the majority of my tools I interact with through a GUI. The method only uses command-lines tools because these can be automated through scripting. The basic premise about ripping data is reducing the amount of time needed to extract information for analysis. The faster information can be presented to an examiner then the faster questions can be answered. I started to really understand this concept when using Regripper. I used to perform registry analysis using a viewer and a paper with a registry key listing. The approached worked but in hindsight it took forever to examine each registry key. Then I started using Regripper and the tool extracted the data from registry keys on my list. In mere seconds I could analyze the information when it took minutes for me to locate the same keys with a viewer. The same concept applies to ripping VSCs; extract the data from a system/forensic image and each VSCs as fast as possible so an examiner can start their analysis. Scripting command-line tools to parse VSCs’ data takes only seconds/minutes while manually processing the same data with tools (GUIs or commands) could take minutes/hours to complete. As a refresher from my previous post, to write scripts one just needs to understand the For loop in the template listed below:

@echo off
for /f %%f in (vscs-2-parse.txt) do (
do something against c:\vsc%%f
)

I’m not going into too much depth explaining the examples because other information accompanies this post. The scripts I’m releasing are loaded with comments explaining what is going on, there’s a readme document explaining how to use the scripts, and there’s a video demonstrating the scripts usage. Taken all together I hope this provides enough information and examples for others to understand how to leverage this method in their own casework.

Now on to some examples showing how to leverage the Practitioner Method to rip data from VSCs.

Extracting Data from VSCs

As I mentioned in the introduction, QCCIS white paper and Richard Drinkwater (Forensics from the sausage factory) both used the Robocopy program to copy data from VSCs while preserving the files’ metadata. The batch script below shows how to extract the Users folder from every VSC that has a symbolic link and store the Users folders in a folder named Exported-folder.

@echo off
for /f %%f in (vscs-2-parse.txt) do (
robocopy.exe C:\vsc%%f\Users Exported-folder
)

The Robocopy program has a lot of options which can be used to preserve files’ metadata, and configure logging. To see the options I used you can review the file-info-vsc.bat script into the archive linked below.

Hashing Files in VSCs

One step in almost every digital forensic examination is to hash one or more files. Sometimes only a few files may be hashed while at other times the contents of entire hard drives are hashed. It makes sense that there could be a need to hash all the files inside of VSCs. The script below shows how to hash every file inside linked VSCs using the program md5deep.

@echo off
for /f %%f in (vscs-2-parse.txt) do (
md5deep.exe -r -c c:\vsc%%f\ >> file-hashes-vsc%%f.txt
)

The –r option is for recursive mode which means all subfolder and files are hashed. The –c option is so the output will be in csv format (this is my personal preference and the –c option doesn’t have to be used). The output is stored in a text file that indicates where the hash list came from. For example, the output hash list for vsc1 would look like file-hashes-vsc1.txt.

Identifying Differences between VSCs

One question I see often about VSCs is how to tell what is different between them. I even asked this question myself since knowing the answer has numerous benefits. If data was deleted then identifying this difference could quickly identify what was deleted. Knowing what files didn’t change can reduce the amount of data one has to analyze. When I first started examining VSCs the one ability I wanted was to able to determine the differences between a forensic image and each VSC. I wasn’t aware how to do this and the questions I saw online at the time weren’t answered with anyone explaining how. Linux has a diff command that has the ability to identify the differences between files and folders. A version of diff has been ported to Windows and it’s available in the UnxUtils package (once extracted the exe is located in UnxUtils\usr\local\wbin\diff.exe. The command below shows the diff.exe command comparing two symbolic links pointing to VSCs which therefore compares the differences between the actually VSCs. The differences are then redirected to a text file.

diff.exe -i -r –q C:\vsc11 C:\vsc10 >> differences.txt

The –i switch is to ignore case, -r is for recursive mode (compare all subfolders and files) and the –q switch will make the output only indicate if the files differ (I didn’t want to identify the actual difference for time sake). The most time consuming activity I have encountered with ripping VSCs is comparing the differences between them. Despite the additional time required, the results are impressive. Not only are files identified that are present in one VSC and not the other but files that have been modified are also highlighted. Check out the screenshot below.

Unlike the other examples I’ve shown so far, automating comparing VSCs was a little more challenging. The script isn’t as simple as copying the template because more logic is needed to make the comparison. Working my way through this issue is when I realized that I had to change my For loop in my scripts to work with text files as an input. The script below shows what I came up with to automate comparing VSCs. To any coders reading this the logic may appear funky. My preference was to use a while loop inside a For loop but there is no while loop in batch scripting. I had to simulate it with a nestled For loop.

@echo off
for /f %%f in (vscs-2-parse.txt) do (
        if !break! == 5 goto :exit
        set f=%%f
        for /f %%x in (vscs-2-parse.txt) do (
                set x=%%x
                if not !f! == !x! (diff.exe -i -r –q C:\vsc!f! C:\vsc!x! >> files-diff_vsc!f!-2-vsc!x!.txt)
                set f=!x!
                set break=5
        )
)

The variables in the scripts are using exclamation points (!) instead of percent symbols (%) for the variables. This is because to set a variable inside a batch For loop an exclamation point has to be used. To compare VSCs the script needs two variables to hold the VSC numbers to use. The first For loop starts the process by storing the first number in the text file inside %%f. The break variable will exit the loop once the inner For loop is done. Before entering into the inner loop the number in %%f is stored in a variable named f (was needed to compare numbers). The inner For loop does the rest of the work. The first time through %%x also stores the first number in the text file and then stores the number in the x variable. A comparison is made between the x and f variables. If they are not equal then diff will compare the links pointing to two VSCs. The first time through the diff doesn’t execute since the x and f variables both store the first number in the text file. The line set f=!x! moves the number inside the x variable to the f variable because the x variable will become the next number in the text file the second time through the loop. Lastly, the set break=5 makes sure the break variable contains the number 5. The inner For loop will keep processing the text file until it reaches the last number which will then go back to the first For loop. The break variable equals 5 so the loop will immediately exit. If anyone is interested in the exact code I used then I highly recommend reading the code in the scripts (file-info-vsc.bat) since I left comments explaining everything.

I took the time to explain this logic because it can be used to make other comparisons. One example is changing the code to run a program to compare registry hives.

VSC-Parser Scripts

I put together a few different scripts to rip VSCs into something I call vsc-parser (I am releasing version 1). The scripts are more of a Proof of Concept to demonstrate different activities that can be done to data stored inside VSCs. Please don’t let the PoC label fool you though. These scripts work and I actually use them in my DFIR work (professional and personal). I only gave vsc-parser the PoC label is because I have no intention to maintain the scripts publicly. The vsc-parser_readme document accompany the scripts outlines how to configure and use the scripts.

I won’t repeat the information in this post but I wanted to provide a little background about why the scripts were developed. The primary reason was because I needed this capability in my work. I wanted to access VSCs quickly and rip certain information. Some other functionality was added as my efforts to get partial credit for a DC3 2011 challenge. This functionality was hashing (MD5 and SHA) and listing files in VSCs. The detailed readme file was also a result from the DC3 challenge.

Here is the download link to vsc-parser on my blog’s Google page site. The following is a about a five minute video I put together demonstrating the Practitioner Method using these scripts on a live Windows 7 Ultimate system.

Up Next: Ripping VSCs – Developer Method

Ripping VSCs – Practitioner Method

2012-02-06T18:12:00.003-05:00

Volume shadow copies (VSCs) store a wealth of data and there are different approaches to extract that data for examination. One approach is to examine the data stored inside VSCs directly thereby skipping the need to image or copy the data. My previous post (Ripping Volume Shadow Copies – Introduction) briefly provides an overview about this approach and the two different methods to implement the approach. One method is the Practitioner Method and this post will explain it in detail.

Background

I wanted to provide a little more background about the Ripping VSCs approach and why I needed this capability. At my day job the majority of my cases are fraud related and one activity I need to do is track users’ activity so I can determine where financial data is located. As most examiners know the registry stores information about what a user was doing on a Windows computer including what files they accessed. Over time I grew accustomed to using Regripper when performing registry analysis. A cool thing about Regripper is it comes with some other useful tools and one of them is RipXP. RipXP enables you to parse a registry key from a hive on a system and then it will extract that same key from every registry hive in the system restore points. On my cases where I wanted to know what files were accessed? I would parse specific registry keys from my forensic image then parse those same keys from all system restore points. RipXP automates this process which was not only a time saver but it enabled me to get a more complete picture about a user’s activity over the course of time.

When I received my first few cases involving Windows 7 (and one Vista) systems then I lost the ability to use RipXP. The issue was that Windows 7/Vista replaced the restore points with VSCs. VSCs have a different structure than system restore points which means RipXP doesn’t work against them. I didn’t want to lose this capability when faced with Windows 7 systems so I went on a quest to figure out what my options were for ripping registry hives in VSCs. I first reviewed others’ research about VSCs and their forensic significance. I proceeded to learn and attempt the two well known approaches to VSCs examination including the robocopy method for copying data. I took what I learned and wanted to take the robocopy method to another level. My logic was if robocopy can copy data from VSCs then Regripper could parse registry hives inside VSCs. I manually ran Regripper against hives in VSCs through symbolic links showing I was on the right track. For the technique to be useful I needed automation so I could replicate how RipXP worked. I had to run the Regripper command in a loop to execute it repeatedly against registry hives in different VSCs. I was working on looping Regripper through the command-line and reached out to Harlan for some help. The end result was a command that would rip registry hives across VSCs. I saw that Harlan shows the exact command in Chapter 3 in Windows Forensic Analysis 3rd Edition.

The technique worked and replicated RipXP’s functionality. However, all you have to do with RipXP is run a script which means the technique had to be scripted. I taught myself Windows batch scripting and created a few scripts to rip registry hives in VSCs thereby getting my lost RipXP capability back. One of these initial scripts is included in the materials that accompanies WFA 3/e (I have made some significant changes too the script since it was given to Harlan). Now my logic was if Regipper can parse registry hives then any program can be automated to parse data inside VSCs. Again I was on the right track and this is how the Ripping VSCs approach came about.

Practitioner Method Overview

The Practitioner Method uses one existing tools to parse data inside a mounted volume’s VSCs by traversing through a symbolic link. I won’t rehash how to mount a volume of interest since it was discussed in the introduction. The method will be explained from the point after the volume was mounted and below illustrates the examination process.

The method can be broken done into the following three steps:

        1. Accessing VSCs
        2. Ripping Data
        3. Removing Access to VSCs

Before breaking down the three steps I wanted to discuss one of the lost DFIR commandments: Thou Shall Not Fear the Command-line. This commandment should be kept in mind because the Practitioner Method doesn’t have a nice GUI since its command-line based. For those who don’t like to interact with the command-line should check out Girl Unllocated’s Basic Command Prompt video since it may be a helpful tutorial. With all joking aside, the method does leverage command-line tools since they can be automated in scripts. I’ve found overtime the technique is very powerful because of the sheer number of free DFIR tools that run from the command-line.

Accessing VSCs

I just started reading Harlan’s WFA 3/e Kindle version (I’m on chapter 4 at the time of this post) and chapter 3 does an outstanding job explaining the process about accessing VSCs. From explaining what VSCs are to mounting a forensic image to creating symbolic links to VSCs to various tools for examining data inside VSCs. WFA 3/e goes into more depth than this post because I’m only providing a quick overview.

Accessing a VSC consists of identifying the VSC’s path followed by creating a symbolic link pointing to that path and the built-in Windows vssadmin command can accomplish this. The command also displays a lot more information including when each VSC was created. The command below will show the VSCs on the mounted volume with the drive letter C:

vssadmin list shadows /for=C:

The picture below shows the output from that command.

As can be seen in the screenshot, VSCs paths start with \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy and each VSC will have a unique number. For this specific volume the VSCs are numbered starting with the number 1 then increasing to 12 since there are 12 current VSCs. To access the first VSC a symbolic link needs to be created pointing to the path \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1. The built-in Windows mklink command can create the symbolic links to VSCs. I’ve only been reading WFA 3/e for a few days and the book as already made me change how I approach VSCs. Harlan was using the mklink’s /d switch to mount a VSC to a symbolic directory which means the link acts as a normal folder. I updated my scripts to use the /d switch instead of /j (creates a directory junction). The following command will create a symbolic link named vsc1 pointing to C volume’s first VSC and the picture shows the result:

mklink /d c:\vsc1 \\?\GLOBALROOT\Device\HardDiskVolumeShadowCopy1\

To access every VSC of interest means someone would have to execute the mklink command multiple times. To access all 12 VSCs on my C volume means I need to type the mklink command 12 times. After working my first case involving Windows 7 I learned pretty quickly the need to automate VSCs access. My post A Little Help with Volume Shadow Copies discussed and provided a batch script that automates creating symbolic links to VSCs. The script worked great but I have since updated it. One change was to incorporate mklink’s /d switch but the more important change is making it easier to access specific VSCs.

Automate Accessing VSCs

If you are only interested in the access-vsc script then skip ahead to the last paragraph in this section for the script’s download link. Otherwise, you can continue reading on to see what and why I changed the script. I already mentioned the significance of mklink’s /d switch so I won’t rehash it here. Just know that I did update my scripts to use this switch. The issue I encountered with my access-vsc script was the difficulty in narrowing my focus on specific VSCs that were not sequential. For example, if I wanted to identify the differences between VSC1, VSC3, and VSC6 then it was difficult due to the For loop used in the script. To show the issue I will discuss how the old For loop worked. The following was the loop in my old script (the command uses two % symbols since the command launches from a batch file):

for /l %%f in (start,step,stop) do echo %%f

Start represents the number the For loop should start at which in this case is 1 for the first VSC. Stop represents the number the loop should stop at which in this case is 6 for the last VSC. Step represents the number to increment each time the loop goes through. If the step was set to 2 then the For loop’s output looks like the following:

As shown in the screenshot setting the increment number to 2 only resulted in numbers 1, 3, and 5 when starting at 1. This means symbolic links would only be created for VSC1, VSC3, and VSC5 while missing VSC6. The only increment number that would work for automation is 1 and this was how my old script worked. Now the For loop’s output looks like the following:

The For loop now counts from 1 to 6; meaning symbolic links would be created for VSC1, VSC2, VSC3, VSC4, VSC5, and VSC6. That’s great since it provides access to the three VSCs of interest (VSC1, VSC3, and VSC6). However, there are VSCs being accessed that I didn’t want. This is only a small issue but it’s pretty significant when trying to automate comparing the differences between VSCs. To get around this issue I change the For loop so it uses numbers listed in a text file:

for /f %%f in (vscs-2-parse.txt) do echo %%f

The text file contains one number per line and in this case the numbers are 1, 3, and 6: Now the For loop’s output looks like the following:

As shown in the screenshot, the numbers count from 1 to 3 then 6. This would provide access to only the three VSCs of interest. To some this issue may seem small because I’m using small numbers. The volume I keep referencing throughout the post has 12 VSCs. If I wanted to access VSC1, VSC6, and VSC12 then the old script would create symbolic links to every VSC. This also means whatever data I want to parse through automation would get parsed in every VSC instead of the three I’m interested in. My new script provides access to only the VSCs someone wants; to see how check out the For loop below:

for /f %%f in (vscs-2-parse.txt) do mklink /d c:\vsc%%f \\?\GLOBALROOT\Device\HardDiskVolumeShadowCopy%%f\

The only difference in this For loop compared to the previous ones I showed is that the echo command was replaced by the mklink command. To access VSCs 1, 6, and 12 means the text file (vscs-2-parse.txt) should contain these numbers. The end result is having access to specific VSCs as shown below.

The cool thing about using a text file is that the same file can be leverage by other scripts to rip data inside VSCs. The access-vsc script pretty much works the same way as the old script. The only noticeable change is that it allows you to create a text file with the VSC numbers of interest (file gets dropped in the same directory as the script). The new script can be located at my blog’s Google Code site here. I’m releasing the script since I previously blogged about and shared the old one. I’m also releasing a series of scripts that work together to rip VSCs and will provide a short demo video showing their capabilities in my next blog post.

Ripping Data

Data can be parsed once the symbolic links pointing to VSCs are created. All that has to be done is to run a command against the data traversing through the symbolic link. For example, the Windows dir command can be executed directly against the symbolic link vsc1 to see what’s in the root directory of the VSC it’s linked to.

Continuing on with the example, the dir command can also show the files located in the Regripper folder inside VSC1.

Programs can run against VSCs’ data by going through the symbolic link. Just switch out the dir command with any other command-line program. So many days ago I switched out the dir command with Regripper. Here’s a screenshot showing Regripper parsing the Software hive’s uninstall registry key inside VSC1.

Automate Ripping Data

The previous Regripper command was only executed against the Software hive in VSC1. To process other software hives that same command needs to be ran against each VSC of interest. Examining VSCs in this manner is doable but the work is timing consuming and tedious. Not only does it take longer to execute the commands manually but typing the commands is error prone. I remember my first case working with VSCs; I was manually creating the symbolic links to VSCs and parsing registry hives. With over 15 VSCs it got old really quick; I had typos thus making the commands not work, wasted time trying to copy commands, and I learned how boring it is to type the same thing over and over. That experience is what influenced me to learn about batch scripting and the same concept applies to ripping VSCs. What option looks better: write a command once to extract information in seconds or write a command many times that takes minutes/hours to extract the same information? I bet most people would be pick door number one; that door is the main motivation to automating ripping VSCs.

One doesn’t have to be an expert in batch scripting to automate ripping VSCs using the Practitioner Method. I think all that someone needs to know is how a For loop works in a batch script. The Automate Accessing VSCs section in this post explained the For loop used in the script to create symbolic links. If you skipped that section; don’t worry and I won’t make you go back to re-read it. The important thing about the section is that the script uses a text file named vscs-2-parse.txt and the file contains a number on each line. The numbers are used to create symbolic links to each VSC. For example, the number 1 on a line results in a link named vsc1 and it points to VolumeShadowCopy1. A For loop can be written which uses the same text file to rip data inside VSCs. The simple batch script below can be used as a template:

@echo off
for /f %%f in (vscs-2-parse.txt) do (
do something against c:\vsc%%f
)

The @echo off line turns off the displaying the commands running in the batch file. The line isn’t needed but most people prefer not to display command executing. The rest of the script is just a For loop. The /f switch makes the loop work against a text file which is specified between the parenthesis (vscs-2-parse.txt). %%f will be the variable used to hold the data on each line in the text file. Quick tip: a For loop in a batch file requires two percent symbols (%%) since it strips out one symbol. However, only use one percent symbol (%) when running a For loop from the command-line. This little nuance caused me a lot of headaches when I first started working with batch files. Everything between the next set of parenthesis is the loop and will be executed until the loop reaches the last line in the text file (vscs-2-parse.txt). To rip VSCs, a program needs to be pointed to the symbolic links using the loop’s variable (%%f).

I know this may seem complicated to those who have never worked with batch files before. I swear, it just seems that way writing and reading about it. All that really has to be done is to copy the template, insert whatever program is to be executed, and save the text file with a .bat file extension. The loop below will rip the Software hive’s uninstall registry key from each link pointing to a VSC and all I did was copy the template.

@echo off
for /f %%f in (vscs-2-parse.txt) do (
rip.exe -r C:\vsc%%f\Windows\System32\config\SOFTWARE -p uninstall
)

The output from the above batch script would just be displayed on the screen. A slight change by -redirecting the output – can save the output to a text file as shown below. Just make sure that >> is used to append the output to the text file.

@echo off
for /f %%f in (vscs-2-parse.txt) do (
rip.exe -r C:\vsc%%f\Windows\System32\config\SOFTWARE -p uninstall >> C:\output.txt
)

The batch script template discussed is the foundation to ripping VSCs with the Practitioner Method and the next post will demonstrate how it can be used.

Up Next: Ripping VSCs – Practitioner Examples

Ripping Volume Shadow Copies – Introduction

2012-01-29T22:29:00.012-05:00

Windows XP is the operating system I mostly encounter during my digital forensic work. Over the past year I’ve been seeing more and more systems running Windows 7. 2011 brought with it my first few cases where the corporate systems I examined (at my day job) were all running Windows 7. There was even a more drastic change for the home users I assisted with cleaning malware infections because towards the end of the year all my cases involved Windows 7 systems. I foresee Windows XP slowly becoming a relic as the corporate environments I face start upgrading the clients on their networks to Windows 7. One artifact that will be encountered more frequently in Windows 7 is Volume Shadow Copies (VSCs). VSCs can be a potential gold mine but for them to be useful one must know how to access and parse the data inside them. The Ripping Volume Shadow Copies series is discussing another approach on how to examine VSCs and the data they contain.

What Are Volume Shadow Copies

VSCs are not new to Windows 7 and have actually been around since Windows Server 2003. Others in the DFIR community have published a wealth of information on what VSCs are, their forensic significance, and approaches to examine them. I’m only providing a quick explanation since Troy Larson’s presentation slides provide an excellent overview about what VSCs are as well as Lee Whitfield’s Into the Shadows blog post. Basically, the Volume Shadow Copy Service (VSS) can backup data on a Windows system. VSS monitors a volume for any changes to the data stored on it and will create backups only containing those changes. These backups are referred to as a shadow copies. According to Microsoft, the following activities will create shadow copies on Windows 7 and Vista systems:

        - Manually (Vista & 7)
        - Every 24 Hours (Vista)
        - Every 7 Days (7)
        - Before a Windows Update (Vista & 7)
        - Unsigned Driver Installation (Vista & 7)
        - A program that calls the Snapshot API (Vista & 7)

Importance of VSCs

The data inside VSCs may have a significant impact on an examination for a couple of reasons. The obvious benefit is the ability to recover files that may have been deleted or encrypted on the system. This ringed true for me on the few cases involving corporate systems; if it wasn’t for VSCs then I wouldn’t have been able to recover the data of interest. The second and possibly even more significant is the ability to see how systems and/or files evolved over time. I briefly touched on this in the post Ripping Volume Shadow Copies Sneak Peek. I mentioned how parsing the configuration information helped me know what file types to search for based on the installed software. Another example was how the user account information helped me verify a user account existed on the system and narrow down the timeframe when it was deleted. A system’s configuration information is just the beginning; documents, user activity, and programs launched are all great candidates to see how they changed over time.

To illustrate I’ll use a document as an example. When a document is located on a system without VSCs - for the most part - the only data that can be viewed in the document is what is currently there. Previous data inside the document might be able to be recovered from copies of the document or temporary files but won’t completely show how the document changed over time. To see how the document evolved would require trying to recover it at different points in time from system backups (if they were available). Now take that same document located on a system with VSCs. The document can be recovered from every VSC and each one can be examined to see its data. The data will only be what was inside the document when each VSC was created but it could cover a time period of weeks to months. Examining each document from the VSCs will shed light on how the document evolved. Another possibility is the potential to recover data that was in the document at some point in the past but isn't in the document that was located on the system. If system backups were available then they could provide additional information since more copies of the document could be obtained at other points in time.

Accessing VSCs

The Ripping Volume Shadow Copies approach works against mounted volumes. This means a forensic image or hard drive has to be mounted to a Windows system (Vista or 7) in order for the VSCs in the target volume to be ripped. There are different ways to see a hard drive or image’s VSCs and I highlighted some options:

        - Mount the hard drive by installing it inside a workstation (option will alter data on the hard drive)

        - Mount the hard drive by using an external hard drive enclosure (option will alter data on the hard drive)

        - Mount the hard drive by using a hardware writeblocker

        - Mount the forensic image using Harlan Carvey’s method documented here, here, and the slide deck referenced here

        - Mount the forensic image using Guidance Software’s Encase with the PDE module (option is well documented in the QCCIS white paper Reliably recovering evidential data from Volume Shadow Copies)

Regardless of the option used to mount the hard drive or image, the Windows vssadmin command or Shadow Explorer program can show what if VSCs are available for a given mounted volume. The pictures below show the Shadow Explorer program and vssadmin command displaying the some VSCs for the mounted volume with drive letter C.

Shadow Explorer Displaying C Volume VSCs

VSSAdmin Displaying C Volume VSCs

Picking VSCs to examine is dependent on the examination goals and what data is needed to accomplish those goals. However, time will be a major consideration. Does the examination need to review an event, document, or user activity for specific times or for all available times on a computer? Answering that question will help determine if certain VSCs covering specific times are picked or if every available VSCs should be examined. Once the VSCs are selected then they can be examined to extract the information of interest.

Another Approach to Examine VSCs

Before discussing another approach to examining VSCs it’s appropriate to reflect on the approaches practitioners are currently using. The first approach is to forensically image each VSC and then examine the data inside each image. Troy’s slide deck referenced earlier has a slide showing how to image a VSC and Richard Drinkwater's Volume Shadow Copy Forensics post from a few years ago shows imaging VSCs as well. The second popular approach doesn’t use imaging since it copies data from each VSC followed by examining that data. The QCCIS white paper referenced earlier outlines this approach using the robocopy program as well as Richard Drinkwater in his posts here and here. Both approaches are feasible for examining VSCs but another approach is to examine the data directly inside VSCs bypassing the need for imaging and copying. The Ripping VSCs approach examines data directly inside VSCs and the two different methods to implement the approach are: Practitioner Method and Developer Method.

Ripping VSCs: Practitioner Method

The Practitioner Method uses ones existing tools to parse data inside VSCs. This means someone doesn’t have to learn a new tool or learn a programming language to write their own tools. All that’s required is for the tool to be command line and the practitioner willingness to execute the tool multiple times against the same data. The picture below shows how the Practitioner Method works.

Practitioner Method Process

Troy Larson demonstrated how a symbolic link can be used to provide access to VSCs. The mklink command can create a symbolic link to a VSC which then provides access to the data stored in the VSC. The Practitioner Method uses the access provided by the symbolic link to execute one’s tools directly against the data. The picture above illustrates a tool executing against the data inside Volume Shadow Copy 19 by traversing through a symbolic link. One could quickly determine the differences between VSCs, parse registry keys in VSCs, examine the same document at different points in time, or track a user’s activity to see what files were accessed. Examining VSCs can become tedious when one has to run the same command against multiple symbolic links to VSCs; this is especially true when dealing with 10, 20, or 30 VSCs. A more efficient and faster way is to use batch scripting to automate the process. Only a basic understanding about batch scripting (need to know how a For loop works) can create powerful tools to examine VSCs. In future posts I’ll cover how simple batch scripts can be leverage to rip data from any VSCs within seconds.

Ripping VSCs: Developer Method

I’ve been using the Practitioner Method for some time now against VSCs on live systems and forensic images. The method has enabled me to see data in different ways which was vital for some of my work involving Windows 7 systems. Recently I figured out a more efficient way to examine data inside VSCs. The Developer Method can examine data inside VSCs directly which bypasses the need to go through a symbolic link. The picture below shows how the Developer Method works.

Developer Method Process

The Developer Method programmatically accesses the data directly inside of VSCs. The majority of existing tools cannot do this natively so one must modify existing tools or develop their own. I used the Perl programming language to demonstrate that the Developer Method for ripping VSCs is possible. I created simple Perl scripts to read files inside a VSC and I modified Harlan’s lslnk.pl to parse Windows shortcut files inside a VSC. Unlike the Practitioner Method, at the time of this post I have not extensively tested the Developer Method. I’m not only discussing the Developer Method for completeness when explaining the Ripping VSCs approach but my hope is by releasing my research early it can help spur the development of DFIR tools for examining VSCs.

What’s Up Next?

Volume Shadow Copies have been a gold mine for me on the couple corporate cases where they were available. The VSCs enabled me to successfully process the cases and that experience is what pushed me towards a different approach to examining VSCs. This approach was to parse the data while it is still stored inside the VSCs. I’m not the only DFIR practitioner looking at examining VSCs in this manner. Stacey Edwards shared in her post Volume Shadow Copies and LogParser how she runs the program logparser against VSCs by traversing through a symbolic link. Rob Lee shared his work on Shadow Timelines where he creates timelines and lists deleted files in VSCs by executing the Sleuthkit directly against VSCs. Accessing VSCs’ data directly can reduce examination time while enabling a DFIR practitioner to see data temporally. Ripping Volume Shadow Copies is a six part series and the remaining five posts will explain the Practitioner and Developer methods in-depth.

        Part 1: Ripping Volume Shadow Copies - Introduction
        Part 2: Ripping VSCs - Practitioner Method
        Part 3: Ripping VSCs - Practitioner Examples
        Part 4: Ripping VSCs - Developer Method
        Part 5: Ripping VSCs - Developer Example
        Part 6: Examining VSCs with GUI Tools

Dual Purpose Volatile Data Collection Script

2012-01-02T13:54:00.004-05:00

When responding to a potential security incident a capability is needed to quickly triage the system to see what's going on. Is a rogue process running on the system, whose currently logged onto the system, what other systems are trying to connect over the network, or how do I document the actions I took on the system. These are valid questions during incident response whether the response is for an actual event or a simulation. One area to examine to get answers is the systems' volatile data. Automating the collection of volatile data can save valuable time which in turn helps analysts examine the data faster in order to get answers. This post briefly describes (and releases) the Tr3Secure volatile data collection script I wrote.

Tr3Secure needed a toolset for responding to systems during attack simulations and one of the tools had to quickly collect volatile data on a system (I previously discussed what Tr3Secure is here). However, the volatile data collection tool had to provide dual functions. First and foremost it had to properly preserve and acquire data from live systems. The toolset is initially being used in a training environment but the tools and processes we are learning need to be able to translate over to actual security incidents. What good is mastering a collection tool that can’t be used during live incident response activities? The second required function was the tool had to help with training people on examining volatile data. Tr3Secure members come from different information security backgrounds so not every member will be knowledgeable about volatile data. Collecting data is one thing but people will eventually need to know how to understand what the data means. The DFIR community has a few volatile data collection scripts but none of the scripts I found provided the dual functionality for practical and training usage. So I went ahead and wrote a script to meet our needs.

Practical Usage

These were some considerations taken into account to ensure the script is scalable to meet the needs for volatile data collection during actual incident response activities.

Flexibility

Different responses will have different requirements on where to store the volatile data that’s collected. At times the data may be stored on the same drive where the DFIR toolset is located while at other times the data may be stored to a different drive. I took this into consideration and the volatile data collection script allows for the output data to be stored on a drive of choice. If someone prefers to run their tools from a CD-ROM while someone else works with a large USB removable drive then the script can be used by the both of them.

Organize Output

Troy Larson posted a few lines of code from his collection script to the Win4n6 sometime ago. One thing I noticed about his script was that he organized the output data based on a case number. I incorporated his idea into my script; a case number needs to be entered when the script is run on a system. A case folder enables data collected from numerous systems to be stored in the same folder (folder is named Data-Case#). In addition to organizing data into a case folder, the actual volatile data is stored in a sub-folder named after the system the data came from (system's computer name is used to name the folder). To prevent overwriting data by running the script multiple times on the same system I incorporated a timestamp into the folder name (two digit month, day, year, hour, and minute). Appending a timestamp to the folder name means the script can execute against the same system numerous times and all of the volatile data is stored in separate folders. Lastly, the data collected from the system is stored in separate sub-folders for easier access. The screenshot below shows the data collected for Case Number 100 from the system OWNING-U on 01/01/2012 at 15:46.

Documentation

Automating data collection means that documentation can be automated as well. The script documents everything in a collection log. Each case has one collection log so regardless if data is collected from one or ten systems an analyst will only have to worry about reviewing one log.

The following information is documented both to the screen for an analyst to see and a collection log file: case number, examiner name, target system, user account used to collect data, drives for tools and data storage, time skew, and program execution. The script prompts the analyst for the case number, their name, and the drive to store data on. This information is automatically stored in the collection log so the analyst doesn’t have to worry about maintaining documentation elsewhere. In addition, the script prompts the analyst for the current date and time which is used to record the time difference between the system and the actual time. Every program executed by the script is recorded in the collection log along with a timestamp of when the program executed. This will make it easier to account for artifacts left on a system if the system is examined after the script is executed. The screenshot below shows the part of the collection log for the data collected from the system OWNING-U.

Preservation

RFC 3227’s Order of Volatility outlines that evidence should be collected starting with the most volatile then proceeding to the less volatile. The script takes into account the order of volatility during data collection. When all data is selected for collection, the memory is first imaged then volatile data is collected followed by collecting non-volatile data. The volatile data collected is: process information, network information, logged on users, open files, clipboard, and then system information. The non-volatile data collected is installed software, security settings, configured users/groups, system's devices, auto-runs locations, and applied group policies. Another item the script incorporated from Troy Larson’s comment in the Win4n6 group is preserving the prefetch files before volatile data is collected. I never thought about this before I read his comment but it makes sense. Volatile data gets collected by executing numerous programs on a system and these actions can overwrite the existing prefetch files with new information or files. Preserving the prefetch files upfront ensures analysts will have access to most of the prefetch files that were on the system before the collection occurred (four prefetch files may be overwritten before the script preserves them). The script uses robocopy to copy the prefetch files so the file system metadata (timestamps, NTFS permissions, and file ownership) is collected along with the files themselves. The screenshot below shows the preserved files for system OWNING-U.

Tools Executed

The readme file accompanying the script outlines the various programs used to collect data. The programs include built-in Windows commands and third party utilities. The screenshot below shows the tools folder where the third party utilities are stored.

I’m not going to discuss every program but I at least wanted to highlight a few. Windows diskpart command allows for disks, partitions, and volumes to be managed through the command line. The script leverages diskpart to make it easy for an analyst to see what drives and volumes are attached to a system. Hopefully, the analyst won’t need to open up Windows explorer to see what the removable media drive mappings are since the script displays the information automatically as shown below. Note, to make diskpart work a text file needs to be created in the tools folder named diskpart_commands.txt and the file needs to contain these two commands on separate lines: list disk and list volume.

Mandiant’s Memoryze is used to obtain a forensic image of the system’s memory. Memoryze supports a wide range of Windows operating systems which makes the script more versatile for dumping RAM. The key reason the script uses Memoryze is because it’s the only free memory imaging program I found that allows an image to be stored in a folder of your choice. Most programs will place the memory image in the same folder where the command line is opened. This wouldn’t work because the image would be dropped in the folder where the script is located instead of the drive the analyst wants. Memoryze uses an xml configuration file to image RAM so I borrowed a few lines of code from the MemoryDD.bat batch file to create the xml file for the script. Note, the script only needs the memoryze.exe; to obtain the exe install Memoryze on a computer then just copy memoryze.exe to the Tools folder.

PXServer’s Winaudit program obtains the configuration information from a system and I first became acquainted with the program during my time performing vulnerability assessments. The script uses Winaudit to collect some non-volatile data including the installed software, configured users/groups, and computer devices. Winaudit is capable of collecting a lot more information so it wouldn’t be that hard to incorporate the additional information by modifying the script.

Training Usage

These were the two items put into the script to assist with training members on performing incident response system triage.

Ordered Output Reports

The script collects a wealth of information about a system and this may be overwhelming to analysts new to examining volatile data. For example, the script produces six different reports about the processes running on a system. A common question when faced with so many reports is how should they be reviewed. The script’s output reports have numbers which is the suggested order for them to be reviewed. This provides a little assistance to analysts until they develop their own process for examining the data. The screenshots below shows the process reports in the output folder and those reports opened in Notepad ++.

Understanding Tool Functionality and Volatile Data

The script needs to help people better understand what the collected data means about the system where it came from. Two great references for collecting, examining, and understanding volatile data are Windows Forensic Analysis, 2nd edition and Malware Forensics: Investigating and Analyzing Malicious Code. I used both books when researching and selecting the script’s tools to collect volatile data. What better ways to help someone better understand the tools or data then by directing them to references that explain it? I placed comments in the script containing the page number where a specific tool is discussed and the data explained in both books. The screenshot below shows the portion of the script that collects process information and the references are highlighted in red.

Releasing the Tr3Secure Volatile Data Collection Script

There are very few things I do forensically that I think are cool; this script happens to be one of them. There are not many tools or scripts that work as intended while at the same time provide training. People who have more knowledge about volatile data can hit the ground running with the script investigating systems. The script automates imaging memory image, collecting volatile/non-volatile data, and documenting every action taken on the system. People with less knowledge can leverage the tool to learn how to investigate systems. The script collects data then the ordered output and references in the comments can be used to interpret the data. Talk about killing two birds with one stone.

The following is the location to the zip file containing the script and the readme file <zip download link is here>. Please be advised, a few programs the script uses require administrative rights to run properly.

Enjoy and Happy Hunting ...

Ripping Volume Shadow Copies Sneak Peek

2011-12-19T22:31:00.003-05:00

I was hesitant to do a sneak peak about a different approach to examine Volume Shadow Copies (VSCs). I personally don’t like sneak peeks and would rather wait to see the finished product. I think it’s along the lines of starting a movie then stopping it after 15 minutes and being forced to finish watching months later. If I don’t like sneak peeks then why am I putting others through it? I previously mentioned how I wanted to spend my furlough days by putting together some posts about another approach to examining VSCs. Well last week was my furlough week and my family wrote a new version to the carol The Twelve Days of Christmas. Four out of town trips, three sick kids, two family emergencies, and one blogger quarantined to his room. Needless to say I had to spend my time focused on my family. I won’t have time to write the VSCs blog posts until next month so I at least wanted to show one example on how I use this method.

There are times when I get a system that has been altered and one change is removing financial software from the system. This is pretty important because if I’m trying to locate financial data then I need to know what software is on the system so I know what kind of files to look for. There is a chance some file types might initially be missed if I’m not aware a certain program was installed at some point in the past. Different registry keys can help determine what programs were installed or executed but you can get a more complete picture about a system by looking at those same registry keys at different points in time. Performing registry analysis in this manner has allowed me to quickly identify uninstalled financial applications which reduced the time needed to find the data. Anyone who has used Harlan’s RipXP understands the value in seeing registry keys at different points in time. I used the same concept with one exception: numerous registry keys can be queried at the same time when dealing with VSCs.

The system I used for this demonstration was a live Windows 7 Ultimate 32 bit system. In the past I also used it against Windows 7 and Vista. forensic images

Obtaining General Operating System Information

I discussed previously one initial examination step is to get a better understanding about the system I’m facing. I use a batch script with Regripper to obtain a wealth of information about how the system was configured when it was last powered on. The configuration information is from only one point in time but if the system has VSCs then that means the same information can be obtained from different points in time. Seeing the same configuration information enables you to see how the system changed slightly over time including what software was installed or uninstalled. To do this I made some modifications to the general operating system batch script which lets me run it against VSCs I have access to.

I’m not going to discuss accessing VSCs in this post. For information on how to access VSCs I’d check out Harlan’s Even More Stuff post since he provides a link to his slide deck he gave to the online DFIR meet-up on the topic. My Windows 7 system had 19 VSCs and for the demonstration I only used the following:

        - ShadowCopy19 12/13/2011 6:13:35 PM

        - ShadowCopy16 12/01/2011 8:08:50 AM

        - ShadowCopy3 11/28/2011 11:19:40 AM

        - ShadowCopy1 8/26/2011 12:15:34 PM

The screen shot below shows the main menu to the vsc-parser (most selections have sub menus). To review the system to identify software of interest I’m interested in selection 2: “Obtain General Operating System Information from Volume Shadow Copies”.

The selection will immediately execute my Regripper batch file against every VSC I have access to. The picture below shows the script running against my four VSCs. I highlighted the samparse and uninstall plug-ins that executed.

The output from the script is nicely organized into different folders based on what the information is.

I’m interested in the software on the system which means I need the reports in the software-information folder. A report was created for each VSC I had access to (notice how the file name contains the VSC number it came from).

Now at this point I can review the reports and notice the slight differences between each VSCs. I tend to look at the most recent VSC then work my way to the oldest VSC. It makes it easier to see how the system slightly changed over time from the forensic image I examined first.

On a case I used this technique and it helped me to identify a financial application that was removed from the system. In the end it saved some a lot of time because this was one of my initial steps and I knew right off the bat I was looking for specific file types. Some may be wondering why I decided to highlight the samparse plug-in as well. At another time the same technique helped me verify a user account existed on the system and narrow down the timeframe when it was removed from the system.

I showed an example running Regripper against registry hives stored in VSCs on a live Windows 7 system. However, the approach is not only limited to registry hives or Regripper since you can pretty much parse any data stored in a VSC.

A Time of Reflection

2011-12-13T14:25:00.001-05:00

Certain events in life cause you to reflect on humility and put back into perspective the meaningful things in life. You remember that in time almost everything is replaceable. Another forensicator will fill your shoes at work and your organization will continue to go on. Another researcher will continue your research and the little that you did accomplish will eventually just be a footnote. Another person will step up to provide assistance to others in forensic forums and listservs. Your possessions and equipment will become someone else’s to enjoy and use. When looking at the big picture, the work we do and value will eventually fade away and life will go on as if we were never there. One of the only things remaining will be the impact we make on others in the little time we have available to us. One doesn’t need a lot of time or resources to make an impact; all that’s needed is having a certain perspective.

Everyone should look out not [only] for his own interests, but also for the interests of others. Philippians 2:4

Having an outlook that looks beyond one’s own self interests can positively impact others and I think the statement holds true regardless of religious beliefs. A perspective that takes into consideration others’ interests is displayed everyday in the Digital Forensic and Incident Response (DFIR) community. DFIR forums have thousands of members but there are only a few who regularly take the time to research and provide answers to others’ questions. DFIR listservs are very similar that despite their membership the minority are the ones who regularly try to help others. Look at the quality information (books, articles, blogs, white papers, etc) available throughout the community and their authorship is only a small fraction of the people in the community. These are just a few examples out of many how individuals within the DFIR community use their time and resources in an effort to not only better themselves but to educate others as well.

When I look at the overall DFIR community I think there’s only a minority who are looking beyond their own interests in an effort to help others. A few people have helped me over my career which contributed to where I am today. They never asked for anything in return and were genuinely interested in trying to help others (myself included). If the DFIR community is what it is because of a few people giving up their time and resources to make a positive impact on others, then I can only wonder what our community would look like if the majority of people looked beyond their own interests to look after the interests of others. In the meantime all I can do is to continue to try to remember to look beyond myself in every aspect of my life. To try to consider those around me so I can help whoever crosses my path needing assistance. When the day is over one of the only things remaining will be the impact I have on others.

Don’t Overlook Simulations

2011-12-05T14:11:00.000-05:00

A few weeks ago my family and I were eating dinner at our dining room table. A car alarm started going off outside so I went to the window to see what was going on. I first checked to make sure our cars weren't the ones making the noise and then I saw it was my neighbor’s car across the street. I went back to the dining table when my three year old said "the car is saying there is a fire drill". Laughing aside his statement made a lot of sense. Before that moment the only time he has heard loud sirens have been during fire drills. Naturally, his first thought when he heard something similar was a fire drill was happening. Fire drills are one simulation people have practiced (most of the time forced) over and over again to help them know how to proceed when the real thing occurs. Simulations in DFIR work the same way in helping educate ourselves how to proceed in certain types of scenarios.

Most trainings I attended reinforced learning by having the attendees practice on test images or data. The attendees just don't stumble around in the data since their objective is dictated by working through a simulation based on some case scenario. The simulation training approach even carries over to when people want to improve their skills on their own. Similar to the fire drill, different DFIR scenarios can expose people to different types of cases so they are more aware about their options and what to do when a real case comes up. The choices one has available for scenarios are to either use a test case put together by someone else or create your own. I found the latter option to be extremely effective at better preparing me since I can focus on areas I want to improve on. Simulations are how I developed my skills to investigative malware infected systems.

Forensicator Readiness is the thought process I use to develop and implement different scenarios. The process focuses my efforts on the exact skills or knowledge I want to learn more about. One simulation I’ve been working on for some time is answering these two questions about infected systems: is the system infected and how did the system get infected. All the different scenarios I developed overtime and some research I conducted was a direct result of trying to answer those two questions.

My scenarios started out by manually infecting systems with different malware to develop my skills in finding malware both in memory and on disk. Once I was effective at quickly locating the malware - without scanning - then the next step was to purposely attack systems. Some attacks I conducted such as running Metasploit against systems with malware as the payload while other attacks involved finding malicious SPAM emails or active drive-by attacks. In all the scenarios I simulated infections with different initial infection vectors on systems to provide myself with test cases. I improved my skills by examining the infected systems so I could answer were the systems infected and how did it occurred.

My neighbor’s car alarm put my three year old in fire drill mode. He didn’t get up and start walking towards the door because it was my neighbor’s car. The drill was for my neighbor and not us; otherwise our cars would have told us. :) Putting ourselves through our own simulations in advance increases our ability to be in the right mode when we need it. I was better prepared when I took on my first infected system. Not only did I locate the malware (without av scanning) but I was successful in tracing the infection back to a drive-by against an Adobe Reader vulnerability. It wasn’t luck I was able to do this right out of the gates. Nor was it luck I have continued to do this on system after system. This ability is a direct result of honing my skills in advanced by putting together my own simulations focused on areas I want to improve on.

People and children are not able to just able magically figure out how to exit a building in chaos. It takes practice and when chaos occurs the training kicks him to help people know how to proceed. DFIR is the same way; we won’t magically know how to process certain cases or answer certain questions. It takes practice and overtime we develop the knowledge on how to proceed with certain cases. Practicing can take the form of trainings or self simulations. Trainings are a one size fits all where the content is the same across the board. An advantage that self simulations have over trainings is one’s ability to focus on whatever area one wants. Time can be better spent focusing on the areas one doesn’t have knowledge about while trainings can be used to supplement other areas (this approach is a better way to use training dollars as well). The next time one wants to develop their DFIR skills then self simulations shouldn’t be overlooked as a viable option.

jIIr Updates

2011-12-03T12:34:00.003-05:00

A few quick updates about some things related to the blog …

Digital Forensic Search (DFS) Updates

I updated the Digital Forensic Search’s index today. Eight new blogs were added and I updated the URL for an existing blog. In no particular order the new editions are: Sketchymoose's Blog, Forensics For the Newbs, WriteBlocked, Hexacorn Blog, Zena Forensics, Taksati, Chris Sanders, and SANs Penetration Testing Blog. As usual, the Introducing the DFS blog post has been updated to reflect the changes.

I’m going to continue documenting the sites in the index on the Intro to DFS post. However, I’m probably going to stop posting updates on the blog since I’m leaning towards mentioning the changes through my twitter account.

I’m Now on Twitter

Earlier in the week I finally finished setting up my Twitter account and actually started to use it. As my profile indicates Twitter is my platform to share random thoughts which will mostly be focused on information security. I said mostly because the account won’t solely be used to discuss security. Please feel free to hit me up at corey_harrell.

A Different Approach to Analyzing Volume Shadow Copies

In a few weeks I’m going to have some time off from work since I’m taking some “furlough” days. My plan is to spend the time putting together some material (blog posts and videos) to further demonstrate a different approach to analyzing the data stored volume shadow copies.

Before discussing my approach I’m pointing out two current approaches. One is to image each VSCs then examining the data in the images. Another approach is to copy the data - including metadata - from all or select VSCs so it can be examined outside the VSCs. The approach I’ve been using is to examine the data while it’s still stored in the volume shadow copies. There are numerous benefits doing it this way such as reducing the amount of time needed or being able to work on both live systems and forensic images. I think the technique’s true power is the ability to see the same data at different points in time since shows how the data changed over time. This has been critical for me on a few different cases.

To help me examine VSCs in this manner I wrote a few different scripts. The material I’m putting together will not only explain my logic behind the scripts’ functionality but will show how it can be easily extended by anyone to meet their own needs. Yes, I'll also release the scripts as well. Plus, if I can pull off a video or two it should be cool for people to see it in action.

What’s TR3Secure?

At some point over the next few months you may see me start referencing and sharing some work I completed for something called TR3Secure. I’ll be the sole author of any work I share (mostly scripts) but I wanted to briefly discuss what TR3Secure is since I’ll be tagging my work with it. A few co-workers and a colleague of mine are working on setting up a training group for us to collaborate and develop our information security skills together. We are trying to create an environment to bring together security testers, incident responders, and digital forensic practitioners. We envision doing different activities including conducting live simulations and this is where bringing together the three different skillsets will shine. The live simulations will be conducted with select people attacking a test network while a second group responds, triages the situation, and if necessary contains the attack. Afterwards, the examiners will collect and examine any evidence to document the attack artifacts. When it’s all said and done then everyone will share their experiences and knowledge about the atack and if necessary train other members on any actions they completed during the simulation.

We are still in the early stages setting the group up and once established it initially has to be a closed group. I’m only mentioning TR3Secure here because I’m going to write various scripts (Perl and Batch) to help with certain aspects of the live simulations. If my scripts work well especially for training then I’ll share it for others to use for self training purposes. The scripts will solely be my own work but I’m still tagging everything with TR3Secure since I’m working with some great individuals. The first item coming down the pipeline is a cool dual purpose volatile data collection script that doubles as a training and incident response tool.

Linkz 4 Exploits to Malware

2011-11-30T18:06:00.000-05:00

In this edition of linkz the theme goes from exploitation to infection to detection. Some linkz discussed include: providing clarity about my exploit artifacts, a spear-phishing write-up, a malware analysis checklist, and thoughts about automated vs in-depth malware analysis.

Picking Vulnerabilities

Over the past year I’ve been conducting research to document attack vector artifacts. Vulnerabilities and the exploits that target them are one component to an attack vector. Some may have noticed I initially focused most of my efforts on vulnerabilities present in Adobe Reader and Java. I didn’t pick those applications by flipping a coin or doing “eeny, meeny, miny, moe”. It is not a coincidence I’m seeing exploit artifacts left on systems that target those applications. This has occurred because I pick vulnerabilities based on the exploits contained in exploit packs.

Exploit packs are toolkits that automate the exploitation of client-side vulnerabilities such as browsers, Adobe Reader, and Java. Mila Parkour over at Contagio maintains an excellent spreadsheet outlining the exploits available in different exploit packs on the market. The reference by itself is really informative. The screenshot below shows part of the vulnerabilities section in the spreadsheet.

Notice how many Java and Adobe vulnerabilities are on the list. Maybe now it’s a little more clearer why I wrote about Adobe/Java exploits and why I wasn’t surprised when system after system I keep finding artifacts associated with those exploits. The spreadsheet shows what applications exploit packs are targeting. I’ve been using the document as a reference to help me decide what exploit artifacts to document. Down the road when I start looking into Word, Excel, and flash exploits then at least there will be a little more clarity as to what I’m choosing to document.

Another Adobe Flash Exploit

Since I mentioned both Adobe, flash, and exploit in the same paragraph then I might as well mention them in the same sentence. Zscaler ThreatLab blog recently posted Adobe Flash “SWF” Exploit still in the Wild. The short write-up discusses how a vulnerability in Adobe flash (CVE-2011-0611) is being exploited by embedding a .swf file into Microsoft Office documents or html pages. I wanted to highlight one specific sentence "this exploit code embeds a “nb.swf” flash file into a webpage, which is then executed by the Adobe Flash player". That one sentence identified numerous potential artifacts one could find on a system indicating this attack vector was used. First there will be Internet browser activity followed by a flash file being accessed. The system may then show a swf file being created in a temporary folder and there may also be indications that Adobe flash executed shortly thereafter. The write-up doesn't go into what artifacts are left on a system since its focus is on how the attack worked. At this point those potential artifacts are just that potential. However, flash exploits are third on my list for what I'm going to start documenting. It shouldn’t come as a surprise by now that Mila’s spreadsheet also shows a few exploit packs targeting the flash vulnerability.

Walking through a Spearphishing Attack

The Kahu Security blog post APEC Spearfish does an excellent job walking the reader through an actual spearphishing attack. The spearphish was an email targeted at a single individual and contained a malicious PDF attachment. There was a flash object in the PDF file that exploited a vulnerability in Adobe Flash Player (yup … CVE-2011-0611). The end result was a malware infection providing backdoor access for the attackers. The post isn't written from the DF perspective; it doesn't outline the artifacts on a system indicating a spearphish occurred or a flash exploit caused the malware infection. However, it does a great job breaking down the attack from the person receiving the email to the PDF file launching to malware getting dropped. One image I liked was the one showing "what’s happening behind the scenes" since it helps DF readers see the potential artifacts associated with the method use to infect the system.

Finding Malware Checklist

Last month Harlan posted about his experience at PFIC 2011. At the end of his post he shared his Malware Detection Checklist which outlines the examination steps to locate malware on the system. I think it’s a great list and I like how the checklist is focused on a specific task; finding malware. I added some of the activities in Harlan’s checklist to my own because I either wasn’t doing it or I wasn’t deliberate about doing it. One step I wasn’t doing was scanning for packed files and thinking about it I can see how it can help reduce the amount of binaries to initially examine. On the other end, one step I wasn’t deliberate about was examining the user’s temporary directories. I was examining these directories through timeline analysis but I wasn’t deliberate about searching the entire folder for malware or exploit artifacts.

The cool thing about Harlan’s checklist is that he already did the heavy lifting. He put together a process that works for him (including the tools he uses) and is sharing it with the community. It wouldn’t be hard for anyone to take what he already did and incorporate it into their own examination process. Plus, his blog post mentioned the checklist came from Chapter 6 in WFA 3 so the book (once released) can be a reference to better understand how to go about finding malware on a system.

Another Angle at Finding Malware

Along the same lines about trying to identify malware on a system Mark Morgan over at My Stupid Forensic Blog discussed the topic in his post How to Identify Malware Behavior. Mark first proceeded to explain the four main characteristics of malware which are: an initial infection vector, malware artifacts, propagation mechanism, and persistence mechanism. (Harlan also described these characteristics on his malware webpage). The characteristics are important since there artifacts associated with them and those artifacts can help identify the malware. Mark provided a great example about how the persistence mechanism played a role in one of his cases. He even went on to explain a few different ways to track down malware and its persistence mechanism.

Analyzing Malware

At some point during the examination malware will be identified on the system. Some can just start analyzing the malware since they are fortunate enough to know how to reverse engineer its functionality or know someone who can. The rest of us may not have that luxury so we should just upload the sample to online scanners such as VirusTotal or Sandboxes right? Well, I wouldn’t be too fast in pulling the trigger without understanding the risks involved. The Hexacorn blog put together the excellent post Automation vs. In-depth Malware Analysis. In the author’s own words the "post is my attempt to summarize my thoughts on the topic of both automated malware analysis in general and consensual submission of files to a web site owned by a third party". There are times when submitting samples to a third party service are not the best choice to make. I first learned about the risk when a discussion occurred in the Win4n6 group sometime ago but the post goes into more depth. For anyone dealing with malware and considering using third party services -such as VirusTotal or ThreatExert - than I highly recommend reading this post to help you make an informed decision.

On a side note, the Hexacorn blog started to post forensic riddles every Friday followed by posting the answer every Monday. The riddles are entertaining and educational. My stat count so far is zero for two (I wasn’t even close).

Finding the Initial Infection Vector

2011-11-20T21:58:00.001-05:00

There are different ways to spread malware. Email, instant messaging, removable media, or websites are just a few options leveraged to infect systems. One challenge when performing an examination is determining how the malware ended up on the system which is also referred to as identifying the malware’s initial infection vector (IIV). A few obstacles in determining the IIV is that a system changes over time: files are deleted, programs are installed, temporary folders are emptied, browser history is cleared, or an antivirus program cleaned the system. Every one of those obstacles may hinder the examination. However, they don’t necessary result in not being able to narrow down the IIV since some artifacts may still be present on the system pointing to the how.

There are various reasons provided why an examination isn’t performed on a malware infected system to locate the IIV. I first wanted to point out why taking the time to find the IIV is beneficial instead of focusing on the reasons why people don’t. The purpose of the root cause analysis is to identify the factors lead up to the infection and what actions need to be changed to prevent the reoccurrence of a similar incident. If the infected system is just cleaned and put back into production then how can security controls be adjusted or implemented to reduce malware infecting systems in a similar manner? Let’s see how this works by skipping the root cause analysis and placing blame on a user opening a SPAM email. A new security awareness initiative educates employees on not opening SPAM email which does very little if the malware was a result of a break down in the patch management process. Skipping figuring out the IIV is not only a lost opportunity for security improvements but it prevents knowing when the infection first occurred and what data may have been exposed. This applies to both organizations and individuals.

Determining how the malware infected a system is a challenge but that's not a good enough reason to not try. It may be easier to say it can’t be done, takes too much resources or it's not worth it since someone (aka users) never listen and did something they weren’t suppose to. As a learning opportunity I’m sharing how I identified the initial infection vector in a recent examination by showing my thought process and tool usage.

First things first… I maintain the utmost confidentiality in any work I perform whether if it’s DFIR or vulnerability assessments. At times on my blog I write detailed posts about actual examinations I performed and every time I’ve requested permission to do so. This post is no different. I was told I can share the information for the greater good since it may help educate others in the DFIR community who are facing malware infected systems.

Background Information

People don’t treat me as their resident “IT guy” to fix their computer issues anymore. They now usually contact me for another reason because they are aware that I’ve been cleaning infected computers for the past year free of charge. So it’s not a strange occurrence when someone contacts me saying their friend/colleague/family member/etc appears to be infected with a virus and needs a little help. That’s pretty much how this examination came about and I wasn’t provided with any other information except for two requests:

        * Tell them how the infection occurred so they can avoid this from happening again

        * Remove the viruses from the computer

     Investigation Plan

The methodology used throughout the examination is documented on the jIIr Methodology Page. I separated the various system examination steps into the first three areas listed below.

        1. Verify the system is infected
        2. Locate all malware present on the system
        3. Identify the IIV
        4. Eradicate the malware and reset any system changes

I organized the areas so each one will build on the previous one. My initial activities were to verify that the system was actually infected as opposed to the requester interpreting a computer issue as an infection. To accomplish this I needed to locate a piece of malware on the system either through antivirus scanning or reviewing the system auto-run locations. If malware was present then the next thing I had to do was locate and document every piece of malware on the computer by: obtaining general information about the system, identifying files created around the time frame malware appeared, and reviewing the programs that executed on the system. The examination would require since the technique excels at highlighting malware on a system. The third area and the focus of this post was to identify the initial infection vector. The IIV is detected by looking at the system activity in the timeline around the timeframe when each piece of malware was dropped onto the system. The activity can reveal if all of the malware is from the same attack or if there were numerous attacks resulting in different malware getting dropped onto the system. The final area is to eradicate every malware identified.

Note: Some activities were conducted in parallel to save time. To make it easier for people to follow my examination I identified each activity with the symbol <Step #>, the commands I ran are in bold, and registry and file paths are italicized.

Verifying the Infection

The computer’s hard drive was connected to my workstation and a software write blocker prevented the drive from being modified. I first reviewed the master boot record (MBR) to see the drive configuration I was dealing with and to check for signs of MBR malware <Step 1>. I ran the Sleuthkit command: mmls.exe -B \\.\PHYSICALDRIVE1 (the -B switch shows the size in bytes). There was nothing odd about the hard drive configuration and I found out that additional time was needed to complete the examination since I was dealing with a 500 GB hard drive. To assist with identifying known malware on the system I fired off a Kaspersky antivirus scan against the drive <Step 2>.

Knowing the antivirus scan was going to take forever to complete I moved on to checking out the system’s auto-runs locations for any signs of infection. The Sysinternals AutoRuns for Windows utility was executed against the Windows folder and the only user profile on the system <Step 3>. In the auto-runs I was looking for unusual paths launching executables, misspelled file names, and unusual folders/files. It wasn’t long before I came across an executable with a random name in the HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell registry key.

The HKCU\Software\Microsoft\Windows\CurrentVersion\Run registry key also listed under Auto-runs Logon tab showed that the C:\Users\John_Doe\AppData\Roaming folder had more than just one randomly named executable. The key also showed an additional location which was the C:\Users\John_Doe\AppData\Roaming\Microsoft folder.

I added the hard drive as an evidence item in FTK Imager v3 to review the folders and executables identified by the Auto-runs utility <Step 4>. I noticed there were two additional executables located directly underneath the Roaming folder with the names iexplore.exe and java.exe. Both files had the same MD5 hash e4c2a000e715d16ec25e2b0a0fb3532f so to confirm the infection I searched for the hash in the Malware Analysis Search custom Google search. There was one search hit for VirScan.org and a few scanners flagged the file as malware (Kaspersky identified it as Trojan.Win32.FakeAV.emha). I followed the similar process to confirm that the other executables were malware as well. At this point I no longer needed the antivirus scan to finish since the infection was verified through other means. Before I moved onto manually locating all malware on the system I needed to document what my timeframe of interest was. I looked at the last modification times and creation times for all the folders/files I found. The rough timeframe spanned over a few days: from 10\13\2011 1:29:34 AM to 10/08/11 11:38:48PM. The picture below shows the last modification times for a few folders in the C:\Users\John_Doe\AppData\Roaming folder.

Locating All Malware on the System

After I verified the system was in fact infected I then proceeded to locate and document every piece of malware. First I had to shed light on the system’s configuration since it would impact how I performed my analysis <Step 5>. I used my regripper-general-os-info.bat batch file to run RegRipper against the system’s registry hives including the one profile’s NTUSER.dat hive. Below I highlighted some information and to the right of the arrow are quick notes about its significance.

        * Operating system was Windows 7 Home Premium <= affected what artifacts are available and where they are located

        * OS Install Date was Sun Feb 20 23:26:29 2011 (UTC) <= may assist with identify activity occurring before this date

        * Timezone was Eastern Standard <= needed to understand time information

        * The registry setting NtfsDisableLastAccessUpdate was enabled <= can’t use files’ last access times since it’s not tracked (default setting in Windows 7)

        * Profilelist registry key only showed one user account besides the default ones <= focused the examination around the activity for one specific user account

       * Installer\UserData registry key showed the following programs: Microsoft Office 2010 including Outlook, iTunes v.10, QuickTime v.7.69, Adobe Reader v9.3.4, and Java(TM) 6 Update 17 <= identified applications that could have been responsible for the malware infection

       * Default browser plugin showed the default browser was Internet Explorer <= system had two web browsers (Chrome was the other) so my initial focus is on the artifacts from the default one

       * Listsoft registry key showed McAfee <= McAfee antivirus software was on the system and its logs may show additional information about the infection.

I opted for the timeline analysis technique to locate all malware on the system and the general information obtained about the system helped to narrow down my artifact list to incorporate into my timeline. Building a timeline on a 500 GB hard drive was going to take some time so I looked at the McAfee logs before tying up my workstation <Step 6>. I exported the McAfee logs with FTK Imager and reviewed them using Notepad ++. The last entry in the log occurred at 10/16/2011 6:50:09 PM and it logged that the file "C:\windows\system32\consrv.DLL" was detected as Generic.dx!bbd4. The next entry didn’t occur until 10/12/11 but there were numerous log entries leading right up until 10/08/11. A few detections included Generic Dropper!1cj, DNSChanger!fa, and Artemis!E4C2A000E715 and they were for files located the folders C:\Users\John_Doe\AppData\Local\Temp\, C:\Windows\assembly\tmp\, and C:\windows\syswow64\. The flurry of McAfee detections for files other than cookies stopped at 10/8/2011 11:37:38 PM as shown in the picture below.

The McAfee log identified potential additional malware on the system and expanded my timeframe to 10/16/2011 6:50:09 PM to 10/08/11 11:37:38 PM. A significant piece of information the log highlighted was Internet activity occurred just before the first detection. I leverage the timeline analysis technique for the rest of the examination. I created a timeline by incorporating the following artifacts: event logs (evtx), registry hives (system, software, and ntuser), link files (win_link), prefetch files (prefetch), Internet Explorer history (iehistory), and the Master File Table (mft) <Step 7>. I ran the following command but replaced the plugin and file path for each desired artifact: log2timeline.pl -f evtx -w timeline.csv E:\Windows\System32\winevt\Logs\Application.evtx. Once my timeline was built I then I started my search for all malware on the system.

Identify the IIV

Locating all malware present on the system and identifying the IIV are not separate activities when I perform timeline analysis. The only reason I separated them was to make it easier to explain my thought process. In actuality the two go hand in hand. Each time a piece of malware is located the system activity around the malware is examined to determine what contributed to the malware being created. Approaching timeline analysis in this manner will help determine if the malware is from the one attack or multiple attacks at different points in time. I review timelines working backwards in time since I find that it’s easier to spot the IIV. Each time I come across a file that could be malicious I first review the file’s header (in this examination I used FTK Imager), perform searches for the file’s MD5 hash (search order is Malware Analysis Search, VirusTotal, and then Google), and at times if the hash search results in no hits and the file type is of interest then I may upload the file to VirusTotal to see if it’s detected. I continue this process in the timeline until I reach the point where the malware activity stops and that’s usually where the IIV is located.

To assist with confirming malicious files I used FTK Imager to export a file hash list for the entire hard drive <Step 8>. It’s a lot easier to already have files’ hashes on hand then it is to calculate the hash each time I come across a new file. I started working my timeline keeping in mind everything I found including the timeframe 10/16/2011 6:50:09 PM to 10/08/11 11:37:38 PM. Besides the timestamps that were not accurate (reflects activity in future) the timeline ended on 10/16/2011 so that is where I started my analysis. I first saw the consrv.dll file detected by McAfee but there were no artifacts around the malware indicating it was the result of a different attack.

After 10/16/11 the next activity started appearing in the timeline on 10/12/11. I found the same thing; more malware and artifacts associated with malware but no artifacts indicating an attack occurred.

I kept working the timeline going backwards in time. I kept finding more malware and malware artifacts but nothing pointing to an IIV explaining how the malware got onto the system. I finally reached the earliest time I noted which was 10/08/11 11:37:38 PM. There was a lot of activity involving files with similar names to the ones reflected in the McAfee log file.

I continued working backwards until I saw no more activity involving the C:\Windows\assessmbly\tmp\U\ folder which is shown in the screenshot below. The U folder was created on the system at the same time as a file resembling a configuration file. One line in the file was srv=hxxps://212.36.9.52/ and my research showed the address appeared in a blacklist and the spsyeyetracker IP blocklist. The activity just before the U folder and configuration file were created was an executable named dbywqomgec (MD5 hash a70e5c48612159b3e936d7e478f4d451) appearing in the John_Doe’s temp folder. VirusTotal showed a few antivirus programs identified the file as a dropper (Microsoft detection was TrojanDropper:Win32/Sirefef.B). Afterwards I analyzed the file with ThreatExpert to see what changes the malware caused.

The activity on the system before the dropper (MD5 hash a70e5c48612159b3e936d7e478f4d451) appeared on the system was a file showing up in the Java cache folder as shown below.

I previously discussed the forensic significance Java index files provide in the post (Almost) Cooked Up Some Java. I exported the Java index file 46e770f3-38b55d85.idx with FTK Imager and looked at the file with Notepad ++. The file’s contents are shown below.

The index file 46e770f3-38b55d85.idx showed a few interesting tidbits. First the file 46e770f3-38b55d85 was downloaded from the URL hxxp://www.seyminck.com/FFFO009/560[dot]gif which had the IP address 212.95.55.40. Secondly, the URL indicated the file was a gif image but the index recorded the file as an application. I checked the file 46e770f3-38b55d85 (MD5 hash 2e833ac26483aaad13a8051bc857ef15) header and it was indeed an executable since the file started with MZ. I analyzed the file with ThreatReport and it was identified as a dropper (Microsoft detection was TrojanDropper:Win32/Sirefef.B). The IIV still wasn’t located so I looked at the activity just before the dropper appeared in the Java cache. The activity showed at the same time another duplicate of the dropper (MD5 hash 2e833ac26483aaad13a8051bc857ef15) appeared in the John_Doe’s temp folder with the file name 0.945837921339929.exe. Four seconds beforehand a file appeared in the Java cache folder which can be seen below highlighted in red.

The Java index file 25e8c780-5c17647b.idx was exported with FTK Imager and read with Notepad ++. The information contained in the index showed that a Java archive file was downloaded from the URL hxxp://www.seyminck(dot)com/FFFO009/RRo/realestate (IP address 212.95.55.40). The Java archive came from the same domain and IP address as the executable located in the Java cache folder. I exported the Java archive 25e8c780-5c17647b (MD5 hash 6b478de65071d94c670a0bfa369a7890) and confirmed the file was a Jar file by examining it with JD-GUI. The MD5 hash search didn’t result in any hits so I uploaded the file to VirusTotal and only 2 out of 42 antivirus products detected it as an exploit. I wanted to know if Java actually executed around the time the exploit appeared in the cache. I exported and reviewed the Java log file C:\Users\John_Doe\AppData\Local\Temp\java_install_reg.log and the log showed Java did in fact execute.

The last piece I needed to identify the IIV was to determine what delivered the exploit to the system. The activity on the system before the exploit answered that question as shown below.

There was a PrivacIE entry for seyminck(dot)com/FFFO009/RRo/*87354602 which means the exploit came from third party content being displayed on a website. The PrivacIE entry was mixed in with activity resembling advertisements from the user searching for someone on peoplefinder and whitepages websites. I continued working backwards in the timeline but there was no more malware activity. The IIV was identified. A user was surfing the Internet when a website visited was hosting third party content which resulted in a successful drive-by download targeting a Java vulnerability.

More Information about the IIV

The Java archive 25e8c780-5c17647b (MD5 hash 6b478de65071d94c670a0bfa369a7890) didn’t have to be examined closer in order to identify the IIV. However, I wanted to better understand how to examine Jar files since they may provide more information about the IIV and help explain some files found on the system. I debated if I should put this section in another blog post because I didn’t want people to think this activity had to be done in order to figure out the IIV. I opted to include the information since it sheds light on what occurred when the exploit was downloaded.

The code in the Jar file was obfuscated to conceal its purpose. I reached out to the Win4n6 group about any methods to automate analyzing Jar files with obfuscated code. A few members pointed me to Java de-obfuscation tools and I’m still in the process of trying to learn how to use them. Another member mentioned that Java obfuscation appears to be not making analysts’ life difficult, but to evade detection by antivirus. The person went on to say the obfuscation is usually weak so it’s relatively simple to de-obfuscate. My first reaction was it may be simple for Java programmers but it seemed impossible to me; I know nothing about Java besides the artifacts left by Java exploits. I took a shot at manually trying to see what the Jar file did by focusing on trying to follow the logic associated the variables, class methods, and functions in the code (I don’t know the Java syntax so if I butcher the names of things such as functions then you know why).

I opened the Java archive 25e8c780-5c17647b in JD-GUI and looked at the manifest file to see the wall Java class gets executed first.

I extracted the Java source code by using the “Save All Sources” option in JD-GUI. I started reviewing the obfuscated source code in the Wall Java class when I saw two lines of code making a call to the Java method Muuum.kjdhfdkjg or Muuum.idufhidufh. For those who don’t know what a Java method is: it’s basically going to the Muuum class and executing the code listed under the method kjdhfdkjg or idufhidufh.

I followed the code to the Muuum class file and found out its purpose was to set a variable to contain an URL. Two variables are set to contain part of the URL and they are then used to build the entire URL. One URL that is built is hxxp://www.seyminck.com/ FFFO009 /560[dot]gif and this was the URL I found in the Java index 46e770f3-38b55d85.idx showing it was where the executable file 46e770f3-38b55d85 (MD5 hash 2e833ac26483aaad13a8051bc857ef15) came from. The screenshot below shows the URL being put together.

I went back to the Wall class and kept reading the code until I came across the first Java function as shown below. The Inputstream function reads data and the data being read was coming from the Java method Kkdjfhgdkfjhgkdfjhgkkkkkkkkkkkk.sodarifhsdoiufhdoiufg86fetgfyusgfyudif. I highlighted the Inputstream function in green while the Java method is highlighted in red.

The followed the code to the sodarifhsdoiufhdoiufg86fetgfyusgfyudif method. The method set the variable URL to contain the value contained in variable s3 which the Wall Java class passed to the method. The method ended with by returning a call to another method in the Kkdjfhgdkfjhgkdfjhgkkkkkkkkkkkk class as highlighted in red below.

Next I went to the mmmm3 method which is pictured below. The first function InputStream sets the URL to read from while the second function Openstream reads the URL stored in the URL variable. I couldn’t find the code that resulted in the URL variable containing the domain hxxp://www.seyminck[dot]com. However, this was the URL the method was reading from becaue the Jar file didn’t reference any other websites. The method returns to the Wall class the data read from the URL.

I went back to the Wall class and continued to follow the code. The next portion I picked up on is the data read from the URL was saved to a file with an exe extension. The picture below shows the code that accomplished this and I highlighted a few areas to make it easier to see. The variable ufy highlighted in the first red box was set to contain a string with a random number ending in .exe. The next variable iioi655er5w5 (highlighted in blue) was set to contain another variable concatenated with the ufy variable at the end. This means the string contained in iioi655er5w5 ends in .exe. The function FileOutputStream writes data to a file and names the file with the string in the iioi655er5w5 variable.

The previous code explains the activity on the system immediately after the exploit was downloaded. Reading the URL hxxp://www.seyminck.com/FFFO009/560[dot]gif resulted in Java caching the file while Java wrote the data to a file with an .exe file extension. The Java index file 25e8c780-5c17647b.idx showed that the file 46e770f3-38b55d85 (MD5 hash 2e833ac26483aaad13a8051bc857ef15) in the Java cache was read from the URL in the Java exploit. Another file with the same MD5 hash was created on the system at the same time and was named a random number with exe as the file extension.

At the bottom of the previous screenshot shows the Java method Kkdjfhgdkfjhgkdfjhgkkkkkkkkkkkk.kjsf8888 being called and the variable iioi655er5w5 (contains the filename ending in .exe) is passed for the method to use. The picture below is a close up of the method call.

My journey following the code ended when I went to the kjsf8888 method in the Kkdjfhgdkfjhgkdfjhgkkkkkkkkkkkk class file. The code highlighted in green in the picture below highlights the function Runtime exec executing the file contained in the iioi655er5w5 variable which is a file whose name is random number with an .exe extension (seems like this file 0.945837921339929.exe found on the system). The activity on the system after 0.945837921339929.exe was created in the temp folder was another dropper (MD5 hash a70e5c48612159b3e936d7e478f4d451) showing up on the system. To me this further confirms the Jar file was successful in exploiting a vulnerability in Java and this was how the system became infected in the first place.

Summary

I went into the examination planning on to perform a surgical malware removal and ended up doing a complete system rebuild due to how bad the infection was. The initial infection vector was a user surfing the Internet and coming across a website hosting third party content which resulted in a successful drive-by download targeting some Java vulnerability. Going back to the person and telling them how the infection happened makes it easier for them to change what lead up to the issue. I would have done a disservice if I skipped trying to find the IIV and went back to the person with a laundry list of recommendations. Enable the firewall, use strong passwords, update anti-virus software, use caution with opening attachments, use caution clicking on links, update computer software, etc … Throwing out a laundry list of recommendations is a lost opportunity to improve security since it doesn’t address the root cause. Trying to implement five or ten recommendations is a lot harder than focusing on the one recommendation that actual caused the infection.

Identifying the IIV is a challenge worth confronting. For success one not only needs to understand the forensic artifacts located on a system and their significance but needs to know about attack vector artifacts and how to recognize them. Being able to understand both artifacts types can help in answering the question how did malware end up on the system.

PFIC 2011 Review

2011-11-14T09:53:00.002-05:00

Last week I had the opportunity to attend Paraben’s Forensic Innovations Conference (PFIC). I had a great time at PFIC; from the bootcamp to the sessions to the networking opportunities. Harlan posted his experience about PFIC, Girl Unallocated shared her thoughts, and SANs Digital Forensic Case Leads discussed the conference as well. The angle I’m going to take in my post is more of a play by play about the value PFIC offers and how the experience will immediately impact my work. Here are a few of my thoughts ….

Affordability

When I’m looking at conferences and trainings the cost is one of the top two things I consider. This is especially true if I’m going to ask my employer to pick up the tab. Similar to other organizations it is extremely hard to get travel approved through my organization. As a public sector employee at times it seems like I’d have better odds getting someone’s first born then to get a request approved through the finance office. The low cost to attend PFIC made it easier for me to get people to sign off on it. The conference with one day training was only $400. The location was the Canyons Resort and attendees got cheaper rates for lodging since it’s the off-season. Rounding out the price tag were the plane flight and shuttle from the airport; both expenses were fairly reasonable. Don’t be fooled by the low costs thinking PFIC is the equivalent of a fast food restaurant while the other conferences are fine dining. PFIC is not only an economical choice but the content covered in the bootcamp and sessions results in more bang for the buck. I like to think PFIC is the equivalent of fine dining with coupons. The cost was so reasonable that I was even going to swing the conference by myself if my employer denied my request to attend. That’s how much value I saw in the price tag especially when I compared it to other DFIR conferences.

Networking Opportunities

The one commonality I’ve see in other’s feedback about PFIC is how the smaller conference size provides opportunities to network with speakers and other practitioners. This was my first DFIR conference so I can’t comment about conference sizes. However, I agree about the ability to talk with people from the field. Everyone was approachable during the conference without having to wait for crowds to disperse. Plus if for some reason you were unable to connect between sessions then PFIC had evening activities such as casino night and night out in town. I meet some great people at the conference and was finally able to meet a few people I only talked to online. Going into the conference I underestimated the value in connecting with others since I was so focused on the content.

Content

Let’s be honest. A conference can be affordable and offer great networking opportunities but if the content is not up to par then the conference will be a waste of time and money. I have a very simple way to judge content; it should benefit my work in some way. This means none of the following would fit the bill: academics discussing interesting theories which has no relevance to my cases, vendors pimping some product as the only way to solve an issue, or presenters discussing a topic at such a high level there is no useful information I can apply to my work. One thing I noticed about the PFIC presenters was they are practitioners in the field discussing techniques and tools they used to address an issue. Pretty much each session I walked away from I felt like I learned a few useful things and got a few ideas to research further. Harlan said in his PFIC 2011 post that “there were enough presentations along a similar vein that you could refer back to someone else's presentation in order to add relevance to what you were talking about”. I think the same thing can be said from the attendee’s perspective. I sat through several presentations on incident response and mobile devices and it seemed as if the presentations built on one another.

I pretty much picked my sessions on a topic I wanted to know more about (incident response) and another topic I wanted to get exposed to (mobile devices). There were a few presentations I picked based on the presenter but for the most part my focus was on incident response and mobile devices. PFIC had a lot more to offer including e-discovery, legal issues, and digital forensics topics but I decided to focus on two specific topics. In the end I’m glad I did since each presentation discussed a different area about the topic which gave me a better understanding. I’m not discussing every session I attended but I wanted to reflect on a few.

        Incident Response

I started PFIC by attending the Incident Response bootcamp taught by Ralph Gorgal. The overview about the process used in the session is shown below and the activities highlighted in red is what the bootcamp focused on (everything to the right of the arrows are my notes about the activity).

     * Detection => how were people made aware
     * Initial Response => initial investigation, interviews, review detection evidence, and facts that incident occurred
     * Formulate Investigation/Collection Strategy => obtain network topology and operating systems in use
     * Identify Location of Relevant Evidence => determine sources locations, system policies, and log contents
     * Evidence Preservation => physical images, logical images, and archive retrieval
     * Investigation
     * Reporting

The approach taken was for us to simulate walking in to a network and trying to understand the network and what logs were available to us. To accomplish that we reviewed servers’ configurations including the impact different configuration settings have and identified where the servers where storing their logs. The Windows services explored during the bootcamp were: active directory, terminal services, internet information server (IIS), exchange, SQL, and ISA. The focus was more on following a logical flow through the network (I thought it was similar to the End to End Digital Investigation) and thinking about what kind of evidence is available and where it was located.

The bootcamp provided a thorough explanation about the thought process behind conducting log analysis during incident response. Even though the course didn’t touch on how to perform the log analysis other sessions offered at PFIC filled in the void. The first session was We’re infected, now what? How can logs provide insight? presented by David Nardoni and Tomas Castrejon. The session started out by first explaining what logs are, breaking down the different types of logs (network, system, security, and application), and explaining what the different log types can tell you. The rest of the session focused on using the free tools Splunk and Mandiant’s Highlighter to examine firewall and Windows event logs. I thought the presentation was put together well and the hands on portion examining actual logs reinforced the information presented to us. The other session I attended about log analysis was Log File Analysis in Incident Response presented by Joe McManus. The presentation was how web server and proxy logs can generate leads about an incident by using the open source tool Log Analysis Tool Kit (LATK). LATK helps to automate the process of log analysis by quickly showing log indicators such as top downloaders/uploaders, SQL queries, and vulnerable web page access. The session was a lab and in the hands on portion we examined web server and proxy logs. This was another session that was well put together and I think the coolest thing about both sessions, besides the great information shared, was that free tools were used to perform log analysis.

        Mobile Devices

Mobile devices are a topic I want to become more knowledgeable about. I went into PFIC wanting to learn a basic understanding about the forensic value contained in mobile devices and get some hands on experience examining them.

The first of the three Paraben labs I attended was Smartphone and Tablet Forensic Processing by Amber Schroader. This wasn’t my scheduled lab so I watched from the back as others did the hands on portion. Amber laid out a case study for the attendees who had to locate a missing 15 year old girl by using Device Seizure to examine an ipad and itouch. What I liked about the session was that answers weren’t provided to the audience which forced them to have to figure out what information on those devices could help locate the girl. A few of the areas examined included: Safari browsing history, Safari download history, Youtube history, facetime history, wifi locations, and pictures. After the case study Amber laid out the different areas on mobile devices containing relevant information but mentioned the biggest issue with mobiles is the sheer number of apps which changes how you look at your data. The next Paraben lab I sat through was Physical Acquisitions of Mobiles by Diane Barrett. The session explained the different methods to acquire a physical image which were chip off, JTAG test access port, flasher boxes, and logical software that can do physical. The cool part about the session was the hands on portion since we used a Tornado flasher box and Device Seizure to acquire a physical image from a Motorola phone. The last Paraben lab I attended was Introduction to Device Seizure by Amber Schroader and Eric Montellese. As the title indicates the session was an introduction on how device seizure can be used to examine mobile devices. The entire session was pretty much hands on; we performed logical and physical acquisitions of a Motorola phone and a logical acquisition of an Android. We also briefly examined both devices to see what information was available.

The only non-Paraben session about mobile devices I attended was iOS Forensics by Ben Lemere. The presentation discussed how to perform forensics on iOS devices using free tools. The information provided was interesting and added to my to-do list but I thought the session would have been better if it was a lab. It would have been awesome to try out the stuff the presenter was talking about.

        Digital Forensic Topics

I couldn’t come up with a better description than Digital Forensics Topics for the sessions I picked based on the presenter or topic. The one session I wanted to mention in this category was Scanning for Low Hanging Fruit in an Investigation by Harlan Carvey. I was really interested in attending Harlan’s session so I could finally see the forensic scanner he has been talking about. Out of all of the sessions I attended I think this was the only session where I knew about the topic being discussed (I follow Harlan’s blog and he has been discussing his forensic scanner). Harlan explained how the scanner is an engine that runs a series of checks searching for low hanging fruit (known artifacts on the system). The usage scenario he laid out involves:

     * Mount an acquired image as a volume (or mount a volume shadow copy)
     * Plug-ins (checks) are based on a specific usage profile
     * Scanner reports are generated including a log of activity (analysts name, details image, plugins ran, etc.)

Harlan mentioned the scanner is still in development but he still did a tool demo by parsing a system’s Windows folder. A few things I noted about what I saw: there’s better documentation than Regripper (analysts name and platform included), still rips registry keys, lists files in a directory (prefetch folder contents were showed), runs external programs (evt.pl was executed), hashes files, and performs different file checks. I saw the value in this kind of tool before I sat through the session but seeing it in action reinforces how valuable this capability would be. I currently try to mimic some activities with batch scripting (see my triage post or obtaining information post). Those scripts took some time to put together and would require some work to make them do something else. I can foresee the forensic scanner handling this in a few seconds since plugins would just need to be selected; plus the scanner can do stuff that's impossible with batch scripting.

Speaking of scripts … Harlan mentioned during his presentation a batch script I put together that runs Regripper across every volume shadow copy (VSC) on a system. I was caught a little off guard since I'd never imagined Harlan mentioning my work during his presentation. I probably didn’t do a good job explaining the script during the session since I wasn’t expecting to talk about it. Here is some information about the script. As Harlan mentioned, I added functionality to the script besides running Regripper (I still have a standalone script for Regripper in case anyone doesn’t want the other functions). The script can identify the differences between VSCs, hash files in VSCs, extract data (preserves timestamps and NTFS permissions) from VSCs, and list files in the VSC. The script demonstrates that you can pretty much do as you please with VSCs whether if you are examining a forensic image or live system. In a few weeks I’ll provide a little more information about the script and why I wrote it, and over the next few months I’ll write a series of posts explaining the logic behind the script before I release it.

PFIC Summary

Overall PFIC was a great experience. I learned a lot of information, I have a to-do list outlining the various things to research/test further, and I meet some great people. The return on investment for my company sending me to the conference is that in a few weeks I’ll be able to perform log analysis, I’m more knowledgeable about mobile device forensics, and if I get into a jam I now have a few people I can reach out to for help.

Closing out my post I wanted to share a few thoughts for improvement. I didn’t have many which I guess is a good thing. ;)

1. Make the names on the name tags bigger. I think my biggest struggle during the conference was trying to figure out peoples’ names since I couldn’t read the tags.

2. Presenters should answer all questions during the session if time permits; especially if the question is a follow-up to something the presenter said. Another attendee asked a great question but I had to stick around for about five minutes after the session to hear the answer. It wasn’t like the question was controversial or something.

3. Verify that all equipment works before the session. One of the labs hit a speed bump when numerous attendees (me included) couldn’t acquire a phone since numerous phones didn’t work. Everyone was able to do the acquisition eventually but time was lost trying to find phones that actually worked.

Book Review Perl Programming for the Absolute Beginner

2011-10-24T17:58:00.002-04:00

I find myself in more situations where I’m not completely satisfied with my DFIR tools. They either don’t parse certain information or lack capabilities I want. Batch scripting helped in some situations but the scripts are limited in what I can do. For example, it’s difficult (if not impossible) to create a script to extract information from an artifact that’s not supported by existing tools. Learning a programming language has been at the top of my to-do list for some time due to these reasons. I was browsing my local book store when I came across the book Perl Programming for the Absolute Beginner.

Why Perl Programming for the Absolute Beginner

I chose the book after I skimmed through a few other Perl programming books. Perl Programming for the Absolute Beginner is written for an audience without previous programming experience. The book goes into great detail explaining basic programming concepts such as variables, arrays, loops, and subroutines. I took a C++ course in my undergraduate about seven years ago and the only thing I remember is that I took a C++ course. Basically, I have zero programming knowledge including not knowing much about programming concepts. A lot of the books I skimmed, such as Learning Perl, don’t take the time to explain the basic concepts since they expect the reader to be already familiar with them. I wanted a book to explain the basics in addition to the language; Perl Programming for the Absolute Beginner fit the bill.

Numerous books I looked at use exercises at the end of each chapter to reinforce the material covered. The exercises are pretty simple and perform one action such as a math calculation. Perl Programming for the Absolute Beginner takes a different approach in teaching Perl. Instead of individual exercises the book has the reader write computer games which are fully functioning programs. I thought this approach does a better job showing how to use Perl since it covers the planning, organizing, coding, and testing activities involved with script development. Plus the approach was entertaining and it kept my interest. I’d rather write a “Fortune Teller Game” than a script to compute “the circumference of a circle”. ‘nuff said.

What I learned

My review is going to be a little different. I’m neither discussing the book’s contents (if you want to know then read the table of contents) nor how helpful the book could be. Instead I’m talking about what I learned from the book and how it has impacted my DFIR work so far.

Seeing Behind the Curtain

Bear with me for this analogy… When I was younger I used to love watching Kung-fu. At times I watched movies completely in another language without subtitles. I got the gist of what was going on by watching body language, facial expressions, tones of people’s voices, and the bad guys getting stomped. However, when I watched the same movie in English (subtitles or dubbed over) I realized how much I missed about the movie’s plot. Learning Perl is the equivalent of adding subtitles or dubbed English to a Kung-fu movie. Before I understood the gist of what my Perl tools were doing but it’s completely different when you can read and actually understand the code to see how it produces its output. It let me see behind the tool abstraction curtain.

Extending my Capability

I was considering between learning Perl or Python since programs in my toolbox are written in those languages. One of my goals is to learn a language that lets me customize tools to better meet my needs. I picked Perl because two tools I extensively use are written in Perl and plug-in based. Plug-ins allow the tool to be extended fairly easily and I felt knowing how to write them would have a greater impact on my DFIR work. My immediate need was for a Regripper plug-in to parse the UserInfo registry key in an NTUSER.DAT hive (I could have asked others for this but I wanted to learn how to do it). In the past I manually examined the UserInfo key in the NTUSER.DAT hive and if present the hives in system restore points or volume shadow copies. Performing the task was time consuming but I needed to know the information. Perl Programming for the Absolute Beginner taught me enough about Perl to make it pretty easy to write a plug-in once I re-read the creating plug-ins section in Windows Registry Forensics. Taking the time to put the userinfo plug-in together will make things easier and faster for me in the future since I can now extract the information from a system in seconds. Talk about improving efficiency.

Breaking my Handcuffs

I’m still wearing handcuffs since I’m still dependent on existing tools and scripts created by others. However, Perl Programming for the Absolute Beginner opened my eyes to a future where if I encounter an artifact not supported by my tools then I could just write my own. A future where I no longer have to be satisfied and accept tools’ outputs when I want to see data differently. A future where repetitive tasks can be automated enabling me to spend more time on analyzing information. The book opened my eyes to a world where I don’t have to be handcuffed to my DFIR tools and the capabilities they provide. Perl Programming for the Absolute Beginner did not make me into a tool developer but it provided me with a foundation to build upon.

Four Star Review

Not all is rosy with the book though. I normally can overlook typos but I’m not very forgiven when there are typos in the code the reader is suppose to copy. It’s bad enough that beginners are going to mess something up and spend time tracking down their own mistakes. There’s no need to add even more typos resulting in people questioning themselves wondering what else they did wrong. Chapter Four’s Star Wars Quiz declares a variable named $valid but the rest of the program uses the variable $isvalid (on page 129). That small typo makes the game not work until the variable $valid is changed to $isvalid. As a reader I shouldn’t be required to find typos in code in order to make things work. I spend enough time finding my own mistakes as it is.

Overall I give Perl Programming for the Absolute Beginner a four star review (based on Amazon’s rating scheme). I highly recommend the book for anyone looking to learn the Perl programming language in addition to basic programming concepts. The book teaches the basics in an entertaining way enabling anyone to write simple scripts to solve issues. For those with programming backgrounds then I suggest looking elsewhere for a book on Perl since this is too basic. Learning Perl is a decent candidate because the target audience is for people familiar with programming concepts (I moved on to this book after reading Perl Programming for the Absolute Beginner).

Linkz about Attacks

2011-10-16T22:30:00.002-04:00

In this round of links I’m talking about drive-bys, malicious ads, web attack artifacts revealed with Mandiant’s Highlighter, and a justification for companies to fail security audits.

Video Showing Drive-by Download from MySQL

As most people probably heard by now MySQL.com was serving up malware to its visitors last month. SecurityMonkey put together the post [Video]: Watch Malware Drive-By Download from MySQL.com which contained various links about the incident. One link was to a video created by Armorize that captured what happened to anyone who visited the website when the issue was occurring. The video is about five minutes long and I highly recommend for people to check it out. I’ve never seen a drive-by broken down before by video. The video by itself is pretty cool but I think the true value is in what it shows about the attack vector infecting people visiting the website. Check out the sequence of events I noted from the video:

        - (00:55) Internet Explorer starts to load the website mysql.com
        - (01:04) Java.exe starts running on the computer
        - (01:11) Executables are dropped onto the computer. These were the attack’s payload
        - (03:43) It was revealed that a Jar file was downloaded to the system and this is why Java started. The Jar file download occurred before the executables appeared on the computer

The attack summary was a user visited mysql.com and eventually gets redirected to a site hosting the Black Hole exploit pack. In that instance, the exploit pack used a Java vulnerability to infect the system. Why does any of this even matter … knowing this can help determine how a system was compromised. Let’s say someone was dealing with an infected computer and were trying to figure out how the malware got installed on the computer. The video didn’t show what was on the system’s hard drive but the attack is very similar to the Java exploit artifacts I documented. To date I’ve documented three different ones which were Java Signed Applet Exploit Artifacts, CVE-2010-0840 (Trusted Methods) Exploit Artifacts, and CVE-2010-0094 (RMIConnectionImpl) Exploit Artifacts. There was a consistent pattern to the all the artifacts:

        - Temporary file created (Jar file got dropped onto the system)
        - Indications of a vulnerable Java executing
        - Internet activity showed a user visited a malicious website

The key difference (besides the Java vulnerability) between the Armorize video and the method I used to document the exploit artifacts was the tool used to create and deliver the exploit. The video documented a Java exploit from the Blackhole exploit pack and according to Contagio’s August 2011 Exploit Pack Overview spreadsheet Blackhole goes for $1,500 a year. My testing leveraged the freely available Metasploit to document exploit artifacts. Taking the time to document the exploit artifacts can pay big dividends during an examination when trying to determine the “how”. How did the system get infected? Well if the activity on the system around the time malware was created shows either a Jar file appearing or Java executing then a Java vulnerability may have been the culprit. If there is Internet activity then the Internet and a web browser may have been used to deliver the exploit to the system.

Malicious Advertisement Leads to PDF Exploit

I first started looking into attack vector artifacts when one of my systems got whacked with a Fake AV virus. At the time I had the DF skills but I lacked the IR skills such as figuring out what happened to my system. I took a shot at trying to figure out how the system became infected to see if I could. It took me a little bit but I was not only able to find the malware dropped onto my system but I traced the infection back to Yahoo email. I was even able to determine the exploit used in the drive-by. It was a malicious PDF file that targeted a vulnerability in Adobe Reader. The PDF appeared on the system in the temporary Internet files folder just prior to the first malware getting dropped. The experience taught me valuable lessons. First the more obvious one; don’t quickly check your web email from a test system with vulnerable apps even if it’s only for a few seconds. The second and more important lesson was the need to understand how different attacks appear on a system after they have occurred. The examination took me some time to figure out since I didn’t really know what to expect or what artifacts to look for.

I recently came across TrendMicro’s post Malicious Ads Lead to PDF Exploits. The post is from last year but it made me reflect on the experience that motivated me to start my journey into incident response. The post mentioned how malvertisements on a popular web-based email service lead to users being directed to sites with exploits. The article isn’t written from the DFIR perspective since it was focused on the vulnerabilities targeted in the attack. There wasn’t much discussion about the artifacts left on a system either besides malicious PDFs and internet activity. The little information provided did show how the attack occurred.

        - User visits web based email service
        - Redirect downloads malicious PDFs targeting Adobe Reader vulnerabilities
        - Adobe reader has to process the PDF for the exploit to be successful and install malware

The attack pattern is something I’ve seen in a few other places. My infected test system had the same sequence of events but it took me a bit to actually see it. That examination made me more aware about the artifacts associated with a PDF exploit thereby making it easier to spot it in a few other examinations I did afterwards. I also saw the same pattern on my test systems I exploited with Metasploit. I researched a PDF exploit in the post CVE-2010-2883 (PDF Cooltype) Exploit Artifacts. Do the following areas I noted in the post look familiar?

        - PDF document created
        - There were references about a PDF file being accessed
        - A vulnerable Adobe Reader started on the system

Web Attack Artifacts

Russ McRee’s October’s Toolsmith Log Analysis with Highlighter is a great read for a couple reasons. I enjoy reading his articles since he provides an overview about a tool’s functionality. In this edition he doesn’t disappoint as he covers how to perform log analysis with Mandiant’s Highlighter. Showing how to do log analysis is cool enough but he demonstrates the tool by looking for attacks in his website’s logs. He looks for specific artifacts caused by remote file include and directory traversal attacks. I haven’t found any references that document the artifacts left in logs by different attacks so I enjoyed reading about it. Eventually I’m going to start researching the artifacts left in logs but I still have a lot to do with the artifacts left on systems.

Fail a Security Audit Already Will You

When I started working full time in the information security field I was performing vulnerability assessments and security audits. Maybe I’m a little biased because of my background but I can see the value security audits provide when performed correctly. I’m not talking about audits where boxes are just checked off but risk based audits looking at the security controls protecting an organization’s critical information. Andreas M. Antonopoulos's article Fail a security audit already -- it's good for you provides an argument for why companies should fail security audits. The article makes some great points but the one thing I thought was missing is when organizations try to justify (aka make excuses) or minimize why serious weaknesses are present. Take patching as an example.

Patching isn’t done to prevent applications and systems from breaking. I was a system admin so I get it … especially since I’ve dealt with the hassle of tracking down the patches that jacked up my systems. However, using the reason as a justification to not patch without doing any due diligence by you know actually testing patches to see if anything breaks is something else. The SANs Top Cyber Security Risks report from a few years ago highlighted how third party applications on client systems are targeted. The exploits I discussed in this linkz edition targeted vulnerabilities in client applications such as Java and Adobe. How can these vulnerabilities on computers with users surfing the web be lumped into the same category as some application supporting a critical business process with neither of them getting patched? The security risk didn’t go away and the vulnerabilities don’t magically repair themselves. It’s too late to finally figure it out once the organization is staring at the artifacts from a successful exploit.

Java Signed Applet Exploit Artifacts

2011-10-13T22:41:00.000-04:00

Artifact Name

Java Signed Applet Exploit Artifacts

Attack Vector Category

Exploit

Description

A signed Java applet is presented to a user and a dialog box asks the user if they trust it. If the user is socially engineered to run the applet then arbitrary code executes under the context of the currently logged on user.

Attack Description

This description was obtained using the Metasploit exploit reference. A user visits a web page hosting the signed Java applet and a Java window pops up asking the user to run the applet. Once the user runs it then a program is downloaded and executed on the system.

Exploits Tested

Metasploit v4.0 multi\browser\java_signed_applet

Target System Information

* Windows XP SP3 Virtual Machine with Java 6 update 16 using administrative user account

* Windows XP SP3 Virtual Machine with Java 6 update 16 using non-administrative user account

Different Artifacts based on Administrator Rights

No

Different Artifacts based on Software Versions

Not tested

Potential Artifacts

The potential artifacts include a Jar file and the changes the exploit causes in the operating system environment. The artifacts can be grouped under the following three areas:

        * Temporary File Creation
        * Indications of the Vulnerable Application Executing
        * Internet Activity

Note: the documenting of the potential artifacts attempted to identify the overall artifacts associated with the vulnerability being exploited as opposed to the specific artifacts unique to the Metasploit. As a result, the actual artifact storage locations and filenames are inside of brackets in order to distinguish what may be unique to the testing environment.

        * Temporary File Creation

            -JAR file created in a temporary storage location on the system within the timeframe of interest. [C:/Documents and Settings/Administrator/Local Settings/Temp/jar_cache5490377340104033776.tmp. The contents of the JAR file contained a manifest file, a class file, and an executable.

* Indications of the Vulnerable Application Executing

- Log files indicating Java was executed within the timeframe of interest. [C:/Documents and Settings/Administrator/Application Data/Sun/Java/Deployment/deployment.properties, C:/Documents and Settings/Administrator/Local Settings/Temp/java_install_reg.log, and C:/Documents and Settings/Administrator/Local Settings/Temp/jusched.log] The picture below shows the contents of the deployment.properties log.

           - Prefetch files of Java executing. [C:/WINDOWS/Prefetch/JAVA.EXE-0C263507.pf]

            - Registry modification involving Java executing at the same time as reflected in the jusched.log file. [HCU-Admin/Software/JavaSoft/JavaUpdate/Policy/JavaFX]

            - Folder activity involving the Java application. [C:/Program Files/Java, C:/Documents and Settings/Administrator/Application Data/Sun/Java/Deployment/, and C:/Documents and Settings/Administrator/Local Settings/Temp/hsperfdata_username]

        * Internet Activity

            - Web browser history of user accessing websites within the timeframe of interest. [Administrator user account accessed the computer -192.168.11.200- running Metasploit]

            - Files located in the Temporary Internet Files folder. [C:/Documents and Settings/Administrator/Local Settings/Temporary Internet Files/Content.IE5/]

           - Registry activity involving Internet Explorer

Timeline View of Potential Artifacts

The images below shows the above artifacts in a timeline of the file system from the Windows XP SP3 system with an administrative user account. The timeline includes the file system, registry, prefetch, event logs, and Internet Explorer history entries.

References

Exploit Information

Metasploit Exploit Information http://www.metasploit.com/modules/exploit/multi/browser/java_signed_applet

Building Timelines – Tools Usage

2011-09-25T18:17:00.006-04:00

Tools are defined as anything that can be used to accomplish a task or purpose. For a tool to be effective some thought has to go into how to use it. I have a few saws in my garage but before I try to cut anything with them I first come up with a plan on what I’m trying to accomplish. Timeline tools are no different and their usage shouldn’t solely consist of running commands. The post Building Timelines – Thought Process Behind It discusses an approach to develop a plan on the way timeline tools will be used. This post is the second part where the tools to build timelines is discussed.

There is not a single tool for building timelines since tools vary based on the DFIR practitioner’s needs and preferences. When I first started learning about timeline analysis I read as much as I could about the technique and downloaded various tools to test their capabilities to see what worked best for me. I’m discussing my current method and a few tools that I build timelines with. The method is different from what I was doing last month and will probably change down the road as tools are updated, new tools are released, and my needs/preferences vary.

I’m trying to show different ways timelines can be built in addition to building my own timeline for an infected Windows XP SP3 test system. The artifacts selected for my timeline are: event logs, Internet Explorer history, XP firewall logs, prefetch files, Windows restore points, select registry keys, entire registry hives, and the file system metadata. The user specific artifacts (ie history and registry keys from the NTUSER.DAT hive) only need to be parsed for the administrator user account. The extraction of the timestamps from those artifacts will be accomplished in the following activities:

        - Artifact Timestamps
        - File System Timestamps
        - Registry Timestamps

Tools’ Output

Before a timeline can be created one must first choose what format to use for the tools’ output. Selecting the format up front ensures multiple tools’ outputs can go into the same timeline. Three common output types are: bodyfile, TLN, and comma-separated value (csv). The bodyfile format shows file activity and separates the output into different sections. The version in use will determine what the sections are but the Sleuthkit Wiki bodyfile page explains the differences and provides an example. The TLN format breaks the data up into five sections: time, source, host, user, and description. Harlan provided a great description about his format in the post Timeline Analysis...do we need a standard? and in Appendum for the post TimeLine Analysis, pt III. The csv format stores data so it is separated by rows and columns. This format works well for viewing the timeline data in spreadsheets. However, unlike the bodyfile and TLN formats csv is not a standard format. The csv schema from tools may differ resulting in the need for additional processing for the outputs to go into the same timeline. Kristinn’s post Timeline Analysis 201 – review the timeline explains the csv schema used in his Log2timeline tool.

I mostly review timelines with spreadsheet programs so I opted for Log2timeline’s csv format. I use Log2timeline to convert other tools’ outputs into proper csv schema. My timeline in this post uses the csv format and I demonstrate how to convert between different formats.

Artifact Timestamps

I couldn’t come up with a good name when I was thinking about how to explain the different activities I do when creating timelines. What I mean when I say artifact timestamps is everything expect for the last write times from dumped registry hives and timestamps from the file system. The different tools to extract timestamps from artifacts include Harlan’s timeline tools and Log2timeline. Harlan accompanies his tools posted on the Win4n6 yahoo group with a great step by step guide about building timelines with his tools. I cover how to use Log2timeline and the following is a brief explanation about the tool’s syntax:

log2timeline.pl -z timezone -f plugin/plugin_ file -r -w output-file-name log_file/log_dir

        -z defines the timezone for the computer where the artifacts came from
        -f specifies the plugin or pluging file to run against the file/directory
        -w specifies the file to write the output to
        -r makes log2timeline work in recursive mode so the folder specified and its subfolders are all examined for artifacts

Options to Extract Timestamps with Single Plugin or Default Plugin File

Log2timeline is plugin based and the tool can execute a single plugin against a single file/directory or execute a plugin file against multiple files in directories. I prefer to use custom plugins for my timelines but first I wanted to show the single plugin and default plugin file methods. The command below will execute the evt plugin to parse the Security windows event log and the output will be written to a file named fake-timeline.csv.

log2timeline.pl -z local -f evt -w fake-timeline.csv F:\WINDOWS\system32\config\SecEvent.Evt

The single plugin method requires multiple commands to extract timestamps from different artifacts in a system. Plugin files address the multiple command issue since the file contains a list of plugins to run. Log2timeline comes with a few default plugin files and the best one that fits my selected artifacts is the winxp plugin file. The command below runs the winxp plugin file against the entire mounted forensic image (the red text highlights what is different from the previous command).

log2timeline.pl -z local -f winxp -w fake-timeline.csv –r F:\

The winxp plugin file makes things a lot easier since only one command has to be typed. However, the file parses a lot more data then I actually need. The plugins executed are: chrome, evt, exif, ff_bookmark, firefox3, iehistory, iis, mcafee, opera, oxml, pdf, prefetch, recycler, restore, setupapi, sol, win_link, xpfirewall, wmiprov, ntuser, software, and system. I only wanted to parse IE history but winxp is doing every browser supported by log2timeline. I only wanted to parse artifacts in the administrator’s user profile but the above command is parsing artifacts from every profile on the system. I wanted to limit my timeline to specific artifacts but winxp is giving me everything. Not exactly what I’m looking for.

Single plugins and default plugin files are viable methods for building timelines. However, neither let’s me easily build a timeline containing only my selected artifacts that were tailored to the case and system I’m processing. This is where custom plugin files come into play and why I use them instead.

Extracting Timestamps for my Timeline with Custom Plugin Files

Kristinn deserves all the credit for why I know about the ability to create custom plugin files. I’m just the guy who asked him the question and decided to blog the answer he gave me. A custom plugin file is a text file that lists one plugin per line and is saved with the .lst file extension. The picture is a custom file named test.lst and it contains plugins for prefetch files, event logs, and system restore points.

Custom Plugin File Example

The custom file is placed in the same directory where the default plugin files are located. On a Windows system with Log2timeline 0.60 installed the directory is C:\Perl\lib\Log2t\input\.

I only want to parse artifacts in the administrator user profile instead of all user profiles stored on the system. At the time I wrote this post, Log2timeline doesn’t have the ability to exclude full paths (such as unwanted user profiles) when running in recursive mode. As a result I create two custom plugin files; one file parses the artifacts in a user profile while the other parses the remaining artifacts throughout the system. This lets me control what user profiles to extract timestamps from since I can run the user plugin file against the exact ones I need.

The user custom plugin file is named custom_user.lst and contains the iehistory and ntuser plugins. The other custom plugin file is named custom_system.lst and contains the evt, xpfirewall, prefetch, and restore plugins. The two commands below execute the custom_user.lst against the administrator’s user account profile and custom_system.lst against the entire drive while saving the output to the file timeline.csv.

log2timeline.pl -z local -f custom_user -w C:\win-xp\timeline.csv –r “F:\Documents and Settings\Administrator”

log2timeline.pl -z local -f custom_system -w C:\win-xp\timeline.csv –r F:\

The commands extracted the timestamps from all of the artifacts on my list except for the entire registry hives last write times and file system timestamps. The picture shows the timeline built so far. The timeline is sorted and the section shown is where the prefetch file I referenced in the post What’s a Timeline is located.

Timeline Data Added by Custom Plugin File

Filesystem Timestamps

The filesystem timestamps is concerned about adding the activity involving files and directories to the timeline. There are different tools that extract the information including FTK Imager, AnalyzeMFT, Log2timeline, and the Sleuthkit. I’m demonstrating two different methods to add the data to my timeline to show the differences between the two. The tools for the first method include the Sleuthkit and Log2timeline while the second method only uses Log2timeline.

The fls.exe program in the Sleuthkit will list the files and directories in an image. The command below creates a bodyfile containing the files/directories’ activity in the test forensic image and stores the output in the file named fls-bodyfile.txt. (the –m switch makes the output format mactime, -r is for recursive mode, and –o is the sector offset where the filesystem starts)

fls.exe -m C: -r -o 63 C:\images\image.dd >> C:\win-xp\fls-bodyfile.txt

Fls.exe’s output is in the bodyfile format but my timeline is in Log2timeline’s csv format. Log2timeline has plugins to parse output files in the TLN and bodyfile formats. This means the tool can be used to convert one format into another. The command below parses the fls-bodyfile.txt file and adds the data to my timeline.

log2timeline.pl -z local -f mactime -w C:\win-xp\timeline.csv C:\win-xp\ fls-bodyfile.txt

The picture highlights the new entries to the section of my timeline. Doesn’t the story about what occurred become clearer?

Timeline Data Added by fls.exe

The file system in the Windows XP test system is NTFS. NTFS stores two sets of timestamps which are the $FILE_NAME attribute and $STANDARD_INFORMATION timestamps. Fls.exe along with the majority of the other forensic tools shows the $STANDARD_INFORMATION timestamps. However, there may be times when it’s important two include both sets of timestamps in a timeline. One such occurrence is when there’s a concern that timestamps might have been altered. Parsing the Master File Table ($MFT) can add both sets of timestamps to a timeline. The command below shows Log2timeline parsing the $MFT and adding the output to the file timeline-copy.csv.

log2timeline.pl -z local -f mft -w timeline.csv F:\$MFT

The picture below highlights the new entries for the data extracted from the $MFT. Notice the difference between the timeline only containing the $STANDARD_INFORMATION timestamps compared to containing both timestamps. Quick side note: the mft plugin could be added to a custom plugin file.

Timeline Data Added by $MFT

Registry Timestamps

In the artifact timestamps section Log2timeline extracted data from select registry keys. However, there are times when I want all registry keys’ last write times from registry hives. So far I want this ability when dealing with malware infections since it helps identify the persistence mechanism and registry modifications. The tools to extract the last write times from registry hives include Harlan’s regtime.pl script (I obtained it from the Sift 2.0 workstation) and Log2timeline. For my timeline I’m interested in the System, Software, and administrator’s NTUSER.DAT registry hives. The commands below has regtime.pl extracting the last write times from each hive and storing it in the bodyfile file named reg-bodyfil.txt (the –m switch prepends the text to each line and the –r switch is the path to the registry hive).

regtime.pl –m HKLM/system –r F:\Windows\System32\config\system >> C:\win-xp\reg-bodyfile.txt

regtime.pl –m HKLM/software –r F:\Windows\System32\config\software >> C:\winxp\reg-bodyfile.txt

regtime.pl –m HKCU/Administrator –r "F:\Documents and Settings\Administrator\NTUSER.DAT" >> C:\win-xp\reg-bodyfile.txt

Regtime.pl’s output is in the bodyfile format so Log2timeline makes the format conversion as shown in the command below.

log2timeline.pl -z local -f mactime -w C:\win-xp\timeline.csv C:\win-xp\reg-bodyfile.txt

The picture highlights the new data added to the timeline with the Sleuthkit. The timeline now highlights the malware’s persistence mechanisms (run and services registry keys)

Timeline Data with Registry Keys' Last Write Times

Sorting the Timeline

When new data is added to a timeline it’s placed at the end of the file which means the timeline needs to be sorted prior to viewing it. There are different sorting options such as the mactime.exe program in the Sleuthkit to bodyfile format timelines. A quick method I use is my spreadsheet program’s sort feature. The settings below will make Excel sort from the oldest time to the most recent.

Excel 2007 Sort Feature

Summary

The approach described in my Building Timeline series is just one way out of many to create timelines. The DFIR community has provided a wealth of information on the topic. Look at the following examples which are only a drop in the bucket of knowledge. Harlan Carvey created and released tools for creating timelines in addition to regularly posting on his blog (a few posts are HowTo: Creating Mini-Timelines and A Bit More About Timelines...). Kristinn Gudjonsson is very similar in that he created and released log2timeline in addition to providing information on his websites (a few posts are Timeline Analysis 101 and Timeline Analysis 201 – review the timeline). Rob Lee has shared his approach in the way he builds timelines and two of his posts are SUPER Timeline Analysis and Creation and Shadow Timelines And Other VolumeShadowCopy Digital Forensics Techniques with the Sleuthkit. Chris Pogue has shared his method to create timelines on his blog and a few posts are Log2Timeline and Super Timelines and Time Stomping is for Suckers. The last author I’ll directly mention is Don Weber who released his scripts for creating timelines and blogged about creating timelines (one post is Hydraq Details Revealed Via Timeline Analysis). These are only a few tools, blog posts, and authors who have taken the time to share their thoughts on timeline analysis. To see more try the keyword “timeline” in the Digital Forensic Search to see what’s out there.

For anyone looking to become more proficient at the timeline analysis then I recommend to do what I did. Read everything you can find on the topic, download and test the different tools people talk about, and try out different approaches to see how the resulting timelines differ. It won’t only teach you about timeline analysis but will help identify what method and tools work best for you.

Building Timelines – Thought Process Behind It

2011-09-17T15:46:00.004-04:00

Timelines are a valuable technique to have at your disposal when processing a case. They can reveal activity on a system that may not be readily apparent or show the lack of certain activity helping rule theories out. Timelines can be used on case ranging from human resource policy violations to financial investigations to malware infections to even auditing. Before the technique can be used one must first know how to build them.

This is the first post in my two part series on building timelines. Part 1 discusses the thought process behind building timelines while Part 2 demonstrates different tools and methods to build them.

Things to Consider

There are two well known approaches to building timelines. On the one hand is the minimalist approach; only include the exact data needed. On the other hand is the kitchen sink approach; include all data that is available. My approach falls somewhere in the middle. I put the data I definitely need into timelines and some data I think I may need. The things I take into consideration when selecting data is:

        - Examination’s Purpose
        - Identify Data Needed
        - Understand Tools’ Capabilities
        - Tailor Data List to System

Examination’s Purpose

The first thing I consider when building timelines is what is the examination’s purpose. Every case should have a specific purpose or purposes the DF analyst needs to accomplish. For example, did an employee violate an acceptable usage policy, how was a system infected, how long was a web server compromised, or locate all Word documents on a hard drive?

Identify Data Needed

The next area to consider is what data is needed to accomplish the purpose(s). This is where I make a judgment about the artifacts I think will contain relevant information and the artifacts that could contain information of interest. A few potential data sources and their artifacts are:

        - Hard drives: file system, web browsing history, registry hives, Windows short cut files, firewall logs, restore points, volume shadow copies, prefetch files, email files, or Office documents

        - Memory: network connections, processes, loaded dlls, or loaded drivers

        - Network shares: email files (including archives), office documents, or PDFs

        - Network logs: firewall logs, IDS logs, proxy server logs, web server logs, print/file server logs, or authentication server logs

I take into account the case type and examination's purpose(s) when picking the artifacts I want. To illustrate the affect case type has on my choice I'll use a malware infected system and Internet usage policy violation as examples. The malware infected system would definitely be interested in the artifacts showing program execution, firewall logs, antivirus logs, and file system metadata. The additional items I'd throw into a timeline would be the user's web browsing history, removable media usage, and registry keys last write times since those artifacts might show information about the initial infection vector and persistence mechanism. For an Internet usage policy violation I'd only include the file system metadata and web browsing history since my initial interest is limited to the person’s web browsing activities.

The examination purpose(s) will point to other artifacts of interest. Let's say if the Internet usage policy violation's purpose was to determine if an employee was surfing pornographic websites and if they were saving pornographic images to the company issued thumb drive. In addition to file system metadata and web history, I’d now want to include artifacts showing recent user activity such as Windows shortcut files or the userassist registry key.

I try to find a balance between the data I know I'll need and the data that may contain relevant information. I don't want to put everything into the timeline (kitchen sink approach) but I'm trying to avoid frequently adding more data to the timeline (minimalist approach). Finding a balance between the two lets me create one main timeline with the ability to create mini timelines using spreadsheet filters. Making the call about what data to select is not going to be perfect initially. Some data may not contain any information related to the examination while other left out data is going to be important. The important thing to remember is building timelines is a process. Data can be added or removed at later times which means thinking about data to incorporate into a timeline should occur continuously. This is especially true as more things are learned while processing the case.

Understand Tools’ Capabilities

After the examination’s purpose(s) are understood and the potential data required to accomplish it is identified then the next consideration is understanding my tools’ capabilities. Timeline tools provide different support for the artifacts they can parse. I review the items I want to put into my timeline against the artifacts supported by my tools to identify what in my list I can’t parse. If any items are not supported then I decide if the item is really needed and is there a different tool that will work. Another benefit to making this comparison is that helps to identify artifacts I might not have thought about. The picture below shows some artifacts supported by the tools I’ll discuss in the post Building Timelines – Tools Usage.

Some may be wondering why I don’t think about the tools’ capability before I consider the data I need to accomplish the examination’s purpose(s). My reason is because I don’t want to restrict myself to the capability provided by my tools. For example, none of my commercial tools are able to create the timelines I’m talking about. If I based my decision on how to accomplish what I need to do solely on my commercial tools then timelines wouldn’t even be an option. I’d rather first identify the data I want to examine then determine if my tools can parse it. This helps me see the shortcomings in my tools and lets me find other tools to get the job done.

Tailor Data List to System

At this point in the thought process potential data has been identified to put into a timeline. A timeline could be built now even though the artifact list is pretty broad. My preference is to tailor the list to the system under examination. To see what I mean I’ll discuss a common occurrence I encounter when building timelines which is including a user account’s web browser history. Based on my tools supported artifacts, the web browsing artifacts could be from: Google Chrome, Firefox 2, Firefox 3, Internet Explorer, Opera, or Safari. Is it really necessary to have my tools search for all these artifacts? If the system only has Internet Explorer (IE) installed then why spend time looking for the other items. If the same system has 12 loaded user profiles but the examination is only looking at one user account then why parse the IE history for all 12 user profiles? To minimize the time building timelines and reduce the amount of data in them the artifact list needs to be tailored to the system. A few examination checks will be enough narrow down the list. The exact checks will vary by case but one step that holds across all cases is obtaining information about the operating system (OS) and its configuration.

I previously discussed this examination step in the post Obtaining Information about the Operating System and it covers the three different information categories impacting the artifact list. The first category is the General Operating System Information and it shows the operating system version. The version will dictate whether certain artifacts are actually in the system since some are OS specific. The second category is the User Account Information which shows the user accounts (local accounts as well as accounts that logged on) associated with the system. When building a timeline it’s important to narrow the focus for the user accounts under examination; this is even more so on computers shared by multiple people. Identifying the user accounts can be done by confirming the account assigned to person, looking at the user account names, or looking at when the user accounts were last used. The third and final category is the Software Information. The category shows information about programs installed and executed on the system. The software on a system will dictate what artifacts are present. Quickly review the artifacts supported by my tools (picture above) to see how many are associated with specific applications. This one examination step can take a broad list and make it more focused to the environment where the artifacts are coming from.

Select Data for the Timeline

I reflect on the things I considered when coming up with a plan on how to build the timeline The examination's purpose outlined what I need to accomplish, potential data I want to examine was identified, my tool's capabilities were reviewed to see what artifacts can be parsed, and then checks were made to tailor the artifact list to the system I’m looking at. The list I’m left with afterwards is what gets incorporated into my first timeline. Working my way through this thought process reduces the amount of artifacts going into a timeline; thus reducing the amount of data I’ll need to weed through.

Thought Process Example

The thought process I described may appear to be pretty extensive but that is really not the case. The length is because I wanted to do a good job explaining it since I feel it’s important. The process only takes a little time to complete and most of it is already done when processing a case. Follow along a DF analyst on a hypothetic case to see how the thought process works in coming up with a plan to build the timeline. Please note, the case only mentions a few artifacts to get my point across but an actual case may use more.

Friend: “Damm … Some program keeps saying I’m infected and won’t go away. Let me call the DF analyst since he does something with computers for a living. He can fix it”

Phone rings and DF analyst picks up

Friend: “DF analyst … Some program keeps saying I’m infected with viruses and blocks me from doing anything.”

DF analyst: “Do you have any security programs installed such as antivirus software, and if so is that what you’re seeing”

Friend: “I think I have Norton installed but I’ve never seen this program before. Wait … hold on … Oh man, now pornographic sites are popping up on my screen”

DF analyst: “Yup, sounds like you’re infected”

Friend: “I know I’m infected. That’s what I told you this program has been telling me”

DF analyst: “Umm .. The program saying you are infected is actually the virus.”

Friend: “Hmmmm….”

DF analyst: “Just power down the computer and I’ll take a look at later today.”

Computer powering down

DF analyst: “When did you start noticing the program?”

Friend: “Today when I was using the computer.”

DF analyst: “What were you doing?”

Friend: “Stuff… Surfing the web, checking email, and working on some documents. I really need my computer. Can you just get rid of the virus and let me know if my wife or kids did this to my computer?”

Later that day

DF analyst has the system back in the lab. He thinks about what he needs to do which is to remove the malware from the system and determine how it got there. The potential data list he came up with to accomplish those tasks was: known malware files, system’s autostart locations, programs executed (prefetch, userassist, and muicache), file system metadata, registry hives, event logs, web browser history, AV logs, and restore points/volume shadow copies.

Wanting to know what launches when his friend logs onto the computer the DF analyst uses the Sysinternals autorun utility in offline mode to find out. Sitting in one run key was an executable with a folder path to his friend’s user profile. A Google search using the file’s MD5 hash confirmed the file was malicious and his friend’s system was infected. DF analyst decided to leverage a timeline to see what else was dropped onto the system and what caused it to get dropped in the first place.

DF analyst pulls out his reference showing the various artifacts supported by his timeline tools. He confirms that all the potential data he identified is supported. Then he moves on to his first examination step which is examining the hard drive’s layout. Two partitions, one is the Dell recovery formatted with Fat32 while the other is for the operating system formatted with NTFS. DF analysts just added NTFS artifacts ($MFT) to his potential data list. To get a better idea about the system he uses Regripper to rip out the general operating system information. Things he learned from the Regripper reports and the decisions he made based on the information:

        - OS version is XP (restore points are in play while shadow copies are out. Need to parse event logs with evt file extensions)

        - Three user accounts were used in the past week (initial focus for certain artifacts will be from friend’s user account since malware was located there. The two other user accounts may be analyzed depending on what the file system metadata shows)

        - Internet Explorer was only web browser installed (all other web browser artifacts won’t be parsed at this time)

        - Kaspersky antivirus software was installed (tools don’t support this log format. AV log will be reviewed and entries will be put into the timeline manually)

DF analyst performs a few other checks. Prefetch folder has files in it and his friend’s user account recycle bin has numerous files in it. Both were added to the timeline artifact list. The final list contains items from the system and one user account. The system data has: prefetch files, event logs (evt), system restore points, Master file Table. The artifacts from one user account are: userassist registry key, muicache registry key, IE history, and the Recycle bin contents. DF analyst is ready to build his timeline …. Stay tuned for the post "Building Timelines – Tools Usage" to see one possbile way to do it.

I'd like to hear feedback about how other's approach building timelines; especially if it's different than what I wrote. It's helpful to see how other analysts are building timelines.

Linkz 4 Advice

2011-09-12T18:16:00.009-04:00

There won’t be any links pointing to Dr. Phil, Dear Abby, or Aunt Cleo. Not that there’s anything wrong that… They just don’t provide advice on a career in DFIR.

Getting Started in DFIR

Harlan put together the post Getting Started which contains great advice for people looking to get into DF. I think his advice even applies to folks already working in the field. DF is huge with a lot of areas for specialization. Harlan’s first tip was to pick something and start there. How true is that advice for us since we aren’t Abby from NCIS (a forensic expert in everything)? People have their expertise: Windows, Macs, cell phones, Linux, etc. but there is always room to expand our knowledge and skills. The best way to expand into other DF areas is to “pick something and start there”.

Another tip is to have a passion for the work we do. In Harlan’s words “in this industry, you can't sit back and wait for stuff to come to you...you have to go after it”. I completely agree with this statement and DF is not the field to get complacent in. There needs to be a drive deep down inside to continuously want to improve your knowledge and skills. For example, it would be easy to be complacent to maintain knowledge only about the Windows XP operating system if it’s the technology normally faced. However, it would be ignoring the fact that at some point in the near future encounters with Windows 7 boxes and non-Windows system will be the norm. A passion for DF is needed to push yourself so you can learn and improve your skills on your own without someone (i.e. an employer) telling you what you should be doing.

I wanted to touch on those two tips but the entire post is well worth the read, regardless if you are looking to get into DF or already arrived.

Speaking about a Passion

Little Mac over at the Forensicaliente blog shared his thoughts about needing a drive to succeed in DF. I’m not musically inclined but he uses a good analogy to explain what it takes to be successful. Check out his post Is Scottish Fiddle like Digital Forensics?.

Breaking into the Field

Lenny Zelster discussed How to Get Into Digital Forensics or Security Incident Response on his blog last month. One issue facing people looking to break into the field is that organizations may not be willing to spend the time and resources to train a person new to the field. Lenny suggested people should leverage their current positions to acquire relevant DFIR skills.

Lenny’s advice doesn’t apply to how I broke into the field since DFIR was basically dropped into my lab when I was tasked with developing the DF capability for my organization. However, his advice is spot on for how I was able to land my first position in the information security field (which is what lead me into DFIR). I was first exposed to security during my undergraduate studies when I took a few courses on the topic. It was intriguing but the reality was there weren’t a lot of security jobs in my area which meant my destination was still IT operations. I continued down the track pushing me further into IT but I always kept my desire for security work in mind. After graduation I took a position in an IT shop where I had a range of responsibilities including networking and server administration. In this role, I wanted to learn how to secure the technology I was responsible for managing and what techniques to use to test security controls. This is due diligence as being a system admin but it also allowed me to get knowledge and some skills in the security field. In addition to operational security, I even tried to push an initiative to develop and establish an information security policy. Unfortunately, the initiative failed and it was my first lesson in nothing will be successful without management’s support. All was not lost because the experience and my research taught me a lot about security being a process that supports the business. This is a key concept about security and up until that point my focus was on security's technical aspects.

I leveraged the position I was in to acquire knowledge and skills about my chosen field (security). My actions weren’t completely self serving since my employer benefited from having someone to help secure their network. I didn’t realize how valuable it was to expand my knowledge and skills until my first security job interview. Going in I thought I lacked the skills and knowledge but over the course of the interview I realized I had a lot more to offer. I took the initiative to expand my skillset and it was an important factor in helping me land in the security field. My experience is very similar to the Lenny’s advice except his post is about getting into the DFIR field.

Get a plan before going into the weeds

Rounding out the links providing sound guidance, Bill over at the Unchained Forensics blog gave some good advice in his recent post Explosions Explosions. He shared his thoughts on how he approaches examinations. One comment he made that I wanted to highlight was “more and more of my most efficient time is being used at the case planning stage”. He mentions how he thinks about his plan to tackle the case, including identifying potential data of interest, before he even starts his examination. I think it’s a great point to keep reinforcing for people new and old to DFIR.

I remember when I was new to the field. I had a newly established process and skillset but I lacked certain wisdom in how to approach cases. As expected, I went above and beyond in examining my first few cases. I even thought I was able to do some “cool stuff” the person requesting DF assistance would be interested in. There was one small issue I overlooked. The person was only interested in specific data’s content while I went beyond that, way beyond that. I wasted time and the cool stuff I thought I did was never even used. I learned two things from the experience. First was to make sure I understand what I’m being asked to do; even if it means asking follow-up questions or educating the requestor about DF. The second lesson was to think about what I’m going to do before I do it. What data do I need? What steps in my procedures should I complete? What procedural steps can be omitted? What’s my measure for success telling me when the examination is complete? Taking the time beforehand to gather your thoughts and develop a plan helps to keep the examination focused on the customer’s needs while limiting the “cool stuff” that’s not even needed.

Books On demand

If someone were to ask me what is the best training I have every taken I know exactly what I would say. A book, computer, Google, and time. That’s it and the cost is pretty minimal since only a book needs to be purchased. I’m not knocking training courses but classes cannot compare to educating yourself through reading, researching, and testing. I never heard about Books24x7 until I started working for my current employer. Books24x7 is virtual library providing access to “in-class books, book summaries, research reports and best practices”. The books in my subscription include topics on: security, DFIR, certification, business, programming, operating systems, networking, and databases. I can find the information I’m looking for by searching numerous books whether I’m researching, testing, or working. A quick search for DFIR books located: Malware Forensics: Investigating and Analyzing Malicious Code, Windows Registry Forensics: Advanced Digital Forensic Analysis of the Windows Registry, Windows Forensic Analysis Toolkit Second Edition, Malware Analyst's Cookbook: Tools and Techniques for Fighting Malicious Code, EnCase Computer Forensics: The Official EnCE: EnCase Certified Examiner Study Guide, and UNIX and Linux Forensic Analysis Toolkit. That’s only a few books from the pages and pages of search results for DFIR. Talk about a wealth of information at your fingertips.

The cost may be a little steep for an individual but it might be more reasonable for an organization. If an organization’s employees have a passion for their work and take the initiative to acquire new skills then Books24x7 could be an option as a training expense. Plus, it could save money from not having to purchase technical books for staff. Please note, I don’t benefit in any way by mentioning this service on my blog. I wanted to share the site since it’s been a valuable resource when I’m doing my job or self training to learn more about DFIR and security.

What’s a Timeline

2011-09-07T21:38:00.001-04:00

Timeline analysis is a great technique to determine the activity that occurred on a system at a certain point in time. The technique has been valuable for me on examinations ranging from human resource policy violations to financial investigations to malware infections. Here is an analogy I came up with to explain what timelines are.

Not Even Close To a Timeline

The picture below shows how data looks on a hard drive using the operating system. It does a decent job if you are using the computer but the method doesn’t work for a forensic examination. There’s a lot of missing data such as: file system artifacts, hidden files/folders, and the metadata stored in files/folders.

In technical books cabinets are used to explain how hard drives function since they store items similar to how a drives store data. Using the operating system to view data on a hard drive is the equivalent to looking at the cabinet as pictured below. You are unable to see what lies beneath.

Getting Closer To a Timeline

The picture below shows how data on a hard drive looks using a digital forensic tool. The tool does a better job than the operating system since it displays a lot more data. File system artifacts, hidden files/folders, and file system metadata can now be examined. However, the tool does not readily show some data such as the metadata stored inside of files. The picture highlights the need for additional steps to extract the data inside prefetch files.

The cabinet’s contents can now be seen since the doors are opened. There are containers, pots, and pans. However, additional steps need to be taken to determine what is inside those items. Just like more steps are required in Encase to see prefetch files’ metadata.

This is What I’m Talking About

The picture below shows how data looks on a hard drive using a timeline. It might not look as pretty as a Graphical User Interface but it provides so much more data. The timeline section shown contains: both timestamps from the Master File Table (MFT), data stored in prefetch files, events from an event log, and registry keys.

The opened cabinet doors allowed the pots, pans, and containers’ contents to be examined. To the untrained eye it might look like chaos but to the knowledgeable observer they can now see what was stored in the cabinet including the now visible measuring cups. It's kind of like how a timeline makes visible activity on a system that may not have been readily apparent.

Batch Scripting References

2011-08-30T19:10:00.006-04:00

“Give a man a fish; you have fed him for today. Teach a man to fish; and you have fed him for a lifetime”—Author unknown.

My ability to use my weak kung fu to put together batch scripts has only been a recent occurrence. For the most part I was always constricted by my tools. If my tool wasn’t able to automate a process then I’d adapt and take a little bit more time to complete a task. If my tools didn’t perform a task then I’d search for another tool or script to accomplish what I needed. Basically, I had to adapt to my tools to perform a task instead of making my tools adapt to the task at hand. Things changed when I spent a week working on a case when I realized knowing how to script was a necessity. I’m sharing the references I came across that did a decent job of teaching me how to write batch files.

The first reference was what taught me how to fish. Batch Files (Scripts) in Windows provides an introductory overview about batch files. The article starts out explaining what a batch file is and how to construct one before it covers more advanced topics. A few topics include explanations about using if statements and for loops in scripts. The author provides links pointing to explanations about terms the reader may want more information on. The article taught me the basics of writing batch files and afterwards I was able to write simple scripts without needing to do anymore research. In a way the article converted me from being a person who receives fish from others (scripts) to one who is able to catch my own fish (write my own scripts).

The scripts I’ve been writing automate repetitive tasks such as running the same command against different folders. The for loop is one option to complete repetitive tasks and this is where the next reference comes into play. ss64.com’s For loop webpages breaks down the syntax for the different ways to implement a for loop. The information on the site gave me a better understanding on how to write for loops. If Batch File (Scripts) in Windows taught me how to fish then ss64 helped me to improve my casting.

Despite having a pretty decent cast, I’m still fishing with a bobber. Beginner fishermen may have a tough time knowing when to set the hook in the fish’s mouth so a bobber helps them. Bobbers are a visual indicator that a fish is biting your line which alerts the fisherman when to set the hook. Similar to a beginner fisherman, I still need to learn a lot more. Rob van der Woude’s Scripting Pages website has a few pages discussing batch scripting. So far the site has helped me solve a few scripting problems I encountered but there’s still a wealth of information I haven’t even read.

One item that makes batch scripting a little easier is native Windows commands can be used in addition to third party tools. Microsoft’s Command-line reference A-Z is a great resource for learning about commands. The command-line reference A-Z is the equivalent to adding additional lures and bait to your tackle box so you can catch bigger and better fish.

The last reference and one that shouldn’t be overlooked is having a person to bounce ideas off of. The person doesn’t need to be an expert either. My coworker is in the same boat as me and is trying to learn how to write batch files. It’s been helpful to have someone to provide feedback on what I’m trying to do and to help me work through complex code. A person is like a fishing buddy who can provide you with some tips, better ideas, or helps you become a better fisherman.

Learning how to write batch scripts has been an awaking. I’m leveraging my tools to extract data in different ways and I'm cutting the time required to complete some tasks in half. I constantly reflect on what tasks can be automated with scripting and how I can present extracted data to better suite my needs. Paraphrasing the quote I referenced through out my post is the best way to illustrate how I benefited from learning how to script.

“Give a man a script; you have solved his issue for today. Teach a man to script; and you help him solve his own issues for a lifetime.”

Where Is the Digital Forensics Threat Report

2011-08-22T22:01:00.000-04:00

Every year brings a new round of reports outlining the current trends. Information security threats, data breaches, and even cyber crime are covered in the reports. The one commonality across every report is they are lacking the digital forensic perspective. The reports address the question of what are the current threats potentially affecting your information and systems. However, the DFIR point of view asks the follow-up questions: how would you investigate a current threat that materialized on your systems and what would the potential artifacts look like? If a DF Threat Report existed then I think those two questions would be answered.

What The DF Threat Report Could Contain?

I’d like to see the report use case examples to illustrate a specific threat on a system. I find it easier to understand an investigative method and potential artifacts by following along an examination from start to finish. A simple way to demonstrate the threats would be to just replicate it on a test system. The use of test systems would enable the threat to be discussed in detail without revealing any specific case details. The current trend reports would just be guides highlighting what threats to focus on.

To see what I’m talking about I’ll walk through the process of how threats can be identifed for the DF Threat Report. The threats can then be simulated against test systems in order to answer the questions I'm bringing up. In the past two weeks I read the Sophos Security Threat Report Mid-Year 2011 and Securelist Exploit Kits Attack Vector – Mid-year Update reports. I’m using both reports since they are fresh in my mind but the areas I’m highlighting as lacking are common to most threat reports I’ve read (I’m not trying to single out these two organizations).

Example DF Threat Report Topics

The Sophos Security Threat Report Mid-year 2011 talked about the different ways malware is distributed. The threats covered included web threats, social networking, and email SPAM / spearphishing. The Securelist Exploit Kits Attack Vector Mid-year Update discussed the popular exploit kits in use and what vulnerabilities are targeted by the two new kits in the list (Blackhole and Incognito). There are threats in both reports that merit further discussion and would fit nicely in a DF Threat Report.

Sophos stated they “saw an average of 19,000 new malicious URLs every day” with more than 80% of the URLs belonging to legitimate companies whose websites were hacked. The report provided some statics on the URLs before moving on to the next threat. The DF Threat report could take two different angles in explaining the web threat; the server or client angle. If the phone rang at your company and the person on the other end said your website was serving up malware then how would you investigate that? What are the potential artifacts to indicate if malware is actually present? How would you determine the attack vector used to compromise the website? Now for the client angle, a customer comes up to you saying there is a rogue program holding their computer hostage. What approach would you use to identify the initial infection vector? What are the potential artifacts on the system to indicate the malware came from a compromised website as opposed to an email? These are valid follow-up questions that should be included in the web threat’s explanation.

The next threat in the Sophos report was Blackhat search engine optimization (SEO). SEO is a marketing technique to draw visitors to companies’ websites but the same technique can be used to lure people to malicious websites. “Attackers use SEO poisoning techniques to rank their sites highly in search engine results and to redirect users to malicious sites”. As expected the report doesn’t identify what the potential artifacts are on a system to indicate SEO poisoning. I could guess what the system would look like based on my write-up on the potential artifacts from Google image search poisoning. However, answering the question by examining a test system is a better option than making an assumption.

Another threat in the Sophos report was the ongoing attacks occurring in Facebook, Twitter, and Linkdin. “Scams on Facebook include cross-site scripting, clickjacking, survey scams and identity theft”. On Twitter attackers are using shortened URLs to redirect people to malicious websites. LinkedIn malicious invitation reminders contain links to redirect people to malicious websites. Again, the investigative method and artifacts on a system were missing. The same question applies to this threat as well. What are the potential artifacts on a system to indicate Blackhat SEO?

Rounding out the Sophos threats I’m discussing is SPAM /spearphishing. A few of the high profile breaches this year were covered and a few of them involved spearphishing attacks. Unfortunately, there was no mention explaining the artifacts tying malware to a specific email containing an exploit. Nor was there a mention of how your investigation method should differ if there is even a possibility spearphishing was involved.

The Securelist Exploit Kits Attack Vector Mid-year Update report identified the top exploit kits used in the first half of the year. One interesting aspect in the report was the comparison between the vulnerabilities targeted by the Blackhole and Incognito exploit kits. The comparison showed the kits pretty much target the same vulnerabilities. The DF Threat Report may not be able to cover all the vulnerabilities in the list but it could dissect one or two of them to identify the potential artifacts left on a system from exploitation.

Conclusion

The process I walked through to identify content for the DF Threat Report used reports related to security threats. However, a DF Threat report could cover various topics ranging from security to cybercrime. The report’s sole purpose would be to make people more aware about how to investigate a threat that materialized on your systems and what might the potential artifacts look like? In my short time researching and documenting attack vector artifacts I’ve found the information valuable when examining a system. I’m more aware about what certain attacks look like on a system and this helps me determine the attack vector used (and not used). I think the DF Threat Report could have a similar effect on the people who read it.

It would take an effort to get an annual/semi-annual DF Threat report released. People would be needed to organize its creation, research/test/document threats, edit the report, and to release the report. I wouldn’t only be an occasional author to research/test/document threats but I’d be a reader eager to see the DF Threat Report with each new year. Maybe this is just wishful thinking on my part that one day when reading a report outlining the year’s trends there will actually be useful DFIR information that could be used when investigating a system.

Links 4 Everyone

2011-08-10T21:51:00.001-04:00

In this edition of Links I think there is a little bit of something for everyone regardless if your interest is forensics, malware, InfoSec, security auditing or even good a rant ….

Digital Forensic Search Updates

The Digital Forensic Search index has been slowly growing since it was put together four months ago. Last Sunday’s update brought the sites in the index to: 103 DFIR blogs, 38 DFIR websites, 13 DFIR web pages, and 2 DFIR groups. The initial focus of DFS was to locate information related to specific artifacts as opposed to locating tools to parse those artifacts. My reasoning was because I didn’t want to weed through a lot of irrelevant search hits. Most tools’ websites only provided a high level overview of an artifact the tool parses instead of in-depth information. It made sense to leave out tool specific sites to reduce the amount of noise but things change.

A question I ask myself at times is what tool can parse artifact XFZ. I’m not alone asking the question because I see others asking the same thing. To make things easier in locating tools I’m now adding tool specific sites to the Digital Forensic Search. So far 15 websites and 7 web pages are indexed. I ran a few tests and the search results seem to be a good mixture of hits for information and tools. My testing was limited so if anyone sees too much noise then just shoot me an email telling me who the culprit is.

Let me know of any links missing from DFS

Windows Shortcut File Parser Update

My post Triaging My Way mentions a need I had for a command line tool to parse Windows Shortcut files. In my quest for a tool I modified the lslnk.pl perl script to produce the output I wanted. One of the modifications I made to the script was to examine all of the files in a folder and to only parse files with the lnk file extension. I was running lslnk-directory-parse.pl (modified script) against some shortcut files when the script would abruptly stop. The parsed information from the last file only contained the file system timestamps. Examination of the file showed that it was empty and this was what caused lslnk-directory-parse.pl to die. I made a slight modification to lslnk-directory-parse.pl so the script checks each files’ header to confirm it is indeed a Windows shortcut file. I uploaded the new scripts (lslnk-directory-parse.pl and lslnk-directory-parse2.pl) to the Yahoo Win4n6 group and added a version number (v1.1) in the comments.

There are always different ways to accomplish something. When faced with trying to parse all of the Window shortcut files in a folder I opted to modify an existing script to meet my needs. The Linux Sleuthing blog took a different approach in the post Windows Link Files / Using While Loops. The author uses a while loop with an existing script to parse all of the shortcut files in a folder. Their approach is definitely simpler and quicker than what I tried to do. I learned a lot from the approach I took since I had to understand what modifications to make to an existing script in order to get the output I wanted.

How to Mount a Split Image

Speaking of the Linux Sleuthing blog. They provided another useful tip in the post Mounting Split Raw Images. As the name of the post implies it is about how to mount a split image in a Linux environment. I can’t remember the last time I dealt with a split image since I no longer break up images. However, when I used to create split images I remember asking myself how to mount it in Linux. To others the question may be simple but I didn’t have a clue besides concatenating to make a single image. The Mounting Split Raw Images post shows that sharing information – no matter how simple it may appear – will benefit someone at some point in time.

$UsnJrnl Goodness

Bugbear over at Security Braindump put together a great post Dear Diary: AntiMalwareLab.exe File_Created. I recommend anyone who will be encountering a Windows Vista or 7 system to read the post even if malware is not typically encountered during examinations. The $UsnJrnl record is an NTFS file system artifact which is turned on by default in Vista and 7. Bugbear discusses what the $UsnJrnl record is and how to manually examine it before discussing tools to automate the examination.

What I really like about the post is the way he presented the information. He explains an artifact, how to parse the artifact, a tool to automate the parsing and then shares an experience of how the artifact factored into one of his cases. I think the last part is important since sharing his experience provides context to why the artifact is important. His experience involved files created/deleted on the system as a result of a malware infection. Providing context makes it easier to see the impact of $UsnJrnl on other types of investigations. For example, a reoccurring activity I need to determine on cases is what files were deleted from a system around a certain time. Data in the $UsnJrnl record may not only show when the files of interest were deleted but could highlight what other files were deleted around the same time.

Memory Forensic Image for Training

While I’m on the topic of malware I wanted to pass along a gem I found in my RSS feeds and seen others mention. The MNIN Security Blog published the Stuxnet's Footprint in Memory with Volatility 2.0 back in June but I didn’t read it until recently. The post demonstrates Volatility 2.0’s usage by examining a memory image of a system infected with Stuxnet. A cool thing about the write-up is the author makes available the memory image they used. This means the write-up and the memory image can be used as a guide to better understand how to use Volatility. Just download Volatility, download the memory image, read the post, and follow along by running the same commands against the memory image. Not bad for a free way to improve your Volatility skills.

Easier Way to Generate Reports from Vulnerability Scans

Different methods are used to identify known vulnerabilities on systems. Running various vulnerability scanners, web application scanners, and port scanners are all options. One of the more tedious but important steps in the process is to correlate all of the tools’ outputs to identify: what vulnerabilities are present, their severity, and their exposure on the network. Obtaining this kind of information from the scans was a manual process since there wasn’t a way to automate it. James Edge over at Information Systems Auditing is trying to address this issue in something he calls the RF Project (Reporting Framework Project). RF Project is able to take scans from Nessus, Eeye Retina, Nmap, HP WebInpect, AppScan AppDetective, Kismet, and GFI Languard so custom reports can be created. Want to know the potential vulnerabilities detected by Nessus, Retina, and Nmap against server XYZ? Upload the scans to the reporting framework and create a custom report showing the answer instead of manually going through each report to identify the vulnerabilities. I tested an earlier version of the framework when it only supported Nessus and Retina a few years ago. It’s great to see he continued with the project and added support for more scans.

Jame’s site has some useful stuff besides the RF project. He has a few hacking tutorials and some technical assessment plans for external enumeration, Windows operating system enumeration, and Windows passwords.

Good InfoSec Rant

I like a good rant ever once in awhile. Assuming the Breach’s I do it for the Lulz explains the reason the author works in security. It’s not about the money, job security, or prestige; he works in security because it’s a calling. The post was directed at the InfoSec field but I think the same thing applies to Digital Forensics. Take the following quote:

“Technology, and especially information security has always been more than a job to me. More than even a career. It's a calling. Don't tell my boss, but I'd do this even if they didn't pay me. It's what I do. I can't help it.”

I can’t speak for others but digital forensics is the most changing field I’ve ever worked in. Technology (hardware and software) is constantly changing in how it stores data and the tools I use to extract information are also evolving. Digital forensics can’t be treated as a normal 8 to 4 job with any chance of being successful. Five days a week and eight hours each day is not enough time for me to keep my knowledge and skills current about the latest technology, tool update, threat, or analysis technique. It’s not a job; it’s my passion. My passion enables me to immerse myself in DFIR so I can learn constantly and apply my skills in different ways outside of work for my employer.

I wouldn’t last if digital forensics was only a day job. Seriously, how could I put myself through some of the things we do if there is no passion? We read whitepapers dissecting artifacts and spend countless hours researching and testing to improve our skills. Doing either of these things would be brutal to someone who lacks passion for the topic. For example, I couldn’t hack it being a dentist because I lack the passion for dentistry. I wouldn’t have the will power to read a whitepaper explaining some gum disease or spend hours studying different diagnosis. Dentistry would just be an 8 to 4 day job that pays the bills until I could find something else. DFIR on the other hand is another story as I spend my evening blogging about it after spending the day working on a case.

Happy Birthday jIIr

2011-08-06T00:43:00.004-04:00

It’s hard to believe a year has gone by since I launched my blog. I didn’t know what to expect when I took an idea and put it into action. All I knew was I wanted to talk about investigating security incidents but at the time I didn’t have the IR skillset. I also wanted to provide useful content but I was short on personal time to research, test, and write. I went ahead anyway despite the reasons discouraging me from blogging.

The experience has been rewarding. I’m a better writer from explaining various topics in a way that others can learn from my successes and failures. I have a better understanding about DFIR from the feedback I received. The feedback also helps to validate what 'm thinking and doing. Different opportunities arose -such as talking with other forensicators- as a direct result of my willingness to share information.

The top six posts of the year covered a range of topics from detecting security incidents to examining an infected system to a book review. The most read posts of the year were:

     1. Google the Security Incident Detector
     2. Introducing the Digital Forensics Search
     3. Reviewing Timelines with Excel
     4. Review of Digital Forensics with Open Source Tools
     5. Smile for the Camera
     6. Anatomy of a Drive-by Part 2

I’m looking forward to another year and there is a range of ideas in the hopper. I’ll still touch on investigating security incidents as well as researching attack vector artifacts. However, my focus will gradually extend from the artifacts on a single system to the artifacts located on different network devices. Besides IR, I’m planning on talking about supporting financial investigations, Windows 7 (and Server 2008) artifacts, my methodology, different information security topics, and random DFIR thoughts inspired by things I come across along the way.

Thanks to everyone who keeps stopping by jIIr. There’s no need to be a stranger when there’s a comment feature to let me know what you think. ;) A special thank you to all of the other bloggers and authors who link to my blog and share their thoughts about my posts. I'm thankful for the additional traffic you send my way since it helps to let others know about the blog.

Obtaining Information about the Operating System

2011-07-31T22:50:00.002-04:00

When I approach an analysis I perform the same initial steps to shed light on the system under examination. The first step is to review the master boot record and the second step is to obtain general information about the operating system and its configuration. The impact of the information on a digital forensic analysis can be significant.

Quick note before anyone takes the time to read further. My post doesn’t offer any new information. The registry keys referenced are well documented and the automation of Regripper is not new. I find it helpful to see how other analysts use tools and I thought others may feel the same way. My post demonstrates how Regripper can be automated in a batch file to reveal general information about a system; thereby saving some time when completing the information gathering examination step.

RegRipper is an open source tool for extracting data stored in the registry. When reviewing Regripper’s output I reference a document I created (outlines various artifacts) which allows me to see the data from registry keys in a specific order. I never thought twice about reviewing the output like this since I was only getting the initial information about the operating system. A couple of weeks ago I was going through Regripper reports when it dawned on me that I should automate the process. Create one report showing the information from the registry keys in a specific order. I wrote a small batch script to automate the creation of the operating system information report. If you just want the script then use the link at the end of the post. Otherwise, you can keep reading to see my thought process of how I put the script together before checking out the file. The script organizes information into the following five categories: general operating system information, user information, software information, networking information, and storage locations.

Thought Process behind the Batch File

        General Operating System Information

The first category has a significant impact on how the examination is conducted since it contains information about the operating system such as version, timezone settings, and machine security identifier (SID). The operating system version will dictate where certain artifacts are located and what tools can be used while the timezone settings should be self explanatory. The machine security identifier comes into play when looking at the user accounts’ SIDs since it shows if the user account is from the local or remote system. The following is the category’s information of interest and the registry keys containing the data:

* Operating system version and product name (HKLM\Software\Microsoft\Windows NT\Currentversion\)

* Registration information for owner and organization entered during installation (HKLM\Software\Microsoft\Windows NT\Currentversion\)

* Machine Security Identifier (SID) (HKLM\Security\Policy\PolAcDms)

* Shutdown information (HKLM\System\Controlset###\Control\Windows)

* Timezone information (HKLM\System\Currentcontrolset\Control\Timezoneinformation)

* Auditing configuration (HKLM\Security\Policy\PolAdtEv)

* Determine if the NTFS last access time is set to not to update (HKLM\System\CurrentControlSet\Control\Filesystem\NtfsDisableLastAccessUpdate)

        User Account Information

The next category obtains information about the user accounts associated with the computer. The information includes the configured local user accounts and groups as well as the artifacts of other user accounts (such as Windows domain users) logging onto the system. The category can help focus the examination on the activity of specific user accounts. The following is the category’s information of interest and the registry keys containing the data:

* Configured local user accounts and groups (HKLM\SAM\Domains\Account\)

* User profiles on machine and registered with Windows (Profilelist registry key)

* Logon username of the specified user account (HKCU\ Software\Microsoft\Windows\CurrentVersion\Explorer)

* Previous user accounts to log onto the machine (HKLM\Software\Microsoft\Windows NT\Currentversion\Winlogon\Defaultusername and HKLM\Software\Microsoft\Windows NT\Currentversion\Winlogon\Altdevaultusername)

        Software Information

The software category obtains information about programs installed and executed on the system. Knowing the software on a system can help shed light on the potential data available. For example, if the examination is interested in locating financial files then the software category will reveal the financial programs on the system thereby identifying the relevant file types. The following is the information of interest in the category and the registry keys containing the data:

* Programs showed on the Add/Remove Programs control panel applet (HKLM\Software\Microsoft\Windows\Currentversion\Uninstall)

* File system paths to various programs (HKLM\Software\Microsoft\Windows\Currentversion\App paths)

* Information about installed products (HKLM\Software\Microsoft\Windows\CurrentVersion\Installer\UserData)

* Default web browser (one area to check is HKLM\Software\Classes\HTTP\shell\open\command)

* User specific software (HCU\Software)

* User activity via the Windows Explorer shell may show programs ran (HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist)

* Executables associated with the user account (XP is HKCU\Software\Microsoft\Windows\ShellNoRoam\MUICache and Vista/7 is is HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\MuiCache in userclass.dat)

        Networking Information

The next category obtains information about networking such as the computer’s name, network shares, and firewall settings. The majority of computers are connected to some sort of network and the information in this category helps explain the type of network the system came from. The following is the information of interest in the category and the registry keys containing the data:

* Computer name (HKLM\System\Currentcontrolset\Control\Computername)

* Domain and hostname (HKLM\System\Currentcontrolset\Services\Tcpip\Parameter)

* Configured network shares on the computer (HKLM\System\Currentcontrolset\Services\Lanmanserver\Shares)

* Configured persistent routes (HKLM\System\ControlSet###\Services\Tcpip\Parameters\PersistentRoutes)

* Firewall configuration (HKLM\System\Currentcontrolset###\Services\Sharedaccess\Parameters\Firewallpolicy)

* Networking information (HKLM\System\Currentcontrolset###\Network)

* Cache of computers seen by Windows Explorer (HKCU\Software\Microsoft\Windows\Currentversion\Explorer\Computerdescriptions)

        Storage Location Information

The last category obtains information about the potential storage locations for user data. The category can reveal additional devices or folders that may contain data of interest. For example, the majority of Window systems I’ve seen in a corporate environment belong to a Windows domain where the IT departments have users store information on servers instead of their own computer (for backup purposes). One method used is to redirect certain folders in the user account’s profile – such as the My Documents- to a folder on the server. The storage location information category will quickly highlight this type of configuration. The following is the information of interest in the category and the registry keys containing the data:

* Devices and volumes mounted to the computer (HKLM\System\MountedDevices)

* Location of the user account profile folders (HKCU\Software\Microsoft\Windows\Currentversion\Explorer\User shell folders)

* Map network drives available to a user (HKCU\Software\Microsoft\Windows\Currentversion\Explorer\Map network drive MRU)

* Volumes mounted by a user (HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2)

Putting the Batch File Together

Putting the batch file together was fairly simple since I already outlined the order of the information I wanted presented and Regripper had plug-ins to extract the data from the registry. The batch file repeats the following three lines for each Regripper plugin to create one report about the operating system and how it’s configured.

echo: >> operating_system_information.txt
rip.exe -r "%regpath%\SECURITY" -p polacdms >> operating_system_information.txt
echo .........................................................................................................>> operating_system_information.txt

The two lines starting with echo are for formatting purposes. The echo: inserts a blank line in the operating_system_information.txt while the other echo command inserts a line of dots to separate each Regripper plug-in. Rip.exe is the commandline version of Regripper and there are two options. The –r specifies the registry hive and –p specifies the plug-in to run. The variable %regpath% gets populated with a prompt for the folder path containing the registry hives.

The batch file gets put in the Regripper folder and gets executed by double clicking the file. Three screenshots show the script against an image mounted with FTK imager.

Prompt for folder containing the registry hives

Asks to parse user's registry hive then prompts for its folder location

Regripper parsing the registry hives and creating the report

Portion of the report showing the Software and Networking Information categories

The information in the report doesn’t include everything that I’d want to know over the span of an examination but it does provide the initial information about the operating system and how it’s configured. Automating the process makes me a little bit more efficient when I’m completing the examination step.

I uploaded the batch file to the jIIr Google site and the file can be downloaded here (to execute the file change the file extension from txt to bat).

Examining IRS Notification Letter SPAM

2011-07-20T19:01:00.004-04:00

A forensicator lives on the 10th floor of a building. Every morning he rides down the elevator to the ground floor and leaves the building to go to his forensic lab. Every night he comes home after spending the day finding evil and gets on the elevator. If it was raining then he takes the elevator to the 10th floor. If the weather is good then he takes the elevator to the 7th floor and walks to the 10th floor using the stairs. Why does he do this?

The forensicator in the elevator is an analogy to a malware infected system. Trying to answer the above riddle cannot be done without looking at the man in his environment (the building). Picturing the forensicator in the building and everything that is in the elevator will shed light on to question of why he takes the stairs. This is similar to answering the question of how malware infected a system. The question can’t be answered without looking at the malware in its environment (the affected system) and examining the other activity on the system around the time the malware appeared. Take the antivirus write-ups as an example. The majority of the write-ups (I’ve read) analyze the malware outside of the environment where it was located. As a result, the write-ups provide vague information on the initial infection vector used such as the statement “distributed through spam campaigns and drive-by downloads, though given its versatility, other vectors may also be utilized”. The description doesn’t shed much light on how a specific system became infected since pretty much all of the bases are covered (SPAM, drive-bys, or some other method). If you have ever wondered what the artifacts are of malware being delivered through SPAM then the rest of this article will be of interest.

Someone was nice enough to send me a SPAM email last month (sarcasm doesn’t come off the some way as the spoken word). The SPAM was a mass mailing so I was probably just one recipient out of thousands but at least the email gave me something to analyze. The examination of this email will first explain the user’s actions followed by the DFIR practitioner’s examination.

Accessing Email

User Perspective

The user fires up a web browser to check their email. Internet Explorer loads the home page before the user navigates to Yahoo email. A few emails are checked before the user comes across the message below.

The user overlooks the indications that the email is SPAM such as the misspellings, punctuation errors, and even a run-on sentence (see the picture below to see what was missed). They proceed to read the notification letter alerting them to some kind of issue with their tax return.

DFIR Perspective

The forensicator was slowly making their way through a system timeline when there was activity involving Internet Explorer. There were modifications made to few Internet Explorer folders in the Administrator user account’s profile and the user account visited a Microsoft’s webpage.

After weeding through all of the web activity related to the Microsoft webpage he noticed the user went to Yahoo’s webpage and accessed their webmail.

The browser history and cache showed that the user spent some time using Yahoo email.

Opening the Email Attachment

User Perspective

Worried there might be an issue with their tax return the user decides to open the email attachment. The user felt more comfortable opening the attachment since Norton Antivirus indicated it was virus free.

The attachment doesn’t initially open a document but instead opens a new window showing a file with the name IRS document.exe. Even though file extensions weren’t hidden by Windows Explorer the user didn’t notice the exe extension since they were too distracted worrying about not receiving their tax refund.

DFIR Perspective

The Internet activity indicated the user was still accessing their Yahoo email when an entry at 06/20/2011 22:10:00 showed the user downloading a zip file.

The file IRS%20document[1].zip was created in the folder \Documents and Settings\Administrator\Local Settings\Temporary Internet Files\Content.IE5\M20M2OXX\ one second after the browser entry made a reference to a zip file in Yahoo email.

Aftermath of Accessing Email Message

User perspective

The user double clicks the file named “IRS document.exe” thinking the file contains the list of missing documents but nothing visually occurs. A document doesn’t open, no error messages popup, and the list of missing documents isn’t shown. The user closes the attachment’s Explorer window at 06/20/2011 10:22 and continues surfing the Internet. This is the point in the story where the user perspective ends. The story tried to illustrate how someone could be tricked into opening the attachment in the SPAM email.

DFIR perspective

The forensicator continued to work his timeline when there was a flurry of activity involving executables. The first artifact was a prefetch file for a program - IRS document.exe - (MD5 hash 77065d6545b0226ccf66ce75d5254bfa and link to the VirusTotal report) that was the executable inside of the zip attachment. 10 seconds later the Windows svchost.exe executable ran before two additional malware were dropped on the system. The malware was PUSK3_~1.EXE (MD5 hash 541c25d26e8b1eb2d1a35cd52854650f and link to the VirusTotal report) and tmp75D5.tmp (MD5 hash 4bda47a91bea4ceccc6003a46aeb754d and link to the VirusTotal report). The executable activity is shown in the picture below.

The forensicator tied the execution of the IRS document.exe and pusk3.exe to the administrator account by finding the following information in the account’s MUICache registry key.

C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\Temporary Directory 1 for IRS%20document[1].zip\IRS document.exe (IRS document)
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\pusk3.exe (ProcFeatures)

The last artifact pointing to a zip file occurred at 06/20/2011 10:22 and it was modifications being made to the HCU\Software\Microsoft\Windows\ShellNoRoam\BagMRU registry key. A summary of the information in the BagMRU registry key is provided below.

* Bag: 9
* Registry Key modification Time [UTC]: 06/21/11 02:12:22.734
* Folder Name: IRS%20document[1].zip
* Full Path: Desktop\{CLSID_MyComputer}\C:\Documents and Settings\Administrator\Local Settings\Temporary Internet Files\Content.IE5\M20M2OXX\IRS%20document[1].zip\

Summary

The artifacts of malware being delivered through SPAM consisted of a user accessing email and opening a file around the same time. These artifacts hold true for malware being delivered via email even if the circumstances are different. At one point I examined an infected system which didn’t involve the IRS notification letter SPAM or web email. The activity on the system showed emails were assessed around the time a zip file was opened which happened just before the first piece of malware appeared on the system. All of the activity (and lack of other activity such as a drive-by download) lead me to conclude the malware was the result of a malicious email attachment. The specific artifacts in the examination varied slightly compared to what was discussed in this article but the general overall artifacts (email and file access prior to malware appearing) remained consistent.

Only examining malware from a system may not indicate email was the vehicle used deliver it. This is similar to antivirus write-ups about the analysis of malware which leave out information about how a specific computer became infected. The same line of thinking applies to the well known but slightly modified riddle at the beginning of the post. The riddle can’t be answered by solely analyzing the man outside of his building. Sure the analysis will reveal a lot of information about the man but it won’t explain why he is on the 7th floor of his building. The man needs to be analyzed in his building and the activity that occurred prior to him reaching the 7th floor should be reviewed. Trying to solve the riddle in this manner will reveal the answer of why he walks the stairs from the 7th to the 10th floor. The guy is too short to press the 10th floor elevator button and the highest he can reach - without an umbrella - is the 7th floor button. Like the man in the riddle, the activity on a system preceding the malware should be analyzed to determine if an email, drive-by, or some other means was used for the delivery.

Google the Security Incident Detector

2011-07-06T22:19:00.002-04:00

Search engines are not only great tools for locating information across the Internet but they can alert organizations of potential security incidents. Others have already published methods on how to use search engines to locate information including web pages infected with SPAM links and common vulnerabilities. In addition to this information, search engines can help determine if a company's data has been stolen. Google queries and alerts can be leverage to assist organizations with noticing security issues such as data leakage, website vulnerabilities, and stolen information. This post will discuss an approach of using Google to search and monitor portions of the Internet for specific security issues.

Search Company’s Website for Security Issues

The term Google hacking refers to when search engine - such as Google - is used to locate weaknesses on the Internet. This is accomplished by building queries a specific way to locate sites containing software vulnerabilities, misconfigurations, or sensitive information. The same technique can be used by organizations to identify security issues on their own websites. What the specific issues are will be dependent on the organization but two possibilities are sensitive information and infected web pages.

Sensitive Information

The business dictionary defines sensitive information as any information if compromised “could cause serious harm to the organization owning it”. Numerous types of data fit into this definition but three examples are: personally identifiable information (PII), credit card information, and network information.

PII can uniquely identify or locate a single person, and PII includes social security numbers, date of births, and addresses. A data breach from a few months ago illustrates the risk of PII being compromised. The personal information (names and social security numbers) of 300,000 people who applied for California workers' compensation benefits were mistakenly exposed online. As reported, the compromised PII was discovered last month after a data security company located the data through automated Google searching. The combination of breaches being reported in the media and the various data breach notification laws, it stands to reason that organizations should monitor their Internet facing sites for exposed PII. The Google queries below may locate information for social security numbers, birthdays, or contact information for specific websites.

ssn | “social security number” site:domain-name-here
dob | “date of birth” site:domain-name-here
“phone * * *” | “address *” | “e-mail” site:domain-name-here

The above queries contain a few symbols needing explnations. The pipe symbol ( | ) means “or” and the query will return hits if either term is present. The quotes ( “” ) mean the string of words has to match exactly while the asterisk symbol ( * ) is a wildcard and can represent any unknown terms. Site: makes Google only search the websites containing the specified domain (the query would contain the organization’s domain instead of “domain-name-here”). For additional information on syntax for Google queries check out Basic Search Help and More Search Help.

The company Blippy exposed data containing credit card numbers to the Internet. A few months later a company discovered the credit card numbers of four Blippy's users were in Google's index. In addition to PII, organizations could monitor their Internet facing websites for data related to credit card information. The Google queries below may locate information related to credit cards and amongst the information could be card numbers.

expiration | expdate | expire site:domain-name-here
CVV2 site:domain-name-here

Sosata.com (a Groupon subsidiary) accidently published a database containing email addresses and plain-text passwords of 300,000 users which was then indexed by Google. The accident was discovered after a security consultant located the exposed information on Google. Network information such as passwords, usernames, login pages, and errors can assist outside parties in attacking an organization. Companies can monitor their websites for leaked network information that may pose a risk to their network security. The Google queries below may locate: login pages, usernames, passwords, and errors.

login | logon site:domain-name-here
username | userid | employee.ID | “your username is” site:domain-name-here
password | passcode | “your password is” site:domain-name-here
intitle:error site:domain-name-here

Infected Web Pages

The University of Calgary’s website was compromised and the attackers used the website to help sell pharmacy products. The Sucuri Research blog performed a Google search against the university’s website and was able to identify more than two thousand infected web pages. The compromise illustrates the point made by Unmask Parasites which was “to make their doorway pages rank better in search engines, spammers search for compromised web sites and use various security holes to insert hundreds of hidden spam links into trusted web pages”. Companies should add infected web pages to the list of what to monitor on their websites.

Google queries can identify infected web pages. The Unmask Parasites blog has a list of queries which can be used as a starting point for searching for SPAM links. In addition to the Unmask Parasites list, additional terms can be identified by using the blog’s Find Infected Pages with Google to locate infected web pages on the Internet. The portion of the infected web page displayed by Google can reveal other terms to use in a SPAM link query. The picture below shows an infected web page with the search terms used highlighted in bold.

Search Specific Websites for Stolen Information

The previous Google queries can help organizations identify sensitive information and infected web pages on their own websites. However, the queries won’t alert an organization to a compromise resulting in company information being stolen. A Naked Security article reported how the Atlanta Infragard chapter was compromised and the attackers “published 180 usernames, hashed passwords, plain text passwords, real names and email addresses”. How can a company feel confident that none of their employees’ information was compromised? Applying the same question to the publicize data breaches over the past year makes it even more difficult for a company to know if they are at risk. Google searches can help by querying the websites where stolen information is published.

One website with stolen information is Pastebin.com. Lenny Zeltser had a great article - The Use of Pastebin for Sharing Stolen Data – explaining what pastebin is and why hackers are using the site to share stolen information such as network configuration details and authentication records. Briefly reviewing Pastebin’s Trending Pages web page shows there is a range of information available from compromised credentials to identified vulnerabilities in websites. Organizations can search Pastebin.com to determine if their network is at risk because of stolen information. The Google query to accomplish is

site:pastebin.com +domain-name-here

The plus symbol ( + ) attached to the domain name makes Google match the domain exactly as it is typed. Pastebin is one example of a website to search but other sites, such as forums, should be queried as well. A few other potential websites to search are mentioned in Lenny’s post Using Pastebin Sites for Pen Testing Reconnaissance.

Automate Searching with Google Alerts

The previous Google queries will identify sensitive information, infected web pages, and stolen information currently in Google’s index or cache. To continuously monitor the Internet for this type of information an organization would need to periodically perform the queries to see if new information was added to Google’s index. Google alerts send email updates of the latest Google results based on the specified query and the alerts can hep organizations with the continuous monitoring. All of the previous queries can be configured as alerts and it's a fairly simple process to setup it up as can be seen in the screenshot below.

There are five required fields in setting up an alert.

* Search term: is where the query is placed
* Type: specify everything, news, blogs, realtime, video, or discussions websites
* How often: indicates the frequency of the email updates and can be set to as it happens, once a day, or once a week
* Volume: will show only the best results or all results
* Your email: the email address where the latest relevant Google results are sent

Summary

Google queries show the information currently in Google’s index and cache while Google alerts send email notifications when Google is returning new information. The combination of queries and alerts can be leverage by organizations to identify security issues such as data leakage, website vulnerabilities, and stolen information. The majority of the data breaches referenced had two things in common. The first commonality was sensitive company information was exposed to the Internet. The second commonality was the companies were notified about the data leakage after a third party located the information through Google searches. The approach of using Google to search and monitor portions of the Internet won’t prevent security issues from occurring in the first place. However, the approach may reduce the amount of time that lapses before an organization knows about the security issue.

My hope is at least a few people / organizations find this post helpful. It wasn’t my plan to write about the leakage of sensitive information (actually I was working on my next post Examination of a Phishing Email) but I wanted to inform others about the risk of leaked information.

References

Some of the queries I mentioned were obtained from the book Google Hacking for Penetration Testers and the Google Hacking Database.

Review of Digital Forensics with Open Source Tools

2011-06-27T22:34:00.003-04:00

I became involved in the digital forensics (DF) field when I had to establish and manage a DF process to support financial investigations and fraud audits. When I got to the point of identifying tools I first looked to see what resources I had at my disposal. Lo and behold my security lab had a dongle to a commercial forensic product. In the beginning I exclusively used a few commercial products to perform forensics but over time I added additional tools to my arsenal to expand my capability. I’m bringing up my background since the intended audience for Digital Forensics with Open Source Tools (DFwOST) is new forensic practitioners and experienced DF practitioners new to open source tools. My review of DFwOST is coming from the perspective of an experienced DF practitioner who may rely on a few (or single) commercial tools during examinations.

Before diving into the world of open source tools DFwOST starts out by defining digital forensics and explaining the goals of any examination which is for an examiner to locate artifacts to indicate if a hypothesis is true or false. DFwOST then covers the three different analysis types used during an examination and the analysis types are: system, application, and file. DFwOST explains how to perform the different analysis by explaining the data, the potential artifacts of interest located in the data, and discussing the open source tools to use against the data. The system analysis covers partitioning and disk layouts of physical storage devices. In addition to this, DFwOST discusses the different file types and artifacts specific to the Windows Linux, and Mac operating systems. The application analysis explains the artifacts associated with different web browsers and mail applications. Rounding out the discussion, the file analysis covers the activities for examining the content of individual files and their metadata. The authors provided a listing of references at the end of each chapter that the reader can use to learn more about the topics DFwOST doesn't go into great detail on.

I think DFwOST will be beneficial to anyone who reads it whether if they are new to the field or an experienced practitioner. However, I think the book is a great resource to experienced DF practitioners who are not familiar with open source and free digital forensic tools. My reasoning is because DFwOST can help to expand capabilities in DF examinations, understand how commercial tools work, and identify additional tools.

Expand Capabilities in DF Examinations

Every tool has its strengths and weaknesses, and commercial tools are no different. There is not a single commercial product that has the ability examine every possible type of data or artifact encountered during exams. This issue is one of the reasons why DF practitioners have multiple tools at their disposal. How does DFwOST fit into the picture?

First DFwOST discusses tools and techniques that have a capability not present in the current crop of commercial tools. The additional capability provided by open source tools can be used to compliment the functionality of commercial tools. For example, chapter 9 discusses the timeline analysis technique and mentions a few tools to create timelines that include the metadata from the file system and various artifacts. In my experiences, timeline analysis is a powerful technique and it has helped me on a range of different examinations from financial investigations to human resource policy violation investigations to security incidents. The ability to generate timelines would be lost by solely relying on a single or few commercial products.

Understand How Commercial Tools Work

Some commercial tools automatically extract information from data and this functionality can help reduce the time needed to complete an examination. On the downside, automation provides a layer of abstraction that may result in examiners not completely understanding the data they are seeing or how the tool works. The tools (open source and free ones in Appendix A) highlighted in DFwOST can be a great educational benefit to examiners by helping better understand the data and how their commercial tools work; thus removing the layer of abstraction caused by automation. Open source tools can not only be ran against data to see how the output is different but the tools' various options can be tested and the code can be read to better understand how the tool functions. The educational benefit provided by open source tools will be helpful to any examination even if the tools are not actually used on a case.

Identify Additional Tools

DFwOST points out numerous tools to use during a digital forensic examination. Using additional tools can provide flexibility and additional resources for validation testing. At times there could be a need to only conduct a few activities and using a multipurpose commercial tool may be overkill for the task at hand. Additional time will be needed for a multipurpose tool since it takes time to load and configure the tool even if the task at hand is just to extract specific information from data. The tools in DFwOST provide this kind of flexibility.

In addition to flexibility, open source tools can be used in the validation testing of commercial tools. Does XYZ commercial software extract the information from a certain type of data properly? Does XYZ commercial tool work as advertised? Both questions can be quickly verified by reproducing the results with the open source tools discussed in DFwOST.

Five Star Review

Overall DFwOST will be a welcome addition to anyone’s DFIR library. The one topic I thought was missing from the book (or I overlooked) is mentioning the process or methods to validate digital forensic tools before they are used during an examination. I don't think the authors had to go into great detail on the subject but pointing the reader (especially people new to the field) to a few references could be helpful. Despite this, if I was posting my review on Amazon then DWwOST would get another five star rating.