Journey Into Incident Response

By failing to prepare, you are preparing to fail.

~ Benjamin Franklin

In many ways preparation is key to success. Look at any sporting event and the team who usually comes out on top are the ones who are better prepared. I'm not just referring to game day; I'm also talking about the coaching schemes and building a roster. Preparation is a significant factor to one's success in the Digital Forensic and Incident Response field. This applies to the entire field and not just malware forensics, which is the focus of this post. When you are confronted with a system potentially impacted with malware your ability to investigate the system successfully depends on your knowledge, experience, and toolset.  This is where there is a conundrum. There is a tendency for people not to do malware cases (either through being hired or within an organization) due to a lack of knowledge and experience but people are unable to gain knowledge and experience without working malware cases. The solution is through careful preparation one can acquire knowledge, experience, and toolset that can eventual lead to working malware cases. This post outlines the process I used and currently use to improve my malware forensics skills.

The process described in this post helped me to develop the skills I have today. I even use a similar process to create test systems to help develop malware forensic skills in others (if you read this blog then you have already seen the benefits of doing this). With that said, what I am describing is a very time consuming process. However, if you decide to replicate the path I took it will be worth it and along the way you'll improve your malware forensic skills. This post is specifically directed at those wanting to take this step using their own resources and time. Those wanting to lose themselves in the DFIR music.

Process, Process, Process

Malware forensics is the process of examining a system to: find malicious code, determine how it got there, and what changes it caused on system. The first place to start for improving one's skills is by exploring the process one should use. The purpose of starting with the process is twofold. First and foremost it is to understand the techniques, examination steps, and knowing what to look for. The second reason is to explore the various tools to use to carry out the process. There are only a few resources available specific to this craft such as: Malware Forensics Field Guide for Windows Systems and Windows Forensic Analysis Toolkit, Fourth Edition. In addition, this has been an area on my radar to add one more book to the discussion but in the meantime my jIIr methodology page outlines my process and links to various posts. My suggestion is to first review the methodology I put together which is further explained in the posts: Overall DF Investigation Process and End to End Digital Investigation. Afterwards, review one or two of the books I mentioned. As you work your way through this material pay attention to the malware forensic process the author uses or references.

When it is all said and done and you completed reviewing what you set out to then document a malware forensic process you want to use. If this sounds familiar then you either started reading jIIr from the beginning or you are one of my early followers. This is exactly what I described in my second and third posts Where to start? and Initial Examination Steps & First Challenge that I wrote almost four years ago. However, a lot of time has passed since I wrote those posts and I improved my process as outlined below:

     - Examine the master boot record
     - Obtain information about the operating system and its configuration
     - Examine the volatile data
     - Examine the files on the system that were identified in volatile data
     - Hash the files on the system
     - Examine the programs ran on the system
     - Examine the auto-start locations
     - Examine the host-based logs
     - Examine file system artifacts
     - Malware searches
     - Perform a timeline analysis
     - Examine web browsing history
     - Examine specific artifacts
     - Perform a keyword search
     - Examine suspected malicious files

Tools, Tools, Tools

After the process you want to use is documented then the next step is to identify the tools you will use in each examination step. There are numerous tools you can use; the tools mentioned by the authors in the reference material, tools talked about the bloggers in my blog roll, or tools you already have experience with. To be honest, what tools someone should use depends. It really depends on what you prefer and are comfortable with. The tools I started out with are not the same ones I use today; the important thing is each tool helped me learn and grow. Pick any tools you want as a starting point and over time you will start to see the pros and cons of various tools.

Testing Environment

With your process and tools selected, now it is finally time to stop the researching/documenting and to actually use the process you documented and tools you selected. To do this you first have to set up a testing environment. There is an inherit risk to using virtualization for the testing environment; the malware may be virtualization aware and behave differently than on real computer. However, despite this risk I highly recommend to use virtualization as your testing environment. It's a lot faster to create multiple test systems (by copying virtual machines) and the snapshot feature makes it easier to revert mistakes. There are various virtualization options available with great documentation such as VirtualBox and VMware. Pick a virtualization platform and install it using the provided instructions.

Creating your VMs

Another decision you'll need to make is what operating systems to perform your testing on. This not only includes the operating system versions (i.e. Windows 7 vs Windows 8) but what processor to use as well (32 bit vs 64 bit). I ended up selecting VMware for the virtualization software and Windows 7 32 bit as the testing platform. You will need to create your first VM by installing the operating system of your choice. After the installation try to make things easier for the system to be compromised.

First disabled security features. This includes the built-in firewall and the user account control. Next make sure the account you are using has administrative privileges. Next you will want to make your test system a very juicy target. To do this you'll need to install vulnerable client-side applications including: Adobe flash, Adobe Reader, Java, Silverlight, Microsoft Office, Internet Explorer, and a non-patched operating system. One place to grab these applications is Old Apps and to determine what versions to install pick the ones targeted by exploit kits. At a minimum, make sure you don't patch the OS and install Java, Silverlight, Adobe reader, and Adobe flash. This will make your VM a very juicy target.

After the VM is created and configured then you'll want to make multiple copies of it. Using copies makes things easier during analysis without having to deal with snapshots.

Manually Infecting Systems

The first approach to improving your skills is a manual method to help show the basics. The purpose is to familiarize yourself with the artifacts associated with malware executing in the operating system you picked. These artifacts are key to be successful in performing malware forensics on a compromise system. The manual method involves you infecting your test VM and then analyzing it to identify the artifacts. The manual method consists of two parts: using known and unknown samples.

However, before proceeding there is very important configuration change. The virtual machine's network configuration needs to be isolated to prevent the malware from calling home or attacking other systems.

Using Known (to you) Samples

Starting out it is better to practice with a sample that is known. By known I mean documented so that you can reference the documentation in order to help determine what the malware did. Again, we are trying to improve our ability to investigate a system potentially impacted with malware and not trying to reverse the malware. The documentation is just to help you account for what the malware did to make it easier to spot the other artifacts associated with the malware running in the operating system.

The way to find known samples really depends. You could find them using information on antivirus websites since they list reports using their malware naming convention. For example, Symantec's Threat Listing, Symantec's Response blog, Microsoft's Threat Reports, or Microsoft's Malware Encyclopedia to name a few. These are only a few but there are a lot more out there; just look at antivirus websites. The key is to find malware with a specific name that you can search on such as Microsoft's Backdoor:Win32/Bergat.B. Once you find one you like then review the technical information to see the changes the malware makes.

I suggested finding known malware by names first because there are more options to do this. A better route if you can find it is to use a hash of a known malware sample. Some websites share the hash of the sample they are discussing but this doesn't occur frequently. A few examples are: Contagio Malware Dump, KernelMode.info, or MxLab blog. Another option is to look at the public sandboxes for samples that people submitted such as Joe Sandbox or one listed on Lenny Zelster's automated malware analysis services list.

After you pick a malware name or hash to use then the next step is to actually find the malware. Lenny Zelster has another great list outlining different malware sample sources for researchers. Anyone one of these could be used; it just needs the ability to search by detection name or hash. I had great success using: VirusShare, Open Malware, Contagio Malware Dump, and KernelMode.info.

Remember the purpose of going through all of this is to improve your malware forensic skills and not your malware analysis skills. We are trying to find malware and determine how the infection happened; not reversing malware to determine its functionality. Now that you have your sample just infect your virtual machine (VM) with it and then power it down. If the VM  has any snapshots then delete them to make it easier.

Now that you have an infected image (i.e. the vmdk file) you can analyze it using the process you outlined and the tools you selected. At this point you are making sure the process and tools work for you. You are also looking to explore the artifacts created during the infection. You know the behavior of the known malware so don't focus on this. Malware is different and so will be their artifacts. Focus on the artifacts created by a program executing in the operating system you selected. Artifacts such as program execution, logs, and file system.

Using Unknown (to you) Samples

Using a known sample is helpful to get your feet wet but it gets old pretty quick. After you used a few different known samples it is not as challenging to find the artifacts. This is where you take the next step by using an unknown (to you) sample. Just download a random sample from one of the sources listed at malware sample sources for researchers.  Infect your virtual machine (VM) with it and then power it down. If the VM  has any snapshots then delete them to make it easier.

Now you can start your examination using the same process and tools you used with a known malware sample. This method makes it a little more challenging because you don't know what the malware did to the operating system.

Automatically Infecting Systems

The manual method is an excellent way to explore the malware forensic process. It allows you to get familiar with an examination process, tools, and artifacts associated with an infection. One important aspect about performing malware forensics is to identify the initial infection vector which was used to compromise the system in the first place. The manual method infections always trace back to you executing malware samples so you need to use a different method. This method is automatically infecting systems to simulate how real infections appear.

Before proceeding there is a very important configuration change. The virtual machine's network configuration needs to be connected to the Internet. This can be done through the NAT or bridged configuration but you will want to be in a controlled environment (aka not your company's production network). There are some risks with doing this so you will need to take that into consideration. Personally, I accept this risk since improving my skills to help protect organizations is worth the trade off.

Using Known Websites Serving Malware

In the automatically infecting systems approach the first method is to use a known website serving malware. There are different ways to identify these websites. I typically start by referring to Scumware.org (FYI, site hates Internet Explorer), Malc0de database, and the Malware Domain List. In both instances I look for URLs that point to a malicious binary. Other sources you can use are the ones listed by Lenny Zelster on his Blocklists of Suspected Malicious IPs and URLs page. Again, you are trying to find a URL to a site hosting a malicious binary. Another, source you shouldn't overlook is your email SPAM/Junk folder. I have found some nice emails with either malicious attachments or malicious links. Lastly, if you pay attention to the current trends being used to spread malware then you can found malicious sites leveraging what you read and Google. This is a bit harder to pull off but it's worth it since you see a technique currently being used in attacks.

Inside your VM open a web browser, enter in the URL you identified, and if necessary click any required buttons to execute the binary. Wait a minute or two for the malware to run and then power it down. If the VM  has any snapshots then delete them to make it easier.

Now you can start your examination using the same process and tools you used with the manual approach. The purpose is to find the malware, artifacts associated with the infection, and the initial infection vector. Infecting a VM in this manner simulates a social engineering attack where a user is tricked into infecting themselves. If a SPAM email was used then it simulates a email based attack.

To see how beneficial this method is for creating test images to analyze you can check out my posts Examining IRS Notification Letter SPAM and Coming To A System Near You. The first post simulates a phishing email while the later simulates social engineering through Google image search.

Using Potentially Malicious Websites

The second method in the automatically infecting systems approach is to use potentially malicious websites. This method tries to infect the VM through software vulnerabilities present in either the operating system or installed client-side applications. This is the most time consuming out of all of the methods I described in this post. It's pretty hard to infect a VM on purpose so you will end up going through numerous URLs before hitting one that works. This is where you may need to use the VM snapshot feature.

To find potentially malicious URLs you can look at the Malware Domain List. Look for any URLs from the current or previous day that are described as exploit or exploit kit as shown below. You can ignore the older URLs since they are most likely no longer active.

Another option I recently discovered but haven't tried yet is using information posted at Malware-Traffic-Analysis.net. The site doesn't obfuscate websites used so you may be able to use it to find active websites serving up exploits. The last option I'm sharing is the one I use the most; the URLs others are submitting to URLQuery.net. Just keep in mind, there are certain things that can't be unseen and there are some really screwed up people submitting stuff to URLQuery. When reviewing the submitted URLs you want to pay attention to those that have detections as shown below:


After you see a URL with detections then you'll need to examine it closer by reviewing the URLQuery report. To save yourself time, focus on any URLs whose reports mention: malicious iframes, exploits, exploit kits, or names of exploit kits. These are the better candidates to infect your VM. The pictures below show what I am referring to.






Before proceeding make sure your VM is powered on and you created a snapshot. The snapshot comes in handy when you want to start with a clean slate after visiting numerous URLs with no infection. An easy way to determine if an infection occurred is to monitor the program execution artifacts. One way I do this is by opening the C:\Windows\Prefetch folder with the items sorted by last modification time. If an infection occurs then prefetch files are modified which lets me know. Now you can open a web browser inside your VM, enter in the URL you identified, and monitor the program execution artifacts (i.e. prefetch files). If nothing happens then move on to the next URL. Continue going through URLs until one successfully exploits your VM. Upon infection wait a minute or two for the malware to run and then power it down. Make sure you delete any snapshots to make it easier.

Now you can start your examination using the same process and tools you have been using. The purpose is to find the malware, artifacts associated with the infection, and the initial infection vector. The initial infection vector will be a bit of a challenge since your VM has various vulnerable programs. Infecting a VM in this manner simulates a drive-by which is a common attack vector used to load malware onto a system. To see how beneficial this method is for creating test images you can check out my post Mr Silverlight Drive-by Meet Volatility Timelines (FYI, I suspended the VM to capture the vmem file in addition instead to powering it down to get the disk image).

Summary

Benjamin Franklin said "by failing to prepare, you are preparing to fail." To be successful when confronted with a system potentially impacted with malware we should be preparing for this moment now. Taking the time to improve our malware forensic skills including our process, tools, and knowledge of artifacts. Making the right preparations so when game day approaches we will come out on top. The process I use to improve my malware forensic skills and the one I described in this post is not for everyone. It takes time and a lot of work; I've spent countless days working through it. However, working your way through this process you will attain something that can't be bought with money. There is no book, training, college course, or workshop that can replicate or replace the skills, knowledge, and experience you gain through careful preparation by training yourself.

Computer users are confronted with a reoccurring issue every day. This happens regardless if the user is an employee doing work for their company or a person doing online shopping trying to catch the holiday sales. The user is using their computer and the next thing they know it is infected with malware. Then someone gets tasked with resolving the malware issue and one of the first things they need to do is to find the malware. This is a common occurrence that plays out every day to anyone who either uses a computer or is responsible for protecting a network. How the malware gets found depends on the person. Some fire off antivirus scanners, others examine memory, some follow a documented process, and others are not sure where to start. I've talked about my detailed process numerous times and I even shared one of my triage techniques last year. Regardless of the process used, there is one examination step that stands above the rest in locating malware on a system. This step is examining the program execution artifacts.

What Malware Indicators to Look For

As the name implies program execution artifacts show what programs executed on a system and at times what programs were present on the system. The significance of knowing what programs ran can be seen in my corollary to the Rootkit Paradox:

      1. They need to run
      2. They want to remain hidden

Malware wants to remain hidden on a system so it can accomplish what it was designed to do. However, in order for malware to hide on a system a program has to run. This program executes to either hide itself or another piece of malware; in the process it will leave artifacts on the system. These artifacts - program execution artifacts - can be used to find where the malware is hidden. Below are the malware indicators to look for as the program execution artifacts are reviewed (my post Triaging Malware Incidents shows how to use these indicators for triaging).

      - Programs executing from temporary or cache folders
      - Programs executing from user profiles (AppData, Roaming, Local, etc)
      - Programs executing from C:\ProgramData or All Users profile
      - Programs executing from C:\RECYCLER
      - Programs stored as Alternate Data Streams (i.e. C:\Windows\System32:svchost.exe)
      - Programs with random and unusual file names
      - Windows programs located in wrong folders (i.e. C:\Windows\svchost.exe)
      - Other activity on the system around suspicious files

Program Execution Artifacts

Program execution artifacts have been well documented over the years. For example, Harlan put together a post explaining how to determine what programs executed on a system. The key to finding malware is to look for the above indicators in the program execution artifacts and to review all of the artifacts since each one provides different information. To illustrate why the reviewing program execution artifacts examination step stands above the rest I'll walk through the step against a system I infected with malware.

Parsing Program Execution Artifacts

The purpose of this post is to show how just the program execution artifacts can reveal malware on a system as opposed to the tools one should use. However, for completeness I'm sharing the tools I use to parse these artifacts. I use the autorip script along with RegRipper to parse the majority of the artifacts and Nirsoft Winprefetchview to parse the prefetch files.

RecentFileCache.bcf File

The first artifact to review on Windows 7 systems is the recentfilecach.bcf file. This file shows programs that executed on a system and the majority of the time these programs are new to the system. The programs listed here executed recently; within the last 24 hours or when the ProgramDataUpdater task last ran. The RecentFileCache.bcf on my test system showed the following:

c:\program files\common files\java\java update\jusched.exe
c:\users\lab\appdata\local\microsoft\windows\temporary internet files\content.ie5\i87xk24w\n6up2014[1].com
c:\program files\common files\java\java update\jucheck.exe

The one program that stands out is the n6up2014[1].com program since it's located in the temporary Internet files folder.

Prefetch Files

The next artifact to review to identify malware quickly on a system are the Windows prefetch files. Prefetch files show a wealth of information: program's file path, last run time, run count, and files accessed during start-up. Furthermore, the prefetch file's creation date can indicate when the program first ran. Sorting the parsed prefetch files on my test system by the program's file path makes it easier to spot malware. The image below illustrates this.


Similar to the RecentFileCache.bcf, the first malware indication is a randomly named program (n6up2014[1].com) executing from a temporary folder in a user profile. The n6up2014[1].com prefetch file also provides the time of interest to help locate other malware which is 01/10/14 00:38:25 UTC. Prefetch files contain references to the files accessed during start-up and these references can point to other malware. The image below highlights the winupdates.exe program referenced in the n6up2014[1].com prefetch file.


The winupdates.exe program is suspicious since it's a program that executed from the users profile. Also, the winupdates.exe zone.identifier alternate data stream indicates the program was downloaded from a different security zone (the Internet). Furthermore, the program executed around the same time as the n6up2014[1].com program. Sorting prefetch files by last modification is a fast and simple method to find other malware on the system. The image below shows the prefetch files sorted by last modification time.


The image above didn't highlight any other potential malware but it does reveal the netsh.exe program executed around the same time as the malware. netsh.exe is a program to "administrator can use to configure and monitor Windows-based computers at a command prompt."

AppCompatCache Registry Key

The next artifact to review to identify malware on a system is the AppCompatCache registry key located in the System hive. Mandiant highlighted the significance of this artifact in their article "Leveraging the Application Compatibility Cache in Forensic Investigations." This article not only shows executables that executed on the system but it also shows executables which were present on the system. The AppCompatCache key from my test system also showed the same suspicious programs with malware indicators.

UserAssist Registry Key

Continuing on with the examination the next artifact to review is the userassist registry key located in the user account's NTUSER.DAT hive. This registry key sheds light on "what programs the user has launched via the Explorer shell." The image below shows the portion of the userassist registry key for the user account where the suspicious programs were located and the timeframe of when they executed.


As can be seen, the image doesn't reveal other malware but it does show the user executed their web browser prior to the infection. This information about the potential source of the malware isn't a surprise since the n6up2014[1].com file was located in the temporary Internet files folder and the winupdates.exe had a zone.identifier alternate data stream.

MUICache Registry Key

Continuing on with the examination is reviewing the muicache registry key located in the user account's NTUSER.DAT (for Windows XP) or UsrClass.dat (for Windows 7) hive. The muicache shows programs that ran under the context of the user account and is another area to look for malware indicators. The muicache from my test system didn't reveal any useful information as shown below.

AppCompatFlags Registry Key

The search for malware indicators should continue by reviewing the AppCompatFlags registry key. This artifact contains information about program execution and is more relevant for Windows 8 systems compared to Windows 7. This registry key hasn't been created on my Windows 7 test system as shown below.

Tracing Registry Key

It may be tempting to stop the examination and follow up on the programs already identified but doing so may result in overlooking other malware. The next artifact to review is the tracing registry key located in the System hive. This key may contain program execution for programs with networking capabilities. The tracing registry key from my test system didn't reveal any useful information as shown below.

Legacy Registry Keys

The last program execution artifact to review is the legacy registry keys located in the System hive. These keys can be helpful to locate malware which installs itself as a Windows service. The legacy registry keys from my test system didn't reveal any useful information as shown below (notice the lack of entries for my timeframe of interest).

Wrapping Things Up

Solely focusing on examining the program execution artifacts identified malware on the test system. Specifically, the following malware was identified:

C:\Users\lab\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\I87XK24W\n6up2014[1].com
C:\Users\lab\AppData\Roaming\winupdates.exe

In addition to locating malware it was also determined the netsh.exe program executed around the same time as the infection. The activity identified in the program execution artifacts matches the activity observed when analyzing the n6up2014[1].com program. n6up2014[1].com creates on the system and executes the winupdates.exe program while netsh.exe is used to modify the Windows firewall.

Knowing the information discovered by reviewing program execution artifacts will empower anyone who is tasked with resolving a malware issue. This is the same technique I have been using for years to find malware on systems extremely fast. Normally I can find malware in minutes; in less than 10 minutes. This is why I stand by my comment examining program execution artifacts stands above the rest of the examination steps in locating malware on a system. This is why my response to anyone asking for help in locating malware is to start by examining the program execution artifacts.

The Overall Digital Forensic Investigation Process post outlined the various phases involved with the investigation process. These phases were: preparation, identification, collection, analysis, reporting, and archiving. There was one issue with this basic overall process that comes to light when an investigation involves a network.

If an investigation is to determine if a person accessed a file on their computer the overall process matches up pretty well. The identification only involves one person, the collection is only a single computer, and the analysis only involves data from one data source which is the computer. The only thing missing is how to organize your evidence so your conclusion can be tested. The previous example is a pretty straight forward investigation but now let's see what happens when a network becomes involved. What if the investigation is to determine if a person accessed a file on a server within an organization? How about if the investigation is to determine if a person accessed a file on a Internet web server? The addition of a network results in the addition of data sources which could potentially store evidence. The data sources can now include servers (proxy servers, Windows domain controllers, or file and print servers), network logs (web server logs, router logs, or firewall logs), or captured network traffic. The basic overall process doesn't cover how to identify these data sources, examine these data sources, how to combine the evidence from different data sources, or how to organize your evidence for analysis.

I noticed the limitation of the basic overall process on my cases which involved multiple subjects, multiple computers, multiple servers, etc. The scenario of a malware infection I have been using made the limitation even worse because this could involve one, 10, 20, or 500 computers across a network. I needed a scalable and repeated process that I could use for the identification, collection, and analysis of information in a networked environment regardless of the type of case (security incident, audit, policy violation, etc.). This is where Dr. Stephenson's End to End Digital Investigation (EEDI) framework comes into play. Not only does EEDI meet the needs I was looking for but it didn't require any significant changes from what I was currently doing because it is just a different way to approach the investigation.

I know I can't do an adequate job of explaining EEDI compared to Dr. Stephenson which is why I am quoting his articles when discussing the framework. If you want to know more about EEDI then I would recommend you read one of his articles. Currently, there is limited information about EEDI on the Internet but I was able to locate a brief article which can be found here.

What is the EEDI

The premise of the framework takes into count that "every digital crime has a source point, a destination point and a path between those two points" (Stephenson, Getting the Whole Picture, 2002, 2003). This means EEDI takes into account the source of the incident, destination of the incident, and all the intermediate devices along the path through the network. EEDI is a "structured method of collecting evidence along the entire path from source to target, using each piece of evidence in that chain to corroborate other evidence (either digitally or traditionally developed) and an approach to presenting the completed chain effectively in court"(Stephenson, Getting the Whole Picture, 2002, 2003).

The EEDI process consists of the following nine activities:

* Collecting evidence
* Analysis of individual events
* Preliminary correlation
* Event normalization
* Event deconfliction
* Second level correlation
* Timeline analysis
* Chain of evidence construction
* Corroboration

Collecting Evidence

EEDI helped me with the issue I was having during the Identification and Collection phases. This issue was scoping an investigation to determine the systems involved and the data sources with potential evidentiary items. I have found the approach of viewing each case as having a source point, destination point, and a path between them to be effective when identifying the scope of an investigation. Take the previous example of a person accessing a file. The source point is the computer the person is using, the destination point is the computer storing the file being accessed, and the path is the network between those two computers. Following this path can help you identify the data sources with potential evidentiary items which needs to be collected.

Analysis of Individual Events

"This analysis step examines isolated events and assesses what value they may have to the overall investigation and how they may tie into each other" (Stephenson, Cyber Investigation, 2009). EEDI is framework to investigate security incidents so this activity's focus is on the examination of each event in a security incident. I had to modify this activity so it would accommodate any type of investigation from security incidents to policy violations to financial audits.

The first change I made was to change the purpose of the activity to be the analysis of individual events or individual case. This slight change enables an investigation to be performed into other types of cases which don't fall into the security incident category. The second change was to incorporate the examination of digital data to locate evidence which may be relevant to the investigation. I decided to organize the examination based on the data sources being examined. Two potential data sources are network logs and a computer's hard drive. This organization allowed me to examine each data source individually. The last change was to incorporate the various examination steps under each data source. The example below shows a few examination steps for examining a computer's hard drive:

* Analysis of individual events (or individual case)
     * System examination
         * Examination of volatile data
         * Hash the files on the system
         * Search for known malware

Basically, the changes I made were to incorporate all of my existing examination steps into this EEDI activity. This means there was hardly any change from the way I was currently performing examinations and the only difference is how I organized any found evidence.

Preliminary correlation

The "first correlation step is to examine the individual events and see how they may correlate into a chain of evidence"(Stephenson, Getting the Whole Picture, 2002, 2003). The "main purpose here is to understand in broad terms what happened, what systems or devices were involved and when the events occurred"(Stephenson, Getting the Whole Picture, 2002, 2003).

The slight change I made in the analysis of individual events trickles down into this activity. All of the evidence located through the examination of the various data sources is correlated into a chain of evidence. The chain of evidence provides an overview of the evidence in your investigation.

Event Normalizing

The definition of normalization is the "combining evidentiary data of the same type from different sources with different vocabularies into a single, integrated terminology that can be used effectively in the correlation process" (Stephenson, Cyber Investigation, 2009). One example of normalization is adjusting the times in order to take into account the time differences between data sources. All of the times should be normalized into a single time. For example, if there were two computers with different times then the time stamps of the evidence from one computer should be adjusted to the time of the other computer.

Event Deconfliction

The definition of deconfliction is the "combining of multiple reportings of the same evidentiary event by the same or different reporting sources, into a single, reported, normalized evidentiary event" (Stephenson, Cyber Investigation, 2009). This activity is required when an item is reported multiple times from the same source. The one example I have come across when this was required involved emails. During an email examination, I will review emails located on the email server, the person's email file, and any backup copies of the person's email file on their computer. Sometimes this results in multiple copies of the same email being found. All of the copies of the email doesn't have to be in the chain of evidence since only one email is required.

Second-Level Correlation

"Second-level correlation is an extension of earlier correlation efforts. However, at this point, views of various events have been refined through normalization or deconfliction" (Stephenson, Cyber Investigation, 2009).

Timeline Analysis

"In this step, normalized and deconflicted events are used to build a timeline using an iterative process that should be updated constantly as the investigation continues to develop new evidence" (Stephenson, Cyber Investigation, 2009).

Chain of Evidence Construction

The evidence in the timeline should be used to form a chain of evidence. "Ideally, each link in the chain, supported by one or more pieces of evidence, will lead to the next link" (Stephenson, Cyber Investigation, 2009). When it is not possible to establish a direct link between evidence a lead can be used to point to the next piece of evidence. "Leads can point us to valid evidence and that valid evidence can, at some point, become the evidence link" (Stephenson, Cyber Investigation, 2009). I briefly touched on this topic in an earlier post titled Broken Chain.

Corroboration

In this step, "we attempt to corroborate each piece of evidence and each event in our chain with other, independent evidence or events" (Stephenson, Cyber Investigation, 2009). This final "evidence chain consists of primary evidence corroborated by additional secondary evidence" (Stephenson, Cyber Investigation, 2009).

To date, the majority of my digital forensic examinations are in support of an investigation being conducted by a group outside of the forensic unit. For example, the human resource department may be conducting an investigation of an employee violating company policy and asks for a forensic analysis to help their investigation. This results in the majority of the corroboration of primary evidence with the secondary evidence being conducted by the persons performing the investigation. However, there is still some secondary evidence which can be collaborated such as information obtained through research.

Conclusion

The EEDI framework combined with the overall digital forensic investigation process provided me with a flexible, scalable, and repeatable investigation process. This process could be used regardless if someone drops off a hard drive asking you to find how it became infected, if an audit team needs assistance investigating a suspected fraud involving multiple people with multiple data sources, or if a malware outbreak is affecting 50 computers on a network. All of these scenarios would require a cyber investigation and I wanted a process which could be used for any type investigation. At this point in my journey I feel that I have found this process.

To see how the cyber investigation methodology looks with the steps for a system examination can be located on the Journey into IR methodology page.



References

As I mentioned previously, one of Dr. Stephenson's articles titled A Comprehensive Approach to Digital Incident Investigation can be located here.

Stephenson, P. (2009). Cyber Investigation. In S. Bosworth, M. Kabay, & E. Whyne, Computer Security Handbook (pp. 55.1 - 55.27). Hoboken: John Wiley & Sons, Inc.

Stephenson, P. (2002, 2003). Getting the Whole Picture A Series of 12 Columns End to End Digital Investigation Appearing in Elsevier Advanced Technology's "Computer Fraud and Security" Publication in 2002 and 2003. Retrieved from Web Site of Peter Stephenson: Document is no longer hosted on Dr. Stephenson's webpage

In order to paint an accurate picture of how I started my journey, my next two posts will be about overall digital forensic (DF) investigation process. Technically these should have been the first two posts but I decided to discuss the examination steps and the testing I did last spring first in order to share information which was relevant to a few discussions at the time. After these two posts are completed then I will finally be caught up to where I currently am in my journey.

The majority of the time when you encounter something new one of the first things you should try to do is understand the overall process. If you want to plant a garden you don't just dig a hole in your yard, throw in some seeds, and hope for the best. If you want to learn how to fish you don't buy fishing equipment at a local store then go to the closest body of water to toss the equipment in. These approaches may result in some of the plants growing or catching a fish after the fishing pole knocked it unconscious but most likely the majority of the time these approaches will fail. The reason for this is because both approaches just tried to wing it instead of first trying to understand the overall process.

What does this have to do with investigating a security incident? When I approached this topic I started by trying to understand the overall DF investigation process prior to the complexities of the investigation such as the various examination steps, tools, techniques, or test systems. My goal was to have a repeatable investigation process which would provide consistent results instead of occasionally being lucky by winging it. To accomplish this goal I started with understanding the different phases, including their purposes, of the DF investigation process. i think the various activities within these phases are critical to understand but my focus in this post is just on the phases.

There are different models outlining the phases of the DF process with three of them being the DFRWS Framework, NIST Guide to Integrating Forensic Techniques into Incident Response, and Building a Digital Forensic Laboratory book. These models also discuss the various activities which can occur within these phases such as case management, evidence management, chain of custody, and documentation.

In 2001, the Digital Forensic Research Workshop (DFRWS) released the Investigation Process for Digital Forensic Science (A Road Map for Digital Forensic Research, 2001). The image below outlines the phases of this investigation process.


In 2006, the National Institute of Standards and Technology (NIST) released the special publication 800-86 Guide to Integrating Forensic Techniques into Incident Response (Kent, Chevalier, Grance, & Dang, 2006). The image below outlines the phases of this investigation process.


In 2009, Elsevier, Inc released the book Building a Digital Forensic Laboratory. This book discussed the phases of the investigation process which is shown below (Jones & Valli, 2009).


As can be seen in the pictures above, there are similarities between all three investigation processes (actually two of the processes are similar to the DFRWS process). The picture below shows the phases of the investigation process I decided use (note: the phases below were created using a combination of the references used in this post, my past experience processing cases, and conversations with a colleague who helped me understand the overall process when I first started in this field).


As you can see the phases above are nothing new and basically just a reorganization of the phases in the models I briefly discussed. The following are brief descriptions about these phases:

The Preparation phase covers all of the activities which would occur before you are working on a case. This would include the activities for preserving evidence and to establish guidelines on how to manage evidence (Jones & Valli, 2009). These guidelines can help ensure evidence is preserved throughout the entire investigation process.  This phase would also cover other activities such as staff training, staff recruitment, tool validation, and quality assurance measures.

The Identification phase is when there's a request for a DF investigation. In my past experience, DF has been more of a service which supports other business processes. This means a request by a customer starts the investigation process. This phase involves understanding the purpose of the request and the scope of the investigation such as type of case, subjects involved, and systems involved.

The Collection phase is when the identification and collection of any items that could be of evidential value occurs (Jones & Valli, 2009). This could include digital content such as hard drives and removable media but it can also include other types of information such as interviews and observations.

The Analysis phase includes the examination and analysis of the information. The examination is to identify evidence in the data which may be relevant to the case while the analysis is to analyze the evidence collected, identified, and extracted to develop a set of conclusions (Stephenson, 2009). The analysis would also include testing those conclusions to ensure they are valid.

The Reporting phase is when the evidence and your conclusion are presented to the person or group requesting the DF investigation.

The Archival phase is the management of the long term storage of the case materials including the evidence once the case has been closed.

My journey has initially focused on the Identification, Collection, and Analysis phases. The scenario I decided to use was a malware infection then I realized the potential complexity of this scenario in a networked environment. It could be one system or 100 systems. Potential sources of evidence could be servers, clients, network logs, or removable media. The infection vector could be email, network shares, or the Internet. I think you can see the picture of this complexity and I wanted to know how to approach this type of investigation during the Identification, Collection, and Analysis phases.

This is where Dr. Stephenson's End to End Digital Investigation (EEDI) framework comes into the picture. My next post will explain why I needed EEDI, how EEDI works, how EEDI can help test your conclusions, and the benefits of EEDI for the investigation process.


References

A Road Map for Digital Forensic Research. (2001, August 7-8). Retrieved from DFRWS 2011[banner]: http://www.dfrws.org/2001/dfrws-rm-final.pdf

Jones, A., & Valli, C. (2009). Building a Digital Forensic Laboratory Establishing and Managing a Successful Facility. Burlington: Elsevier, Inc.

Kent, K., Chevalier, S., Grance, T., & Dang, H. (2006, August). Guide to Integrating Forensic Techniques into Incident Response. Retrieved from National Institute of Standards and Technology: http://csrc.nist.gov/publications/nistpubs/800-86/SP800-86.pdf

Stephenson, P. (2009). Cyber Investigation. In S. Bosworth, M. Kabay, & E. Whyne, Computer Security Handbook (pp. 55.1 - 55.27). Hoboken: John Wiley & Sons, Inc.