Category Archives: Forensics

Mac Forensic Artifacts

Below are a list of forensic artifacts for Mac devices, categorized by file location

*This is a running list of notes gathered based on experience investigating devices. This is very much an incomplete collection of artifacts*

Epoch Time = seconds since 1/1/1970

Mac Epoch Time = seconds since 1/1/2001

Difference = 978307200 seconds

mac time + 978307200 = epoch time

  • ~/System/Library/CoreServices/
    • SystemVersion.plist
      • ProductVersion: Operating System version.
        • 10.10.x  = Yosemite
        • 10.9.x = Mavericks
        • 10.8.x = Mountain Lion
        • 10.7.x = Lion
        • 10.6.x = Snow Leopard
  •  ~/Users/user/Library/Preferences
    • com.apple.finder.plist
      • FXDesktopVolumePositions – list of volume names
      • FXRecentFolders – string name for 10 most recent folders
    • com.apple.recentitems.plist
      • RecentApplications: CustomListItems contains 10 most recent applications
        • Application names
      • RecentDocuments: CustomListItems contains 10 most recent Documents
        • File names
      • RecentServers: CustomListItems contains 10 most recent connected servers
        • Server names
    • com.apple.sidebarlists.plist
      • FavoriteItems: Shares/Folders/Drives listed in “Favorites” in Finder
        • Names of items
      • FinderProjects: Tag colors
        • Red, Orange, Yellow, Green, Blue, Purple, Gray, Work, Home, Important
      • SystemItems > VolumesList: Mounted volumes
        • Volume names
    • com.apple.Safari.plist
      • DownloadsPath: Default location of downloaded files
      • HomePage: Default homepage settings
      • LastOSVersionSafariWasLaunchedOn: Version number
      • RecentSearchedStrings: recent strings searched in Address Bar
      • SuccessfulLaunchTimestamp: Last time Safari was launched successfully in Epoch time
  • ~/Users/user/Library/Safari
    • Browsing History
      • History.plist (10.9 and below)
      • History.db (10.10 and later)
        • Opened in a SQLite browser
        • History_items: Each URL visited, domain, and its associated ID #
        • History_Visits: Mac Epoch time associated with with history_item ID #
          • Need to associate history_item ID number in this table with the entry in History_items table to determine timestamps of visits
  • ~/.fseventsd
    • File system events daemon
    • System process that is responsible for handling changes to the file system
    • Writes file system event log files and monitors file system changes
    • /.fseventsd is a staging or buffer area
    • http://techblog.willshouse.com/2011/05/05/what-is-fseventsd/
  • ~/private/var/log
    • system.log
      • Logs all kernel related messages
      • Archives to compressed folders – .bx2 extensions
      • Old system log archived 12:30am local time if machine is left on at that time
      • Not comprehensive log
    • fsck_hfs.log
      • Shows disks/partitions mounted (no volume names)
      • Timestamps available (not Epoch in Plist Editor Pro)
      • i.e. /dev/rdisk3s2
    • hdieject.log
      • Limited eject notices for drives
      • can tie disks/partitions to volume names, but not for all instances
      • Timestamps available
  • ~/Library/Logs
    • DiskUtility.log
      • Individual user records for Disk Utility
      • Does not show every mount
      • Times of drives erased/renamed etc. in Disk Utility
      • Occasionally shows Volume names if logging the drive being renamed

Mac OS X Internet History

As most forensicators would agree, index.dat files are an extremely valuable Windows artifact to an investigation. These files store all sorts of internet browsing history from Internet Explorer, as well as where a user browsed to within directories on the device using Windows Explorer. Even after clearing the internet history, emptying your cache, and removing cookies in Internet Explorer, the logs of where a user surfed on the internet remains stored within the file.

Even though Windows operating systems are still the most prevalent, what is the equivalent to Mac operating systems, which are quickly becoming just as popular? The sad revelation (in my mind) is that there is no exact equivalent of an index.dat file on a Mac. For Safari, internet browsing history is stored in a plist (property list file which stores application information) within the system library. This plist is located at:

/username/Library/Safari/History.plist

*One commonality between index.dat files and history.plist is that they are both stored locally under the user’s profile

To view plist files, I use a program called PlistEditor Pro which is a standalone version of the tool that is integrated with the Xcode 4 developer application. 

One Xcode4 is installed, navigating to the history.plist file and double-clicking it will automatically open the file in the PlistEditor. Under “WebHistoryDates” will be each entry in the browser history.

Screen Shot 2013-04-05 at 6.33.24 PM

 

The history.plist files are read in chronological order from the bottom to the top, meaning that the top entry (Item 0) is the most recently visited website.

Expanding each item in the history will show its contents

Screen Shot 2013-04-05 at 6.33.52 PMAs you can see, the browsing history is displayed. Although, by default the LastVisitedDate is displayed as a string. This can be changed by clicking “String” next to the value and selecting “Date”

Screen Shot 2013-04-05 at 6.34.13 PM

By doing this for the logs, the timestamps will be converted into date/time format.Screen Shot 2013-04-05 at 6.34.18 PM

Although, one flaw (forensically speaking) of this plist file is that unlike the index.dat files, the history.plist file gets cleared when the browsing history is cleared from Safari. Because of this, a lot of valuable data can become lost. When a user is in Safari and goes to History > Clear History (which is the easy way to clear browsing history) there are still some artifacts left behind that investigators can use to determine other sites that were browsed before history was cleared. One of these artifacts is the Cache.

The first method is to carve deleted browsing history from unallocated space. More details on this methodology can be found on Richard Drinkwater’s blog.

Cached entries are located at /username/Library/Caches/com.apple.Safari where there is a Cache.db (SQL Database file) and a folder called “Webpage Previews” The Webpage Previews folder will contain snapshots of webpages that were previewed even before the browser history was clearedScreen Shot 2013-04-05 at 6.50.54 PM Screen Shot 2013-04-05 at 6.51.28 PM

Opening the cache.db file is a bit different. A program I like best for opening these on a Mac is called File Juicer which will parse this database file and display its contents, including a range of image files, html files, javascripts, and text files

Screen Shot 2013-04-05 at 7.04.45 PM

In my opinion, analyzing the web browsing history on a Mac operating system can be much more work intensive than analyzing an index.dat file, seeing as an investigator has to look in multiple places on a Mac device to find the same information that can be found in the index.dat. Learning forensics on a Windows device, I was surprised when I found out that deleted browsing history is not kept on the device normally. On the other hand, when I mentioned this topic to a coworker, he was surprised that Windows actually kept that information.

If anyone has any further guidance or comments, please feel free to post. Mac analysis is extremely new to me, but what I’ve found so far is extremely interesting

Calling all expertise

Being a good student, I have learned that while a tool is designed to automate a portion of an analysis, it’s always good to have a general understanding as to how the tool is able to accomplish this. One feature of FTK that has me questioning is the fact that given a pst, the tool is able to determine which emails were read vs. which were unread. One thing I cannot find solid research on is how FTK is able to parse this information. A friend has conducted experiments around this by viewing an unread message, a read message, and a message marked as unread forensically. There are slight differences in the hex, but what does that mean?

Is there a bit somewhere in the message headers that determines this? (True/False?)

Is it a hidden setting in message headers?

Is it determined based on timestamps? (Modified/Accessed dates)

Is there a way to forensically distinguish between a message that was truly unread, or that was “mark as unread”?

 

If anyone has any resources or ideas, please let me know. I’d love to learn about it.

 

MoVP

Volatility (in chemistry) — the property of changing readily from a solid to a vapor
Volatility (in finance) — a measure of price variation over time
Volatility (in technology field) — when memory loses its contents when the device is turned off
Volatility (in computer forensics) — an open source set of forensic tools used to extract artifacts from memory used for incident response and malware analysis
Volatility (in Corrie’s world) — being easily excited and excitable…about the next 4 weeks

This month, Volatility (the forensic kind) is starting the Month of Volatility Plugins (MoVP) where they are releasing new plug-ins every day in anticipation for the new release of Volatility 2.2. According to the blog, “Each plugin will describe a brand new capability exclusive to Volatility that deals with analyzing Windows or Linux RAM dumps for malware infections or compromises.”

Sound pretty neat. They’ve only released three new plugins, and already it looks pretty neat. Take a look!

http://volatility-labs.blogspot.com/2012/09/month-of-volatility-plugins-movp.html

AccessData’s MPE+ Potential

Eventually we will be getting AccessData’s Mobile Phone Examiner Plus as part of our forensic toolset in the lab. I’m not a huge AccessData product user (even though I just got re-certified as an AccessData Certified Examiner today) so I know basically next to nothing about the product. I participated in a Webex that AD presented on the tool, and I surprised myself when I realized I’m excited to use it.

The difference between EnCase’s Smartphone Module and AD’s MPE+ is that EnCase supports phones based by operating system, whereas AD supports media by manufacturer and model of the phone. My first intention is that EnCase would be a better solution because there are zillions of smartphones, with new ones being released every week. How can MPE+ keep up with all the new technologies? Theoretically, EnCase would be able to support a wider range of mobile devices since it parses information based on a handful of operating systems (which usually update less frequently) as opposed to trying to support thousands of phones being released. Although, there were plenty of things I learned in the Webex that caught my eye and made me all giddy inside:

  1. It supports 3,500+ phones. With some afterthought, our company only uses a certain few types of phones, so worrying about support with over 3 thousand options is behind me.
  2. It supports phones running Android, Windows Mobile, iOS, Symbian, and Blackberry (as well as SIM cards, and blackberry/iOS backup files)
  3. There is a TABLET version, which has the software installed so you can do mobile phone analysis in the field — COOL!
  4. There is an auto-update prompt at startup if there are any new releases. This might run into a problem at our lab because our forensic machines are not connected to any network, so updates will have to be checked and installed frequently.
  5. When you add a phone, it shows a picture of the manufacturer and model you selected. I like this as a verification that I selected the correct phone I’m trying to analyze.
  6. Once a phone is added, the acquisition can be exported as an AD1 image if I decide to analyze the contents in FTK.
  7. If a phone is jailbroken (iOS) or rooted (Android) MPE+ is able to take a PHYSICAL image of the device (something EnCase is not able to do…they only support logical acquisition)
  8. MPE+ supports a whole slew of image formats — E01, DD, AD1, etc. This is awesome if lets say I image a phone using EnCase or the Oxygen Suite, I can throw it into MPE+ and examine the contents using the parsing tools that’s built in
  9. It has the ability to play videos within the interface — as opposed to opening an external application like Windows Media Player
  10. It allows you to data carve within the folders and files
  11. It parses by OS for folders that hold valuable information, even protected data files, and will pull all of the information out and display it into a spreadsheet-esque report for easy viewing
  12. It will (unofficially) support hard drive images, like Mac for example. You add the image to the MPE+ case as if it was iOS, then use the tools to extract data
  13. Password protected device? MEH! It has brute-force password cracking options built-in.
  14. Android has what is called as “Forensic Files” which allows you to see the protected user data that wouldn’t normally be seen on the phone (like Google contacts, for example)
  15. It has Android support for multiple partitions. Aka, you can see every partition that’s created on the device (which is normally hidden)
All-in-all, I’m super excited to get this tool in the lab. I was a bit weary at first, but this thing seems PRETTY nifty! =D

EnCase 7: Smartphone Frustrations

We recently upgraded to EnCase 7, and now with smart devices becoming a hot commodity in the business, there’s a need for smartphone analysis. Now, I haven’t done much with smartphones when it comes to acquiring them (anything I have done has been infrequently on a Celebrite) so playing around with version 7’s new smartphone functionality has been, a bit challenging.
My first fight was with iOS. Understandably, I needed to install iTunes on the forensic machine so that the device would be able to talk with the Windows machine. I got that. That was fine. I first tried an iPad. Everything worked great — it acquired, I was able to pull information, and EnCase was able to put it in a report format for me. Awesome. I next played with an iPhone (which had the same iOS version, settings, apps, etc., mind you) and ran into all sorts of difficulties. I entered the passcode for the iPhone to unlock it (just as I had done with the iPad) but the contents seemed to be encrypted. I was able to read the names of the files, but the contents were all jibber-jabble. As I said before, the settings were all the same on the iPhone as they were on the iPad, and the backups weren’t encrypted, so what’s the problem? Why would the iPad read perfectly fine, but the iPhone not? Mysteries Mysteries…
Today I tried acquiring a Blackberry. Once again, I got nowhere significant. EnCase was able to detect it, but wouldn’t acquire it. After research, I found that I also needed to install a program and/or driver for Blackberry, since Device Manager recognized it, but I wasn’t able to access it. The driver I needed was included in a Windows Update (which I cannot perform because our forensic machines are not connected to any network) so further research continued. A few forums mentioned installing Blackberry Desktop to help the computer talk with the Blackberry, but ran into issues installing that, with error after error during the install (“The installation files cannot be validated. Please verify the installer package and try again.”). Websense blocked a few websites which Google displayed having an answer for these errors, so at the time I dropped the project. Now, I might have a solution to the digital signature problem with the Blackberry which I will try tomorrow.
My experience with the EnCase smartphone suite was not an easy task. Maybe it’s because I’m inexperienced (I just got my first smartphone a couple weeks ago) or because EnCase’s tool isn’t all that great. I’m going to look into and play around with Oxygen Forensic Suite to look at their mobile forensic solution, in anticipation for AccessData’s Mobile Phone Examiner Plus software to be installed and tested.