Preface
I am not an expert. I don’t know everything. In particular, I do not and have never claimed to be an expert at analyzing Windows systems nor in analyzing the Windows Registry. What I have done is taken all that stuff I’ve got written down over the years, in different places, as well as stuff I’ve found online, stuff I’ve found after running malware in a VM and creating a timeline, etc., and put it into what I thought would be a logical structure. I then decided to call some of this stuff “chapters,” and I sent them to Mari to review and tech edit. She sent them back, I looked at her comments, decided that she was right in most cases, and sent the chapters into Syngress. They made it into a book. That’s a process, and it doesn’t make me an expert at anything, especially digital forensic analysis.
When I wrote the first edition of this book, I mentioned in the preface that by 2010, I had met a good number of forensic analysts who had little apparent knowledge of the value that the Windows Registry can hold. As 2015 draws to a close and I am submitting the manuscript for the second edition of the book, the same holds true. Data within the Windows Registry can provide a great deal of context to investigations, illustrating user access to files, devices that have been attached to the system, applications that have been executed, and users that have been added to the system. Configuration settings maintained with the Registry will inform the analyst as to what they can expect to see on the system; did deleted files bypass the Recycle Bin, was the page file cleared at shutdown, and what is the effective audit policy for the system? I’ve used information from the Registry to determine that a user intentionally infected a system with a remote access Trojan (RAT) and then attempted to “clean up” after removing the malware. Prior to sharing my findings, the popular notion was that systems infected with that RAT were the result of spear phishing.
Throughout this book, I have maintained a good deal of information specific to Windows XP and 2003 systems, because they are still out there. However, I’ve included more information regarding Windows 7, as well as 8, 8.1, and Windows 10 systems, where possible. There are things that we still don’t know about Windows 7 systems, and at the time of this writing, Windows 10 is still somewhat new. However, it’s likely that by the time the book is published and on the shelves, that holiday season would have resulted in a large number of newly purchased systems arriving with Windows 10 preinstalled. As such, there is still a great deal of research to be done, and even more to discover about Windows 10.
Again, I am not an expert, and I don’t know it all; I have simply tried to include some of what I’ve encountered and experienced in this book.
Intended Audience
The intended audience for this book is anyone analyzing Windows systems. This includes, but is not limited to, law enforcement officers, military personnel, those in academia (students, professors, lab assistants, etc.), as well as investigators in full-time employment and consulting positions. IT admins and managers will find useful things in the chapters of this book.
So…yeah…the intended audience is “everyone who performs incident response and/or digital forensic analysis of Windows systems,” and this also includes anyone interested in doing so.
Book Organization
This book consists of five chapters following this preface. Those chapters are as follows:
Chapter 1: Registry Analysis
In the first chapter of the book, we go over some of the basic concepts of digital forensic analysis and then present some basic information about the Windows Registry; where it can be found in the file system, nomenclature, that sort of thing. This chapter may seem somewhat rudimentary to some, but it lays a foundation for the rest of the book. Over the years, and even today, I find that there are some examiners who try to jump into Registry analysis and go from “0 to 60” without that base foundational knowledge. This understanding of Registry analysis is critical, as it allows the examiner to be discerning of not only the tools used but also of the available data itself.
Chapter 2: Processes and Tools
In this chapter, we discuss some open source and freeware tools that are available to analysts. There are viewers and data extraction tools available, and it’s important for analysts to understand the strengths and weaknesses of each class of tool, as well as each individual tool, when using them.
What you won’t find discussed in this chapter is the use of commercial analysis suites. The decision to go this route was a conscious one, with two guiding reasons. The first is that it’s important for analysts to be aware of their analysis goals and what it is they’re trying to achieve, before using an automated tool set.
The second reason is simply that I don’t have access to the commercial tools. And honestly, I don’t want access to them. But don’t misunderstand my reasoning as to why; it’s not the suites themselves that I have an issue with, it’s how most analysts use them. So, again, my goal with this book is to provide a resource from which analysts can build a solid foundation.
Chapter 3: Analyzing the System Hives
In this chapter, we discuss the Registry hives that pertain to the system as a whole (not specifically to the users). In this edition, I wanted to organize the keys and values discussed into “artifact categories,” in the hope of making it a bit clearer as to why an analyst would be interested in the various keys and values in the first place.
For example, one of the things I’ve tried to illustrate with respect to the value of Registry analysis is that even some of the stealthiest malware found needs to persist in some manner. In 2015, analysts from a computer security company published their findings with respect to extremely stealthy malware named “Moker”; they went into significant detail regarding how the malware itself was written to avoid detection and hamper analysis. However, in the comments section of their blog post, they mentioned that the malware persisted via the use of the “Run” key, which should make it trivial to detect something anomalous on the system.
I’ve also tried to illustrate the value of Registry analysis by discussing how system configuration settings within the Registry can impact an investigation, as well as how there are various bits of malware that leave traces in the Registry that have nothing to do with persistence (the values appear in some cases to be associated with the configuration of the malware).
Chapter 4: Case Studies: User Hives
In this chapter, we discuss the Registry hives specific to the user, and once again, present various Registry keys and values of interest to analysts broken down into artifact categories. There is a great deal of valuable information within the user’s hives that can have a significant impact on an investigation. I’ve had occasion to examine systems thought to have been infected with remote access Trojans (RATs) through the use of spear phishing or a “watering hole attack” (also referred to as a strategic web compromise), only to find that the user had purposely infected the system. In more than one instance, I’ve also used data derived from the user hives to illustrate that a user or administrator had attempted to “clean up” a malware infection.
Chapter 5: RegRipper
In the final chapter of the book, we specifically discuss the RegRipper tool itself. Over the years, I’m aware that there are a lot of folks who use RegRipper but largely from the perspective of downloading and running the GUI for the tool. I don’t think that what folks are aware of is that RegRipper can be a much more powerful tool, if you know a bit more about how it functions and how it can be used. My hope is that a few will not only develop a better understanding of the tool but also choose to open an editor and write their own plugins. Consider this chapter a “user manual” of sorts.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.