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.

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.

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.

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.

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.

Updates

RegRipper
Not all RegRipper plugins come from external sources; in fact, a good number of the plugins I've written start as something I've run across on the Internet, from various sources (most times Twitter).  Sometimes it's a blog post, other times it's a malware write-up, or it could be the result of a working a forensic challenge.

Based on Adam's post, I created a plugin (named wsh_settings.pl) that outputs the values of the Settings key, and includes an Analysis Tip that references the Remote value.

I also updated the clsid.pl plugin to incorporate looking for the TreatAs value. On a sample hive that I have from a Win7 SP1 system, I ran the following command:

rip -r d:\cases\test\software -p clsid | find "TreatAs"

I got a total of 9 hits, 7 of which were all for the same GUID (i.e., {F20DA720-C02F-11CE-927B-0800095AE340}), which appears to refer to packager.dll.

I also created a TLN output version of clsid.pl (named clsid_tln.pl) so that this information can be used to create timeline (in and of itself), or can be added to a timeline that incorporates other data sources.  I know from initial testing that under "normal" circumstances, the LastWrite times for the keys may be lumped together around the same time, but what we're looking for here is outliers, timeline entries that correspond with other suspicious activity, forming an artifact cluster.

Book
I received an email from my publisher on 20 Aug 2018 telling me that Investigating Windows Systems had officially been published, and is available here through the publisher!  I'm not sure what that means with respect to the book actually being available or shipped (if you pre-ordered it) from Amazon; for me, it's a milestone, something I can mark off my list. That's #9 down (as in, nine books that I've authored), and I'm currently working on Practical Windows Investigations, which will is due out next year.

IWS is a bit of a departure from my previous books; instead of listing various artifacts that you could use in an investigation, and leaving it to the reader to figure out how to string them together, I used images available online to illustrate what an investigation might look like.  Using the images, I provide analysis goals that are more inline with what one might expect to see during a real world IR investigation.  I then walk through the analysis of the image (based on the stated goals), providing decision pivot points along the way.  However, these investigations are somewhat naturally limited...they aren't enterprise level, don't involve things like lateral movement, etc.  As such, these things aren't addressed, but I did try to cover as much as I could with what was available.

I have a GitHub repo for the book - it doesn't contain a great deal at the moment, just links to the images used, and in the folder for chapter 4, code that I wrote for that particular chapter.  I'm sure I'll be adding material over time, either based on requests or based on interesting things from my notes and folders for the book.

Practical Windows Investigations is going to swing the pendulum back a bit, so to speak, in that rather than just looking at artifacts, I'm focusing on different aspects of investigations and addressing what can be achieved when pursuing those avenues.  The book is currently spec'd at 12 chapters, and the list is not too different from what was listed in this post from March.

The current chapters are:

Core Concepts
How to analyze Windows Event Logs
How to get the most out of RegRipper
Malware Detection
How to determine data exfiltration
File (LNK, DOCX/DOC, PDF) Analysis
How to investigate lateral movement
How to investigate program execution
How to investigate user activity
How to correlate/associate a device with a user (USB, Bluetooth)
How to detect/analyze the use of anti-forensics
Making use of VSCs

As with my previous books, tools used for analysis will be free and open source tools; this is due to the fact that I simply do not have access to commercial tools.  This is a topic that is continually brought up during prospectus reviews, and the reviewers simply do not seem to understand. 

Updates

Win10 Notification Database
Leave it to MS to make our jobs as DFIR analysts fun, all day, every day!  Actually, that is one of the things I've always found fascinating about analyzing Windows systems is that the version of Windows, more often than not, will predicate how far you're able to go with your analysis.

An interesting artifact that's available on Win10 systems is the notification database, which is where those pop up messages you receive on the desktop are stored.  Over the past couple of months, I've noticed that on my work computer, I get more of these messages, because it now ties into Outlook.  It turns out that this database is a SQLite database. Lots of folks in the community use various means to parse SQLite databases; one of the popular ways to do this is via Python, and subsequently, you can often find either samples via tutorials, or full-on scripts to parse these databases for you.

MalwareMaloney posted a very interesting article on parsing the write-ahead logging (.wal) file for the database.  Also, as David pointed out,

Anytime you're working with a SQLite database, you should consider taking a look at Mari's blog post on recovering deleted data.

RegRipper
Based on input from a user, I updated the sizes.pl plugin in a way that you may find useful; it now displays a brief sample of the data 'found' by the plugin (default is 48 bytes/characters).  So, instead of just finding a value of a certain size (or above) and telling you that it found it, the plugin now displays a portion of the data itself.  The method of display is based on the data type...if it's a string, it outputs a portion of the string, and if the data is binary, it outputs of hex dump of the pre-determined length.  That length, as well as the minimum data size, can be modified by opening the plugin in Notepad (or any other editor) and modifying the "$output_size" and "$min_size" values, respectively.

Here is some sample output from the plugin, run against a Software hive known to contain a malicious Powershell script:

sizes v.20180817
(All) Scans a hive file looking for binary value data of a min size (5000)

Key  : \4MX64uqR  Value: Dp8m09KD  Size: 7056 bytes
Data Sample (first 48 bytes) : aQBmACgAWwBJAG4AdABQAHQAcgBdADoAOgBTAGkAegBlACAA...

From here, I'd definitely pivot on the key name ("4MX64uqR"), looking into a timeline, as well as searching other locations in the Registry (auto start locations??) and file system for references to the name.

Interestingly enough, while working on updating this plugin, I referred back to pg 34 of Windows Registry Forensics and for the table of value types.  Good thing I keep my copy handy for just this sort of emergency.  ;-)

Mari has an excellent example of how she has used this plugin in actual analysis here.

IWS
Speaking of books, Investigating Windows Systems is due out soon.  I'm really looking forward to this one, as it's a different approach all together from my previous books.  Rather than listing the various artifacts that are available on Windows systems, folks like Phill Moore, David Cowen and Ali Al-Shemery graciously allowed me access to the images that they put together so that I could work through them.  The purpose of the book is to illustrate a way of stringing the various artifacts together in to a full-blown investigation, with analysis decisions called out and discussed along the way.

What I wanted to do with the book is present something more of a "real world" analysis approach.  Some of the images came with 30 or more questions that had to be answered as part of the challenge, and in my limited experience, that seemed a bit much.

The Github repo for the book has links to the images used, and for one chapter, has the code I used to complete a task.  Over time, I may add other bits and pieces of information, as well.

OSDFCon
My submission for OSDFCon was accepted, so I'll be at the conference to talk about RegRipper, and how you can really get the most out of it.

Here is the list of speakers at the conference...I'm thinking that my speaker bio had something to do with me being selected.  ;-)