Windows Forensic Analysis Toolkit: Advanced Analysis Techniques for Windows 8

Marines.

Chapter 1

Analysis Concepts

This chapter provides a foundation for analysis discussed in the rest of the book. We discuss core analysis concepts so that they can be built upon in the following chapters of the book.

Keywords

Concepts; analysis; framework; set up

Chapter Outline

Introduction 1

Analysis concepts 4

Windows versions 4

Analysis principles 6

Goals 7

Tools versus processes 9

The tool validation myth-odology 9

Locard’s exchange principle 11

Avoiding speculation 11

Direct and indirect artifacts 13

Least frequency of occurrence 16

Documentation 18

Convergence 19

Virtualization 20

Setting up an analysis system 22

Summary 25

Information in This Chapter

 Analysis Concepts

 Setting Up An Analysis System

Introduction

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 will be glaringly obvious to you. First, computers and computing devices are more ubiquitous in 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, but 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 reach to others using instant messaging, email, Twitter, or Skype applications.

The second truth is that as computers become more and more parts of our lives, so does crime involving those devices in some manner. Whether it’s cyberbullying or cyberstalking, identity theft, the advanced persistent threat (APT), 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 of the crime. As we began to move a lot of the things that we did in the real world to the online world (i.e., banking, shopping, filing taxes), we became targets for cybercrime. Organizations become targets (and subsequently, victims) of online crime, simply because they have something someone wants, be it data or computing power. 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 booty. Cybercrime doesn’t look like this; often, something isn’t stolen and then absent, so much as it’s copied, and then used for malicious purposes. The data (credit card numbers, personally identifiable information, etc.) still exists in its original location, but is now also in the possession of someone who intends to sell it to others. Other times, the crime does result in something that is stolen and is removed from our ownership, but we may not recognize that immediately, because we’re talking about 1s and 0s in the ether of cyberspace, not a car that should be sitting in your driveway, in plain view.

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 days 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 person, 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 APT actor groups. The examples continue on through 2012 and into 2013, but the point is that there’s no one specific type of attack, or victim that gets targeted. The end of 2012 saw some banks and other organizations falling victim to massive distributed denial of service attacks, and the spring of 2013 saw a specific group in China, and even specific individuals, identified as being responsible for long-term and long-standing data theft attacks on US companies. Shortly thereafter, a group in India was identified as being responsible for other attacks, predominantly against targets in Pakistan. Anyone can be a target.

In order to address this situation, we need to have responders and analysts who are at least as equally educated, knowledgeable, and collaborating 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. These goals are best achieved by having knowledgeable groups of responders working together, and sharing information across arbitrary boundaries.

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 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, and much of the book, after Chapter 2, will be tailored specifically to the analysis of forensic images acquired from those systems. I will be including information regarding Windows 8 artifacts, where appropriate, throughout the book. While there are some notable differences between Windows 7 and Windows 8, the simple fact is that there are also some similarities, so I will attempt to highlight those in addition to pointing out some of what is different. However, at this writing, analysts should be more concerned with what is available in Windows 7, as understanding data structures and developing skills in addressing the available data will be very beneficial when analyzing a Windows 8 system.

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 an 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.

Analysis concepts

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 your thought processes but also your investigative processes and how we look at and approach the various problems and issues that we 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 process of learning 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 hard drive, as well as those that we could hook up to a laptop and use acquisition software to acquire an image to an external USB hard drive. However, the act of removing the hard drive from the computer system isn’t the extent of the foundational knowledge; it’s the documentation that we developed and maintained during this process that was so critical. 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 critically important, 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.

Windows versions

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 versions of Windows 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 between the versions of Windows, particularly from the perspective of a forensic analyst. In fact, there are some fairly significant differences between in Windows when service packs, or even just patches, are installed. In some ways, there are significant differences between Windows XP with no service packs installed and XP SP1, SP2, etc.

The differences between Windows versions go beyond just what we see in the graphical user interface (GUI). Some of the changes that occur between versions of Windows affect entire technologies. For example, the Task Scheduler version 1.0 that shipped with Windows XP was 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, and 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 versions of Windows, from Windows 2000 all the way through to Windows 7. 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, is similar between the two versions of Windows. However, there are significant differences between the two versions of Windows 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 (i.e., Start→Search) were recorded in the ACMru key. With Vista, information about searches was moved to a file, and with Windows 7, user searches are now recorded in the WordWheelQuery key.

Other differences in Windows versions are perhaps unintentional. In December 2010, there was a question posted to an online forum asking about the purpose of the Microsoft\ESENT\Process Registry key within the Software hive on a Windows XP system. During the ensuing exchange, various respondents included references to Google searches that indicated that there were some versions of malware that modified the contents of that key. For example, one reference at the ThreatExpert.com site indicated that a Trojan associated with online games modified this key when installed. Ultimately, with the assistance of Troy Larson (senior forensic investigator at Microsoft), it was determined that the key should only exist on Windows XP systems, as Windows XP shipped with a debug or checked build of esent.dll. This indicated that the dynamic link library (DLL) had been compiled to generate additional information for debugging purposes, and then had not been recompiled for production delivery, and the debug version of the DLL was shipped with the operating system installation. In checking the Software hives on several available test systems, as well as within acquired images of Vista, Windows 2003/2008, and Windows 7 systems I had access to, I didn’t find any indication that the key existed on other than Windows XP systems.

Some differences between versions of the Windows operating system can be subtle, while others can be covert and not visible to the casual user or administrator. However, the fact remains that, as a forensic analyst, what you look for (based on your examination goals) and what you see, and how you access and interpret it will be impacted significantly by the version of Windows that you’re examining. Troy Larson has been putting considerable effort toward highlighting many of the new technologies within Windows 7 and identifying possible sources of forensic artifacts, and discussing these areas in presentations. There are a number of other presentations available (via searching) online that discuss similar findings, indicating that there are those, in the forensic community as well as within academia, who feel that it’s important to identify as many of the new potential sources of forensic artifacts or evidence as possible.

Documenting all of the differences between the various versions of Windows would simply be a never-ending task. Throughout the rest of this book, as different topics are discussed, I will attempt to point out the differences between the Windows versions, where this is pertinent to the understanding of the topic. The point, however, is to understand that Windows is not simply Windows, and the version of Windows (XP, Windows 7, 32- or 64-bit, etc.) will have a significant impact on the tools used or the investigative approach used.

Analysis principles

Many times when discussing forensic analysis with other folks, particularly new analysts, it seems that when someone gets into this business, the primary focus of their training (and therefore, their investigative approach) is on tools. So when they’re given an image to analyze, these analysts sit down and the first thought is to open up the commercial forensic analysis application that they’re familiar with or were trained on. However, if you were to take that application away, where would they be? What would they be left with, and what would they be able to do? I ask this, because I have heard analysts state, I need when given an examination.

Many of the principles and concepts discussed throughout the rest of this chapter will likely be familiar to many analysts. You may have seen them in my blog, or you may have heard another analyst or responder discuss them in a presentation at a conference. Chris Pogue’s Sniper Forensics presentations cover many of these ideas; Chris and I worked at IBM together and spent time discussing many of these concepts. I’m presenting the principles again here because they’re important, and I really feel that analysts need to understand them, or at least have a familiarity with them.

Goals

The goals of our analysis are perhaps the most important aspect of what we do. Without having goals for our analysis, we’d likely end up spending weeks or months combing through a few images, finding all manner of potentially bad stuff. But to what end? Analysts and consultants in the private sector most often work under the auspices of a contract that specifies a set number of hours. The same is true for law enforcement examiners, although any limits or constraints are often more of a resource issue than from a contract. Cases are often prioritized by how serious the crime was, or the odds of identifying and successfully prosecuting a suspect; therefore, some cases may not receive a great deal of attention due to being low on the priority list.

When handed a drive image, the first question that should come to every analyst’s mind is, What question am I trying to answer? Locate and identify malware? Locate indications of access to (or attempts to access) specific files? Locate indications of attempts to hide activity? Determine if a user accessed specific web sites or remote computer systems? Without having some kind of concise, achievable goal for analysis, a small stack of hard drives (or images acquired from them) can easily engage an analyst for a significant (perhaps inordinate) amount of time, but to what end? At the end of, say, two weeks of dedicated analysis, what is the final result? What does the report look like, if a report can be written at all? What are the analyst’s findings and conclusions? Without a destination, how do you know when you get there?

As such, find all bad stuff is NOT a goal of forensic analysis. I know of an analyst who acquired an image of a desktop hard drive and was told to find all bad stuff. Accepting that as a goal, the analyst returned to their lab and began analysis, and found quite a bit of bad stuff. However, it turned out that the employee whose system had been imaged was tasked with hacking activities in order to protect the company web site; once that context was added to the examination, it was clear that all of the work that had been done had simply found the tools that the employee used in his