Journey Into Incident Response

Change is one of the only constants in incident response. In time most things will change; technology, tools, processes, and techniques all eventually change. The change is not only limited to the things we rely on to be the last line of defense for our organizations and/or customers. The threats we are protecting them against change too. One recent example is the Angler exploit kit incorporating fileless malware. Malware that never hits the hard drive is not new but this change is pretty significant. An exploit kit is using the technique so the impact is more far reaching than the previous instances where fileless malware has been used (to my knowledge.) In this post I'm walking through the process one can use to triage a system potentially impacted by fileless malware. The post is focused on Poweliks but the process applies to any fileless malware.

Background on Why This Matters

In my RSS feeds, I was following the various articles about how an exploit kit incorporated the use of fileless malware. The malware never gets dropped to the disk and gets loaded directly into memory. A few of the articles I'm referring to are: Poweliks: The file-less little malware that could, Angler EK : now capable of "fileless" infection (memory malware), Fileless Infections from Exploit Kit: An Overview, POWELIKS: Malware Hides In Windows Registry, and POWELIKS Levels Up With New Autostart Mechanism. Reading the articles made one thing clear: one of the most effective tools to deliver malware (exploit kits) is now using malware that stays in memory.

This change has a significant impact on multiple areas. If the malware stays in memory then the typically artifacts we see on the host will not be there. For example, when the malware is loaded into memory then it won't create program execution artifacts on the system. This means the triage and examination process needs to adjust. As I mentioned previously, this change was implemented into a widely known exploit kit (Angler exploit kit.) The systems infected with this exploit kit can be far reaching. This means we will encounter this change sooner rather than later; if you haven't faced it already. Case in point, recently the Internet Systems Consortium website was compromised and was redirecting visitors to the Angler exploit kit. The last impact is if this change provides better results for the people behind it then I can see other exploit kit authors following suit. This means fileless malware may become even more widespread and it's something that is here to stay.

I knew memory forensics is one technique we can use to find the malware in memory. (if you need a great reference on how to do this check out the book the Art of Memory Forensics.) However, the question remained what does this look like. I took the short route for a quick answer to my question by reaching out to my Twitter followers. I asked them the following: "Anyone know how Poweliks code looks from memory forensics perspective?"

The first responses I got back was from Adam over at the Hexacron blog (great blog by the way) as shown below.

Adam provided some great information; to narrow in on the dllhost.exe process and what strings to look for. Another response I got was from @lstaPee as shown below:


@lstaPee provided a few more tidbits. RunDll32.exe injects code into the Dllhost.exe and dllhost.exe should have network connections. The response I got back from Twitter was great but I really needed to address the bigger question. If and when I have to triage a system infected with Poweliks what is the fastest way to perform the triage to locate the malware and determine the root cause of the infection. A question I needed to dig in to in order to find out the answer.

Testing Environment

As much as I wanted to simulate this attack by finding a live link to an Angler exploit kit I knew it would be very difficult. Based on various articles I read, Angler is VMware aware and  it doesn't always deliverer the fileless malware. I opted to use a Powelik's dropper/downloader. I used the sample MD5 0181850239cd26b8fb8b72afb0e95eac I found on Malwr. The test system was a Windows 7 32bit virtual machine in VMware.

The test conditions were really basic. I executed the sample by clicking it and then waited for about a minute. The VM was suspended and I collected the memory and prefetch files. I then unsuspended the VM followed by rebooting the system. After reboot, I logged onto the VM and then suspended it to collect the memory and prefetch files.

My tests was to analyze the Poweliks infection from two angles. The initial infection prior to a system reboot and a persistent infection after the system reboots. My analysis had one exception. By clicking the Poweliks executable to infect the system this action created program execution artifacts. I ignored these artifacts since they wouldn't be present if the malware was loaded directly into memory. I followed my typical examination process on the memory images and vmdk files but this post only highlights the activity that directly points to Poweliks. There was other activity of interest but the activity by itself does not indicate anything malicious. This activity I opted to omit from the post.

Poweliks' Behavior

Before diving into the triage process and what to look for it's important I discuss one Poweliks' behavior. I won't go into any details how I first picked up on this but I will show the end result. What the behavior is and how it can help when triaging Poweliks specifically. The screenshot below shows partial of the Malwr's behavior analysis section showing the behavior I'm referring to.


Upon a system's initial infection, the malware calls rundll32.exe which then calls powershell.exe who injects code into the dllhost.exe process. In the image above the numbers are for the process IDs and this relevant as we dig deeper into the behavior.

The image below shows activity that occurs shortly after the rundll32.exe process starts. As can be seen, rundll32.exe attempts to load a module into its own address space with the LdrLoadDll function. The module being loaded is actually javascript; this behavior is well documented for Poweliks such as in the article Poweliks – Command Line Confusion. Notice the activity following the LdrLoadDll function call is trying to locate the address for the RunHTMLApplication function. Here's the keyword Adam pointed out.


The images below shows activity that occurs just prior to powershell.exe process exiting. Powershell.exe creates the dllhost.exe process in the suspended state. Code gets injected into this suspended dllhost.exe process and then it is resumed. This technique is process hollowing and when the suspended process is resumed it executes the injected code.

Triaging System Infected with Poweliks

Triage is the assessment of a security event to determine if there is a security incident, its priority, and the need for escalation. As it relates to potential malware incidents, the purpose of triaging may vary. In this instance, triage is being used to determine if an event is a security incident or false positive by identifying  malware on the system. Confirming the presence of malware allows for a deeper examination to be completed. The triage process I'm outlining is to confirm the presence of the Poweliks fileless malware.

Triaging with Host Artifacts

Normally, triaging a system using artifacts on the host is an effective technique to identify malware. This is especially true when leveraging program execution artifacts. However, loading malware directly into memory has a significant impact on the artifacts available on the host. There are very little artifacts available and if the malware doesn't remain persistent then there will be even less. Triaging a system infected with Poweliks is no different. Most of the typically artifacts are missing but it can still be identified using prefetch files and autorun locations.

Prefetch Files

Previously I outlined the Poweliks behavior where the rundll32.exe process runs, which then starts a powershell.exe process before injecting code into the dllhost.exe suspended process. This behavior is apparent in the prefetch files at the point of the initial infection. The image below shows the activity.


The prefetch files show the sequence of rundll32.exe executing followed by powershell.exe before dllhost.exe. Furthermore, the dllhost.exe prefetch file is missing the process path. The missing process path indicates process hollowing was used as I outlined in the post Prefetch File Meet Process Hollowing. The prefetch files contain references to files accessed during the first 10 seconds of application startup. The dllhost.exe prefetch file contains revealing ones. It contains a reference to wininet.dll for interacting with the network and files associated with Internet Explorer as shown below.


This specific prefetch file sequence only occurs upon the initial infection. Future system restarts where Poweliks is loaded into the dllhost.exe process only shows the dllhost.exe prefetch file. The file references in this prefetch still show references to files located in the user profile.

Autoruns

The prefetch files contain a distinctive pattern indicating a Poweliks infection. Depending on the sample, autoruns can reveal even more. I mention depending on the sample because Poweliks has changed its persistence mechanism. Initially it used the Run registry key before moving on to a CLSID registry key. I thought one article mentioned Poweliks may not try to remain persistent at all times. If Poweliks does try to remain persistent then its mechanism can be used to find it. Keep in mind, Poweliks has taken self protection measures to prevent this mechanism from being located on a live system. The easiest method to bypass these measures is to access the system remotely with a forensic tool like Encase Enterprise, mount the drive, and then run Regripper across the hives.

The image below shows the Run key from the user account on my test system. The sample I used was older since the Run key was used but it still is a tell-tale sign for a Poweliks infection.

...snip....

Memory Analysis Triage

Fileless malware may leave very little artifacts available on the host's hard drive but it still has to reside in memory. The most effective technique to identify a fileless malware infection is memory forensics. A Poweliks infection is not an exception since it stands out in memory whether if the memory is examined after the initial infection or a system reboot.

Network Connections

One area with malware indications is network activity are for unusual processes. @lstaPee alluded to this in their tweet about Poweliks. The Volatility netscan plug-in does show network activity for  the dllhost.exe process involving the IP address 178.89.159.35 on port 80 for HTTP traffic. dllhost.exe is not a process typically associated with web traffic so this makes it a good indicator pointing to Poweliks.

Process Listing

Another area with malware indications is the process listing showing unusual ones or ones with unusual commands. The Volatility pslist, psscan, and pstree -v plugins did not reveal anything that could definitely be used as an indicator but they did show the dllhost.exe process running. I checked a few clean systems to see if dllhost.exe normally runs but the process was not running by default.  This doesn't mean it can be used as an indicator because there could be other reasons for dllhost.exe running besides Poweliks. The screen below is from the pstree plug-in showing the command-line for launching dllhost.exe (notice there are no other options used in the command.)

Injected Code

Looking for processes with injected code is an effective technique to locate malware on a system. This is the one technique that absolutely reveals Poweliks on a system. The Volatility malfind plug-in showed the dllhost.exe process with injected code. This matches up to the articles about the malware and behavior analysis showing code does get injected into the dllhost.exe process. The image below shows the partial output from malfind.


Extracting the injected code and scanning it with antivirus confirms it is Poweliks. The image below shows the VirusTotal results for the injected code. Microsoft detected the code as Trojan:Win32/Powessere.A which is their classification for Poweliks.

Strings

The last area containing indicators pointing to Poweliks are the strings in the dllhost.exe process. The method to review the strings is not as straight forward as running a single Volatility plug-in. The strings command reference walks through the process and it's the one I used. The only thing I did different was to grep for my process ID to make the strings easier to review. The dllhost.exe strings revealed URLs such as one containing the IP address found with the netscan plug-in.


The most significant string found was the command used to make rundll32.exe inject code into the dllhost.exe process as shown below. The presence of this string alone in the dllhost.exe process indicates the system is infected with Poweliks.

Wrapping Things Up

The change introduce by the Angler exploit kit creator(s) is causing us to make adjustments in our processes. The effective techniques we used in the past may not be as effective against fileless malware. However, it doesn't mean nothing is effective preventing us from triaging these systems. It only means we need to use other processes, techniques, and tools we have at our disposal. We need to take what artifacts do remain and use it to our advantage. This post was specific to the Poweliks malware but the techniques discussed will apply to other fileless malware. The only difference will be what data is actually found in the artifacts.

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.

Today I gave a presentation titled Malware Root Cause Analysis Don't Be a Bone Head at the New York State Cyber Security Conference. This presentation was a follow-up to the presentation I gave last year titled Finding Malware Like Iron Man. Last year I laid out a triage process to find malware and this year I went into more depth discussing how the malware got there in the first place. This post contains the following for my talk: CFP, slide deck, and video I showed.

CFP

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 summer sales. The user is using their computer and the next thing you know it is infected with malware. Even Hollywood is not immune to this issue as illustrated in the TV show Bones.  The most common action to address a malware infection is to reimage, rebuild, and redeploy the system back into production.  Analysis of the system to understand where the malware came from is not a priority or goal.

Root case analysis needs to be performed on systems impacted by malware to improve decision making. The most crucial question to answer is how did this happen since it will determine if we were targeted and more importantly what can be done to mitigate this from re-occurring. Last year, in my presentation Finding Malware Like Iron Man I explored the first step in root cause analysis, which is locating the malware. The next step in root cause analysis is to identify the malware's source.

In this technical presentation Corey will discuss the root cause analysis process to determine how malware infected a computer running the Windows operating system. The topics will include: why perform root cause analysis, how not to perform root cause analysis,  compromise root cause analysis model, attack vector artifacts, and scenarios.

Slide Deck

Malware Root Cause Analysis Don't Be a Bone Head slides viewable online

Malware Root Cause Analysis Don't Be a Bone Head slides PDF file

Video

I chopped up the Bones TV episode The Crack in the Code (Season 7 episode 6) I purchased through iTunes. However, others have posted the segment I used in my presentation. For your viewing pleasure here is "Malware on Bone".
 

In this Linkz edition I’m mentioning write-ups discussing tools. A range of items are covered from the registry to malware to jump lists to timelines to processes.

RegRipper Updates

Harlan has been pretty busy updating RegRipper. First RegRipper version 2.5 was released then there were some changes to where Regripper is hosted along with some nice new plugins. Check out Harlan’s posts for all the information. I wanted to touch on a few of the updates though. The updates to Regripper included the ability to run directly against volume shadow copies and parse big data. The significance to parsing big data is apparent in his new plugin that parses the shim cache which is an awesome artifact (link up next). Another excellent addition to RegRipper is the shellbags plugin since it parses Windows 7 shell bags. Harlan’s latest post Shellbags Analysis highlights the forensic significance to shell bags and why one may want to look at the information they contain. I think these are awesome updates; now one tool can be used to parse registry data when it used to take three separate tools. Not to be left out the community has been submitting some plugins as well. To only mention a few Hal Pomeranz provided some plugins to extract Putty and WinSCP information and Elizabeth Schweinsberg added plugins to parse different Run keys. The latest RR plugin download has the plugins submitted by the community. Seriously, if you use RegRipper and haven’t checked out any of these updates then what are you waiting for?

Shim Cache

Mandiant’s post Leveraging the Application Compatibility Cache in Forensic Investigations explained the forensic significance of the Windows Application Compatibility Database. Furthermore, Mandiant released the Shim Cache Parser script to parse the appcompatcache registry key in the System hive. The post, script, and information Mandiant released speaks for itself. Plain and simple, it rocks. So far the shim cache has been valuable for me on fraud and malware cases. Case in point, at times when working malware cases programs execute on a system but the usual program execution artifacts (such as prefetch files) doesn’t show it. I see this pretty frequently with downloaders which are programs whose sole purpose is to download and execute additional malware. The usual program execution artifacts may not show the program running but the shim cache was a gold mine. Not only did it reflect the downloaders executing but the information provided more context to the activity I saw in my timelines. What’s even cooler than the shim cache? Well there are now two different programs that can extract the information from the registry.

Searching Virus Total

Continuing on with the malware topic, Didier Stevens released a virustotal-search program. The program will search for VirusTotal reports using a file’s hash (MD5, SHA1, SHA256) and produces a csv file showing the results. One cool thing about the program is it only performs hash searches against Virustotal so a file never gets uploaded. I see numerous uses for this program since it accepts a file containing a list of hashes as input. One way I’m going to start using virustotal-search is for malware detection. One area I tend to look at for malware and exploits are temporary folders in user profiles. It wouldn’t take too much to search those folders looking for any files with an executable, Java archive, or PDF file signatures. Then for each file found perform a search on the file’s hash to determine if VirusTotal detects it as malicious. Best of all, this entire process could be automated and run in the background as you perform your examination.

Malware Strings

Rounding out my linkz about malware related tools comes from the Hexacorn blog. Adam released Hexdrive version 0.3. In Adam’s own words the concept behind Hexdrive is to “extract a subset of all strings from a given file/sample in order to reduce time needed for finding ‘juicy’ stuff – meaning: any string that can be associated with a) malware b) any other category”. Using Hexdrive makes reviewing strings so much easier. You can think of it as applying a filter across the strings to initially see only the relevant ones typically associated with malware. Then afterwards all of the strings can be viewed using something like Bintext or Strings. It’s a nice data reduction technique and is now my first go to tool when looking at strings in a suspected malicious file.

Log2timeline Updates

Log2timeline has been updated a few times since I last spoke about it on the blog. The latest release is version 0.64. There have been quite a few updates ranging from small bug fixes to new input modules to changing the output of some modules. To see all the updates check out the changelog.

Most of the time when I see people reference log2timeline they are creating timelines using either the default module lists (such as winxp) or log2timeline-sift. Everyone does things differently and there is nothing wrong with these approaches. Personally, both approaches doesn’t exactly meet my needs. The majority of the systems I encounter have numerous user profiles stored on them which mean these profiles contain files with timestamps log2timeline extracts. Running a default module list (such as winxp) or log2timeline-sift against the all the user profiles is an issue for me. Why should I include timeline data for all user accounts instead of the one or two user profiles of interest? Why include the internet history for 10 accounts when I only care about one user? Not only does it take additional time for timeline creation but it results in a lot more data then what I need thus slowing down my analysis. I take a different approach; an approach that better meets my needs for all types of cases.

I narrow my focus down to specific user accounts. I either confirm who the person of interest is which tells me what user profiles to examine. Or I check the user profile timestamps to determine which ones to focus on. What exactly does this have to do with log2timeline? The answer lies in the –e switch since it can exclude files or folders. The –e switch can be used to exclude all user profiles I don’t care about. There’s 10 user profiles and I only care about 2 profiles but I only want to run one log2timeline command. No problem if you use the –e switch. To illustrate let’s say I’m looking at the Internet Explorer history on a Windows 7 system with five user profiles: corey, sam, mike, sally b, and alice. I only need to see the browser history for the corey user account but I don’t want to run multiple log2timeline commands. This is where the –e switch comes into play as shown below:

log2timeline.pl -z local -f iehistory -r -e Users\\sam,Users\\mike,"Users\\sally b",Users\\alice,"Users\\All Users" -w timeline.csv C:\

The exclusion switch eliminates anything containing the text used in the switch. I could have used sam instead of Users\\sam but then I might miss some important files such as anything containing the text “sam”. Using a file path limits the amount of data that is skipped but will still eliminate any file or folder that falls within those user profiles (actually anything falling under the C root directory containing the text Users\username). Notice the use of the double back slashes (\\) and the quotes; for the command to work properly this is needed. What’s the command’s end result? The Internet history from every profile stored in the Users folder except for the sam, mike, sally b, alice, and all user profiles is parsed. I know most people don’t run multiple log2timeline commands when generating timelines since they only pick one of the default modules list. Taking the same scenario where I’m only interested in the corey user account on a Windows 7 box check out the command below. This will parse every Windows 7 artifact except for the excluded user profiles (note the command will impact the filesystem metadata for those accounts if the MFT is parsed as well).

log2timeline.pl -z local -f win7 -r -e Users\\sam,Users\\mike,"Users\\sally b",Users\\alice,"Users\\All Users" -w timeline.csv C:\

The end result is a timeline focused only on the user accounts of interest. Personally, I don't use the default module lists in log2timeline but I wanted to show different ways to use the -e switch.

Time and Date Website

Daylight savings time does not occur on the same day each year. One day I was looking around the Internet for a website showing the exact dates when previous daylight savings time changes occurred. I came across the timeanddate.com website. The site has some cool things. There’s a converter to change the date and time from one timezone to another. There’s a timezone map showing where the various timezones are located. A portion of the site even explains what Daylight Savings Time is. The icing on the cake is the world clock where you can select any timezone to get additional information including the historical dates of when Daylight Savings Time occurred. Here is the historical information for the Eastern Timezone for the time period from the year 2000 to 2009. This will be a useful site when you need to make sure that your timestamps are properly taken into consideration Daylight Savings Time.

Jump Lists

The day has finally arrived; over the past few months I’ve been seeing more Windows 7 systems than Windows XP. This means the artifacts available in the Windows 7 operating system are playing a greater role in my cases. One of those artifacts is jump lists and Woanware released a new version of Jumplister which parses them. This new version has the ability to parse out the DestList data and performs a lookup on the AppID.

Process, Process, Process

Despite all the awesome tools people release they won’t be much use if there isn’t a process in place to use them. I could buy the best saws and hammers but they would be worthless to me building a house since I don’t know the process one uses to build a house. I see digital forensics tools in the same light and in hindsight maybe I should have put these links first. Lance is back blogging over at ForensicKB and he posted a draft to the Forensic Process Lifecycle. The lifecycle covers the entire digital forensic process from the Preparation steps to triage to imaging to analysis to report writing. I think this one is a gem and it’s great to see others outlining a digital forensic process to follow. If you live under a rock then this next link may be a surprise but a few months back SANS released their Digital Forensics and Incident Response poster. The poster has two sides; one outlines various Windows artifacts while the other outlines the SANs process to find malware. The artifact side is great and makes a good reference hanging on the wall. However, I really liked seeing and reading about the SANs malware detection process since I’ve never had the opportunity to attend their courses or read their training materials. I highly recommend for anyone to get a copy of the poster (paper and/or electronic versions). I’ve been slacking updating my methodology page but over the weekend I updated a few things. The most obvious is adding links to my relevant blog posts. The other change and maybe less obvious is I moved around some examination steps so they are more efficient for malware cases. The steps reflect the fastest process I’ve found yet to not only find malware on a system but to determine how malware got there. Just an FYI, the methodology is not only limited to malware cases since I use the same process for fraud and acceptable use policy violations.

Volume Shadow Copies has been my main focus on the blog for the past few months. I took the time needed to share my research because I wanted to be thorough so others could use the information. As a result, the interesting linkz I’ve been coming across have piled up in my hopper. In this Linkz post I’m cleaning out the hopper. There are linkz about: free DFIR e-magazines, volume shadow copies, triage, timeline analysis, malware analysis, malware examinations, Java exploits, and an interesting piece on what you would do without your tools. Phew …. Let’s roll

Into The Boxes has Returned

Into The Boxes is an e-magazine discussing topics related to Digital Forensic and Incident Response. When the magazine was first released a few years ago I saw instant value in something like this for the community. A resource that not only provides excellent technical articles about DFIR but also compliments what is already out there in the community. I really enjoyed the first two editions but a third issue was never released…. That is until now. The ITB project is back up and running as outlined in the post Into The Boxes: Call for Collaboration 0×02 – Second Try.

It looks like ITB won’t be the only free DFIR magazine on the block. Lee Whitfield is starting up another free magazine project called Forensic 4cast Magazine. His magazine will also be discussing topics related to Digital Forensic and Incident Response.

It’s great to see projects like these but they will only be successfully with community support such as feedback and more importantly writing articles. Without support then efforts like these will go to where great ideas go to die. I’m willing to step up to the plate to be a regularly contributor of original content. I’ll be writing for ITB and my first article discusses how to find out how a system was infected after I.T. tried to clean the infection. Cleaning a system makes it harder to answer the question of how but it doesn’t make it impossible. Stay tuned to see what artifacts are left on a cleaned system in an upcoming ITB edition.

RegRipper Plugins Maintenance Perl Script

This link is cool for a few reasons. Sometime ago Cheeky4n6Monkey sent me an email introducing himself and asking if I had any project ideas. I knew who Cheeky was even before his introductory email because I’ve been following his outstanding blog. I thought this was really cool; he is looking to improve his DFIR skills by trying to reach out and help others. He isn’t taking a passive approach waiting for someone to contact him but he is doing the complete opposite. I went over my idea hopper and there was one thing that has been on my to-do list for some time. At times I wanted to review the RegRipper profiles to update the plugins listed. However, I didn’t want to manually review every plugin to determine what the profile was missing. A better approach would be to flag each plugin not listed which would then reduce the number of plugins I had to be manually review. I mentioned the idea to Cheeky and he ran with it. Actually he went warp speed with the idea because he completed the script within just a few days. To learn more about his script and how to use it check out the post Creating a RegRipper Plugins Maintenance Perl Script.

VSC Toolset

The one thing I like about the DFIR community is the people who willingly share information. Sharing information not only educates us all thus making us better at our jobs but it provides opportunities for others to build onto their work. Case in point, I didn’t start from scratch with my Ripping VSCs research since I looked at and built on the work done by Troy Larson, Richard Drinkwater, QCCIS, and Harlan. I was hoping others would take the little research I did and take it another step forward. That is exactly what Jason Hale from Digital Forensics Stream did. Jason put together the VSC Toolset: A GUI Tool for Shadow Copies and even added additional functionality as outlined in the post VSC Toolset Update. The VSC Toolset makes it extremely easy for anyone to rip VSCs and to add additional functionality to the tool. Seriously, it only takes one line in a batch file to extend the tool. Jason lowered the bar for anyone wanting to examine VSCs using this technique.

Triage Script

When I put together the Tr3Secure Data Collection script I was killing two birds with one stone. First and foremost, the script had to work when responding to security incidents. Secondly, the script had to work for training purposes. I built the script using two different books so people could reference them if they had any questions about the tools or the tools’ output. As such, the one limitation with the Tr3Secure Data Collection is it doesn’t work remotely against systems. Michael Ahrendt (from Student of Security) released his Automated Triage Utility and has since updated his program. One capability Automated Triage Utility has is being able to run against remote systems. To see how one organization benefited by Michael’s work check out Ken Johnson (from Random Thoughts of Forensic) post Tools in the Toolbox – Triage. If you are looking for triage scripts to collect data remotely then I wouldn’t overlook Kludge 3.0. The feedback about Kludge in the Win4n6 Yahoo group has been very positive.

HMFT – Yet Another $MFT extractor

Speaking about Triage, Adam over at Hexacon recently released his HMFT tool in the post HMFT – Yet Another $MFT extractor. I was testing out the script and it grabbed an MFT off a live Windows 7 32 bit Ultimate system within a few seconds. One area where I think HMFT will be helpful is in triage scripts. Having the ability to grab a MFT could provide useful filesystem information including the ability to see activity on a system around a specific time of interest. I plan on updating the Tr3secure Data Collection script to incorporate HMFT.

Strings for Malware Analysis

While I’m talking about Adam I then I might as well mention another tool he released. Sometime ago he released the HAPI – API extractor. The tool will identify all the Windows APIs present in a file’s strings. I’ve been working my way through Practical Malware Analysis (except a full review soon) and one of the steps during static analysis is reviewing a file’s strings. Identifying the Windows APIs in strings may give a quick indication about the malware’s functionality and HAPI makes it so much easier to find the APIs. I added the tool to my toolbox and it will be one of the tools I run whenever I’m static analysis against malware.

Need for Analysis on Infected Systems

Harlan recently discussed the need to perform analysis on infected systems as a means to gather actionable intelligence. His first post where this was mentioned was The Need for Analysis in Intelligence-Driven Defense while the second one was Updates and Links. Alright, Harlan made a lot of great points in those both besides the need to analysis infected systems and they are both definitely worth the read. I’ve heard discussions among digital forensic practitioners about performing analysis on infected systems to determine how the infection occurred. A few responses included: it’s too hard, too time consuming, or most of the time you can’t tell how the infection occurred. People see the value in the information learned by performing an examination but there is no follow through by actually doing the exam. It makes me wonder if one of the roadblocks is that people aren’t really sure what they should be looking for since they don’t know what the Attack Vector Artifacts look like.

NTFS INDX Files

Sometime time ago William Ballenthin released his INDXParse script that can be used to examine NTFS INDX files. To get a clearer picture about the forensic significance of INDX files you can check out Chad Tilbury’s post NTFS $I30 Index Attributes: Evidence of Deleted and Overwritten Files in addition to the information provided by William Ballenthin. INDXParse comes with an option to use a bodyfile as the output (-b switch) and this can be used to add the parsed information to a timeline. Don’t forget that next week William Ballenthin is presenting about his INDX files research in a DFIROnline special edition.

Colorized Timeline Template

Rob Lee created a timeline template to automate colorizing a timeline when imported into Excel. His explanation about the template can be found on his post Digital Forensic SIFTing: Colorized Super Timeline Template for Log2timeline Output Files. Template aside, the one thing I like about the information Rob shared is the color coding scheme to group similar artifacts. To name a few: red for program execution, orange for browser usage or yellow for physical location. Using color in a timelines is a great idea and makes it’s easier to see what was occurring on a system with a quick glance.

Checklist to See If A System's Time Was Altered

Rounding out the posts about time is Lee Whitfield’s slide deck Rock Around the Clock. In the presentation, Lee talks about numerous artifacts to check to help determine if the time on the system was altered. After reading his slides over and the information he provided makes a great checklist one could follow if a system’s time comes into question. The next time I need to verify if someone changed the system clock then I’ll follow these steps as outlined by Lee. I copied and pasted my personal checklist so if any information is listed below that didn’t come from Lee’s slide deck then I picked it up from somewhere else.

        - NTFS MFT entry number
                * New files are usually created in sequence. Order files by creation then by identifier. Small discrepancies are normal but large require further investigation

        - Technology Advancement
                * Office, PDF, Exif images, and other items' metadata show program used to create it. Did the program exist at that time?

        - Windows Event Logs
                * Order event logs in order then review the date/time stamps that are out of order
                * XP Event ID 520 in security log "the system time was changed" (off by default) Vista, 7 Event ID 1 in system log "the system time has changed to ..." and event id 4616 in security log "the system time was changed"

        - NTFS Journal
                * Located in the $J stream of $UsnJrnl and may hold few hours or days of data. Entries sequentially stored

        - Link files
                * XP each link file has a sequence number (fileobjectid). Sort by creation date then review sequence number

        - Restore Points
                * XP restore points named sequentially. Sort by creation date then review RP names for out of sequence

        - Volume Shadow Copies
                * VSC GUIDs are similarly named for specific times
                * Sort by creation data and then review the VSC names to identify ones out of place

        - Web pages (forums, blogs, or news/sports sites)
                * Cached web pages may have date/time

        - Email header

        - Thumbnails
               * XP one repository for each folder and Vista/7 one for all folders. Both store items sequentially.
               * Sort by file offsets order then review for out of place dates

Attackers Are Beating Java Like a Red Headed Stepchild

I don’t have much narration about Java exploits since I plan on blogging about a few case experiences involving it. I had these links under my exploits category and wanted to get rid of them so I can start fresh. Towards the end of last year a new Java vulnerability was being targeted and numerous attacks started going after it. DarkReading touched on this in the article The Dark Side Of Java and Brian Krebs did as well in the post New Java Attack Rolled Into Exploit Kits. The one interesting thing about the new Java attack from the DFIR perspective is it looks the same on a system as other Java exploits going after different vulnerabilities. It’s still good to be informed about what methods the attackers are using. Another link about Java was over at the Zscaler Threatlab blog. There’s an excellent write-up showing how a Java Drive-by Attack looks from the packet capture perspective.

What Can You Do Without Your Tools

The Security Shoggoth blog's post Tools and News provided some food for thought. The post goes into more depth on the author’s tweet: Want to find out how good someone is? Take away all their tools and say, "Now do it.". When I first got started in DFIR I wanted to know the commercial tool I had available inside and out. I learned as much as I could about the tool except learning how to write enscripts. Then one day I thought to myself, could I do forensics for another shop if they don’t have Encase and the answer was unfortunately no. I think there are a lot of people in our field who fall into the on commercial tool boat. They can do wonders with their one tool but if they don’t have access to it or if the tool can’t do something then they get stuck. I made the decision to improve my knowledge and skills so I could do my job regardless of the tools I had available. The change didn’t happen overnight and it took dedication to learn how to do my job using various tools for each activity. Try to answer two of the questions the author mentioned in his post and if you are unable to fully answer them then at least you know an area needing improvement.

Imagine for a moment that you didn't have the tool(s) you use most in your job - how would you perform your job? What alternatives are available to you and how familiar you are with them?

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