Sunday, January 16, 2011
New blog design
hope you enjoy the new blog design as much as I do. I've added some facebook/twitter buttons as well to make things easier for those of you already sharing, thanks btw. Looking for the next blog to be up Tuesday.
Tuesday, January 11, 2011
What are you missing?
Every image is a special snowflake in regards to what software you find installed. There are times though when an investigator, myself included, gets comfortable as to what to expect and what they believe their tools are already doing for them. I had such an occasion last month when I found an image where the user was using Google Chrome as their browser. The case this was for is now settled and there was no public disclosure of my involvement in any form of declaration/affidavit/report so I will not be identifying the parties.
I was the second person to review the image at the time and we were looking to recover communications between our suspect and other parties around the time of his departure from his then current employer. What was suspiciously absent in our first round of reviews was a lack of web activity being reported from our standard tools. When this happens three things come to my mind for sanity checking:
1. When did the user profile I am looking at get created?
If this is a new system and I got handed it a couple days after the suspect started using it maybe what I'm seeing is correct. In this case, no the system had been in use for at least a year.
2. Is there any indications of popular 'cleaning' or wiping software being used?
Running through the user assist records, lnk files to no longer existent sources or other artifact sources that no longer show data after a consistent date are all signs of this. I will write another blog post about detecting what/when something was cleaned. In this case everything else was in place as it should be.
3. What other programs are installed? Am I missing something?
A quick look through the program files folder and user assist should be done at this point, is there something being used here that you hadn't dealt with previously. The user in this case had IE and firefox installed on his system so I didn't think to check for yet another web browser.
So I took a look through the keyword hits coming from his personal email address and noticed for the first time that they were contained within Chrome SQL Lite databases. Prior to this point I had not extracted the history files for a Chrome user and began a round of google searches to determine how to proceed.
While Google Chrome does make use of SQL Lite databases, basically flat files that contain a database structure that can be used like a relational database without the overhead, I didn't want to manual string together queries. I found two pages that helped me reach the evidence I needed.
The first located on the SANS blog provided me the information I needed regarding the structure of where the files should exist and what files I was most interested in. If I was looking to use log2timeline I could have stopped there, but I already have a license of NetAnalysis so I went to their site next.
Luckily for me in version 1.52 was announced in my inbox on 12/11/10 and now included Google Chrome support. So utilizing the information from the SANS blog I exported it to NetAnalysis for parsing and came up with all of the webmail usage I was expecting.
So the next time you don't find what you are expecting try my three steps and see if there is something you are missing.
If you know of a tool that supports Google Chrome histories besides log2timeline and NetAnalysis please comment or email with it.
Wednesday, January 5, 2011
Happy New Year and new Federal Civil Procedure Rules Year
Since I last so optimistically posted that I would resume blogging in 2010 I had no idea what the first year of a child's life meant for a new parent. I am making a commitment in 2011 to begin regularly posting again and I hope you will believe me and choose to follow along.
In 2010 news I did speak at HTCIA 2010 in Atlanta this year on forensic cases studies from some of G-C's greatest civil cases.
In 2011 news I will be speaking at CEIC 2011 http://www.ceicconference.com on outlook web access forensic analysis. I've been asked to make it a lab so if you are going to CEIC I hope you sign up and learn about what I've learned about OWA analysis in 2010 as it relates to Exchange 2003/2007/2010.
I plan to try to speak more often in 2011 so if your conference is looking for a speaker let me know.
In civil expert witness news I am very happy to join the chorus of other legal commentators to praise the change in the federal rules of civil procedure for expert disclosures. The rule took effect December 1, 2010.
You can read more about it here and here but the jist of it is that emails and drafts of documents exchanged between lawyers and experts is no longer discoverable unless it contains information regarding compensation or information that leads to an opinion. This will make mine my life considerably easier and I hope yours as well.
Monday, February 22, 2010
New Year New Post
I'm still alive, sorry for the lapse in content for the last 6 months. The second edition of the book is out, we will be at the RSA conference doing a book signing next week so make sure to stop by and say hi.
I'll be finishing the current series today and then moving on to new topics.
Friday, August 14, 2009
I love ftk 2.2.1
Dear FTK,
I know we've had some tough times together in the past. Me cussing at a crashed indexed, you not responding to my mouse clicks. There were times I thought we wouldn't last and that I would find someone else who would fulfill my needs. Then I saw the new you (FTK 2.2.1) and when I actually exported the emails from a indexed search into a recreated recursive directory path from the PST folder structure that it came from I held my breath. When I then saw that actual MSG files were contained in the right folders my heart skipped a beat. Then when I saw that the attachment was actually in place in the MSG ... I knew everything would work out.
Love,
G-C Partners, LLC
Seriously though, for those who didn't immediately get this joke alot of the forensic tools available to the market for the last 10 years have had some real gaps of functionality that made our lives torture. One of these most basic features missing was the ability to export an email found when reviewing an image in a forensic tool back to a msg or pst instead of just a text export or html export that wasn't even compliant to the rfc specifications needed for most tools to convert it. If we didn't have it in msg or pst most lawfirms and ediscovery firms could not process it.
FTK 2.2.1 has fixed that issue and for this my office will gain many, many hours of producivity back instead of running my very long process to reassemble the data from other tool outputs.
Back to the series in the next post, thanks for reading.
Saturday, August 8, 2009
What did they take when they left? Part 4 (External Devices) - Where did it go and what did they take?
Howdy Reader,
It's been quite some time since my last blog post, I apologize. Things have been pretty busy, apparently the recession/depression has really spurred civil crimes and I had a very nice vacation. In our last time together we discussed more detectable methods of how suspects remove data from their systems. I've left off the most common and lengthy portion of the post so I could give it the detail and supporting documentation it deserves. In this post we will finish the concept exploring method 3 in this post and 4-5 in the next. This series does focus on Microsoft windows systems as they are the most popular business system in use, I will write another linux or mac specific series at another time.
Method 3 – Copying data to an external drive
- How did they take data from the system
The first step you should take in a windows system is examining the contents of the registry keys that track storage devices plugged into the system. Inside these registry keys located under the system registry file under the system control sets are at least three keys keeping track of three types of external storage devices:
- USB Devices
USB storage devices have their information store under the USBSTOR key found under:
system\currentcontrolset\enum\usbstor
- Firewire Devices
Firewire devices that are also storage devices can be found in the system registry under the system control set as well at:
System\currentcontrolset\enum\sbp2
- eSATA Devices
eSATA devices that are plugged into the system can be found in the system registry under the system control as well at:
system\currentcontrolset\enum\ide
It's important to know that the type of eSATA enclosure (for instance I was testing with a Simpletech Prodive) will not appear in the IDE registry key. The type and serial number of the drive will appear in the registry but you will have no way to identify what enclosure the drive was in from the registry. Of course you can compare the drives in enclosure to find the right drive but if drafting a subpoena you will not be able to specify what enclosure the drive is in.
- Responsive to all types of devices:
There are additional versions under the system key some of which are duplicates of currentcontrolset so make sure to check each one. Each controlset that is numbered such as controlset001 is a configuration state of the system that booted successfully at one time. The currentcontrolset points to the numbered controlset that was last booted from successfully.
An easy way to parse out these registry entries is with RegRipper which creates a nice text file with all the most useful parts of the registry for the forensic examiner but in its latest version does not include the sbp2 key but I'm sure it will be added soon.
There is one registry entry under these keys for each storage device that has been attached to the computer since it was first installed if these keys do not exist or are empty then someone has run a system cleaner as the key will only get created on the first attachment of a storage device except for IDE which will exist if their is an IDE drive in the system. Remember these entries are in the system registry so it applies to every user who has used the system. This means that if you have a multi user system you still will have to verify who plugged it in during the times and dates we find. These entries will contain digital cameras, thumb drives, external hard drives, ipods, cell phones, anything that provides some type of storage and will be accessed as a drive letter. Each entry will contain the parent id, the vendor id and what is marked as the serial number of the device. The serial number reported to windows is not always the serial number printed on the physical device and this varies by manufacturer so when requesting these devices in a subpoena or other form make sure to specify it 'as reported to Microsoft Windows'.
The last written date of the registry key for each device entry tells you the last time the device was plugged into the system. We can determine the first time the device was plugged into the system by searching for the device name we found in the USBSTOR/SBP2/IDE keys and searching for it in the setupapi.log file found in the 'windows' directory in windows xp and in the setupapi.dev.log located under 'windows\inf' in Vista.
To find out each additional time the device was plugged into the system we can look at the backed up copies of the system registry located in the restore points. For Windows XP this is located under the 'system volume information folder\rp'. There is a new version of regripper for restore point registry examination called ripxp that will run the ripper not only against the current registry file but also all the previous copies of it in the restore points.
Windows Vista restore points are renamed to "system restore" points and utilize the shadow copy service to make a separate volume where previous versions of files and system files are kept depending on the configuration and version of windows vista. You can use programs such as Shadow Explorer to access these volumes on a live system (or an image running in a vm) where you can browse the point in time back up of each partition on the system for the same registries. I have not found a forensic tool to date that can mount these shadow volumes in the way that shadow explorer can.
- USB Devices
- What did they take
If our suspect did not wipe the system clean of the information we now know all of the external devices they could have copied information to. Determining the extent of what they have copied on to these devices is not as well recorded by the system. There are several ways that a suspect may attempt to copy data to the external drive.
- Backup programs
There are a variety of backup programs a suspect can use. Some of them will come bundled with the external media and others are built into the operating system. We can determine what backup program the suspect ran from the techniques discussed in part 2. Once you've identified the software used a quick google should reveal what if any logging the software left behind. For instance in Carreker Corporation v. Cannon et al (4:06-cv-00175-RAS-DDB) we found the use of Dantz Retrospect which creates a log file for each of the backups performed logging the configuration, directories backed up, files backed up and total data copied for each backup done with the software.
- Copy programs
Some suspects will choose to use utilities such as robocopy or xxcopy to copy the data to external media. In those cases the techniques discussed in part 2 will help you identify what program they used and when they copied the data.
- Standard copy and paste
If our suspect copied the data to some external media with just a copy and paste or drag and drop there will be no record that I have found to date to reflect it.
The next thing we have to determine is what they copied on to the external drive. There are two reliable methods generated by Windows automatically that can tell us what files and/or directories they accessed from the external media.
- LNK Files
Windows shortcut or 'LNK' (pronounced link) files have been a standard feature of windows since windows 95. LNK files as most forensic examiners refer to them are created for a variety of reasons. What is most important to us for this method is that for files and directories opened in windows explorer a LNK file will be created in the users recent directory ('\documents and settings\user name\recent' in windows xp, '\users\user name\recent' in windows vista) and if a program such as Microsoft office is associated with the file then a second lnk file will be located in the program's own recent directory located in the application data directory. The LNK file in its normal usage allows a user to quickly access the file that it points to. We can examine the LNK files and see which of them show that the file or directory it points to existed on an external disk. For more information on LNK files read this or this. For a free utility that will parse these files and other try Windows File Analyzer (most forensic tools have this capability already either built in or through some provided script).
The LNK file tells us many important facts about a file that it points to.
- The time the file was first accessed on this computer
The created date of the LNK file will tell you the first time the file was accessed through windows explorer, this captures the first access to the file. If the modification date varies from the creation date then you have the last time the file was opened as well.
- The time the file was first created on the media it resides on
The LNK file captures the creation, modification, access dates as well as the size of the file that it points to within the LNK file structure. This allows us to know the creation time of the file which reflects the first time the file was copied onto the media. We can then determine when the data our suspect has taken was first copied on to the media. We will only know this if the suspect accesses the files or directories after copying them to the disk.
- The name, type and volume serial number of the media the file resided on.
Using this we can determine which files accessed came from external media and match it up to those devices we identified in this section.
- MRU
Most Recently Used entries in the registry exist for multiple types of applications and windows components. They keep track of the last files opened by the user for that application but they only track the file opened and the date on which the file was opened. The only way to determine if the path where the file was opened was on external media is to check if the drive letter shown was not local to the system. You can easily pull out most MRUs with regripper.
- LNK Files
At this point we can now determine what external devices were in use and what files we can determine were placed there. The last two methods to discuss are copying data to network locations and uploading data to file hosting websites.
Thursday, July 23, 2009
Back in the US
Sorry for the lack of new posts. I've been out of the country for work and vacation the last couple months but I'm back and ready to finish the series. In good news while onsite for two months I did run across a number of new OWA log format that I wrote some new parsers for that I will be posting soon.