Carvey - Investigating Windows Systems

I am not an expert. I have never claimed to be an expert, particularly at analyzing Windows systems. As I have done before, got to a point where I looked around at the materials I had written into blog posts, into various documents, and even in a hard copy notebook and on scraps of paper, and saw that I had reached a critical mass. At that point, once I had stacked everything up, I felt that I likely had too much for a blog post (definitely too much for Twitter), and should just put everything into a book.

Looking back, I really feel like I decided to write this book for a couple of reasons. First, all of my earlier books have included lists of artifacts to be analyzed and tools for parsing various data sources, but little in the way of the thought process and analysis decisions that go into the actual analysis. This thought process is something I follow pretty much every time I perform analysis of an acquired image, and I thought that, taking a different approach with this book would be beneficial to someone. This is also due to the fact that when I have attended training courses and conference presentations, something I have asked a number of times is, what is the analysis decision that led you to this point? I thought that since I have had that question, is it possible that others might have had the same or similar questions? What was different about someone elses experiences such that they chose to follow one path of analysis over another? My thinking has been that by engaging with each other and understanding different viewpoints, we all grow, develop, and get better at analysis.

Another reason for writing this book is that there are a number of sites you can visit online that describe the use of open source and freely available tools for parsing data sources. However, rather than listing the tools and providing suggestions regarding how those tools might be used, I thought it would be a good idea to provide example analyses, from start to finish, and include the thought processes and analysis decisions along the way with respect to what tool to use, why, and what the analysis of the output of the tool provided, or led to.

In this book, I relied upon the kindness of others who have posted images of Windows systems online as part of forensic challenges. To each and everyone of them, I am grateful. In some cases, these online challenges have links to analysis performed by others, but what is often missing is the decision the analyst made as to why they did something. Why did you start there, or why did you choose one direction, or one data source, in your analysis over another?

Throughout this book, I have tried to remain true to a couple of base tenants and concepts. First, documentation is everything. As is often said on the Internet, picture, or it did not happen. That is to say, unless you have documentation of your actions (in this case, a picture), it did not really happen. The same thing applies to forensic analysis; over the years, many of us have shared the euphemism of having to explain what actions we took and decisions we made during analysis 6 months ago. Well, it was all a euphemism, until it was not. I have worked with analysts who have had to go back to an engagement that was 12 months old, and try to explain what they did to their boss, or to legal counsel, without any documentation whatsoever. Furthermore, too many times, we miss the opportunity to share findings with other analysts, or even simply use what we learned on future engagements because we did not document what we did, nor what we found. We cannot remember everything, and baking our findings back into our analysis tools and processes means that we do not have to.