Windows Forensic Analysis Toolkit
Advanced Analysis Techniques for Windows 7
By Harlan Carvey
Copyright © 2012 Elsevier Inc.
All right reserved.
CHAPTER OUTLINE Introduction 1 Analysis Concepts 3 Windows Versions 4 Analysis Principles 6 Goals 6 Tools Versus Processes 8 Locard's Exchange Principle 8 Avoiding Speculation 9 Direct and Indirect Artifacts 10 Least Frequency of Occurrence 14 Documentation 15 Convergence 16 Virtualization 17 Setting Up an Analysis System 19 Summary 22
INFORMATION IN THIS CHAPTER
Setting Up an Analysis System
If you've had your eye on the news media, or perhaps more appropriately the online lists and forums, over the past couple of years, there are a couple of facts or "truths" that should be glaringly obvious to you. First, computers and computing devices are more and more a part of our lives. Not only do most of us have computer systems, such as desktops at work and school, laptops at home and on the go, we also have "smart phones," tablet computing devices, and even smart global positioning systems (GPSs) built into our cars. We're inundated with marketing ploys every day, being told that we have to get the latest-and-greatest device, and be connected not just to WiFi, but also to the ever-present "4G" (whatever that means ...) cellular networks. If we don't have a phone-type device available, we can easily open up our laptop or turn on our tablet device and instantly communicate with others using instant messaging, email, Twitter, or Skype applications.
The second truth is that as computers become more and more a part of our lives, so does crime involving those devices in some manner. Whether it's "cyberbullying" or "cyberstalking," identity theft, or intrusions and data breaches that result in some form of data theft, a good number of real-world physical crimes are now being committed through the use of computers, and as such, get renamed by prepending "cyber" to the description. As we began to move a lot of the things that we did in the real world to the online world (e.g., banking, shopping, filing taxes, etc.), we became targets for cybercrime.
What makes this activity even more insidious and apparently "sophisticated" is that we don't recognize it for what it is, because conceptually, the online world is simply so foreign to us. If someone shatters a storefront window to steal a television set, there's a loud noise, possibly an alarm, broken glass, and someone fleeing with their stolen loot. Cybercrime doesn't "look like" this; often, something isn't stolen and then absent, so much as it's copied. Other times, the crime does result in something that is stolen and removed from our ownership, but we may not recognize that immediately, because we're talking about 1s and 0s in cyberspace, not a car that should be sitting in your driveway.
These malicious activities also appear to be increasing in sophistication. In many cases, the fact that a crime has occurred is not evident until someone notices a significant decrease in an account balance, which indicates that the perpetrator has already gained access to systems, gathered the data needed, accessed that bank account, and left with the funds. The actual incidents are not detected until well after (in some cases, weeks or even months) they've occurred. In other instances, the malicious activity continues and even escalates after we become aware of it, because we're unable to transition our mindset from the real world (lock the doors and windows, post a guard at the door, etc.) to the online world, and effectively address the issue.
Clearly, no one and no organization is immune. The early part of 2011 saw a number of high-visibility computer security incidents splashed across the pages (both web and print) of the media. The federal arm of the computer consulting firm HBGary suffered an embarrassing exposure of internal, sensitive data, and equally devastating was the manner in which it was retrieved. RSA, owned by EMC and the provider of secure authentication mechanisms, reported that they'd been compromised. On April 6, Kelly Jackson Higgins published a story (titled "Law Firms Under Siege") at DarkReading.com that revealed that law firms were becoming a more prevalent target of advanced persistent threat (APT) actor groups. The examples are numerous, but the point is that there's no one specific type of attack that is used in every situation, or victim that gets targeted. Everyone's a target.
To address this situation, we need to have responders and analysts who are at least as equally educated, armed, and knowledgeable as those committing these online crimes. Being able to develop suitable detection and deterrence mechanisms depends on understanding how these online criminals operate, how they get in, what they're after, and how they exfiltrate what they've found from the infrastructure. As such, analysts need to understand how to go about determining which systems have been accessed, and which are used as primary jump points that the intruders use to return at will. They also need to understand how to do so without tipping their hand and revealing that they are actively monitoring the intruders, or inadvertently destroying data in the process.
In this book, we're going to focus on the analysis of Windows computer systems—laptops, desktops, servers—because they are so pervasive. This is not to exclude other devices and operating systems; to the contrary, we're narrowing our focus in order to fit the topic that we're covering into a manageable volume. Our focus throughout this book will be primarily on the Windows 7 operating system (OS), and much of the book after Chapter 2 will be tailored specifically to the analysis of forensic images acquired from those systems.
In this chapter, we're going to start our journey by discussing and understanding the core concepts that set the foundation for our analysis. It is vitally important that responders and analysts understand these concepts, as it is these core concepts that shape what we do and how we approach a problem or incident. Developing an understanding of the fundamentals allows us to create a foundation upon which to build, allowing analysts to be able to address new issues effectively, rather than responding to these challenges by using the "that's what we've always done" methodology, which may be unviable.
Very often when talking to analysts—especially those who are new to the field—I find that there are some concepts that shape not only their thought processes but also their investigative processes and how they look at and approach the various problems and issues that they encounter. For new analysts, without a great deal of actual experience to fall back on, these fundamental analysis concepts make up for that lack of experience and allow them to overcome the day-to-day challenges that they face.
Consider how you may have learned to acquire images of hard drives. Many of us started out our learning process by first removing the hard drive from the computer system, and hooking it up to a write-blocker. We learned about write-blockers that allowed us to acquire an image of a hard drive to another, "clean" hard drive. However, the act of removing the hard drive from the computer system isn't the extent of the foundational knowledge we gathered; it's the documentation that we developed and maintained during this process that was so critical and foundational. What did we do, how did we do it, and how do we know that we'd done it correctly? Did we document what we'd done to the point where someone else could follow the same process and achieve the same results, making our process repeatable? It's this aspect that's of paramount importance, because what happens when we encounter an ecommerce server that needs to be acquired but cannot be taken offline for any reason? Or what happens when the running server doesn't actually have any hard drives, but is instead a boot-from-SAN server? Or if the running laptop uses whole disk encryption so that the entire contents of the hard drive are encrypted when the system is shut down? As not every situation is going to be the same or fit neatly into a nice little training package, understanding the foundational concepts of what you hope to achieve through image acquisition is far more important than memorizing the mechanics of how to connect source and target hard drives to a write-blocker and perform an acquisition. This is just one example of why core foundational concepts are so critically important.
I've been told by some individuals that there are three basic computer operating systems that exist: Windows, Linux, and Mac OS X. That's it, end of story. I have to say that when I hear this I'm something a bit more than shocked. This sort of attitude tells me that someone views all Windows versions as being the same, and that kind of thinking can be extremely detrimental to even the simplest examination. This is due to the fact that there are significant differences among Windows versions, particularly from the perspective of a forensic analyst.
The differences among Windows versions go beyond just what we see in the graphical user interface (GUI). Some of the changes that occur among Windows versions affect entire technologies. For example, the Task Scheduler version 1.0 that shipped with Windows XP is pretty straightforward. The scheduled task (.job) files have a binary format, and the results of the tasks running are recorded in the Task Scheduler log file (i.e., "SchedLgU.txt"). With Vista and Task Scheduler version 2.0, there are significant differences; while the Task Scheduler log file remains the same, the .job files are XML format files. In addition (and this will be discussed in greater detail later in the book), not only do Vista and Windows 7 systems ship with many default scheduled tasks, but information about the tasks (including a hash of the .job file itself) is recorded in the Registry.
On Windows XP and 2003 systems, the Event Log (.evt) files follow a binary format that is well documented at the Microsoft web site. In fact, the structures and format of the .evt files and their embedded records are so well documented that open-source tools for parsing these files are relatively easy to write. Beginning with Vista, the Event Log service was rewritten and the Windows Event Log (.evtx) framework was implemented. Only a high-level description of the binary XML format of the logs themselves is available at the Microsoft site. In addition, there are two types of Windows Event Logs implemented; one group is the Window Logs and includes the Application, System, Security, Setup, and ForwardedEvent logs. The other group is the Application and Services logs, which record specific events from applications and other components on the system. While there are many default Application and Services logs that are installed as part of a Windows 2008 and Windows 7, for example, these logs may also vary depending on the installed applications and services. In short, the move from Windows XP/2003 to Vista brought a completely new logging format and structure, requiring new tools and techniques for accessing the logged events.
From a purely binary perspective, there is no difference among the Registry hive files of the various Windows versions, from Windows 2000 all the way through to Windows 7 (and even into Windows 8). In some cases, there are no differences in what information is maintained in the Registry; for the most part, information about Windows services, as well as the contents of the USBStor key, continue to be similar for versions between Windows 2000 and Windows 7. However, there are significant differences between these two Windows versions with respect to the information that is recorded regarding USB devices, access to wireless access points, and a number of other areas. Another example of a difference in what's recorded in the Registry is that with Windows XP, searches that a user performed through the Explorer shell (e.g., "Start->Search") are recorded in the ACMru key. With Vista, information about searches is moved to a file, and with Windows 7, user searches are recorded in the WordWheelQuery key.
Excerpted from Windows Forensic Analysis Toolkit by Harlan Carvey Copyright © 2012 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.