Windows Registry Forensics: Advanced Digital Forensic Analysis of the Windows Registry
248
Windows Registry Forensics: Advanced Digital Forensic Analysis of the Windows Registry
248eBook
Related collections and offers
Overview
- Packed with real-world examples using freely available open source tools
- Deep explanation and understanding of the Windows Registry - the most difficult part of Windows to analyze forensically
- Includes a CD containing code and author-created tools discussed in the book
Product Details
| ISBN-13: | 9781597495813 |
|---|---|
| Publisher: | Elsevier Science |
| Publication date: | 01/03/2011 |
| Sold by: | Barnes & Noble |
| Format: | eBook |
| Pages: | 248 |
| File size: | 3 MB |
About the Author
Read an Excerpt
Windows Registry Forensics
Advanced Digital Forensic Analysis of the Windows RegistryBy Harlan Carvey
SYNGRESS
Copyright © 2011 Elsevier, Inc.All right reserved.
ISBN: 978-1-59749-581-3
Chapter One
REGISTRY ANALYSIS
INFORMATION IN THIS CHAPTER
• What Is "Registry Analysis"?
• What Is the Window Registry?
• Registry Structure
Introduction
The Windows Registry is a core component of the Windows operating systems, and it maintains a considerable amount of configuration information about the system. In addition, the Registry maintains historical information about user activity; in order to provide the user with a "better", more personalized experience, the Registry maintains details about applications installed and opened, as well as window positions and sizes. This information is maintained within the Registry in a manner similar to a log file. By this, I mean that there's a great deal of time-stamped information maintained in the Registry, including, but not limited to:
• When a user opened an application or accessed a Control Panel applet
• The last time the system connected to a particular wireless access point
• When a graphic image viewing application was used to access a particular file
All of this information can be extremely valuable to a forensic analyst, particularly when attempting to establish a timeline of activity on a system. A wide range of cases would benefit greatly from information derived or extracted from the Registry if the analyst was aware of the information and how to best exploit or make use of it.
Information in the Registry can have a much greater effect on an examination than I think most analysts really realize. There are many Registry values that can have a significant impact on how the system behaves; for example, there is a Registry value that, on Windows XP and 2003 systems, tells the operating system to stop updating file's last access time so that whenever a file is opened (albeit nothing changed) for viewing or searching, the time stamp is not updated accordingly. And oh, yeah ... this is enabled by default on Vista, as well as Windows 2008 and Windows 7 systems. A few other examples of Registry values that can impact an examination include (but are not limited to) the following:
• Alter or disable File System Tunneling
• Modify System Crash Dump, Prefetcher, and System Restore Point behavior
• Clear the page file when the system is shut down
• Enable or disable Event log auditing
• Enable or disable the Windows firewall
FILE SYSTEM TUNNELING
"File system tunneling" refers to an operating system's ability to "hold onto" file system metadata for a short period of time. How this can affect an analyst's examination is that if a file is deleted and then another file created in relatively short order that reuses the directory entry for the deleted file, the second file will actually take on the metadata (time stamps) for the previous file. It turns out that this also works for file renaming operations, as well, according to Microsoft. In short, when a file is removed from a directory, either by deleting or by renaming the file, the metadata for that file is temporarily cached. If, within a predefined amount of time (15 s by default), another file is added to that directory with the same name, the cached information is reused. This capability is meant for compatibility with earlier DOS programs that require the functionality and would affect an examination by providing false information about the creation date of a file in an analyst's timeline. The file system tunneling functionality can be controlled or simply disabled through specific Registry values.
There are a number of other values that can have a significant impact (possibly detrimental) on what an analyst sees during disk and file system analysis. Some of these values do not actually exist within the Registry by default and therefore must be added, usually in accordance with a Microsoft Knowledge Base (KB) article. At the very least, understanding these values and how they affect the overall system can add context to what the analyst observes in other areas of their examination.
REGISTRY VALUES AND SYSTEM BEHAVIOR
The Windows Registry contains a number of values that significantly impact system behavior. For example, an analyst may receive an image for analysis and determine that the Prefetch directory contains no Prefetch (*.pf ) files. Registry values of interest, in such a case, would include those that identify the operating system and version; by default, Windows XP, Vista, and Windows 7 will perform application prefetching (and generate *.pf files). However, Windows 2003 does not perform application prefetching (although it can be configured to do so) by default. The Prefetcher itself can also be disabled, per MS KB article 307498 [2]. This same value can be used to enable or disable application prefetching on Windows XP, Vista, and Windows 7 systems.
The purposes of this book are to draw back the veil of mystery that has been laid over the Registry, and to illustrate just how valuable a forensic resource, the Registry, can really be during malware, intrusion, or data breach examinations, to name just a few. The Windows Registry contains a great deal of extremely valuable information that can provide significant context to a wide range of investigations.
What Is "Registry Analysis"?
When examining an acquired image, an analyst will many times include "Registry analysis" as one of their analysis steps. You'll see this mentioned during initial calls, listed in reports, mentioned during final close-out of a project or analysis engagement, and discussed online. Most times, this will amount to opening a Registry hive file in a viewer application and looking at the contents of a couple of the more well-known Registry keys or locating a couple of values. Sometimes, the keys examined are pulled from the analyst's previous experience, and in other cases, they may be part of an analysis plan or standard operating procedure for the organization. This list may expand to a significant number of Registry keys, and be included in a checklist or spreadsheet.
However, does this really constitute "Registry analysis"? I mean ... really? When someone says "disk analysis," it usually constitutes much more than just looking at the disk itself, or just accessing the disk via the appropriate write-blocking hardware. Usually, the word analysis refers to (or infers) examining something from various angles and degrees, in an attempt to determine the context of the object of our attention in relation to other information or data from the same or other sources. The same holds true for the Windows Registry. There's much more to "Registry analysis" than simply looking at a couple of keys or values.
How does this approach differ from more "traditional" Registry analysis? The approach to Registry analysis has traditionally been one of looking at a specific key or at several specific values, and this approach has long been reflected in commercial tools. Commercial forensic analysis applications tend or attempt to represent the Registry in much the same manner as one would expect to see it on a live system (with obvious limitations, of course, all of which we will discuss later in this chapter and throughout the book), providing a layer of abstraction to the analyst through that representation. Looking at a specific key or value may answer a specific question for the analyst, but how often is that all we're really looking for? Registry keys and/or values may be pertinent in and of themselves, but more and more, they are simply part of the story, rather than being the entire story themselves. Don't misunderstand; there will be times when one Registry key or value is all you need. However, what I'm trying to convey here is that there is much more information and context available, so don't stop at just that key or value because you may think that's all you need, or that's all that you have available to you.
In short, "Registry analysis" can run across a spectrum of activities, from extracting specific key and/or value information to searching within the Registry and correlating data retrieved from different areas of the Registry. All of these activities can constitute the scope of "analysis," although both analysis and the examination itself may often benefit from something more. For example, what do certain Registry keys or values mean within the context of others? As we mentioned earlier in this chapter, a specific Registry value controls whether or not the operating system updates a file's last access times; so, how does this affect an analyst attempting to determine when a particular image file was viewed? If an analyst understands what information is maintained in the Registry, he/she will then be able to determine not only which user on the system viewed the image but also which application and when. Or, consider a flag value within a Registry value that determines whether or not a password is required for a user account? Is that flag value sufficient, or should the analyst check to see if the user account actually has a password (this is covered in detail in Chapter 3, "Case Studies: The System")?
Also, there may be far more information within the Windows Registry than meets the eye, particularly when the Registry is presented to the analyst via the abstraction layer of a viewing application. Much like files within a file system, Registry keys and values that are deleted do not simply disappear; as we'll see, the Registry files can contain significant information within the unallocated space of the files themselves.
Throughout the rest of this book, we're not going to be looking so much at this Registry key or that Registry value; rather, in most (albeit not all) instances, we'll be interested in examining the Registry as part of a postmortem analysis and as such, we'll use Registry analysis to help us determine not only the context of what we're looking at but also how that object of our attention plays into the overall context of our analysis. That context may be determined based on the analysis of other Registry keys and values, or it may be dependent upon other objects, such as file system metadata, Windows Event log records, entries in other logs, and so on.
Analysis Concepts
Before we talk about Registry analysis specifically, there are a few analysis concepts that we need to discuss that are pertinent to examinations as a whole. Keeping these concepts in mind can be extremely beneficial when performing digital analysis in general.
Locard's Exchange Principle
Dr. Edmund Locard was a French scientist, who formulated the basic forensic principle that every contact leaves a trace. This means that in the physical world, when two objects come into contact, some material is transferred from one to the other and vice versa. We can see this demonstrated all around us, every day ... let's say you get a little too close to a concrete stanchion while trying to parallel park your car. As the car scrapes along the stanchion, paint from the car body is left on the stanchion and concrete, and paint from the stanchion becomes embedded in the scrapes on the car.
Interestingly enough, the same holds true in the digital world. When malware infects a system, there is usually some means by which it arrives on the system, such as a browser "drive-by" infection via a network share, USB thumb drive, or an e-mail attachment. When an intruder accesses a system, there is some artifact such as a network connection or activity on the target system, and the target system will contain some information about the system from which the intruder originated. Some of this information may be extremely volatile, meaning that it only remains visible to the operating system (and hence, an analyst) for a short period of time. However, remnants of that artifact may persist for a considerable amount of time.
EVERYTHING LEAVES A TRACE
Almost any interaction with a Windows system, particularly through the Windows Explorer graphical interface, will leave a trace. These indications are not always in the Registry, and they may not persist for very long, but there will be something, somewhere. It's simply a matter of knowing what to look for and where, and having the right tools to gain access to, and understanding of how to correctly interpret the information.
The quote, "absence of evidence is not evidence of absence," is attributed to the astrophysicist Dr. Carl Sagan and can be applied to digital forensics, as well. Essentially, if an analyst understands the nature of a user's interaction with a Windows system, then the lack or absence of an artifact where one is expected to be is itself an artifact. During a recent examination, I was trying to determine a user's access to files on the system and could not find the RecentDocs (this key will be discussed in greater detail in Chapter 4, "Case Studies: Tracking User Activity") key within the user's NTUSER.dat hive file; RegRipper did not find it, and I could not locate the key manually. As it turns out, the user had run the "Window Washer" application, which reportedly clears the list of recently accessed documents. The time associated with the user launching the application (derived from the user's UserAssist key) corresponded to the LastWrite time on the RecentDocs parent key.
(Continues...)
Excerpted from Windows Registry Forensics by Harlan Carvey Copyright © 2011 by Elsevier, Inc.. Excerpted by permission of SYNGRESS. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Table of Contents
Chapter 1. Registry Analysis Chapter 2. Tools Chapter 3. Case Studies: The System Chapter 4. Case Studies: Tracking User Activity
What People are Saying About This
The second edition of this go-to reference provides readers with the information, tools, and processes needed to find and analyze forensic evidence using Windows Registry. Tools and techniques for post mortem analysis are discussed at length to take users beyond the current use of viewers and into real analysis of data contained in the Registry