“Investigating Windows Systems” by Harlan Carvey was a great read on so many different levels for me. After binge-reading it over a weekend, I was so excited about it that the following Monday morning I found myself almost shouting at warp-speed to a co-worker about why it was such an important read. Our chat reminded me of something I had thought about while still making my way through the book. How could a book so compact, contain that much valuable information?! I actually believe this book could have been titled, “DFIR Field Manual”, or “DFIRFM.”

For one thing, the book was easily digestible. At times, I found myself “playing along”, almost like a CTF. That’s because the book takes you (step-by-step) on an analyst’s journey through several investigations, and invites you to follow-along by downloading all the free images and open source tools the author is using to walk you through. You get to learn alongside a seasoned veteran, almost in real-time, and observe, even as critical case decisions are being made along the way.

The book felt really timely to me. I’d recently been following some thought-provoking discourse around the pronounced differences between the “DF” and “IR” of “DFIR” – Digital Forensics and Incident Response, and have even myself gotten into some rather animated discussions during time-sensitive incidents asking, “Where’s our DirListing?!” or, “May I please just have a DirListing!”

The book had a recurring theme for me, and that was, the steps you take regardless of the type of investigation, are often consistent. Why? Low hanging fruit! My take-away was that Harlan almost always makes a visual inspection of the data before he does anything else. That is not just to verify that he has an image that isn’t damaged, but it’s also so that he can identify outliers rather quickly, such as a batch file sitting in the root of C:\ – might be nothing, but could be something. Things that make you go, “hmmm”.

Another important concept I learned was the art of discernment and how critical that can be to your end-goal (which an analyst must keep in mind is often guided by a paying client, not your own curiosity). So, should you choose to dive down a rabbit-hole, (and we all do), a concise analysis plan will help keep you on track, and he shows you how.

As our digital landscape continues to grow, and the average size of hard drives (and memory) gets larger and larger, sometimes it can seem like we’re trying to “boil the ocean”. To combat that, Harlan teaches us the art of timelining and how that process can help you streamline your analysis by distilling down the data and filtering out the noise. Additionally, we learn that we have tiered options in our approach, so that we don’t lose meaningful data by doing so; mini, micro, and even nano timelines.

I also learned how to “fail fast”. Trust me, when you have a client or upper management breathing down your neck for answers, you’ll be glad you grasped that concept. Regardless of how long you’ve been in the field, you will be astounded at the knowledge you acquire from this book. New folks might learn not to assume that malware or “hacking tools” simply sitting on a system, are bad. On the contrary, they’ll become proficient in how to prove whether or not those tools were launched, and how they might have been used. Or, what local accounts on a system with no profile might mean, and how FTP being run from a browser might be overlooked as it leaves fewer artifacts and in “unusual” places. Even TimeStomping is covered, as well as using the “Conversations” filter in WireShark to “Follow Stream”. It’s all there!

The book also tackles another topic I’ve been seeing articles around recently – Sufficiency. How much data is enough data for us to come to our analysis goals? Lately that’s been on a lot of people’s minds. Well, perhaps that answer depends. For example, have we answered the questions the (paying) principal has asked of us? It also pivots on another very important case concept – have we, as the investigator, helped our client ask the right questions, because they don’t always know themselves what questions they need to be asking. If so, and we’ve come to a solid conclusion, then yes, we can confidently state that “our work here is done!” Even more so, if the principal cannot articulate those questions, and in fact leaves you with almost no information to begin your quest, how do you still make magic happen? Those answers are all in the book, and the reader is steadily guided through every scenario.

You’ll learn what persistence can look like, and how to spot it. You’ll grasp what the artifacts of “staging” resemble, whether it’s being done by an advanced adversary, or an insider who’s ready to bolt. You will also learn how not to allow your own analysis to create a red herring in your case, in other words, if you detonate a piece of malware from the Desktop of your VM, you need to understand that you might be building artifacts that would not be present had it been introduced via its native vector (email, URL, USB), and what those are so you don’t include them in your findings. You might even find a new trick for using Calc.exe.

I also learned a new thought process around triaging malware that I hadn’t read before and found it to be quite clever. Execute the sample, let it run for a bit, then shut the box down and grab an image. Then you can perform analysis to examine the complete file system after the malware runs. Perhaps not all incidents have time for that, but I thought it was a brilliant methodology. I typically use RegShot or other tools to snapshot the Registry state before (and after) I run a sample, but now I no longer need to chance missing anything that the malware might have changed.

In conclusion, it truly is fascinating how much ground the book covers in such a concise manner, which I believe can only be attributed to the author being both an accomplished writer, and a seasoned investigator. Whether you’re running-to-ground File System Tunneling, WindowsXP, Windows10, a Web Server running iis or Apache, it’s all covered in the book, and with log locations and examples. You. Will. NOT. Be. Disappointed!  8 people found this helpful

I was anxiously awaiting the release of this book, since the summer. I knew I had to have it for one reason – the book’s author. I’ve read Windows Forensic Analysis Toolkit (one of Harlan’s other books), and was not disappointed. One section in that book, in particular, appealed to me – the report writing/documentation section. This is an area of digital forensics for which I do not find many resources. So, when I opened Investigating Windows Systems, and realised the content was divided into various scenarios (each scenario was basically written in report-format) my eyes almost popped out of my head (that’s a good thing). Harlan provides great perspective on a myriad of topics, and sparks a lot of thought on how an investigation can be handled. It’ll also spark thought on other items of interest, based on the reader’s experience (I’m sure).

One overarching concept I identified in the book was this – a practitioner must give value to findings, by documenting the meaning of particular artifacts, as a function of context (ie given a scenario, an artefact means ‘x’; in another scenario, the same artifact still proves ‘x’, and may prove ‘y’. Additionally, the concept of drilling down, and making sense of digital evidence, must be part of a practitioner’s feedback (to a prosecutor, client, or student of the trade).

Harlan’s method of conveying examination/analytical details, makes sense to me, and gives me a rhythm to emulate. Whether in part or in whole, I can use the content of this book as a template, and modify as necessary. As you read Harlan’s book (any of them really), you’ll notice great value through the explanations he provides. I purchased the electronic version, but wish I had purchased the paper version – this way I could highlight and use sticky-flag, for parts that are of interest to me.