Investigating Windows Systems

Harlan Carvey

• Publisher: Academic Press
• Year: 2018
• ISBN:
  9780128114162
• Topic: Diritto
• Subtopic: Scienza forense

Unlike other books, courses and training that expect an analyst to piece together individual instructions into a cohesive investigation, Investigating Windows Systems provides a walk-through of the analysis process, with descriptions of the thought process and analysis decisions along the way.

Investigating Windows Systems will not address topics which have been covered in other books, but will expect the reader to have some ability to discover the detailed usage of tools and to perform their own research. The focus of this volume is to provide a walk-through of the analysis process, with descriptions of the thought process and the analysis decisions made along the way.

A must-have guide for those in the field of digital forensic analysis and incident response.

• Provides the reader with a detailed walk-through of the analysis process, with decision points along the way, assisting the user in understanding the resulting data
• Coverage will include malware detection, user activity, and how to set up a testing environment
• Written at a beginner to intermediate level for anyone engaging in the field of digital forensic analysis and incident response

Chapter 1

The Analysis Process

Abstract

Forensic analysis is an iterative process; analysts do not take one walk through the data and are then done. Rather, an analyst will start by looking for something, and may find additional items or “pivot points” that take their analysis in a new direction. At the same time, analysts need to be careful to avoid “rabbit holes,” points of interest during analysis that take them off track. Finally, significant value has been demonstrated in developing intelligence from an investigation and “baking it back into” both tools and processes.

Keywords

Analysis; process; documentation; sharing

Chapter Outline

• Introduction 1
• The Analysis Process 2
  • Goals 5
  • Analysis Plan 6
  • Reporting 10
  • Lessons Learned 11
• The Rest of This Book 14

Information In This Chapter

• • The Analysis Process
• • The Rest of This Book

Introduction

There are a number of resources available that talk about the digital forensic analysis of Windows systems, including some books and blogs posts that I have written. There are courses available through community colleges, universities, and online resources that do the same sort of thing. However, most of these resources follow a similar format; that is, data sources or “artifacts” are presented and discussed, often independent of and isolated from the overall “system” itself. After all, a modern computer system is just that…a system of myriad, interacting components that include the hardware, operating system, applications, and user(s). Tools to parse these data sources are illustrated, demonstrated, and discussed. And then…that is it. What is missing from these resources is any discussion of the analyst’s thought processes and decisions; why is a particular data source of interest? What does the data mean, and based on that meaning, what decision path (or paths) does that lead the analyst down? Most (albeit not all) of the available resources put the pieces on the table, and expect the investigator to assemble the puzzle themselves. Few demonstrate to any great degree how those pieces are connected, and how the interpretation of that data answers the goals of the analysis.

I have spent most of my career (after leaving active duty service in the military) in information security as a consultant, and as such, I tend to approach the topic of analysis from that perspective. What that means is that I have had the opportunity in any given month or year to experience different incidents, from different environments, with different goals in mind. While I am not a member of law enforcement, I have assisted law enforcement officers in analyzing and understanding various artifacts. This also means that when I am involved in performing digital forensic analysis as part of an incident response, I have usually operated within a time limit (i.e., a contract specifying a specific number of hours, or a range), and under a specific set of goals (i.e., determine the initial infection vector (IIV), or “how did the malware get on the system”?). This requires a more structured and focused approach to analysis than other environments; a friend of mine was once bouncing some ideas around with me, and started off his description of the situation he was in with, “…I have been looking at this one system for three months.” I cannot say that I have ever operated in an environment or position where I had that kind of time available to look at one system.

My intention in writing this book is to lay out how I would go about analyzing a Windows image, from start (I have an image acquired from a Windows system) to finish (I have completed my analysis). More importantly, I want to share my thought processes along the way, how the data is interpreted, where that data and interpretation leads me, and ultimately how the analysis process provides answers.

The Analysis Process

What is “digital forensic analysis”? When we say, “I did digital forensic analysis,” what does that mean? To be honest, I think it is one of those terms that we use, often without really thinking about what it means. Does it mean that we opened our favorite (or available) commercial or open source application and found a data point? No, it does not. What it does mean is that as analyst, you have applied the wealth of your training, knowledge, and experience (and through a collaboration mechanism, the shared knowledge and experience of others…) to interpret a particular set of data so that someone else can understand what happened, and use that at the basis for making decisions.

The purpose of digital forensic analysis, and hence, an analyst’s job, is to paint a narrative that informs those who need to make critical business (or legal) decisions. This means that you cannot put a bunch of facts or data points “on paper” and expect whoever is reading it (your client) to connect the dots. The analyst’s job is to build an outline and start filling in the picture, addressing the client’s questions and analysis goals. You do this by collecting the available and appropriate data, and then extracting and interpreting those elements or data points that are pertinent to answering the analysis goals or questions. The keys to this, although not the sum total, are to extract all of the relevant and pertinent data points, and to interpret them correctly. Not extracting all or most of the relevant data points will leave gaps in your interpretation, and not interpreting the data correctly will lead to incorrect findings, which in turn will incorrectly inform decision makers.

Does that make sense? If not, allow me to share an example I see quite often, and one that I have seen discussed publicly during conferences. An analyst is interested in answering questions of process execution on a Windows system, and finds a suspicious entry in the AppCompatCache data extracted from the System Registry hive. The analyst incorrectly interprets the time stamp associated with the entry as indicating the date and time that the suspiciously named application was executed; unfortunately, the time stamp is the last modification time extracted from the file system metadata (specifically, from the $STANDARD_INFORMATION attribute within the master file table, or MFT). Not realizing their misunderstanding and subsequent misinterpretation of the data, and also not realizing that the time stamp (within the MFT) is easily modified, the analyst then tells the client that their “window of exposure” or “window of compromise” incorrectly extends back to 2009.

So how is this important? Well, for one, if you have ever done analysis for a payment card industry breach, you know that many organizations that process credit cards have information about how many transactions that they process daily, weekly, or monthly. They maintain this information because it is important (the reasons why are beyond the scope of this book). If they were compromised 6 weeks ago, and you tell them (incorrectly) that they were compromised 3 years ago, that finding significantly impacts the number of potentially compromised credit card numbers, and will tremendously impact the fines that they receive. The same can be said when dealing with other breaches, as well. Incorrect interpretation of data will lead to incorrect findings communicated to the client, who will in turn make decisions based on those incorrect findings.

For me, analysis has always been a process; that is to say, it is not something you do one time, make one pass at the data, and then you are done. It is a series of steps that one follows to get from point A to point B, starting with why we are collecting data in the first place, moving on to the data that is provided and ultimately getting to your findings, or as far as you can get given the data. Some of the steps along the way will have you going back to the data again in an iterative fashion; something you find will lead you to look deeper at some of the data you have, or look for additional data, or move to another artifact all together.

Analyzing an image acquired from a Windows system is not a “one pass” thing. You do not usually start at byte 0, run all the way to the end, and you are done. Similarly, analysis is not a matter of running an automated tool or two, maybe an antivirus scan (or two), and you are done. More often, one finding will lead to another, which will lead to another data source from the image to examine (page file, hibernation file, etc.), and the outline you started with will begin to be filled in as the narrative is being developed.

Using some simple PowerPoint skills, I developed a graphical representation of what “the analysis process” looks like to me; that graphic is illustrated in Fig. 1.1.

Figure 1.1 The analysis process.

As illustrated in Fig. 1.1, the analysis process starts with the goals of the analysis, proceeds to the analysis plan (your plan to “approach” the data), through to the actual analysis (and maintenance of case notes) to reporting and finally, lessons learned. You will also notice that throughout the process there is “documentation.”

I know what you are thinking…documentation. That means I have to write stuff, and writing is hard. Yeah, I get that…in the time I have been part of the tech industry, one of the consistent things I have seen is that technical folks, for the most part, do not like to write.

The purpose of the analysis process, the reason we need to have an analysis process, is to inform further analysis, and to ultimately inform both the development and application of an overall security program. Digital forensic analysis is an often overlooked piece of the incident response (and by extension, threat intelligence) puzzle; however, examination of endpoint systems will often provide us a much more granular picture of the actions taken by an intruder, adversary, or malicious insider. With the appropriate instrumentation of endpoints (i.e., to say, with the right stuff installed on endpoints), we can get a wealth of information about a “bad guy’s” actions that are not available to us through network monitoring or log analysis.

Analysis is very often an iterative process. We will often start with some sort of finding or indicator, use that to develop new information, and “pivot” from there. Then we find something else, and “pivot” again, continuing to build toward the narrative of our findings, addressing the goals of the analysis itself.

The approach I have taken to analyze has always been iterative, adding overlays one (or more) at a time as the picture becomes more clear. The “give me everything” approach has never worked for me, in part because it simply provides too much information, a great deal of which I do not need. Further, the “give me everything” approach tends to not provide everything.

Goals

All examinations have to start somewhere. If you are a consultant (how I have spent the majority of my private sector career), that “somewhere” is most likely a call from a client. If you are in an “internal” position, working as a full-time employee within a company, that “somewhere” maybe the IT director telling you that a system may have been compromised, or perhaps the HR director asking for your assistance with a “violation of acceptable use policy” case. Regardless of your position, or the impetus for the call, all of us can probably agree that there is a discussion that takes place between the analyst and the principal (or client), as the analyst works to develop and determine some background for the examination, understanding what the principal is interested in understanding or demonstrating, with respect to the issue at hand. Very often, this involves the analyst asking questions of the principal and then doing an internal translation of the principal’s responses into the data that the analyst will need in order to best accomplish the task before them.

Most often, this discussion between the analyst and the principal not only informs the need to collect data and helps determine what data should be collected. Are there logs from network devices available? Which systems, and how many, need to be collected? Is it sufficient to collect volatile data from systems, or is a full memory capture and hard drive acquisition required? Is there any network flow data available, or should we consider placing a laptop on a span port on the switch in order to collect pcaps? Some of these questions may be answered directly by the principal, while others will be addressed through the analyst’s own internal dialog.

In most cases, the final phase of this discussion centers around the goals of the analysis to be conducted; what would the principal like the analyst to determine, illustrate, or show? What informs the work that the analyst will ultimately do is the question(s) that the principal would like answered. In some ways, there can be no analysis without some sort of goals; after all, without analysis goals, what will the analyst look at or examine?

Analysis must always start with goals. Goals are the key component of any analysis. Before starting on your analysis, you must have a detailed understanding of what it is you are attempting to show or demonstrate. Having those goals documented and in front of you during your analysis will also keep you focused on the task at hand, which is important to those who have a schedule to meet, or have a purchase order authorizing a specific number of hours for the analysis. Hey, I have been just as guilty of this as the next guy…you are going about your analysis and all of sudden, that little voice in your head goes, “oh, my, that is interesting…” …although in my case, it is been more like “LOOKASQUIRREL!!” At that point you are going down a rabbit hole that just seems to have no end, and it takes a call (or scream) of nature to bring you back to the real world.

When working with the principal (or client), it is a good idea to remember that very often, they are relying on your expertise as an analyst to help guide them with respect to goals that are achievable. They have their concerns and issues that they have to address, they have business decisions they need to make, and they have someone to whom they have to answer. As such, as analysts, it is our job to do more than simply take what they say and run with it; we need to set their expectations with respect to what can be achieved given the available data, as well as the time frame in which that can be achieved. We need to work with the principal to develop goals that make sense, are something ...