How Does Integration Help You as an Investigator?

Lance Mueller

A new IEF/EnCase Processor Module will be available September 12th.

The IEF/EnCase Connector referenced in the Blog is available here.

Let’s imagine I have been assigned to investigate case involving an employee who is suspected of posting threatening comments on a co-worker’s Facebook account (this could either be an internal employee misconduct or criminal investigation). The messages were sent yesterday.

The suspect: A male employee named “Thomas Cator”

The victim: A female employee named ”Dewey Brooks”

The posts that Dewey Brooks received were from ”Randy Miller” and said:

1. "You better watch your back. I know where you live, when you leave and the car you drive. I also know where your family is."
2. "Next time I see that guy with you I will shot him dead"
3. "The next time I see you outside, I'm going to run over you with my car!"

The victim (Dewey Brooks) went out on a few dates with suspected co-worker identified as Thomas Cator but then stopped going out with him after he seemed to get very jealous if she didn’t quickly reply email to his email or return his calls right away. She is not sure who is posting the threatening comments on her Facebook wall, but she suspects it may be her co-worker Thomas Cator. A few days ago, Dewey received and accepted a friend request from a “Randy Miller,” but admits she is not sure who this person is.

Using EnCase® Forensic v7 and the included direct servlet, IT Security has obtained a surreptitious forensic image across the network of “Thomas Cator’s” computer hard drive and an image of RAM the same day the messages were posted, once the supervisor was told about the issue.

A common starting point for this type of investigation would be using known keywords (in this case, passages from the messages posted on Facebook) to try and identify relevant artifacts that may exist on Cator’s computer. This would help establish at least that this computer viewed the Facebook page that had the threatening comments. I could then see if I could establish the messages were sent from this same computer and then ultimately tie all these artifacts to a specific computer user account.

I would start this analysis by first looking at the RAM image. There is no rule that says I have to start with RAM, but for me, RAM represents a smaller subset of data than a disk image, yet it will likely yield a higher percentage of artifacts for the size of RAM compared to a disk image. It also represents the most recent volatile data set that I have available.

Loading the RAM image into EnCase v7, I can run the evidence processer against it looking for Internet artifacts. Since it would be considered an unstructured disk image, you would have to be sure to enable the “Search unallocated space” option.

We could also create some keywords to search for and search the RAM image at the same time we process the Internet history.

I will use the following case insensitive keywords to get me started:

• Dewey
• "I will shot him dead" (I like using keywords or phrases with spelling or grammatical errors, since it would help eliminate false positive hits)
• "You better watch your back"
• "The next time I see you"
• "randy miller”"

And the results of the keyword search against the RAM image gets me this:

The results of the Internet history search against the RAM image gets me this:

Looking at the first search hit, we can clearly see some Facebook data and the text we were looking for.

This is a great find, but without context, it makes it very hard to understand how or why this text is here. Did Cator just happen to just view the victim’s Facebook page and this data was just cached? Or did he actually post the messages himself? We need more context.

Looking at a few more search hits for the keyword “dewey” I find this:

Now we’re talking. Here is a fragment that looks like a friend request confirmation and there is a reference to “Randy” with a date/time. Why would this be on Cator’s computer?

Let’s run the RAM image through Internet Evidence Finder (IEF).

Looks like there are several artifacts from the RAM image to look through. I could use the keyword feature in IEF Report Viewer to find artifacts with specific keywords. Using the term ‘dewey’, IEF filters out the artifacts that only contain that keyword:

Now we’re getting closer to having more context. We found really good keyword hits in EnCase Forensic v7, and now we can clearly see these are Gmail webmail fragments that involve the victim.

Looking at another artifact category, I see this:

Whoa! Why is there a Facebook URL that references the victim’s Facebook page with a title “Randy Miller” on Cator’s computer (in RAM)? We better go look at that file offset to see what exact the fragment says. Looking at IEF, we see it’s at offset 11107201 in the RAM image. Going to that offset in EnCase Forensic, I see this:

Wow, I see several references to “Randy Miller”. I also see an actual Facebook profile named “crazyrandym”. Let’s add that as a keyword in EnCase Forensic:

Oh snap, look at these great artifacts! At this point, I am well on my way in establishing that Cator’s computer was used to check a Gmail account tied to the Randy Miller Facebook profile used to post the threatening comments on Facebook.

EnCase Forensic/Internet Evidence Finder Integration

One of the questions I have heard since we released the IEF EnCase EnScript (May 2013) that provides the ability to parse the evidence files loaded within EnCase Forensic, is what is the advantage/disadvantage of doing it that way and why would I want to pull the artifacts IEF found back into EnCase Forensic?

Everyone’s workflow and/or organizational requirements may be different, but there are some clear advantages of using an EnScript® that allows you to leverage any third-party tool, such as IEF, on already loaded evidence and then bring the resulting artifacts back into EnCase Forensic.

• Efficiency
• The ability to launch a third-party tool using an EnScript can be more efficient and reduce the total number of steps to process same data compared to processing it separately with each tool. The number of steps saved may vary and be small when looking at each individual case, but over time it is much easier to have a single ”view “where I can launch and process my evidence with all the necessary options for that specific case (i.e. much like the design of the EnCase® evidence processor).
• Compartmentalization
• Having all the artifacts or processed data in one common place or container helps with case portability and compartmentalization. It’s easier to know that all the data from a specific case or investigation is located in one place as opposed to be scattered in several different and diverse locations.
• Data Normalization
• Having all the relevant data in one location or view provides normalized data that is structured and similar in nature. This also provides the ability to use additional tools such as filters, conditions, and EnScripts to further process or view all the data.
• Reporting
• Provides the ability to include all the relevant data in the reporting process without having to cut and paste from different reports to make a master report.
• Depth and Breadth
• Having as much of the relevant data as possible in one place provides a broader picture of what is going on. The use of third-party tools commonly provides depth into a specific area of artifact recovery, while being able to see all of the data from different categories of artifacts provides perspective, context and breadth.

Integrated Approach

Let’s go back to the above scenario and work through it using the integrated approach. Starting from the beginning where I received the disk image and RAM image, I would load the RAM image into EnCase Forensic v7 and quickly run the IEF EnScript to launch IEF in the background and parse out any artifacts and pull it back into EnCase Forensic.

Once it’s completed, we will have an additional piece of evidence (LEF) that contains all the artifacts that IEF found and parsed out into their respective categories.

Let’s run our keyword search again, but this time we will index both the RAM image and the new LEF that was created by IEF.

Once indexed, we can enter a few search terms and quickly see the results. Entering the term “randy” immediately shows us some relevant results:

We can also see in exactly which artifact category in IEF this keyword was found in (Chrome and Gmail fragments). We can also review the exact URL by viewing the Fields tab.

Entering the term “dewey” also gives us some immediate results with the context of knowing exactly what type of Internet artifact generated the hit.

I originally loaded only the RAM image and then ran the IEF EnScript and indexing on that. If I had added the RAM image and the disk image and then ran the IEF EnScript against both, as well as indexing them for a keyword search, a whole new level of context arises.

A quick keyword search across both images (RAM and disk image), as well as the IEF artifacts from both, reveal all sorts of relevant hits that clearly identify a user account, dates and times, and applicable Internet artifacts.

Filters/Conditions

By bringing the data IEF found back into EnCase Forensic, you can also leverage the built-in filter/conditions feature to quickly isolate artifacts that match certain criteria and can easily be mapped back to a specific activity (i.e. Chrome browsing or Facebook post). Below is an example of building a condition that looks for specific keywords (dewey, randy) anywhere in the Internet artifacts that IEF found and were imported back into EnCase Forensic.

The Value of Integration

As you can see from the example above, there are some significant advantages to bringing the data back into EnCase Forensic and using that as the main platform to collate, search, and report on all the relevant data. Additionally, by using the customized reporting templates, you can then include various components of the data IEF found into the standard EnCase® Examination Report without having to generate two separate reports (that may look different) and then be required to merge or combine the two.

As always, I appreciate any feedback, comments, or questions. You can reach me anytime at lance (at) magnetforensics (dot) com