Links

Wednesday, June 22, 2011 Posted by Corey Harrell
The links discussed include a triage model, mapping tweets, and an incident analysis write-up.

A Triage Model

Last week I attended my graduation at Norwich University. Not only was it great to finally be done with college but I had the opportunity to sit through presentations including a few on digital forensics. One of the DF presentations was given by Marc Rogers of Purdue University on the Computer Forensics Field Triage Process Model (CFFTPM). Marc’s presentation was informative and afterwards I wanted to learn more about the model so I read a whitepaper on it. For people unfamiliar with the model, the image below shows the different CFFTPM phases.

Source: http://www.mendeley.com/research/computer-forensics-field-triage-process-model/
CFFTPM appears not to be technology dependent which means the model can be used against different platforms in various types of cases. Even knowing this couldn't stop me from thinking about what impact technology may have when trying to implement the model. The majority of the systems I come across run some version of Windows and there has been an increase in the number of Windows 7 systems I’m seeing. If I were to use the model then I take into consideration the volume shadow copies (VSCs) on the newer Windows operating systems. For example, one of the phases in CFFTPM is the examination of the User Profiles by reviewing the following: the home directory, file properties, and registry. If the system contains VSCs then there may be user profile data at different points in time and just triaging the data in the current state might not show an accurate picture of the system. What happens if data is deleted from the user profile prior to the triage? The examiner might not notice this occurred without taking a look at the data in VSCs.

The example holds true for the other triage phases as well. On a few recent cases VSCs contained pertinent data and if I was triaging a system then the VSCs need to be considered. A script and a few tools could parse all of the data - including data in the volume shadow copies – in a short timeframe and still allow me to review all of the information onsite.

Mapping Tweets

A few months ago the article This is What A Tweet Looks Like discussed the metadata stored in a tweet. The metadata contains a wealth of information such as the author's name, account creation date, and the author’s location. I thought about the article when I was reading Creepy, the Geolocation Information Aggregator. Creepy is a python script (still in beta form) that allows people to gather publicly available geolocation information from social networking platforms and image hosting services. The article showed how Creepy can harvest “geolocation information from Twitter in the form of geotagged tweets, foursquare check-in’s, geotagged photos posted on twitter via image hosting services such as yfrog, twitpic, img.ly, plixi and others, and Flickr”.

I didn’t test the python script and my judgment is solely based on the content of the article. Creepy appears to make it extremely easy to map the geolocation information from Twitter and I can see the two sides of how this ability can be used. For investigations it might be helpful to confirm the whereabouts of the person tweeting. On the other side, this ability can make it pretty easy to stalk someone and help identify people’s patterns.

Incident Analysis Write-up

The Carnal0wange blog posted Incident Analysis: Lost Million Dollars in a Minute. The post has a link to their write-up about an incident where a victim’s online banking account was compromised and a sum of money was transferred to Eastern Europe. The analysis involved examining a forensic image of the victim’s machine and a network packet capture. Over the past few years, I’ve seen numerous articles about Trojans being leverage to steal money but until now I haven’t seen any public write-ups about the examination of systems infected with a banker Trojan. The write-up is interesting and I’m thankful the authors shared the information.

One of the conclusions was the “victim's machine is infected via an email by executing a malicious executable file” but the write-up didn’t cover the artifacts to point to this type of delivery mechanism. The next area I’m looking into is the artifacts left by using email as the delivery mechanism so it would have been nice to see how the artifacts looked in an actual incident. Despite this, the write-up still provides a glimpse about the analysis of a system infected with a banker Trojan.

***** Update *****
The Carnal0wange blog had a link to the incident analysis report but has since removed the link and is providing the report by email.
***** Update *****

Mass Malware Still a Threat

Speaking of attack vector artifacts… The ThreatPost article Forget APT, Mass Malware is Still the Big Threat said “type of attacks that most enterprises see today still come from mass malware that defenders haven't yet figured out a good way to stop”. Unfortunately, there are a lot of enterprises who don’t react well to the mass malware problem. The standard SOP is to wipe, reimage, update, and redeploy. The one step missing is the investigation to determine how the malware got onto the system in the first place. Did an exploit target one of the following vulnerable applications: Java, Adobe Flash, Adobe Reader, QuickTime and Internet Explorer? If so which one and how did the exploit get delivered to the system. Did a social engineering trick make an end user infect the system themselves? Did the malware spread through email?

The answer to the how question is crucial for an organization to decide what measures to put in place to better protect themselves for the future. Do resources need to be used to improve a breakdown in the patch management process, offer a security awareness refresher training to employees, implement a new security control, etc.. The attack vector artifacts left on the infected system can help an examiner determine the how of a mass malware infection.

Information Gleamed from Stolen Router

This isn't directly related to DFIR but part of my background includes networking so articles about network security peeks my interest. When I was checking out the InfoSec Resources newsletter I saw the article The Case of the Great Router Robbery which discusses the different information that can be obtained from a stolen router and ways to reduce your exposure if a router is stolen from your organization. I don’t know how many routers are actually being stolen from organizations but it’s good to be informed about the potential risk.
Labels: ,

Post a Comment