Windows 7 Forensic Analysis

12/18/2019 Journey Into Incident Response: February 2012
Review of Windows Forensic Analysis 3rd Edition

Sunday, February 26, 2012 Posted by Corey Harrell
4 comments
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.
https://journeyintoir.blogspot.com/2012/02/ 1/26
* 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).
book review
Examining VSCs with GUI Tools

Wednesday, February 22, 2012 Posted by Corey Harrell
0 comments
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.
volume shadow copies
Ripping VSCs – Developer Examples

Tuesday, February 14, 2012 Posted by Corey Harrell
3 comments
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
script, volume shadow copies
Ripping VSCs – Developer Method

Sunday, February 12, 2012 Posted by Corey Harrell
5 comments
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.

($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).

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

Wednesday, February 8, 2012 Posted by Corey Harrell
3 comments
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
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
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
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

Monday, February 6, 2012 Posted by Corey Harrell
6 comments
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 Promptvideo 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
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
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
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.

Windows 7 Forensic Analysis

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Windows 7 Forensic Analysis

Hochgeladen von

Copyright:

Verfügbare Formate

12/18/2019 Journey Into Incident Response: February 2012

Review of Windows Forensic Analysis 3rd Edition

All about Windows 7

Process, Process, Process

Don’t Overlook the Materials Accompanying the Book

Clarification about ShadowExplorer

Overall Five Star Review

Examining VSCs with GUI Tools

Exposing VSCs as Symbolic Folder

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

Windows Explorer Browsing VSC

Mitec WFA Analyzing Prefetch Files

FTK Imager Browsing VSC

Exposing VSCs as a Network Share

net share testshadow=\\.\HarddiskVolumeShadowCopy18\

net use K: \\127.0.0.1\testshadow

Windows Explorer Browsing VSC

MalwareBytes Scanning VSC

Ripping VSCs Summary

volume shadow copies

Ripping VSCs – Developer Examples

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

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

read_open_xml_win.pl against VSCs

92. # read the parameter (the document)

RegRipper against VSCs

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

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

Lslnk.pl against VSCs

16. my $file = shift || die "You must enter a filename.\n";

64. # Get info about the file

71. # Open file in binary mode

# (corey) Had to move to first in script to access file in VSC

# (corey) line below is not needed because of the line above

# (corey)Line below caused error even though file opened

# Setup some variables

script, volume shadow copies

Ripping VSCs – Developer Method

Developer Method Overview

$file_path = shift || die "You must enter a filename.\n";

entered on the command-line.

$file_path = shift || die "You must enter a filename.\n";

$file_path = shift || die "You must enter a filename.\n";

foreach $num (@vscs) {

Research behind Ripping VSCs – Developer Method

Next Up: Ripping VSCs - Developer Examples

script, volume shadow copies

Ripping VSCs – Practitioner Examples

Extracting Data from VSCs

Hashing Files in VSCs

Identifying Differences between VSCs

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

Up Next: Ripping VSCs – Developer Method

script, volume shadow copies

Ripping VSCs – Practitioner Method

command in Chapter 3 in Windows Forensic Analysis 3rd Edition.

Practitioner Method Overview

vssadmin list shadows /for=C:

The picture below shows the output from that command.

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

Automate Accessing VSCs

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

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

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