I am not an expert. I have never claimed to be an expert at anything, least of all when it comes to incident response and digital forensic analysis of Windows systems. I am simply someone who has found a deep, abiding interest in my chosen field of employment, and a bit of passion to make things more efficient for myself and develop a deeper understanding. I enjoy delving into and extending my analysis process, as well as exploring new ways to approach problems in the fields of digital forensic analysis and incident response. It was more than 16 years ago that I decided to focus on Windows systems specifically, in large part because no one else in the team I worked with at the time did so; we had folks who focused on routers and firewalls, as well as those who focused on Linux. However, almost no effort, beyond enabling configuration settings in the vulnerability scanner we used, was put toward really understanding Windows systems. As I moved from vulnerability assessments into incident response and digital forensic analysis, understanding what was happening “under the hood” on Windows systems, understanding what actions could create or modify certain artifacts, became a paramount interest. Even so, I am not an expert.
When I sat down to update the material for this edition, I wanted to not only include new information that I’d found or developed since the third edition was published, but I also wanted to try to include as much information as possible regarding Windows 8 and 8.1. With Windows 8.1 becoming available while I was updating the book, the inevitable questions were being asked, and invariably it won’t be long before we start seeing the systems appear on analyst’s workbenches. As such, I’ve tried to provide as much information as I could with respect to newer versions of Windows (i.e., 8 and 8.1), either by writing it directly into the book or linking to the sources of information on the Internet, when attempting to summarize it would simply not do the content justice. Keep in mind, however, that new information is being discovered and developed all the time, and at some point, I needed to stop writing and submit the book for final review and publishing. I’m sure that even more information will become available during the time between when the book goes to the printer, and when it actually comes out on the shelves at bookstores.
As I’ve said in previous editions, there are some things that are simply not covered in this edition. There are some topics, such as Windows memory collection and analysis that are best addressed by those who are much better versed in and capable of presenting the topic than I; I have used available tools for collecting memory dumps, and I have used Volatility to analyze memory dumps, including converting a hibernation file into a raw format and then using it to find a malicious process. However, that does not necessarily make me an authority on using Volatility during even a moderate range of analysis. Many times, I’ve relied on assistance from others regarding how to get started or even just maintain forward momentum. That being said, I wanted to focus on topics with which I was much more familiar. For example, in this book, I also discuss malware detection within an acquired image, but I do not discuss the in-depth analysis of any malware found using this process, as this topic has been much more thoroughly addressed in other books.
This book is intended for anyone with an interest in developing a greater understanding of digital forensic analysis, specifically of Windows systems. This includes digital forensic analysts, incident responders, students, law enforcement officers, and researchers, or just anyone who’s interested in digital forensic analysis of Windows 7 systems. Even system administrators and hobbyists will get something useful from this book. I’ve tried to point out how the information in this book can be used by both forensic analysts and incident responders alike.
In reading this book, you’ll notice that there are several tools described throughout that were written in the Perl scripting language. Don’t worry, you don’t need to be a Perl expert (after all, neither am I) to use these scripts; not only are the scripts very simple to use but in most cases, they are accompanied by Windows executables, “compiled” using Perl2Exe (found online at http://www.indigostar.com/perl2exe.php). While some programming capability would be beneficial if you want to develop your own RegRipper plugins, several folks with little to no Perl programming skill have written working plugins for that particular tool. Others have rewritten tools like RegRipper in other languages, because again, it’s not about the tool you use to solve the problem, it’s about solving the problem.
This book consists of nine chapters following this preface. Those are:
This chapter addresses the core investigative and analysis concepts that I’ve found to be so critical to what we do, yet somehow glaringly absent from many books and discussions. As professionals within the digital forensic analysis community, there are a number of concepts that are central to what we do, and while (at this time) there isn’t a centralized authority to mandate and manage this sort of information, I’ve found these concepts to be absolutely critical to the work I’ve been doing. Further, whether presenting at a conference or discussing analysis with someone one-on-one, I see “the light come on” when talking about these concepts. These concepts are vitally important because we cannot simply load an acquired image into a forensic analysis application and start pushing buttons; this really gets us nowhere. What do we do when something doesn’t work or gives us output that we didn’t expect? How do we handle or address that? Do we move on to another tool, documenting what we’re doing? I hope so—too many times, I’ve seen or heard of analysts who’ve accepted whatever the tool or application has provided, neglecting to conduct any critical thought, and moved on to their findings. Operating systems and targets may change, but the core concepts remain the same, and it’s imperative that analysts understand and employ these concepts in their analysis.
In this chapter, we discuss the need for immediate response once an incident has been identified. Often, an organization is notified by another entity (e.g., bank, law enforcement agency) that they’ve been compromised, and an external third party consulting firm that provides incident response services is immediately contacted. Once contracting issues have been addressed, consultants are sent on-site, and once they arrive, they need to gather further information regarding what was identified, as well as the “lay of the land” with respect to the network infrastructure. All of this takes additional time, during which information that could prove to be very critical to addressing the inevitable questions faced by the potentially compromised organization is fading and expiring (this says nothing about sensitive data that may continue to flow from the infrastructure). Processes complete, deleted files get overwritten and new Volume Shadow Copies are created as old ones are deleted. Windows systems are surprisingly active even when supposedly sitting idle; therefore, it is paramount that response activities begin immediately, not whenever someone from outside the organization, who isn’t familiar with the infrastructure, can arrive on-site.
The existence of Volume Shadow Copies (VSCs) is relatively well known within the digital forensics community, but means by which analysts can exploit their forensic value is still not something that’s discussed at great length, particularly when it comes to accessing and processing data within VSCs in a timely manner, without purchasing additional software. As much of the digital forensic analysis that I’ve been engaged in occurs using images acquired from systems, this chapter addresses how analysts can access the wealth of information available in VSCs without having to interact with the live system, and without having to purchase expensive solutions.
This chapter addresses not only the analysis of some of the usual files available on Windows systems but also files and data structures that are new to Windows 7 (or Vista) and have been identified and better understood through research and testing. Some files available on Windows 7 systems have changed formats, while others are simply new, and both need to be understood by analysts. For example, Jump Lists are new to Windows 7 systems, and some of them use the compound document binary format (popular in MS Office documents prior to version 2007 of the office suite), in conjunction with the SHLLINK format most often seen in Windows shortcut files. As such, Jump Lists can contain considerable information (including metadata) that can be very valuable during an investigation.
This chapter addresses some of the information provided through other sources, most notably Windows Registry Forensics, and takes that information a step further, particularly with respect to Windows 7 systems. Rather than reiterating the information available in other sources, this chapter uses that information as a foundation and presents additional information specific to the Windows 7 Registry.
Oddly enough, this chapter does not contain the word “analysis” in the title, because we’re not going to be discussing either static or dynamic malware analysis. Instead, we’re going to discuss a specific type of analysis that is becoming very prominent within the digital forensic community; that is, given an image acquired from a Windows system, how can we go about detecting the presence of malware within that image? Professionally, I’ve received quite a number of images with the goal being to determine if there was malware on the system. Sometimes, such a request is accompanied by little additional information, such as the name of a specific malware variant, or specific information or artifacts that can be used to help identify the malware. Given that malware authors seem to be extremely adept at keeping their code hidden from commercial antivirus scanning applications, analysts need other tools (preferably a process) in their kits for detecting malware within an acquired image.
The idea of timeline analysis has been around for over 14 years. Over time, we’ve seen how a considerable amount of time stamped information is maintained by the Windows operating systems, and all of this can potentially be extremely valuable to our analysis. Also, much of this time stamped information is contained in artifacts that persist even after applications and malware have been removed from the system, and can be revealed through timeline analysis. In addition, incorporating multiple data sources of time stamped data into a timeline will provide considerably more value to an examination. This chapter walks the reader through the process for creating a timeline, so that that process can be understood to the point where reasoned decisions can be made with respect to the tools used and the data incorporated into the timeline.
Over the years, as I’ve presented at conferences, written blog posts, and talked with other analysts, a topic that keeps coming up is that analysts very often want to see how other analysts have accomplished tasks; in short, what everyone seems to want to hear about are “case studies” or “war stories” from the front lines. What I’ve attempted to do in this chapter is harken back to the second edition and share some aspect of the analysis process I’ve used during various examinations. No two analysis engagements are ever the same, and I tend to carry forward things I’ve learned from past engagements, in an effort to make the next one just a bit more efficient and comprehensive. My hope is that something I’ve shared will be useful to you.
In this chapter, my intention was to present the reporting process that I’ve found to be useful. In my experience in the technical information security industry, I’ve seen the reporting is the most difficult, and perhaps the most important, task. After all, regardless of the type of work that you’re doing, such as digital forensic analysis or penetration testing, if you can’t communicate your findings to your customer in a manner that they can understand and use the information, what have you really accomplished? What I wanted to do with this chapter is share what I’ve learned over my professional career, including my time in the military, in hopes that the lessons I’ve learned can be useful to others. Please keep in mind as you’re reading this chapter that it’s based solely on my own experiences; if you’re looking for something specifically to address a very narrow niche, you most likely won’t find it there. However, my hope is that the information is useful to others.
There is no DVD that accompanies this book; instead, you’ll be able to find a link the code that I’ve written and described in this book online at the Books page for the WindowsIR blog, found online at http://windowsir.blogspot.com/p/books. Just find the entry for this edition and follow the appropriate link to download an archive of the tools.