The written first review of IWS comes from Joey Victorino, a consultant with the IBM X-Force IRIS team. Joey sent me his review via LinkedIn, and graciously allowed me to post it here. Here are Joey's thoughts on the book, in his own words:
I've been a fan of Harlan Carvey ever since his first release of Windows Forensic Analysis, 2nd Edition book years ago when I first entered the digital forensics environment. Initially, I had reservations that the new book "Investigating Windows Systems" would be a bit simplistic as I've read quite a bit of forensics books and attended multiple SANS Courses. However, I was wrong, and I really enjoyed this book - especially because Harlan Carvey is an awesome analyst.
Essentially, it looks into different scenarios a DFIR professional will encounter throughout their career, by unpacking these scenarios through the eyes of a professional analyst. After the initial evidence is triaged it is then broken down into a conversation about the scenario, with clear examples of what the artifacts are like in this stage of the investigation and then provides practical examples in identifying actionable data and leveraging that as a pivot point to uncover more data. Because of the spread of knowledge, I found it very interesting and very useful to cover off areas where I was a bit unfamiliar with the subject matter. My favorite was "Chapter 4" as it went into Ali Hadi’s “Web Server Case” in a fantastic manner. I've been using this challenge as a method to train junior analysts and another IT professional moving into the DFIR field. His approach to solving the exercise was a great example, of being a consultant performing on-site DFIR with a focus on getting the answers needed quickly, and in a proper manner to be able to allow clients to make important business decisions.
Overall, the greatest message learned from this book is that even though there are many different tools, the most effective skill a forensic analyst can have is being able to investigate properly, by analyzing the correct data, and using it to clearly answer the important questions. This would be an excellent book to not only have on the shelf but read and actively reference for DFIR practitioners of all experience levels.
Joey Victorino – Consultant
IBM X-Force IRIS
Thanks, Joey, for your kind words, and thanks taking the time to share your thoughts on the book. Most importantly, thank you for purchasing and reading my book! My hope is that others find similar interest and value in what I've written.
Addendum, 26 Sept: Mary Ellen posted a review, as well!
Sunday, September 23, 2018
Tuesday, September 18, 2018
Book Writing
With the release of my latest book, Investigating Windows Systems, I thought that now would be a good time to revisit the topic of writing books. It occurred to me watching some of the activity and comments on social media that there were likely folks who hadn't seen my previous posts on this topic, let alone the early stuff I'd posted about the book, particularly the stuff I'd written about the book two years ago.
As I said, I've blogged on the topic of writing (DFIR) books before:
17 Dec 2010
26 Dec 2010
28 Mar 2014
29 Mar 2014
16 Feb 2018
There are some things about writing books that many folks out there simply may not be aware of, particular if they haven't written a book themselves. One such item, for example, is that the author doesn't own the books. I had a sales guy set up an event that he wanted me to attend, and he suggested that I "bring some books to sell". I don't own the books to sell, and as far as I'm aware, I'm not PCI compliant; I don't process credit cards.
Further, authors have little, if any, control over...well, anything beyond the content, unless they're self-published. For example, I'm fully aware that as of 17 Sept 2018, the image on the Amazon page for IWS is still the place holder that was likely used when the page was originally set up. I did reach to the publisher about this, and they let me know that this is an issue that they've had with the vendor, not just with my book but with many others, as well. While I can, and do, market the books to the extent that I can, I have no control over, nor any input into, what marketing the publisher does, if any. Nor do authors have any input or control over what the publisher's vendors do, or don't do, as the case may be.
Addendum, 19 Sept: I checked again today, and the Amazon page for the book has been updated with the proper book cover image.
Taking a quick look through a copy of the Investigating Windows Systems book, I noted a few things that jumped out at me. I did see a misspelled word or two, read a sentence here and there that seemed awkward and required a re-read (and maybe a re-write), and noticed an image or two that could have been bigger and more visible. Would the book have looked a bit better if it had a bit bigger form factor? Perhaps. Then it would have been thinner. However, my point is that I didn't have any input into that aspect of the book.
I'm also aware that several pages (pp. 1, 45, 73, 97) have something unusual at the bottom of the page. Specifically, "Investigating Windows Systems. DOI: https://doi.org/10.1016/{random}", and then immediately below that, a copyright notice. Yes, this does stand out like a sore thumb, and no, I have no idea why it's there.
If you purchased or received a copy of the book, I hope you find value in it. As I've said before, I wanted to take a different approach with this book, and produce something new and I hope, useful.
As I said, I've blogged on the topic of writing (DFIR) books before:
17 Dec 2010
26 Dec 2010
28 Mar 2014
29 Mar 2014
16 Feb 2018
There are some things about writing books that many folks out there simply may not be aware of, particular if they haven't written a book themselves. One such item, for example, is that the author doesn't own the books. I had a sales guy set up an event that he wanted me to attend, and he suggested that I "bring some books to sell". I don't own the books to sell, and as far as I'm aware, I'm not PCI compliant; I don't process credit cards.
Further, authors have little, if any, control over...well, anything beyond the content, unless they're self-published. For example, I'm fully aware that as of 17 Sept 2018, the image on the Amazon page for IWS is still the place holder that was likely used when the page was originally set up. I did reach to the publisher about this, and they let me know that this is an issue that they've had with the vendor, not just with my book but with many others, as well. While I can, and do, market the books to the extent that I can, I have no control over, nor any input into, what marketing the publisher does, if any. Nor do authors have any input or control over what the publisher's vendors do, or don't do, as the case may be.
Addendum, 19 Sept: I checked again today, and the Amazon page for the book has been updated with the proper book cover image.
Taking a quick look through a copy of the Investigating Windows Systems book, I noted a few things that jumped out at me. I did see a misspelled word or two, read a sentence here and there that seemed awkward and required a re-read (and maybe a re-write), and noticed an image or two that could have been bigger and more visible. Would the book have looked a bit better if it had a bit bigger form factor? Perhaps. Then it would have been thinner. However, my point is that I didn't have any input into that aspect of the book.
I'm also aware that several pages (pp. 1, 45, 73, 97) have something unusual at the bottom of the page. Specifically, "Investigating Windows Systems. DOI: https://doi.org/10.1016/{random}", and then immediately below that, a copyright notice. Yes, this does stand out like a sore thumb, and no, I have no idea why it's there.
If you purchased or received a copy of the book, I hope you find value in it. As I've said before, I wanted to take a different approach with this book, and produce something new and I hope, useful.
Monday, September 17, 2018
IWS is out!
My latest book, Investigating Windows Systems (Amazon, Elsevier) is out, and it seems that some have already received their ordered copies. Very cool. For anyone who's ordered a copy, I thank you and I hope you find some value in it.I've blogged about the book several times (beginning here) since I started writing it, and I wanted to take a moment, now that it's out, to maybe clear up what may be some misconceptions about the book, because this book isn't at all like any of my previous books.
My goal in writing the book was to demonstrate the analysis process, and provide the analysis decisions I made during that process. I wanted to write a book like this, because as with my other books, I hadn't seen anything out there (blogs, books, etc.) that provided something similar. When I've had time to reflect on and look back over my own analysis engagements, this is something that has interested and fascinated me. It's also made its way into conversations, but has also been something that has proven difficult when engaging with others; that is, understanding what led a particular analyst down a particular investigative route, to choose a particular tool, or to pivot on a particular artifact or piece of data.
As such, this book does not cover things like the basic usage of the mentioned or described tools, as these topics have been covered before, and anyone can look the usage up. Also, the very basics of constructing a timeline are not addressed, as that topic has been covered extensively in other resources.
While writing the book, I used available images from several online sources (and with permission) as a backdrop against which to demonstrate the analysis process, as well as to illustrate the analysis decisions made during that process.
What the book is not is a walk-through of each CTF or forensic challenge employed. That is to say, when engaging in analysis of a particular image, I do not simply walk through the posted challenge. There's nothing wrong with the posted challenges at all, and most of the ones I've seen are quite good. However, in two decades of performing DFIR work, I have yet to engage with a client that had 37 questions they wanted me to answer. I wanted to present the analysis based on (in my experience) as close to real world engagements as I could.
As I said, I used available images as the basis for the analysis I was performing. I did this intentionally, as it provides an opportunity for the reader to follow along, or to try their own hand at analyzing the images. The images range from Windows XP to Windows 7 and 10, and there's even a Windows 2008 image in there, as well.
In addition, the tools used in the book are all free and open source tools. The reason for this was two-fold; first, I wanted readers to see (as much as possible) and understand what was being done, so that when it came time to decide upon a commercial forensic suite to use, they could make better educated decisions. Second, being just one person, I do not have access to commercial forensic suites. The same goes for the images used; I do not have access to MSDN, nor other compromised images, and decided to make use (again, with permission) of what was available.
For anyone who purchased the book, thank you. I hope you find value in it, enough so that you opt to write a review, or simply provide feedback. Thanks.
Saturday, September 15, 2018
A lil Saturday morning computer programming
I've wanted to update lfle.pl for sometime, and with the rain this weekend, Saturday morning was the perfect time do so. For those who may not be aware, lfle.pl is a script I have for extracting WinXP/2003 style Event Log records from unstructured data. This means that it can be run against Event Log files, page files, unallocated space, and even memory dumps in order to extract these records. When it finds a valid EVT record, it dumps the contents in TLN format, so that a timeline can be easily generated.
Okay, so the obvious elephant in the room...why bother updating this tool? Well, in the summer of 2017, the world saw the NotPetya incident. During this incident, one of the analysts on the team I was working with got several Windows XP and 2003 systems in for analysis.
I downloaded the CFReDS hacking case image, and use FTK Imager to create a single, raw/dd-style image. I then exported the unallocated space from the image file, using the following commands:
mmls -i raw -t dos g:\cfreds\image.001
blkls -i raw -f ntfs -A -o 63 g:\cfreds\image.001 > g:\cfreds\image_unalloc
Next, I ran lfle.pl against the resulting file:
lfle.pl -f g:\cfreds\image_unalloc
This command yielded no results. Okay, next I exported the Event Log files from the image and ran lfle.pl against each one. Forty records were found in the AppEvent.evt file, and 141 in the SysEvent.evt file.
Troubleshooting
Interestingly, I go no results running lfle.pl against the Security Event Log file, using the following command:
lfle.pl -f g:\cfreds\image\secevent.evt
The prompt simply returned. Okay, so let's do some troubleshooting. Using the "-s" switch to display statistics, I get the following results:
lfle.pl -f g:\cfreds\image\secevent.evt -s
Small records skipped : 1
Large records skipped :
Malformed records skipped:
Records retrieved :
Okay, that's interesting. Only one "small" (i.e., less than 0x30 bytes) record was located. Going with the "-d" switch to enable debugging output, I get the following:
lfle.pl -f g:\cfreds\image\secevent.evt -d
Magic number located at offset 0x4 with length of 48 bytes
0x00000000 30 00 00 00 4C 66 4C 65 01 00 00 00 01 00 00 00 0...LfLe........
0x00000001 30 00 00 00 30 00 00 00 01 00 00 00 00 00 00 00 0...0...........
0x00000002 00 00 01 00 00 00 00 00 80 3A 09 00 30 00 00 00 .........:..0...
My final step was to open the secevent.evt file in hex editor, and low and behold, I found that there was just one record visible in the file, the one illustrated above. Following the record, there is the "cursor", which is 0x28 bytes, and does not contain the "LfLe" magic number. After that, what remained of the file was all zeros. So, that explains the results; it's not that the tool is "broken" or "doesn't work", but instead that there's nothing to display in the file.
Hibernation File
The image also contains a hibernation file, which I exported from the image. Using Volatility 2.6, I checked which profile would work for the image:
vol -f g:\cfreds\image\hiberfil.sys imageinfo
*Suggested Profile(s) : WinXPSP2x86, WinXPSP3x86 (Instantiated with WinXPSP2x86)
I then converted the hibernation file to raw format:
vol -f g:\cfreds\image\hiberfil.sys --profile=WinXPSP2x86 imagecopy -O g:\cfreds\image\mem.raw
Finally, I ran lfle.pl against it, with all switches enabled:
lfle.pl -f g:\cfreds\image\mem.raw -d -s > g:\cfreds\image\mem_lfle_out.txt
With everything turned on and being collected in the output file, it's kind of messy, with valid records mixed in with debugging info, etc. However, the statistics displayed at the end of the file tell us the story:
Small records skipped : 22
Large records skipped : 2
Malformed records skipped: 4
Records retrieved : 95
So, 22 "small" records were skipped, 2 "large" (i.e., 0x1000 bytes or larger) were skipped, 4 malformed (size values that bracket the record were not identical) records were skipped, and a total of 95 valid records were retrieved. Very nice.
Both the Perl script and the portable .exe version of the tool can be found on the GitHub repository.
Okay, so the obvious elephant in the room...why bother updating this tool? Well, in the summer of 2017, the world saw the NotPetya incident. During this incident, one of the analysts on the team I was working with got several Windows XP and 2003 systems in for analysis.
I downloaded the CFReDS hacking case image, and use FTK Imager to create a single, raw/dd-style image. I then exported the unallocated space from the image file, using the following commands:
mmls -i raw -t dos g:\cfreds\image.001
blkls -i raw -f ntfs -A -o 63 g:\cfreds\image.001 > g:\cfreds\image_unalloc
Next, I ran lfle.pl against the resulting file:
lfle.pl -f g:\cfreds\image_unalloc
This command yielded no results. Okay, next I exported the Event Log files from the image and ran lfle.pl against each one. Forty records were found in the AppEvent.evt file, and 141 in the SysEvent.evt file.
Troubleshooting
Interestingly, I go no results running lfle.pl against the Security Event Log file, using the following command:
lfle.pl -f g:\cfreds\image\secevent.evt
The prompt simply returned. Okay, so let's do some troubleshooting. Using the "-s" switch to display statistics, I get the following results:
lfle.pl -f g:\cfreds\image\secevent.evt -s
Small records skipped : 1
Large records skipped :
Malformed records skipped:
Records retrieved :
Okay, that's interesting. Only one "small" (i.e., less than 0x30 bytes) record was located. Going with the "-d" switch to enable debugging output, I get the following:
lfle.pl -f g:\cfreds\image\secevent.evt -d
Magic number located at offset 0x4 with length of 48 bytes
0x00000000 30 00 00 00 4C 66 4C 65 01 00 00 00 01 00 00 00 0...LfLe........
0x00000001 30 00 00 00 30 00 00 00 01 00 00 00 00 00 00 00 0...0...........
0x00000002 00 00 01 00 00 00 00 00 80 3A 09 00 30 00 00 00 .........:..0...
My final step was to open the secevent.evt file in hex editor, and low and behold, I found that there was just one record visible in the file, the one illustrated above. Following the record, there is the "cursor", which is 0x28 bytes, and does not contain the "LfLe" magic number. After that, what remained of the file was all zeros. So, that explains the results; it's not that the tool is "broken" or "doesn't work", but instead that there's nothing to display in the file.
Hibernation File
The image also contains a hibernation file, which I exported from the image. Using Volatility 2.6, I checked which profile would work for the image:
vol -f g:\cfreds\image\hiberfil.sys imageinfo
*Suggested Profile(s) : WinXPSP2x86, WinXPSP3x86 (Instantiated with WinXPSP2x86)
I then converted the hibernation file to raw format:
vol -f g:\cfreds\image\hiberfil.sys --profile=WinXPSP2x86 imagecopy -O g:\cfreds\image\mem.raw
Finally, I ran lfle.pl against it, with all switches enabled:
lfle.pl -f g:\cfreds\image\mem.raw -d -s > g:\cfreds\image\mem_lfle_out.txt
With everything turned on and being collected in the output file, it's kind of messy, with valid records mixed in with debugging info, etc. However, the statistics displayed at the end of the file tell us the story:
Small records skipped : 22
Large records skipped : 2
Malformed records skipped: 4
Records retrieved : 95
So, 22 "small" records were skipped, 2 "large" (i.e., 0x1000 bytes or larger) were skipped, 4 malformed (size values that bracket the record were not identical) records were skipped, and a total of 95 valid records were retrieved. Very nice.
Both the Perl script and the portable .exe version of the tool can be found on the GitHub repository.
Friday, September 14, 2018
Random Stuff
I decided to put this post together because some things just need to persist beyond the typical Twitter life cycle. The focus here is free and open source tools that can be used on Windows to investigate/parse/enable analysis of Windows artifacts. It's not my intention to take anything away from current repositories of such tools, such as the DFIRTraining site, but rather to bring these tools to the forefront again.
Random
Windows 10 Oct 2018 update includes clipboard history and cloud sync
Ryan Kovar shared this resource regarding detailed properties in O365 audit logs
Registry
Maxim tweeted (on 4 Sept, I just saw it today) that yarp-carver had been run against the image from the LoneWolf scenario and recovered a good deal of Registry data.
Here's a great explanation of ShimCache data from the folks at Mandiant.
yarp tools - be sure to follow Maxim on Twitter (ex: tweet regarding yarp-carver)
Windows 10 Timeline
Matthew Seyer wrote up a nice article over on Medium regarding a tool that he wrote to parse the Windows 10 Timeline database (SQLite format). In that article, he also referred to Eric Zimmerman's WxTCmd tool, which can be found here.
Anytime you're working with an SQLite database, be sure to incorporate Mari's SQLite deleted data parser (blog, Github)
Paper: A Forensic Exploration of the Microsoft Windows 10 Timeline
Windows 10 Notification Database
Yogesh's post - 2016
David Cowen's post - 2018
Malware Maloney's post on parsing the .wal file - 2018
Windows Event Logs
Tools for parsing Windows Event Log (*.evtx) files:
LogParser - MS's tool
parse_evtx.exe - KasperskyLab ForensicTools (x64)
Evtx2json - includes experimental support for EVTXtract output
EVTXtract - Willi Ballenthin's Python code (presentation)
EvtxParser - Andreas Schuster's Perl code (here's some more info on getting it installed)
EventCleaner - reportedly will allow you to remove EVTX records
VSCs
I blogged about accessing VSCs recently (actually, I blogged about it twice...), and I wanted to include the information in this post.
Something to be clear about...the version of Arsenal's Image Mounter tool is the one from GitHub, NOT the one discussed here. Yes, one of the issues I ran into when seeking assistance in this endeavor was that there is more than one tool with same name, and that presented some challenges in communication.
My hope is that the version found on Github is updated to include the ability to mount raw/dd-style images via "Write-Temporary".
Here's a tweet about a presentation regarding recovering deleted VSCs using vss-carver.
DFIRTraining list of tools -
Parsing RDP Cache Files
remotecache.py -
bmc-tools.py -
Link to tools at DFIRTraining site
I'm more than happy to add to this list as new things come in.
Random
Windows 10 Oct 2018 update includes clipboard history and cloud sync
Ryan Kovar shared this resource regarding detailed properties in O365 audit logs
Registry
Maxim tweeted (on 4 Sept, I just saw it today) that yarp-carver had been run against the image from the LoneWolf scenario and recovered a good deal of Registry data.
Here's a great explanation of ShimCache data from the folks at Mandiant.
yarp tools - be sure to follow Maxim on Twitter (ex: tweet regarding yarp-carver)
Windows 10 Timeline
Matthew Seyer wrote up a nice article over on Medium regarding a tool that he wrote to parse the Windows 10 Timeline database (SQLite format). In that article, he also referred to Eric Zimmerman's WxTCmd tool, which can be found here.
Anytime you're working with an SQLite database, be sure to incorporate Mari's SQLite deleted data parser (blog, Github)
Paper: A Forensic Exploration of the Microsoft Windows 10 Timeline
Windows 10 Notification Database
Yogesh's post - 2016
David Cowen's post - 2018
Malware Maloney's post on parsing the .wal file - 2018
Windows Event Logs
Tools for parsing Windows Event Log (*.evtx) files:
LogParser - MS's tool
parse_evtx.exe - KasperskyLab ForensicTools (x64)
Evtx2json - includes experimental support for EVTXtract output
EVTXtract - Willi Ballenthin's Python code (presentation)
EvtxParser - Andreas Schuster's Perl code (here's some more info on getting it installed)
EventCleaner - reportedly will allow you to remove EVTX records
VSCs
I blogged about accessing VSCs recently (actually, I blogged about it twice...), and I wanted to include the information in this post.
Something to be clear about...the version of Arsenal's Image Mounter tool is the one from GitHub, NOT the one discussed here. Yes, one of the issues I ran into when seeking assistance in this endeavor was that there is more than one tool with same name, and that presented some challenges in communication.
My hope is that the version found on Github is updated to include the ability to mount raw/dd-style images via "Write-Temporary".
Here's a tweet about a presentation regarding recovering deleted VSCs using vss-carver.
DFIRTraining list of tools -
Parsing RDP Cache Files
remotecache.py -
bmc-tools.py -
Link to tools at DFIRTraining site
I'm more than happy to add to this list as new things come in.
Thursday, September 06, 2018
Accessing Volume Shadows, re-revisited
As a follow-on to my previous post, I wanted to provide a concise summary or overview of the processes for accessing VSCs.
First, a couple of important factors regarding this exercise:
The goal of this exercise was to identify and validate processes for accessing VSCs within acquired images, using free and open source tools on a Windows analysis system.
The source image file was from Digital Corpora's Lone Wolf scenario (downloaded *.e0x files, also converted to raw/dd). Note that when using mmls.exe to view the partition table, the partition type is "gpt", not "dos". This is part of the reason I wanted to use this image, to see if the tools used have any issues with different partition types. The other reason for using this image is that it is (relatively) easily accessible by almost anyone, and anything I did can be validated using the image.
Processes
*.e0x
Arsenal Image Mounter (Mount through libewf)
|__ ShadowExplorer (v0.9)
*After I posted this article, Eric Zimmerman pointed me to his VSCMount tool, which would be a great alternative to ShadowExplorer. Note that if you're using VSCMount, you won't be able to access the VSCs via Windows Explorer, but Eric was able to use PowerShell to navigate the file system. Similarly, I had no issues using a command prompt. There simply appears to be an issue when trying to use Windows Explorer.
raw/dd #1
Arsenal Image Mounter (Mount raw image)
|__ vssadmin
|__ vss (X:\)
|__ FTK Imager (add X:\ as logical drive evidence item)
raw/dd #2
mmls
|__vshadowinfo/vshadowmount (requires Dokan 0.7.4)
|__ access individual VSCs via FTK Imager (Image File)
raw/dd #3
Convert to *.e0x format, use *.e0x process (above)
I've been able to repeatedly replicate raw/dd processes #1 and #2 on several other images to which I have access.
Addendum, 7 Oct: I ran across Andrea Fortuna's blog post that addresses a few means for accessing VSCs, as well. At this point, I've already submitted that chapter for PWI that addresses this topic for technical review; this doesn't mean that there isn't time to address other methods; in fact, I'm going to be waiting until just prior to the due date to submit the chapter, as I'm keeping an eye on some tools to see if they're updated before the final submission of the chapter, and the overall manuscript.
First, a couple of important factors regarding this exercise:
The goal of this exercise was to identify and validate processes for accessing VSCs within acquired images, using free and open source tools on a Windows analysis system.
The source image file was from Digital Corpora's Lone Wolf scenario (downloaded *.e0x files, also converted to raw/dd). Note that when using mmls.exe to view the partition table, the partition type is "gpt", not "dos". This is part of the reason I wanted to use this image, to see if the tools used have any issues with different partition types. The other reason for using this image is that it is (relatively) easily accessible by almost anyone, and anything I did can be validated using the image.
Processes
*.e0x
Arsenal Image Mounter (Mount through libewf)
|__ ShadowExplorer (v0.9)
*After I posted this article, Eric Zimmerman pointed me to his VSCMount tool, which would be a great alternative to ShadowExplorer. Note that if you're using VSCMount, you won't be able to access the VSCs via Windows Explorer, but Eric was able to use PowerShell to navigate the file system. Similarly, I had no issues using a command prompt. There simply appears to be an issue when trying to use Windows Explorer.
raw/dd #1
Arsenal Image Mounter (Mount raw image)
|__ vssadmin
|__ vss (X:\)
|__ FTK Imager (add X:\ as logical drive evidence item)
raw/dd #2
mmls
|__vshadowinfo/vshadowmount (requires Dokan 0.7.4)
|__ access individual VSCs via FTK Imager (Image File)
raw/dd #3
Convert to *.e0x format, use *.e0x process (above)
I've been able to repeatedly replicate raw/dd processes #1 and #2 on several other images to which I have access.
Addendum, 7 Oct: I ran across Andrea Fortuna's blog post that addresses a few means for accessing VSCs, as well. At this point, I've already submitted that chapter for PWI that addresses this topic for technical review; this doesn't mean that there isn't time to address other methods; in fact, I'm going to be waiting until just prior to the due date to submit the chapter, as I'm keeping an eye on some tools to see if they're updated before the final submission of the chapter, and the overall manuscript.
Tuesday, September 04, 2018
Accessing Volume Shadows, Revisited
Almost 3 yrs ago, I published this blog post regarding accessing VSCs, via several different means. I recently did some testing, revisiting the methods, and oddly enough, I couldn't get the several of them to work. I posted to Twitter, but due to the nature of the medium, things started to get out of hand. As such, I thought I'd post what I'd done, so that others could try the same methods, and see if maybe they could get the processes to work.
My analysis system is Windows 10; when I open a command prompt, I get "Microsoft Windows [Version 10.0.17134.228]".
I downloaded the *.e01 images files from the LoneWolf scenario that is available via the Digital Corpora site. The image is of a physical Windows 10 system. I then used FTK Imager to convert the split *.e0x images files into a unified raw/dd-style image, and I used that file (i.e., lonewolf_dd.001) in all of my testing.
Vhd Method
This method is defunct, in part because it no longer seems to work.
I did try vhdxtool, as well, but that didn't work at all...I'm not working with a .vhd file that needs to be converted to a .vhdx file, I'm using a raw/dd-style image.
Libvshadow/vshadowmount
This method requires Dokan 0.7.4 and pretty much follows along from the Libvshadow section of my previous post. For this attempt, I used the extended libvshadow tools provided with vss_carver.py.
First, I used mmls (from the TSK tools) to determine the offset to the partition of interest:
mmls -i raw -t gpt g:\lonewolf\lonewolf_dd.001
From that, I saw:
Slot Start End Length Description
00: Meta 0000000000 0000000000 0000000001 Safety Table
01: ----- 0000000000 0000002047 0000002048 Unallocated
02: Meta 0000000001 0000000001 0000000001 GPT Header
03: Meta 0000000002 0000000033 0000000032 Partition Table
04: 00 0000002048 0001023999 0001021952 Basic data partition
05: 01 0001024000 0001226751 0000202752 EFI system partition
06: 02 0001226752 0001259519 0000032768 Microsoft reserved partition
07: 03 0001259520 1000214527 0998955008 Basic data partition
08: ----- 1000214528 1000215216 0000000689 Unallocated
The partition we're interested in is the one in bold, and the offset is 1259520 sectors, or 644874240 bytes. Using that information, I can run vshadowinfo (I don't have to, but I can):
vshadowinfo -o 644874240 g:\lonewolf\lonewolf_dd.001
From the output of the above command, I can see two VSCs, which is what I expected. Now, for vshadowmount:
vshadowmount -o 644874240 g:\lonewolf\lonewolf_dd.001 x:\
After running this command, do not expect the command to exit...it won't, until you hit Control-C. I minimized the command prompt (which was running with Admin privileges) and could see "VSS1" and "VSS2" in the X:\ volume via Windows Explorer.
Next, I opened FTK Imager 4.2.0.13, and added the X:\ volume as an logical drive evidence item, or I tried to. I got an error dialog that said simply "Incorrect function. (1)".
I then opened Autopsy 4.8.0, and tried to add the volume as a local disk data source to a case. Unfortunately, unlike FTK Imager, Autopsy did not 'see' the X:\ volume.
Arsenal Image Mounter
I downloaded Arsenal Image Mounter, and used it to mount the image file. When mounting, I chose the "Read Only" option (the "Write Temporary" option was grayed out, and reportedly not available for raw/dd-style images). The image was mounted as "F:\", and I could easily browse the volume via Windows Explorer.
I had also downloaded ShadowExplorer 0.9, and when I opened it, it did not recognize the F:\ volume. I could see C:\, D:\, and G:\ (ext HDD where the image was stored).
Vss Method
Finally, I tried vss.exe, mentioned in my previous post; however, I should note that Jimmy Weg seems to no longer maintain his "justaskweg" domain, or the site(s) referenced in my original blog post. Further, the copy of vss.exe that I have has no identifying information (file version info), nor any syntax info.
I mounted the image via Arsenal Image Mounter (just like I did above), and got identifiers for both VSCs:
vssadmin list shadows /for=f:
I copied the ID for one of the VSCs to the clipboard, and then pasted it into the following command:
vss x: Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy47
The response I got back was:
Drive X: ---> \Device\HarddiskVolumeShadowCopy47
Okay...that's a start. I then opened FTK Imager and added the X:\ volume as a logical drive evidence item, and was easily able to traverse through the image, just as I normally would.
Summary
Of all of the methods tested, only vss.exe in conjunction with Arsenal Image Mounter was the one method that worked.
Addendum, 5 Sept
I've continued my testing, but before I kicked off the summary, I wanted to provide a link for vss.exe. Thanks to Brian Maloney for tracking that down.
One thing that's been clear over the past day or so is that even providing clear documentation (above) as to what I did, and where I got the tools, there's been a significant disconnect with respect to those offering assistance. It appears that the biggest one is that when we say "Arsenal Image Mounter", apparently, we're not all referring to the same thing. I got a copy of Arsenal Image Mounter from Github, not from the from the main ArsenalRecon.com web site, and that appears to make a significant difference. In particular, the option to mount a raw/dd image in "Write Temporary" mode is specifically NOT supported in this version of the tool.
So, to clarify, what I've been looking to do is get working processes for accessing VSCs within acquired images, using free and/or open source tools that run on Windows.
To get this version of Arsenal Image Mounter to work, I had to do a couple of things. First, I had to download libewf.dll (My system is x64, so I used the DLLs from this location). I then copied the libewf.dll from my Autopsy installation over to the same folder as the Arsenal Image Mount tool, overwriting the older version of libewf.dll (there was some speculation online that the older version of libewf.dll was causing problems). Finally, I had to open the E01 files from the Lone Wolf scenario, rather than the raw/dd format image (I'd opened the E0x image files in FTK Imager and exported a raw/dd image, so I had both available). Once I did that, I was able to use Shadow Explorer to successfully view and access the VSCs.
The process that appears to work for raw/dd images is to use the Arsenal Image Mounter to mount the image file in Read Only mode, and then use vssadmin (via an Admin-level command prompt) to list the VSCs, and then mount a VSC as X:\ (or whatever you choose) via vss.exe. Once you've done that, you can open the now mounted VSC via FTK Imager,
I'm still trying to get vshadowmount to work, as well... I got the vshadowmount method working right after I published the updated post...essentially, once you run the vshadowmount command, you can access the individual VSCs via FTK Imager, by adding one of the VSCs as an image file evidence item, rather than logical drive. That is, when adding an evidence item to FTK Imager (after running the vshadowmount command), you choose "Image File". Boom. Done.
My analysis system is Windows 10; when I open a command prompt, I get "Microsoft Windows [Version 10.0.17134.228]".
I downloaded the *.e01 images files from the LoneWolf scenario that is available via the Digital Corpora site. The image is of a physical Windows 10 system. I then used FTK Imager to convert the split *.e0x images files into a unified raw/dd-style image, and I used that file (i.e., lonewolf_dd.001) in all of my testing.
Vhd Method
This method is defunct, in part because it no longer seems to work.
I did try vhdxtool, as well, but that didn't work at all...I'm not working with a .vhd file that needs to be converted to a .vhdx file, I'm using a raw/dd-style image.
Libvshadow/vshadowmount
This method requires Dokan 0.7.4 and pretty much follows along from the Libvshadow section of my previous post. For this attempt, I used the extended libvshadow tools provided with vss_carver.py.
First, I used mmls (from the TSK tools) to determine the offset to the partition of interest:
mmls -i raw -t gpt g:\lonewolf\lonewolf_dd.001
From that, I saw:
Slot Start End Length Description
00: Meta 0000000000 0000000000 0000000001 Safety Table
01: ----- 0000000000 0000002047 0000002048 Unallocated
02: Meta 0000000001 0000000001 0000000001 GPT Header
03: Meta 0000000002 0000000033 0000000032 Partition Table
04: 00 0000002048 0001023999 0001021952 Basic data partition
05: 01 0001024000 0001226751 0000202752 EFI system partition
06: 02 0001226752 0001259519 0000032768 Microsoft reserved partition
07: 03 0001259520 1000214527 0998955008 Basic data partition
08: ----- 1000214528 1000215216 0000000689 Unallocated
The partition we're interested in is the one in bold, and the offset is 1259520 sectors, or 644874240 bytes. Using that information, I can run vshadowinfo (I don't have to, but I can):
vshadowinfo -o 644874240 g:\lonewolf\lonewolf_dd.001
From the output of the above command, I can see two VSCs, which is what I expected. Now, for vshadowmount:
vshadowmount -o 644874240 g:\lonewolf\lonewolf_dd.001 x:\
After running this command, do not expect the command to exit...it won't, until you hit Control-C. I minimized the command prompt (which was running with Admin privileges) and could see "VSS1" and "VSS2" in the X:\ volume via Windows Explorer.
Next, I opened FTK Imager 4.2.0.13, and added the X:\ volume as an logical drive evidence item, or I tried to. I got an error dialog that said simply "Incorrect function. (1)".
I then opened Autopsy 4.8.0, and tried to add the volume as a local disk data source to a case. Unfortunately, unlike FTK Imager, Autopsy did not 'see' the X:\ volume.
Arsenal Image Mounter
I downloaded Arsenal Image Mounter, and used it to mount the image file. When mounting, I chose the "Read Only" option (the "Write Temporary" option was grayed out, and reportedly not available for raw/dd-style images). The image was mounted as "F:\", and I could easily browse the volume via Windows Explorer.
I had also downloaded ShadowExplorer 0.9, and when I opened it, it did not recognize the F:\ volume. I could see C:\, D:\, and G:\ (ext HDD where the image was stored).
Vss Method
Finally, I tried vss.exe, mentioned in my previous post; however, I should note that Jimmy Weg seems to no longer maintain his "justaskweg" domain, or the site(s) referenced in my original blog post. Further, the copy of vss.exe that I have has no identifying information (file version info), nor any syntax info.
I mounted the image via Arsenal Image Mounter (just like I did above), and got identifiers for both VSCs:
vssadmin list shadows /for=f:
I copied the ID for one of the VSCs to the clipboard, and then pasted it into the following command:
vss x: Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy47
The response I got back was:
Drive X: ---> \Device\HarddiskVolumeShadowCopy47
Okay...that's a start. I then opened FTK Imager and added the X:\ volume as a logical drive evidence item, and was easily able to traverse through the image, just as I normally would.
Summary
Of all of the methods tested, only vss.exe in conjunction with Arsenal Image Mounter was the one method that worked.
Addendum, 5 Sept
I've continued my testing, but before I kicked off the summary, I wanted to provide a link for vss.exe. Thanks to Brian Maloney for tracking that down.
One thing that's been clear over the past day or so is that even providing clear documentation (above) as to what I did, and where I got the tools, there's been a significant disconnect with respect to those offering assistance. It appears that the biggest one is that when we say "Arsenal Image Mounter", apparently, we're not all referring to the same thing. I got a copy of Arsenal Image Mounter from Github, not from the from the main ArsenalRecon.com web site, and that appears to make a significant difference. In particular, the option to mount a raw/dd image in "Write Temporary" mode is specifically NOT supported in this version of the tool.
So, to clarify, what I've been looking to do is get working processes for accessing VSCs within acquired images, using free and/or open source tools that run on Windows.
To get this version of Arsenal Image Mounter to work, I had to do a couple of things. First, I had to download libewf.dll (My system is x64, so I used the DLLs from this location). I then copied the libewf.dll from my Autopsy installation over to the same folder as the Arsenal Image Mount tool, overwriting the older version of libewf.dll (there was some speculation online that the older version of libewf.dll was causing problems). Finally, I had to open the E01 files from the Lone Wolf scenario, rather than the raw/dd format image (I'd opened the E0x image files in FTK Imager and exported a raw/dd image, so I had both available). Once I did that, I was able to use Shadow Explorer to successfully view and access the VSCs.
The process that appears to work for raw/dd images is to use the Arsenal Image Mounter to mount the image file in Read Only mode, and then use vssadmin (via an Admin-level command prompt) to list the VSCs, and then mount a VSC as X:\ (or whatever you choose) via vss.exe. Once you've done that, you can open the now mounted VSC via FTK Imager,