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.

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.

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.