IWS

As I'm winding up the final writing for my next book, Investigating Windows Systems, I thought I'd take the opportunity to say/write a few words with respect to what the book is, and what it is not.

In the past, I've written books that have provided walk-thrus of various artifacts on Windows systems.  This seemed to be a good way to introduce folks to the possibilities of what was available on Windows systems, and what they could achieve through their analysis of images acquired from those systems.

With Investigating Windows Systems, I've taken a markedly different approach.  Rather that providing introductory walk-thrus of artifacts, I'm focusing on the analysis process itself, and discussing pivot points, and analysis decisions made along the way.  To do this, I've used available CTF and forensic challenge images (I reached to the authors to see if it was okay with them to do this...) as the basis, and in chapters 2, 3, and 4, walk through the analysis of the images.  In most cases, I've tried to provide more real world examples of the analysis goals (which we document) than what was provided as part of the CTF.  For instance, one CTF has 31 questions to answer as part of the challenge, some of which are things that should be documented as a matter of SOP in just about every case.  However, I opted to take a different approach with the analysis goals, because in two decades of cybersecurity consulting, I've never worked with a client that has asked 30 or more questions regarding the case, or the image being analyzed.  In the vast majority of cases, the questions have been, "..was the system compromised/infected?", often followed by "...was sensitive data exfiltrated from the system?"  Pretty straightforward stuff, and as such, I wanted to take of what I've seen as a realistic, IRL approach to the analysis goals.

Another aspect of the book is that a certain level of knowledge and capability is assumed of the reader, like a "you must be this tall to ride this ride" thing.  For example, throughout the book, in the various sections, I create timelines as part of the analysis process.  However, I don't provide a basic walk-thru of how to create a timeline, because I assume that the reader already knows how to do so, either by using their own process, or from chapter 7 of Windows Forensic Analysis (in both the third and fourth editions).  Also, in the book, I don't spend any time explaining all of the different things you can do with some of the tools that are discussed; rather, I leave that to the reader.  After all, a lot of the things that someone might be curious about are easy to find online.  Now, this doesn't mean that a new analyst can't make use of the book...not at all.  I'm simply sharing this to set the expectation of anyone who's considering purchasing the book.  I don't cover topics such as malware RE, memory acquisition and analysis, etc., as there are some fantastic resources already available that provide in-depth coverage of these topics.

Additional Materials
With some of my previous books, I've established online repositories for additional materials included with the book.  As such, I've established a Github repository for materials associated with this one.  As an example, in writing Chapter 4, I ended up having to write some code to parse some logs...that code is included in the repository.

Producing Intel
Something else I talk about in the book, in addition to the need for documentation, is the need for DFIR analysts to look at what they have available in an IR engagement that they can use in other engagements in the future.  The basic idea behind this to develop, correlate and maintain corporate knowledge and intelligence.

In one instance in the book, during an analysis, I found something in the Registry that didn't directly pertain to the analysis in question, but I created a new RegRipper plugin, wc_shares.pl.  I added the plugin directly to the RegRipper repository.

As a bit of a side note, if you're a Nuix customer, you can now run RegRipper through Workbench.  Nuix has added an extension to their Workbench product that allows you to run RegRipper without having to close out the case or export individual files.  For more details, here's the fact sheet.

Other ways to maintain and share intelligence include Yara rules, endpoint filter/alert rules, adding an entry to eventmap.txt, etc.  But that's not it, there are other ways to share intelligence, such as this blog post that I wrote during previous employment, with a good deal of help from some really smart folks.  That blog post alone has a great deal of valuable intelligence that can be baked back into tools and processes, and extend your team's capabilities.  For example, look at figure 2 in the blog post; it illustrates the command that the adversary issued to take specific actions (fig. 1 illustrates the results of that command).  If you're using an EDR tool, monitoring for that command line (or something similar) will allow you to detect this activity early in the adversary's attack cycle.  If you're not using an EDR tool and want to do some threat hunting, you now have something specific to look for.