This paper will introduce the Property Lists in the Apple OS X and compare them to the Microsoft Windows Registry. Also within this paper we will examine how important some of the Property List can be to an examination. Examples of crucial information that can be found within Property List will be presented.
Let it be noted that this paper is by no means a complete look into the property lists and Mac OS X. All information looked at this in this paper has been the product of personal research. All opinions expressed in this paper are those of the authors.
The Importance of Plist Examinations
In 2007, Derrick Farmer, a Champlain College student, wrote a paper entitled A Forensic Analysis of the Windows Registry. This paper explored some of the key locations of where vital information could be found during a computer investigation. In Farmers paper, he explores areas of the registry pertaining to the location of autorun locations, recent items, wireless networks, Internet history, and 3rd party software that has been installed on a Windows machine. In todays world, Macintosh (Mac) computers are becoming very popular. For this reason, it is important for forensic examiners to understand where they can find similar information in Mac OS X as they would find in Windows. Property Lists are very similar to that of the Windows Registry. These files contain information that can make or break a case. In this paper I will be comparing the Mac version to the Registry entries found in Windows.
First off, it is important to know what a Property List (plist) actually is, and the type of information that can be stored within them. Apple Developers describe the plist as follows, property lists organize data into named values and lists of values using several object types. These types give you the means to produce data that is meaningfully structured, transportable, storable, and accessible, but still as efficient as possible (Property List Programming Topics, 2008). Plists can be considered the registry for OS X. A little later we will explore the structure of a plist file. The information contained within these files is different for each program on the system. Each contains the settings for the program, which calls the plist. Similar to Windows Registry entries, if you change any value set in the file, the program will run differently. It should be noted that plist are not a Mac OS X item. They are actually found within Linux and Unix distributions.
Structure of Property List
Plists can take one of three different formats. The most recent, and more common, format one will see is the XML format. This format is more portable then that of the alternatives and can be edited manually where as the other two options are not. The other two formats are binary and ASCII. Binary formats are still used today but, one will rarely find an ASCII formatted plist. Binary formatted plists will perform faster if the plist is a large collection of data. Figure 1 below shows the XML formatted plist viewed using the program TextEdit, which comes installed on all Macs. It is obviously very hard to read in this format. If you were to open this same file in a plist editor one can clearly see the structure of the file better as seen in Figure 2.
Figure 1 TextEdit
Figure 2 Plist Editor Pro
Plists can be composed of one or two forms of structured data, Core Foundation or Cocoa. Core Foundation is described as follows by Apple Developers, Core Foundation is a procedural C framework that is conceptually modeled on the object-oriented Foundation framework in Cocoa and that uses the abstraction of the opaque type as a procedural analog to an object (Getting Started with Core Foundation, 2006). Cocoa is described as follows by Apple Developers, Cocoa is Apple’s name for the collection of frameworks, APIs, and accompanying runtimes that make up the development layer of Mac OS X (Cocoa). For more information on Cocoa and Core Foundation, please refer to the links in the reference. Figure 3 below shows a table of the plist types and various representations.
There are many different tools available to forensic examiners to use for plist examinations. The tools used in this paper to analyze and parse through the plist files are Fat Cat Softwares Plist Edit Pro and Echo Ones File Juicer. Plist EditPro has a free trial period that was used for this research and can be obtained from http://www.fatcatsoftware.com/plisteditpro/. File Juicer also has a free trial period that was used for this research paper. File Juicer can be obtained from http://echoone.com/filejuicer/. Both programs were fully functional during the trials.
Plist as Logs
In most cases, data is only written to plists on the initial install of a program or when OS X is first installed. In all other cases plists are written each time a program is run. For the purpose of this paper, the plists that are being looked at are updated each time they are used. We will be looking at plist files related to the following: autorun locations, recent items, wireless networks, mounted devices, Internet history, and installed programs, as they relate to their Mac OS X equivalent locations.
Derrick Farmer defines autorun locations as Registry keys that launch programs or applications during the boot process (Farmer, D, 2007). This has a very similar meaning in the Mac world. On a Mac, the location of this information is in the loginitems.plist. An examiner should look at this location to see what programs or applications are of any evidentiary value to the case. For the most part, when someone installs a program on a Windows machine, the program has a default setting of starting on boot. For example, AOL Instant Messenger (AIM), when installed, will automatically start on start-up unless told otherwise. On the Mac side of installations, this is not as accurate. If one wants to have a program start on login/boot, they must tell the program to do so. It would be beneficial for examiners to look at the startup items, as it would be proof that the user of that Mac intended for the program to start on login/boot. The loginitems.plist can be found in the following location: /user/Library/Preferences/com.apple.loginitems.plist.
In the Windows environment, the registry contains entries for Most Recently Used (MRU) list, and User Assist. The MRU is a list of recent programs and files accessed. Multiple lists are created throughout the registry. MRUs are similar to the history that one can view in an Internet browser. The sites that have been most recently visited are kept in a list for the user to go back to if needed. In addition to the MRU, Windows has the UserAssist entry. This entry holds information about the most frequent programs used by a user. These entries are actually encrypted using the ROT-13 algorithm. To learn more about ROT-13, please visit the following site: http://en.wikipedia.org/wiki/Rot13.
In the Mac environment, these lists are more limited. During the research for this paper, only one location could be found with recently open items. Within the /user/Library/Preferences/com.apple.recentitems.plist, the last 10 accessed applications, documents, hosts, and servers are listed. Within the settings for each section, a user can increase or decrease the amount of records that are kept. By default, Mac OS X keeps track of the last 10. Figure 4a below shows an entry into the applications section of the plist. Figures 4b and 4c show the most recent files opened and hosts connected to, respectively.
Figure 4a Most Recent Application Run
Figure 4b Most Recent File Opened
Figure 4c Most Recent Host/Computer Connected to
The information that can be found in this plist, unfortunately is only available as long as it been one of the last items opened in its respective section. Although, it can be beneficial for an examiner, if the user has only connected to a select few hosts.
In a forensic investigation, being able to determine if a suspects computer was connected to a wireless network could be of evidentiary value. The SSID or service set identifier is recorded for all wireless networks that are added to the users preferred network connections. This can include connections to Wi-Fi hotspots at Starbucks or similar hotspots. In the Windows Registry, SSIDs are stored in one key and the settings, such as the IP address, subnet mask and other information about a particular network is stored in another key. This is similar on a Mac. The two important plists to look at can be found at the following locations: /hd/Library/Preferences/SystemConfiguration/com.apple.airport.prefrences.plist and /hd/Library/Preferences/SystemConfiguration/com.apple.network.identification.plist. By using the two of these files together, an examiner can see the last date that the computer was connected to that network by looking at the com.apple.airport.preferences.plist. For example, figure 5a shows the SSID of 3dd. Also, you can see that the security type and password are shown. The password is hashed.
Figure 5a com.apple.airport.preferences.plist
Once the examiner has the timestamp found in the Airport Preferences plist, they can then go to the Network Identification plist. In there they will find the corresponding date on an entry to find out more information about the network including: DNS servers, IP address, the interface used (wired or wireless), subnet mask, and router IP. Figures 5b-5d show the information.
Figure 5b Timestamp Match to figure 5a
Figure 5c DNS servers connected to
Figure 5d IP address obtained, router IP and Subnet Mask
Based on the above information, an examiner can determine if or when a suspect was connected to a network. An examiner can use the DNS Servers to find out the Internet Service Provider (ISP) to which the suspect connected to the Internet with. Many ISPs keep record of the hardware address that is obtaining an IP address from them. By getting a subpoena, an examiner can get log histories for the owner of the network.
USB devices and other mounted devices, such as CD/DVD installers, are almost an everyday occurrence now. A feature of the USB devices registry key found on a Windows machine is that the serial number for the USB device is recorded, making it easier to prove that a certain USB was connected to the suspects computer. Some USB devices dont have a serial number so a random string is created in place of the serial number. On a Mac, this is not true. While a Mac does recorded that a USB device was connected to a machine, it does not record the serial number of that device. On the Mac, the plist /user/Library/Preferences/com.apple.finder.plist, shows all devices, whether it is a USB device, image, CD, DVD, or iPod, that are connected to the computer while logged in as a certain user. In this plist, the location of where the Finder opened the item is recorded under the FXDesktopVolumesPositions Key. The Finder is Macs version of Explorer in Windows. If a USB device or CD has an unique name, this plist is useful to show that at some point, the device was mounted on the suspects computer. In figure 6a you can see Volumes that were mounted. Volumes can include USB devices, CDs, DVDs, and iPods.
Figure 6a Volumes Mounted
When a user downloads a program on a Mac, a .dmg file is opened in order to install the program. This is equivalent to an installed .exe in Windows. On the Mac, these files are mounted in order for the user to see the install program. These files are also noted in this plist. Figure 6b shows an example of some .dmg files that have been mounted.
Figure 6b Software DMG’s
An examiner can use this list to see if software was ever downloaded onto the computer. For example, if an examiner is looking through a Mac to see if any kind of encryption software has been installed, it can be seen here that TrueCrypt was downloaded and mounted at some point. If the suspect says they have never looked into encryption software, the examiner can prove that they have.
In todays music loving world, many people now have some form of MP3 player. With the advancement of technology, criminals are starting to hide information on iPods. On the Mac, the following plist can be informative to an examiner: /user/Library/Preferences/com.apple.iPod.plist. With this file, the examiner can verify if an iPod has been connected to that computer. In figure 7 you can see that an iPod has been connected to the computer.
Figure 7 iPod Information /user/Library/Preferences/com.apple.iPod.plist
With the information found in the above plist, an examiner can check the serial number to an iPod to see if it has been connected. If, in a case, a suspect states that they do not have an iPod, this file can show that an iPod has been used. The connected date shown above, shows the last date the iPod was in use on the suspects computer. The examiner can also prove how many times the iPod has been connected to that computer by the use count variable shown above.
Safari is the native Internet browser on a Mac. This is similar to Internet Explorer on a Windows machine. In Windows, the Internet Explorer Registry key has three subkeys, which include: main, typedURLs and download directory. On a Mac, Safari has a similar setup. Plists related to browsing history, download history, and cookies, each have their own location. In Internet Explorer, temporary internet files are stored as cache files, which is similar in Safari. These file are located in /user/Library/Caches/Safari. Using File Juicer, an examiner can view the contents of the caches files. File Juicer will take the Cache.db file found in the locations previously mentioned and parse through it, breaking cached items into folders of similar extensions. Figure 8a shows the folder created once File Juicer has processed the caches data.
Figure 8a File Juicer Results
The above listed index.html file, is a webpage created by File Juicer that contains all images found in the Safari Cache. This program makes it easier for an examiner to parse through potential evidence.
Another great place to look for evidence is the browser history. The plist found at /user/Library/Safari/History.plist provides an examiner with the Safari browser history. Figure 8b shows an example of the record in the plist.
Figure 8b Browser History
From the information found in this entry, an examiner can tell that the user visited this site nine times. The value found in lastVistedDate is formatted in absolute time and date. This can easily be converted using a program such as CFAbsoluteTimeConverter. This program can be downloaded from the following link: http://www.hsoi.com/hsoishop/software/. All that needs to be done is copy and paste the value into the program. The above value is converted to tell the examiner that the page was last visited on Sunday 07 September 2008 10:41:04 am. Time and dates are always great supporting evidence to help prove a suspect committed an act.
The downloads.plist file is another file for the examiner to look at for evidentiary information. This file provides an examiner with files that were downloaded using Safari. This plist can be found in the /user/Library/Safari/ directory as well. When looking at the information found in this plist, an examiner can prove that a program, such as Limewire, has been downloaded on the suspects computer. Figure 8c shows the entry in the downloads.plist that can prove that Limewire was indeed downloaded.
Figure 8c Download.plist
These files are great places to look for evidence. In Safari 3.2.1, similar to Internet Explorer 7, users can now clear all cookies, download history, cache, and all the great information examiners look for. If the user is smart enough to do this, the above plists get cleared and are of no use to an examiner.
When looking at alternative web browsers, such as Firefox, Opera, and Netscape, on a Windows machine, the information is recorded differently. On a Mac, this is similar. Since Firefox is not the native browser, information is stored differently. This folder can be found at /user/Library/Application Support/Firefox/Profiles. An examiner can take the profile folder and run it through File Juicer. File Juicer will again parse through all the files and provide the examiner with a folder with items in their respective folders. One difference here is when a user tells Firefox 2.0 or higher to clear its history, caches, etc., the typed URLs are not cleared. A list of these URLs can be found in File Juicers subfolder named URLs. If an examiner looks at the HTML page created, they will see a list of all URLs that the enter key has been hit for. An example can be found in figure 8d.
Figure 8d URL’s
Other browser, such as Opera and Netscape, are similar to Firefox. They have a folder in the application support, which can be found to contain all information needed.
Similar to the Windows world, when a user installs a program, a folder is then created for that piece of software. In Windows, the folder is usually created in the program files folder, and contains executable and other important files. Some files may also be placed in other directories. On a Mac, the executable is placed in the applications folder, and all other important files needed to run the program are placed in the application support folder found at /user/Library/. In Windows, for the most part, when a user uninstalls a program, all files and folders related to that program are subsequently deleted as well. On a Mac, this is not true. When a user uninstalls or deletes a program, all they are doing is removing the executable from the applications folder. The application support folder will still contain all of the files associated with that program. The examiner can now go in and see what programs have been installed on the machine even if the program has been deleted.
Just to show what some of the information that can be found in the application support folder, we will take a look at the folder for the program Adium. Figure 9a shows the Adium Folder.
Figure 9a Adium Application Folder
An examiner should be interested in the usernames that are associated with an instant messaging program like Adium. When the users folder is opened, the default user is the only one listed. When that folder is opened, an examiner has access to all of the settings and accounts that have been setup. Figure 9b shows the account setup under the default user account.
Figure 9b AIM user account
With the program Adium, a user can setup accounts for Facebook, MSN, Jabber, Yahoo and many others. If a user has setup multiple accounts, they would all be listed in the account.plist.
Within this users folder, there is another folder for logs. This log folder contains chat logs for every screen name the user has talked to. The chat logs are formatted as XML sites. Figure 9c shows part of a chat log.
Figure 9c Chat log
An examiner can use these logs to see the time and date of when a message was sent. Also by looking at the above figure, the examiner can see the user who sent the message and if the user has setup an alias for the screen name they are talking to.
The following list includes all of the plist entries that were discussed in this paper.
user folder /Library/Preferences/com.apple.loginitems.plist
user folder /Library/Preferences/com.apple.recentitems.plist
user folder /Library/Preferences/com.apple.finder.plist
user folder /Library/Preferences/com.apple.iPod.plist
user folder /Library/Caches/Safari
user folder /Library/Safari/
user folder Library/Application Support/Firefox/Profiles
user folder /Library/Application Support/Adium 2.0/Profiles
With the growing popularity of Macs in todays technological world, it is important that Forensic Examiners have the knowledge of the location of potential evidentiary information on a Mac. Having a basic knowledge of the Mac OS X file structure and Linux file structure will only help an examiner comprehend what they are looking at. By knowing where the information is and how to interpret that information, an examiner can be confident when going into an investigation that involves a Mac. The files discussed in this paper are only a few of the many possible evidentiary locations that an examiner should look at.
Cocoa. (n.d.). Retrieved April 5, 2009, from http://developer.apple.com/cocoa/
Farmer, D. (2007.). Computer Forensics – A Forensic Analysis Of The Windows Registry. Retrieved March 1, 2009, from http://www.forensicfocus.com/a-forensic-analysis-of-the-windows-registry
Fat Cat Software – PlistEdit Pro. (n.d.). Retrieved March 6, 2009, from http://www.fatcatsoftware.com/plisteditpro/
Getting Started with Core Foundation. (2006, November 7). Retrieved April 5, 2009, from http://developer.apple.com/referencelibrary/GettingStarted/ GS_CoreFoundation/index.html#//apple_ref/doc/uid/TP30001089
Hsoi’s Shop: Software . (n.d.). Retrieved April 5, 2009, from http://www.hsoi.com/hsoishop/software/
Mac OS X Manual Page For plist(5). (2003.). Retrieved March 6, 2009, from http://developer.apple.com/documentation/Darwin/Reference/ManPages/man5/plist.5.html
Property List Programming Guide: About Property Lists. (2008.). Retrieved March 6, 2009, from http://developer.apple.com/documentation/Cocoa/Conceptual/ PropertyLists/AboutPropertyLists/chapter_3_section_1.html#/ /apple_ref/doc/uid/10000048i-CH3-SW2
Property List Programming Topics for Core Foundation: Introduction to Property List Programming Topics for Core Foundation. (2008.). Retrieved March 6, 2009, from http://developer.apple.com/documentation/ CoreFoundation/Conceptual/CFPropertyLists/CFPropertyLists.html
Read Me – File Juicer for Mac OS X. (2008, December 30). Retrieved March 2, 2009, from http://echoone.com/filejuicer/ReadMe
ROT13 – Wikipedia, the free encyclopedia. (n.d.). Retrieved April 5, 2009, from http://en.wikipedia.org/wiki/Rot13
(2008). Mac OS X, iPod, and iPhone Forensic Analysis DVD Toolkit. US: Syngres
Below you will find a table showing the Windows Registry Key location and the Mac OS X plist location of the information discussed in this paper.
Law enforcement officers seek to locate the proverbial smoking gun as a means to close each investigation. The smoking gun is the one item that proves, without a doubt, the party responsible for the crime. In the cyber world, the computer is analogous to the gun. Therefore forensic examiners have naturally focused their considerable skills on possessing the computer, rather than capturing the data. In doing so, these examiners taught the necessity of pulling the plug on the computer to minimize altering any potential evidence. Pulling the plug is no longer a sustainable preference. In fact, given the modern threat environment, pulling the plug on a running system that is not actively destroying data borders on malfeasance. The data that is lost when pulling the plug can be the difference between catching the criminal or having him walk free. The gun or computer in this case, may not contain any bullets once the power is off, so catching the smoke, (volatile data) may be the only way to identify exactly what was occurring during the crime. In todays investigations the smoke is often more important than the gun. This is the art of incident response and when done correctly, the smoke may end up blowing right back into the criminals face.
By understanding the threat environment, defining and identifying the characteristics of incident response, and discussing appropriate response strategies, this article will demonstrate that appropriate incident response is imperative to modern investigations. In essence, this article will discuss how to catch the smoke from a gun.
The Threat Environment The combination of complex communication networks, anti-forensic tools, encryption and criminals willing to do anything to avoid capture defines the modern threat environment. Indeed the ability for these criminals to hide their nefarious acts has never been easier, making incident response more important than ever.
Definition of Incident Response It is obvious, given the threat environment, that the accepted forensic process of pulling the plug has become increasingly damaging to the investigation. Therefore it is important to clearly define what constitutes incident response. For the purpose of this article, incident response is defined as those actions taken, on a running computer, by the investigator, focused on stopping destructive activity, obtaining volatile information, and preparing the machine for further forensic examination.
Characteristics of Incident Response Incident Response is characterized by a dynamic environment that requires a higher level of skill to successfully negotiate, and given the ever diminishing nature of the data concerned, present the best chance of obtaining data critical to the investigation. Furthermore, the proliferation of computing technologies has made it impossible for only highly trained computer forensic examiners to respond to every digital crime scene, making the responder undertrained for the mission. The combination of environmental complexity and nontechnical responders is a recipe for disaster without the proper planning.
The Scene Law enforcement officers will face one of the following scenes during his duties; the computer is running, computer is in a suspended state and computer is off. Furthermore there are categories defining the state of the running computer; computer is performing intentionally destructive activity, computer is performing unintentionally destructive activity, and computer is running normally. Furthermore, there are additional considerations for modern law enforcement officers. Encryption, remote shares, networked devices, wireless access points, alias commands, booby traps, and more. All theses considerations combine to make the scene a complex, uncertain environment for the responder.
Response Strategies It is imperative that some form of incident response be performed on scene whenever there is a running computer. As such broad guidelines can be established. Assuming officer safety has been accounted for the on-scene assessment must be made to determine the requisite course of action. This is similar to emergency medical personnel arriving on-scene of an accident. The medical personnel use the ABC (airway, breathing and circulation) acronym to assess injuries and establish priorities of work. In the digital crime scene, the priority of work is centered on preserving potential evidence. By following the acronym STU responders of the digital crime scene now have an approach to effectively control the scene. STU stands for Stop destructive activity, Take volatile data and Unplug the system for removal to a lab for further analysis.
The actions the responder takes to stopping the destructive activity depend on the type of destructive activity. If the destruction is intentional, the only viable option may be to pull the plug on the system. If the destructive activity is unintentional it may be as simple as stopping a running process, removing a network cable or even removing liquid spilled on the computer. Once the destructive activity has been stopped, and if the computer is still running, the responder has a chance to capture the volatile data.
Capturing volatile data on a system can be accomplished manually or through automated tools. By comparison, manually capturing volatile data represents a much higher risk as it is prone to typing and user errors, has a greater affect on the digital crime scene and takes substantially longer to perform. Automated tools provide the best chance for successfully capturing volatile data in the digital crime scene. The best example of an automated incident response tool is MacLockPick. MacLockPick is the only cross platform tool designed with a plug-in architecture to allow for variations on the scene and the expanding needs of an organization. For additional details concerning MacLockPick visit (https://www.MacForensicsLab.com)
It should be made clear that although the volatile data is extremely important, it may not represent a complete picture of the digital crime scene. As such, the computer must be unplugged and moved to a forensic laboratory for detailed analysis.
Responding to the Live Macintosh Computer
As previously mentioned there are commonalities regardless of operating system, when responding to running computers. However, the differences can be enough to stop the investigation dead in its tracks. There are several features to consider when approaching a Macintosh computer; the keychain, FileVault, the kernel and disk arbitration are some of the most important features unique to the Macintosh.
The Keychain Macintosh computers take a centralized approach to password management. Passwords are managed through a keychain. A user can have an unlimited amount of keys. The keychain login is the default and as such opens upon user login. Furthermore, the keychain remains unlocked while logged in, granting access to all keys in the keychain. These default settings must be explicitly changed by the user. The ability to access the keychain and all the subsequent passwords is one of the primary goals of responders to a Macintosh system.
FileVault Macintosh computers running Mac OS X can turn on FileVault. FileVault is a program that encrypts a users home folder using 128-bit encryption. By default all data generated by a particular user is stored in their user folder. Once FileVault is enabled it requires a Master Password to be set for the user. The Master Password allows the user to unlock the FileVault container, which is seen only as a sparseimage. If the Macintosh is running FileVault and the responder pulls the power on the computer without knowing the password, the user folder will become completely inaccessible to the forensic examiner.
The Kernel Mac OS X is a fully compliant UNIX operating system. As such, there are a myriad of processes, logs and scripts that are running at any given time. Furthermore, the responder has access to these directly through the built-in Terminal application. It is important to appreciate that UNIX systems have scheduled maintenance operations controlled by cron and that these operations can inadvertently destroy data that may be of consequence in the investigation. Therefore, timely response to the system is paramount. Additionally, Mac OS X has a wide variety of logs containing critical information pertaining to the system, networks, connections, and more. The default shell for Mac OS X (10.4 and higher) is bash. In previous versions of Mac OS X the default shell is tsch. The default shell is important to the responder that uses the Terminal application to gather critical data as each shell has its own set of commands and capabilities.
Disk Arbitration The Disk Arbitration service is run by the Disk Arbitration Daemon. This daemon attempts to automatically mount any device attached to the computer. By default all devices mounted by the Disk Arbitration Daemon on mounted onto the Desktop. As a responder, it is vital to observe the Desktop for any devices mounted there. Equally important, any device the responder attempts to connect to the system will be mounted unless the Disk Arbitration Daemon issue is adequately addressed. The responder may choose ignore Disk Arbitration, allowing it to run as designed and opt to account for any devices mounted by the responder by means of investigative notes.
These Mac-specific features provide the responder powerful tools to perform a manual analysis and allow the automated tools such as MacLockPick to perform an in-depth data capture. Regardless of these unique features, the responder should still follow the STU process as it is operating system and environment neutral.
As the world of technology continues to alter society, the digital crime scene bends with it. The increasingly complex communications networks and remote storage have made locating and preserving data challenging. Specifically the type, location and state of data have made the art of Incident Response arguably more important than the follow-on forensic examination. As such, every organization should consider incident response as the first critical step in the forensic process, rather than a token procedure to that can be skipped based on the incorrect assumption that they can gain access to the data later. Organizations that embrace incident response, follow the STU process and seek to employ automated tools such as MacLockPick will have the best chance of catching the smoke from the gun and making major steps forward in combating cybercrime.
This document discusses the technologies used in malware. These include viruses, Trojans and worms. The specific intention is to bring forth detailed discussion on how this affects the Apple Mac OS X platform. The document outlines a potential framework for a Mac OS X malware suite. The document closes with recommendations on what Apple Inc, and users of Mac OS X can do to defend against such technology.
This paper was created to outline the results of research performed by the MacForensicsLab.com research and development team. These results are presented to the public in order to raise awareness of the situation and to prompt the relevant responsible parties to address the issues outlined within.
The MacForensicsLab.com staff and SubRosaSoft.com Inc consider it important to bring such discussions out into the public and welcomes all opportunities to discuss the paper on firstname.lastname@example.org.
Apple Inc. and all third parties discussed in this paper do not endorse this content and they did not cooperate in the production of this paper. All trademarks contained within this paper remain the property of their respective owners with all rights reserved.
In the early days of computing the term hacker was used to describe those with a deep understanding of the core functionalities that comprised a computer system. These hackers were able to apply this understanding to enable computers to perform in a manner which was previously unimaginable. Therefore, these hackers were a fundamental catalyst for the change and growth of modern computer systems and the Internet.
The term has been degraded over time to be generally limited to someone who targets system security and ways to get around it. In modern times it has come to include people using tools they did not produce in order to cause damage or nuisance to computer systems.
Academia The Study And Creation Of Malware
The academic world of computer science has been at the forefront of the discussion and definition of malware since the first virus was discovered. Universities became perhaps the first victims of malware and consequently the first defenders against them.
Some notable academics in the early days include:
1980 Jrgen Kraus, a computer science student at the University of Dortmund, wrote his master’s thesis on Selbstreproduktion bei Programmen, [Program Self-Reproduction]. This thesis is the first study to show that certain programs can display behavior similar to that of a biological virus.
1981- 82 Professor Len Adleman, of USC, employs the term virus to describe self-copying programs when discussing them with Fred Cohen, his computer science student.
1981 – 82 Joe Dellinger, a student at Texas A&M University, writes several self-reproducing programs for Apple II disks, naming them Virus 1, Virus 2 and Virus 3.
Apple Computer Inc. had a very strong presence in the academic community throughout the early personal computing era. The use of the Apple platform in the development of malware is an extension of its overwhelming presence in the academic arena.
Hax0r The Growth Of The Script Kiddy Generation
As home computer use grew, a new generation of hackers arose. These young hackers represented a fundamental change in ability, ideology and intent from their predecessors. The new generation of hackers is referred to as script kiddies. The name script kiddies is a descriptive term, popularized by the original hacking core, as a means to reflect their general disdain of the new generations lack of understanding of the core concepts of computing and their inability to create tools of their own.
An Apple Users Perspective
Apple Computer Inc. was given the historic honor of being the first computer to bring virus technology into the home when Richard Skrenta wrote Elk Cloner in 1982. This program attached itself to the Apple DOS operating system of the time and spread via floppy disks.
[Figure 1 The message shown on every 50th boot on disks infected by Elk Cloner]
Prior To The Mac
The story of the early years of Apple Computer Inc. and the relationship between the founders Steve Jobs and Steve Wozniak cannot easily be told without including hacking and underground technology. From the days of the BlueBox, a device designed to fool the telephone systems of AT&T into providing free long distance phone calls, through the creation of the first commercial home computer in a garage in what later became known as Silicon Valley.
Apple Inc. and the modern high tech lifestyle we all enjoy today were founded by (so-called) old school hackers.
Figure 2 This blue box, on display at the Computer History Museum was previously owned by co-founder of Apple Computer Inc.  Steve Wozniak. Steve once used this to impersonate Henry Kissinger in a prank call to the Vatican City. The Pope was reportedly asleep. 
The Mac Classic operating system (any version prior to version 10, Mac OS X) enjoyed a long life and a wide user base from the initial release in 1984 to the first desktop version of Mac OS X in March of 2001. This operating system revolutionized the way we work with personal computers offering many of the user interface concepts taken for granted today.
During the lifetime of Mac OS Classic many varieties of malware were developed to take advantage of the user base including some very notorious viruses such as nVir in 1987. The nVir author(s) released the source code for their work resulting in a large proliferation of derivatives causing wide and varied effects in the field.
The wide spread introduction of viruses for Mac OS at this time brought forth the corresponding large number of anti-malware tools that are stillaround today. These tools scan for code found within known viruses and eradicating them when found.
Apple Computer Inc. made changes to the operating system to stop some of the methods used by viruses on Mac. Perhaps the most notable change was to stop autorun, a technology still present on Microsoft Windows that will automatically execute programs when a disk is inserted.
Mac OS X (Including Mac OS X 10.5 Leopard)
All successful, and most plausible, malware attacks on Mac OS X have occurred in the last 2 years with the last quarter of 2007 being particularly prolific. Market penetration and overall sales of the Mac OS X system have directly mirrored development of malware, a phenomenon also demonstrated with other operating systems such as Microsoft Windows. Based on this data there is no reason to believe the trend will not continue as Apple continues to increase their market share.
The concept of the economy of scale has historically meant that malware authors have not previously considered the Mac a viable target. This protection is being eroded by the increase in size of the Mac user base.
IDC analyst Chris Christiansen is warning Mac users of the growing threat.
This century has seen significant changes in the hacking community with an overall trend away from the technology enthusiast to the organized crime rings committing mass fraud and global extortion on the global digital marketplace. This change in culture has brought with it many changes in focus for the modern malware author.
Malware is now being used to steal information, and thus property, from a users system. These types of attacks range from simply extracting the requisite personal information to assist in identity theft to more complicated attacks known as phishing whereby the malware pretends to be a trusted service such as a bank or service provider in order to steal from an external resource.
Organized crime groups are using malware in order to extort payment from system owners and operators. Large collections of infected systems can be used to cause servers and systems to become inoperable by flooding their connections with traffic, thus cutting off desirable traffic, or by overwhelming a systems resources.
The criminals use malware to convert innocent users systems into virtual soldiers in their army of computers. These armies are called bots, bot networks, or bot nets, and can sometimes number into the tens of thousands . This is generally done without the user being aware they have joined into the network of bots.
Global Cyber Terror
This century has seen the rise in state-funded cyberterrorism. There has become a very high potential for cyberterrorism to impact our economy and our society in ways that are difficult to define.
A virus is a piece of software that attaches itself to another program (the host) then uses the ability of the host program to self-replicate. Stephen Hawking once said that a virus should count officially as a form of life adding  I think it says something about human nature that the only new form of life we have created so far is purely destructive. Weve created life in our own image.
The name for this variety of malware is derived from the Latin word for toxin. The medical community defines a virus is an infectious agent that is unable to replicate or grow outside of a host cell.
How They Replicate
A computer virus will generally execute when the host program is executed. The first priority is to look for additional hosts and to copy itself into them. The second priority is often, but not always, to execute its payload. Payloads vary heavily from the harmless to full cyber terrorism and have historically included such functions as erasing the entire system, stealing personal information, or simply declaring their existence (digital graffiti).
Macs Are Vulnerable
The primary requirement of a virus is a host program into which it can write itself. The Mac OS X platform makes little or no effort to protect the main applications on the system (in fact, as discussed later, it actually makes it easy through the use of the bundle architecture.)
What Defines A Trojan
A Trojan, or more accurately Trojan Horse, is a piece of software that contains a hidden payload. The word ‘Trojan horse’ is generally attributed to Daniel Edwards of the NSA. He is given credit for identifying the attack form in the report “Computer Security Technology Planning Study”.
The name for this variety of malware is derived from the Greek legend where Odysseus had a giant hollow wooden horse and hid his soldiers inside. The people of Troy believing it to be a gift brought the horse inside their city and their defenses.
What They Do
In computing terms the concept is identical to the legend. The malware is able to enter the users system and bypass security measures be pretending to be something the user wants. Once the user executes the malware on their computer the hidden payload can perform the function desired by the malware author.
Macs Are Vulnerable
The definition of a Trojan makes defense very difficult. The weakness in any system defense starts with the user and a Trojan defines its attack by exploiting that weakness.
Early versions of Mac OS X had little or no protection against a Trojan attack. The effect a Trojan could have on the system was limited to the users data and the applications installed on that computer.
OS X 10.5 Leopard introduces new sandboxing technology to show a dialog box to the user before running any new program downloaded from the Internet. Software downloaded from the Internet, both from the mail and from browser applications, is marked as suspicious and will not be executed until the user clicks on a confirmation dialog box to explicitly allow it to run.
SubRosaSoft.com Inc. extended this paradigm to sandbox all applications, not just ones downloaded from the internet.
Other commercial software vendors (such as Symantec, McAfee, and Intego) offer varying technologies to assist in this area. More information can be found at the companies respective web addresses:
A computer worm is similar to a virus in that it is self-replicating, but different in that it does not require a host program to exist. The first computer worm was defined and produced by researchers Jon A. Hupp and John F. Shoch at Xerox PARC in 1978. The worm was created to search a network to find idle processors so that they could share the processing load of large operations across an entire network, but was self-limited to their own network to avoid accidental global expansion.
What They Do
As with other forms of malware the worm matches many of the characteristics of its biological equivalent. A worm will work its way through a network of computers and resources leaving a copy of itself wherever possible to assist in the dissemination process.
Macs Are Vulnerable
When combined with Trojan and virus technologies, worms can infect entire Mac OS X networks. For example if an initial victim is attacked using a Trojan which infects them with a virus that reproduces the worms throughout their system, thus threatening the entire network. These worms, when executed by automated or viral functions, can be used to reinitiate the Trojan attack on other users Mac OS X Address Book, and the unprotected Applications folder.
Malware How It Can Affect Mac OS X
The current Apple Mac OS X environment has some strengths and weaknesses. It has become an abnormally biased situation in that the strengths are very strong and the weaknesses are becoming increasingly obvious.
Users of Apple Mac OS X have been encouraged by media advertising to believe their systems have never been exposed to malware. This culture has grown to a point where many users believe their systems are invulnerable to malware and always will be.
The result of these ill-founded beliefs is a complacency that seriously compromises the ability of the user to make informed decisions when dealing with a malware threat. This complacency can potentially nullify the effectiveness of the sandboxing technology in OS X 10.5Leopard.
A file extension is designed to tell the system and the user what kind of file they are dealing with. Some examples of system extensions are .exe (a Windows executable program), .app (a Mac OS X executable bundle), and .jpg (a common digital photo format).
Both Microsoft Windows and Mac OS X offer the ability to hide the extension from the user. This is often used to disguise the true nature of file from the user. If this hiding is combined with a less technically-oriented user (the majority of all users) then a Trojan can exploit this to hide its own true nature.
The Bundle Architecture
What It Is
Applications on the Mac OS X system are structured using an architecture called a bundle. A bundle is a special folder that pretends to be a single file. The advantage of this, for programmers, is that it allows multiple resources to be contained in one single folder that is, from the users perspective, indivisible.
It should be noted at this point that Apple Inc. also use the bundle format for many of their pro tools to save documents.
Programmers use these special folders to allow certain resources to be treated as part of the program without the risk of those being separated from the main executable code of a program. Some examples are:
Multiple executables for different platforms such as Classic Mac OS, PowerPC or Intel-based computers.
Multiple language files so that a single copy of the application bundle can be used in different countries and appear in the native language of that country.
Graphics, buttons, and media resources used within the application.
Help files, manuals, etc.
A user is presented with an object that looks like (for example):
[figure 3 iTunes.app as it appears to the user]
The underlying bundle appears to the operating system as follows:
[figure 4 iTunes.app as it appears to the operating system]
How This Assists Malware
The structure of the bundle architecture makes it easier to piggyback executable code within an existing trusted application by simply renaming the existing executable iTunes found in the MacOS subfolder and inserting a second executable into the MacOS folder with the originals executable name.
When the user executes the bundle (in this case iTunes.app) the virus code would execute instead. The virus would then launch the renamed iTunes executable so that the user would not be aware they had run the wrong program.
Mac OS X also makes use of the bundle architecture for storage of user documents in many modern applications such as iMovie, iDVD, and the many pro tools. These bundles typically have their file extension marked invisible so it is possible to disguise an executable program as a data file for such a tool. These bundles can open both their own malware code as well as the desired real application whilst conserving the look and feel of the real data.
This technology makes the process of creating a virus easier since the bundle architecture greatly assists the process of installing multiple executables into one program. Reproduction is greatly simplified since the same architecture is used on most OS X applications.
Unprotected Application Folder
What It Is
Traditional UNIX systems protect their key executables by using file permissions and storing them inside protected folders (such as /usr/bin).
Mac OS X systems maintain their operating system files in the same protected method that traditional UNIX systems use. The programs (commonly known as Applications) that a user relies upon and considers part of their system such as iTunes, iChat, Keynote, etc. are stored unprotected inside a folder called /Applications. Any program running on a Mac OS X system can write to this folder and to most of the contents therein.
How This Assists Malware
Most common applications running on your Mac can be modified, either by replacing the core executable of that program or adding piggyback executables (viruses) without leaving an obvious trace due to the nature of the bundle architecture.
Centralized Open Address Book
What It Is
A Mac OS X user enjoys the convenience of the Address Book. This centralized database keeps track of all other contacts the user communicates with including their instant messaging addresses, email addresses, phone numbers, physical addresses, etc. The database is open to access from all programs running on the Mac OS X computer.
Programs running on the Mac OS X system can read, write and delete addresses from this database at will.
Side note: Addresses that are deleted are not actually removed from the database. Instead they are marked for deletion so that the computer can notify other devices such as cellphones, iPods, and PDAs that the user wants that address deleted.
How This Assists Malware
The worm known as ILOVEYOU, the Love Bug worm, or VBS/Loveletter started arriving in email boxes with an attachment LOVE-LETTER-FOR-YOU.TXT.vbs on May 4th, 2000 . This worm spread itself by interrogating users contacts and emailing copies of itself to everyone it found. On its journey it is estimated that it infected 10% of all internet-connected personal computers and caused more than 5 billion dollars in damage.
The ILOVEYOU worm only infected computers running Microsoft Windows but the mechanisms for dissemination exist on Mac OS X:
A user base believing themselves safe
Available open database of contacts
Ability to write to the Applications
Microsoft implemented a user-controlled system that sandboxes new applications and warns users they are about to run a new application. Apple recently introduced similar technology. It should be noted however that the user is already complicit with the operation at this point so should not be considered a reliable security measure.
Anatomy Of A Mac OS X Malware Suite
For the purposes of this discussion this section will be limited to descriptions of malware that does not have a payload. No attempt will be made to damage a users system or gain any resources. All technologies will focus on the delivery mechanism that could be used to attack Mac OS X (and other) users. The aim and purpose here is to outline how a suite might work so that recommendations can be received on how to stop such a suite from being successful. The reader is invited to contact Apple Inc., and/or SubRosaSoft.com Inc. with suggestions.
Initial infection (First Wave) – The Trojan Attack
For a successful infection there would be two goals required by the malware author. First the infection should distance the author from the first wave victims while simultaneously making that first infection as wide as possible.
Primary consideration in the production of a Trojan horse would be placed on making the user want to accept the Trojan.
The Latin epic poem The Aeneid  describes events between the time of Homers Iliad and Homers Odyssey surrounding the Trojan War. This legendary war between the cities of Sparta and Troy had resulted in a deadlock whereby the defenses of the city were equal to the challenge of the attacking army. The attacking leader, Odysseus, needed to create a gift the defending leader would voluntarily accept inside the city defenses. Realizing the men of troy revered the horse he had a mighty wooden horse made large enough to allow his soldiers to hide inside it and left it at the gate of the city.
Do not trust the horse, Trojans. Whatever it is, I fear the Greeks even when they bring gifts. (Virgil, Aeneid, Book 2, circa 19 BC)
Naught from the Greeks towards me hath sped well. So now I find that ancient proverb true, Foes gifts are no gifts: profit bring they none (Sophocles 496 406 BC, Ajax)
In computing terms this same ruse would be used.
The creation of a helpful freeware tool containing a version of a virus that will infect once then lay dormant to a later date can be hosted on a public site then advertised using one of the many freeware distribution sites such as http://www.VersionTracker.com or http://www.Downloads.com.
In keeping with the primary consideration of this step a malware author would leverage public popularity of fashionable technologies of the time, make a small but helpful enhancement for that technology, and then distribute that tool for free. For example, a small freeware utility that assists in the management of SMS text messages on an iPhone.
The malware authors intent is not to fully disseminate the malware suite but to get a wide enough secondary infection wave ready on a time-delayed basis. This methodology follows the concept of the sleeper cell as defined in the Al Qaeda training manual . The virus contained within this Trojan would infect only the system where the Trojan was executed and make a copy of the virus component into all of the unprotected application bundles on that system. This virus would then sit in a dormant state, execute then quit without further action, until a predetermined later date.
The malware author would ensure that once the Trojan has completed its own initial infection that the Trojan application itself self-inoculates to cover the source of the second (main) deployment wave.
Before the main wave of attack is initiated the author should repost and allow for dissemination of a vaccinated version of the Trojan. At this point the number of suspect applications have been greatly increased while simultaneously removing base suspicion from the originating Trojan. Many of the newly infected applications (hereinafter called the second wave Trojans) are, in fact commonly trusted applications such as the Apple tools and third-party tools found on most computers.)
This attack infrastructure delivers a ready supply chain for the second wave in much the same way as the Ho Chi Minh Trail  provided for the North Vietnamese. It does so by forming a relatively complex web of available infection points that the malware author can control. It also provides for a significant level of overlap and duplication should any one conduit be closed.
Reproduction (Second Wave)
The malware authors goal for the second wave is to greatly increase the number of infections. This wave would be repeated on a fixed schedule until the desired infection ratios have been achieved and the desired payload can be implemented.
The second wave would not proceed until sufficient time has passed from the first wave. This time could be determined remotely by having the virus check an online source for a code to proceed. This approach would give the most flexibility, but also offers the highest risk of discovery. Checking system date and time and waiting for a predetermined moment could also determine this time. This approach would give the most protection from discovery, but also offers the least flexibility.
The malware author would use the users data to prepare ammunition for the second wave. This would contain packages made from their own data that are disguised using the bundle architecture. It might also contain sample programs from the users machines that are determined to be small freeware downloads newly infected by the malware code. Because these payloads are prepared on the users own machines they would not trigger the sandbox protection code found in OS X 10.5 when executed on the users machines.
Now that the malware author is sufficiently distanced from the second wave Trojans, the primary consideration moves to mass production of malware. Traditionally this was achieved by at least two separate methods. In this case the malware author uses both methods together and separately for maximum effect.
The Virus Approach The malware should look for attached devices and network volumes and infect every available application bundle with its own code.
The Worm Approach The malware should send copies of itself to as many available recipients as possible.
The virus approach would cause the malware to immediately deploy copies of the pre-prepared payloads onto any removable media or network storage device.
The first application to trigger itself would make use of the open address book database to find potential candidates to send a copy of itself to. Special attention would be made to indicators that the potential recipient is a Mac user such as the content of the headers for incoming emails in the victims inbox. The malware author would benefit from the inherent trust of the secondary wave victim for the first wave victim.
This final dissemination would be done in such a way so as to temporarily self-inoculate the application responsible and to carefully feed the outgoing mail to stop from flooding the victims connection and alerting them. Alternatively it might be done in a massive full frontal attack in the manner performed by the ILOVEYOU virus. This remains the prerogative of the malware author, and our responsibility as an industry, to defend against.
What has been discussed in this section of the document covers the three main definitions of malware and documents how each can apply to Mac OS X.
The Trojan Attack Pretending to be a gift while hiding an intruder
The Computer Virus Self replicating programs dependent on a host
Digital Worms Producing and disseminating copies directly without a host.
It is this authors hope that this will open learned discussion of the topic. It is in no way intended as a manual on how to create such a suite of malware technologies. SubRosaSoft.com Inc. would like to take this opportunity to point out that the dissemination of malware is not only immoral, but also illegal. Please refer to Title 18 U.S.C. 1030 Fraud and related activity in connection with computers  for more information.
For Apple, Inc.
Control The Bundle Architecture
Apple might consider implementing a mechanism whereby a bundle cannot contain more than one executable for any given Contents subfolder. This would reduce the ability of malware authors to piggyback their code inside an otherwise legitimate bundle.
Apple may also wish to discuss disallowing multiple extensions inside a .app bundle. This would reduce the ability of malware authors to disguise executable bundles as data files for their pro tools.
Control Access To The Address Book
This paper recommends Apple should contemplate a similar system to the keychain whereby the address book can be locked unlocked and access to the address book can be restricted to certain applications.
Control Write Access To The Applications Folder And Subfolders Found Therein
Apple may think about making it the default behavior for the system to require admin access to write to this very important folder. Furthermore Apple should make an interface that is easy, obvious, and non-technical to turn this access control on or off.
Extend The OS X 10.5 Leopard Sand Box Concept
Apple might consider extending the built in security functions found in OS X 10.5 to include executable code that is created locally rather than the current restriction to download content only. This would slow down the reproduction of code that has already been authorized by the user.
Carefully determine the validity and source of any executables you wish to install and run on your Mac OS X computer.
Install and utilize third-party utilities to monitor for malware activity. Care should be made to avoid programs that specifically rely on scans for known malware as these tools do not offer protection until it is potentially too late.
A Guide for the Forensically Sound Examination of a Macintosh Computer Part 2 of 2 Ryan R. Kubasiak, Investigator – New York State Police
Reprinted with the kind permission of the author.
(Apple Document 301533)
The information here comes from the best source, Apple Inc. The following information is directly from the Support website.
Mac OS X 10.4 Tiger features Spotlight, a lightning-fast search technology that instantly lets you find thingson your Mac. By default, Spotlight will index and search in the following locations:
All Home folders (local and network-based, as well as FileVault and non-FileVault). This includes:
The Documents, Movies, Music, and Pictures folders
The Trash of all users and each mounted volume.
Spotlight also searches these non-Home folder locations by default:
Can Spotlight search anywhere else? Of course! Any new folder you create in your Home automatically getsindexed so that it’s searchable. If you connect an external storage device, such as a USB or FireWire harddrive, Spotlight will index the stuff on it, too. (If you want to exclude certain areas from Spotlight searching,see the tip below.)
Note: If your computer has multiple user accounts, any files that reside at the top level of each user’s Homefolder will also be indexed and searchable by Spotlight, even though they cannot be modified. However, all files and folders located within a user’s Desktop, Documents, Library, Music, Movies, and Pictures folders will not be indexed nor can they be searched by other user accounts using Spotlight.
User Home Directory Structure
Finder – User Home Directory Structure
The home directory is the likely area to find all of the evidence for any case, barring system widelog and settings files. MacOS X is very good at containing a user’s files and settings to this area. This trait allows FileVault to work as well as it does. When conducting a limited scope examination, directing your searches to this area first is a good idea.
A User’s home directory will contain many standard folder’s from a MacOS X installation, as well asapplication specific folders. The above window shows the user “Moof ” home directory. Alwaysremember when using the Finder, the window will NOT show hidden files or directories with thetypical MacOS X settings. There is no easy way to change this from any menu, and is best accomplished with a third party application (Onyx, Tinkertool, etc.) or at the command line with a writeto the proper Plist file. A description of each entry in the window follows.
Desktop – contains all of the items that are seen on the user’s desktop.
Documents – typically will contain user data files such as Pages, Keynote, MS Word, and othertypes of files.
Incomplete – created by Limewire and will contain files that have not yet successfully downloadedto this user’s account. 2 files, downloads.dat and downloads.bak will potentially contain incriminating evidence in the user’s use of Limewire
Library – This is a gold mine of information on the way a user utilizes the Macintosh. It will contain logs, preferences, browser history, recent files, etc. Many of these aspects will be discussed ingreater detail later.
Limewire – This is created by the Limewire application. By default, shared files and downloadedfiles will be here. A user can change this location within the application itself.
Magazines – used by the Zinio Reader application for electronic magazines
Movies – typically will contain iDVD movie data, Quicktime files, and other digital video material
Music – typically will contain a user’s iTunes library and other digital music material such as MP3files.
Pictures – typically will contains a user’s digital photo collection such as the iPhoto library.
Public – this is a “drop box” where other users have permissions to place files, read files, but not delete files.
Sites – if a WWW server is active such as the built in Apache web server, a user can host their website from this directory. This may contain a user’s internet published incriminating evidence.
User Library Folder – In Depth
The User Library folder will contain huge amount of information including user specific drivers,fonts, settings, system add-ons, etc. Not everything here will be meaningful to a case. On theother-hand, many items in here will be direct evidence of the crimes at hand. Browser history, wepage cache, email remnants, email attachments, and indexes are just a few examples of this. Mypersonal Library folder contains 45 folders. Some folders are from a standard MacOS X installation, whereas others are created by installing an application. Here are some of the folders and theinformation that can be gathered from them.
Application Support – Folders will be located in here that are created from Application installations. When a user removes the application from the system, the folder will remain in here. Amanual delete is required to remove this information. Although there may not be specific historyhere, it will be indicative of an application having been installed, and may show usage information.
Automator – User specific actions will be stored here. The actions are added by the user, and maycontain some very indicative information of file copying, server connections and other actions auser wants to automate.
Caches – This folder has the potential to be a gold mine of historical data for the examiner. Thecontents include information of application usage, web sites visited, buddy lists, downloaded files,etc. The best general advice that can be given regarding this directory is – explore. Look in thefolders here and see how the information may apply to your specific case. Keep in mind that manyfolders here will remain even after an application has been removed from the system!
Cookies – Used by Safari and other web browsers for the Cookies of various websites. A file named “Cookies.plist” is likely in this folder.
Favorites – This folder contains favorites for the “Connect to Server” option in the Finder. It willshow other network resources that the User considered important enough to be able to easily return to.
Logs – This folder contains log files for many applications and usage information. Excellent evidentiary resource.
Mail and Mail Downloads – These folders contain email and files that were attached to emails received under this account.
Phones – This folder contains cell phones that have been connected to this computer under thisaccount. Specific information about the phones can be found within the Info.plist file.
Recent Servers – This folder contains information on servers that have been recently connected toincluding AFP and FTP sites.
Safari – This folder contains the vital information on Safari usage including bookmarks, history, etc.
Each of these folders, and others, should be explored for evidence relating to the specific case athand. It would be impossible to write specific information for each of the folders and files that canpossibly be found here.
Address Book is the bundled application that allows users to store names, addresses, telephonenumbers, screen names, web page information and just about anything else related to a contact. Address Book is integrated into many applications, such as Mail, Safari, and .Mac. A user can export VCards from here as well.
iCal is the bundled calendar application. iCal is a simple program compared to many of the morerobust, enterprise type calendar systems. iCal is well used, and has the ability to synchronize with .Mac. A user can also publish a calendar to .Mac for public viewing.
Mail (or Mail.app as some will call it) is the bundled email application. Mail is integrated with theAddress Book, and also maintains a list of people emailed outside of the Address Book for autotyping. Mail offers Rules to be set and also has basic Junk Mail filtering. Multiple accounts can exist within one user’s Mail configuration. It has POP3 and IMAP functionality and can retrieveHotmail, Gmail, and .Mac email.
.Mac and Related Evidence
.Mac is an internet resource available from Apple Inc. Features include email (5 possible addresses), web site hosting, and iDisk storage of files. This service is subscribed to on a yearly basis. A usermay store files here, Backup files, Address Book entries, Safari bookmarks, Quicken data, etc. Any application that supports iDisk will be a potential area of evidence. Information can be automatically synced from a Macintosh to the iDisk, and multiple Macintosh can be configured to sync withthis iDisk. Below is a screen capture of the plist file showing Moof ‘s House is set to automaticallysync with the associated iDisk.
.Mac plist Window
Safari, and Other Web Browsers
Safari is the bundled web browser with all versions of MacOS X. The browser is the most predominantly used browser, but certainly not the only one. Safari offers excellent History and Cacheremnants in it’s default configuration.
Other web browsers that may be installed include Mozilla, Netscape, Firefox, Opera, and InternetExplorer. There are others. Look in the Applications folder to see what has been installed andthen looked for the associated setup files, bookmarks, and history in the users’ Library folder.
iChat, and Instant Messaging Applications
iChat is the bundled instant messaging client in MacOS X. As of version 10.3, iChat becameknown as iChat AV because of the added video capability. iChat uses .Mac accounts as well as AOLInstant Messenger screen names natively. iChat also will interface with any instant messagingtechnology that uses “Jabber”. An added feature for .Mac members is the ability to encrypt theiChat conversations. This only occurs between two .Mac members.
Other chat applications include AOL Instant Messenger, Adium, Microsoft Messenger, Skype, andSMS based applications or widgets. Look in the Applications folder to see what has been installedand then looked for the associated setup files users’ Library folder or Home folder.
Mac OS X Log Files
Mac OS X, like Linux and other UNIX variants, keeps many log files. Some of the files are verydetailed, yet of little use forensically. Other logs, seemingly innocuous, contain direct or indirectevidence to a users actions and intentions. Some log files will directly state exactly what a user wasdoing and the log entry itself would show the crime. Other entries will be indirect, yet help establish the circumstantial evidence of the crime committed. The Console utility, typically found in the/Applications/Utilities folder is where most logs can be read natively. Here are some, but certainlynot all of the log files than can help establish time-tables, actions, and configurations.
Application Usage History, information is written here when an applicationcrashes only.
Printer Connection Information
Printer Connection Information
Network Interface History
Samba (Windows based machine) connection information
Any logs in this area will be specific to the user of this Home directory. Application specific logs will be found here
Log of CD or DVD media burned using the Finder. This is specific to theuser of this Home directory.
Log of CD or DVD media burned using the Finder, mount and unmount history of ISO or DMG image files, Permission Repair history. and hard diskpartition information.
Log files here contain information of past iChat connection attempts. Data such as username, IP address, and Date&Time of the attempt
Log files here will contain information on .Mac syncing, mobile devices suchas iPods and cell phones, and Date&Time of the activities
Mac OS X “plist” Files
Mac OS X, and all versions of the Macintosh operating systems, do not use a registry like MicrosoftWindows. User settings are “remembered” through the use of “plist” files. Plist stands for Property List Format file. There is a MAN page describing the file in detail. Here is an excerpt from the Description:
Property lists organize data into named values and lists of values using severalCore Foundation types: CFString, CFNumber, CFBoolean, CFDate, CFData, CFArray,and CFDictionary. These types give you the means to produce data that is meaningfully structured, transportable, storable, and accessible, but still as efficient as possible. The property list programming interface allows you to converthierarchically structured combinations of these basic types to and from standardXML. The XML data can be saved to disk and later used to reconstruct the original Core Foundation objects. Note that property lists should be used for datathat consists primarily of strings and numbers because they are very inefficientwhen used with large blocks of binary data.
This description shows us that the data is more complex than a simple “Cookie” and not easily readwith a standard text editor. A Utility from Apple called “Property List Editor” will reveal the datacontained within each of these files in a user friendly way. As implied by the title, it will also allowyou to edit the content, so be very careful! The utility is part of the Developer tools XCode, freelyavailable from Apple Inc. The following table lists some, but certainly not all of the valuable plistfiles. You will find application specific plist files created, and they will always be worth looking atfor forensic data.
In the event you haven’t downloaded the XCode tools, it is still possible to look a plist file. Theplist file is likely stored in binary XML format. Opening this type of file in TextEdit will yield nothing useful. Fortunately, the Terminal command plutil converts plist file to XML format. The MAN entry for plutil is as follows:
plutil — property list utility
plutil [command_option] [other_options] file
plutil can be used to check the syntax of property list files, or convert a plist file from one format to another.
Be certain that your destination file is saved on YOUR drive and not a target drive.
The following list contains miscellaneous files, their location, and use.
Contains the current version of the installed operating system
Contains the date and time the operating system was first installed (completion time, not start time)
Contains defined IP addresses and the associated name
The following PLIST files can be found in the user home directory ~/Library/Preferences/
Contains the data this user has entered about him/her self
Contains devices that have connected via Bluetooth. It will show last connection date as well.
Contains information on installed Widgets for this user.
Contains information on applications available in the Dock
Contains information on items to be synced as well as how often the sync isdone
Contains information on Recently opened folders, last server connection from Finder and the last “Go to Folder” selection
Last directory a capture was saved.
AOL Instant Messenger information
Jabber account information
Information on Mail.app setup including account names and where the emailis stored locally
Information on network lookups such as Lookups, Whois, Ping and PortScans.
Recent Documents opened using Preview.app
Information on recently connected to printers
Recently viewed movie files
History from the web browser Safari, including Recent Search terms, Recentfolders utilized locally
Scheduled activities to run automatically such a .Mac sync or Software Update
Contains a History or Current and Past item that have shown up in the FinderWindows Sidebar. It will show System assigned items as well as the items inthe Custom portion of the window.
Contains a list of the custom “menus” installed by the user. Useful in showingwhat runs on the machine when a user logs in.
Recent audio and video clips
Again, this table is by no means complete. Using the Property List Editor, view each and anyPLIST file that seems to be relevant. Many times, when software changes in version, a new PLISTfile is used.
Sleep and Safe Sleep
/private/var/vm/sleepimage – This file is on Intel Macintosh portable computers to save contents of RAM to the hard disk. Its use is to recover from a power outage during sleep mode or when thebattery is just about to run out of power during use. As of this writing, the file is written to disk, unencrypted, and yields many usual artifacts of user history, inclusive of passwords. All Macintoshes running OS X can go into sleep mode, but the computer must support “safe sleep” (sometimes referred to as Deep Sleep) to have this functionality. It is possible to turn off the safe sleepfunction from the command line, but not thru the System Preferences.
Detailed Macintosh Techniques
First off, the Macintosh has many, many key combinations that cause different actions right fromthe initial power on. Not every key combo works on every Macintosh. Most work on most Macs. That is the best that can be said. Document which ones you try for the specific case at hand, and also for future reference.
Apple Boot Key Combos
Bypass startup drive and boot from CMD-OPT-SHIFT-DELETE external (or CD) Boot from CD
Boot from a specific SCSI ID #
Eject Floppy Disk
Hold down Mouse button
Select Volume to start from
Start in Target Disk Mode
OS X Verbose Boot
OS X Single User Mode
Create a Brute Force Dictionary File
The MacOS X Terminal makes it rather easy to create a brute force dictionary for attacking variousencoded files. It certainly isn’t a guarantee, but it offers hope. Creating this dictionary is usefulwhen the source is not encrypted. For instance, if you try to make a dictionary file from a sparseimage file, you will get nothing useful. However, making a dictionary from the entire device mayyield the password to a user’s login, a website, their keychain, and so-on.
The terminal command “strings” can create a text file with the useful words contained in a file orraw device. The MAN entry for “strings” is as follows: strings – find the printable strings in a object, or other binary, file.
We can use this against a device file such as /dev/disk0 or against an unencrypted DMG file such as/Evidence/sample.dmg and have a text file created with the useful strings.
This command will output a text file that contains all of the useful strings contained in the DMGfile. You can now use this file as a “dictionary” in a brute force attack on passwords. It might befurther useful to take the repeated strings out of this file.
Useful Artifacts and Commands
As with any operating system or file system, there are numerous places to look for evidence. TheMacintosh is no exception. The following tables begin to list areas of interest.
Table 1 – Artifacts
Safari = /Users//Libary/Safari/History.plist (dates are in AbsoluteDate Format) Note: if the file /Users//Library/Preferences/com.Apple.Safari.plistcontains the value “WebKitPrivateBrowsingEnabled” set to TRUE, no browsing history will be kept.
Internet Explorer =/Users//Library/Preferences/Explorer/History.html
Perform a search for files with the following extensions: .mbx, .mbox, .emlx, .imapmbox, .eml, .msf
Microsoft Entourage uses a file named “database”.
Perform a search for the file “com.Apple.iPod.plist”. It will contain information such as serial number of the iPod, last connect time, use count, etc.
limewire.props contains last used forward facing IP address
IP Address Info
IP Address info may be found in any of the following locations: /var/log/ipfw /var/log/secure /var/log/system
I also suggest looking at other logs kept in this directory!
Table II – Terminal Window Commands
ls -al | more
“ls” is the command to list the directory contents (Present Working Directory). Adding the “-al” switch will give all entries including hidden files andshow “long” entries. “Long” entries simply means you will see the associatedinformation for each entry, rather than just the name. The “| more” is thepipe command to send the output to the “more” command. “more” is acommand that will list the screen output one page at a time, pausing every 24lines. This causes the directory listing to pause, rather than just go flying by. Some people prefer the “less” command. Read the MAN pages and choose for yourself.
(Present Working Directory) This will simply out the path of your current directory. Sitting at a “$”prompt isn’t always the most useful and its easy to get lost when navigatingthe disk hierarchy.
find / -name "*.jpg" -print
This command will list all files, path included, that match the expression *.jpgstarting from the root of the file structure. This is an example of crudesearching for possible image files. Change the starting location for the searchby changing the “/” to the path of choice. An example might be /Users/ where is a valid home directory.
Displays the current system date and time in GMT
Information in this document has been gathered from years of education, training, and work experience. I would also be remiss if I did not mention training, websites and mailing lists that I readoften, with great respect.
Many thanks go to the resources of:
Apple Inc. including the Support and Developer websites. The information on these websites is an Examiner’s greatest tool to understanding any analysis.
June 21, 2007 Macintosh Forensics A Guide for the Forensically Sound Examination of a Macintosh Computer Part 1 of 2 Ryan R. Kubasiak, Investigator – New York State Police
Reprinted with the kind permission of the author.
About The Author – Ryan R. Kubasiak, Investigator – New York State Police
I began my foray into the world of computers in 7th grade. Our school laboratory was using Commodore 64 computers and the BASIC programming language. Soon, my parents purchased an Apple IIc for our home and I continued writing in BASIC, and now “Apple Logo” as well. My intrigue continued thru high school developing my skills in BASIC and the Pascal programming languages. Ultimately, I achieved Advanced Placement in Computer Science my senior year, yielding college credits.
I went on to the State University of New York at Buffalo and earned a Bachelor of Science in Com>puter Science and a Concentration in Mathematics. All of my schooling was done on the Macintosh LC, VAX/VMS and Sun Solaris based systems. We utilized Modula-2 and C as programming languages. C++ just wasn’t prevalent enough during my college years. One of my favorite achievements of college was writing from scratch, an Assembly language code compiler. I also wrote a multi-tasking operating system for a fictitious Robot, and a dating service front and back end for a fictitious customer.
During school, and immediately after graduation, I worked for SUNY at Buffalo in the LAN Sys-tems group. I went from a student assistant to full time employee and totaled 4 1/2 years with the university as an employee. As a LAN Administrator, I was charged with the setup, maintenance and upgrading of 4 public computing laboratories with hundreds of PC and Macintosh computers, and many office “node” sites with multiple PC and Macintosh computers. Along with the desktops, I also was charged with the operation and maintenance of Novell Netware and Microsoft NT based servers. I was a part of the team that also setup and maintained Remote Access Services and Tape Backups. The experience was invaluable towards the world of forensics, but didn’t begin to educate me on the intricacies of a forensic examination.
I moved on from SUNY at Buffalo in 1998 to become a New York State Trooper. After 5 years “on the road”, I was selected as a new member to the Computer Crime Unit. I have received two certifications, Encase Certified Examiner and Certified Computer Examiner. I hold multiple certifi-cates from classes I have completed and have “expert witness” status in the criminal court system.
My passion in computing has always been the Apple platform. Starting with my first computer, the Apple IIc, I have owned a Mac LC, LCIII, Centris 650, PowerMac 8500AV, iMac G4 and Macbook Pro. I have been installing and configuring the operating system since “System 6” and I maintain a membership with the Apple Developer Network. I routinely following the develop-ment of the operating system itself with great interest.
I continue today to enhance my education, training, and investigative skills. My goal is to share some of what I have learned within this writing.
This is the first of what I hope to be many iterations of MacOS X information for the forensic investigator. In order to keep this relevant, I look forward to hearing from anyone and everyone!
Here are a few of the ways you can get in touch with me:
Mail 1220 Washington Avenue, Building 30 Albany, NY 12226
About This Document
This document is to guide a digital forensic examination of a Macintosh computer in the simplest yet sound manner. In order to accomplish this writing, you will notice a rather extensive bibliography. There are many great resources on the internet, in the local bookstore and via training sessions. It seems there is no “one” resource that begins to consolidate this information to create a reference. It is highly recommend that as a digital forensic examiner, you take advantage of the most current information available, utilizing this document and the sources cited. The most informative site on MacOS specifics will always be Apple Inc. You will see throughout that specific Apple Document reference numbers have been included for both credibility as well as future use when new technologies replace what is written here. Apple Inc. does not delete the texts posted on their site. Use this site and others for independent sources of what you plan to testify to.
There will never exist a complete guide to a forensic examination of any platform. There are near infinite directions a case may lead, as well as the fact that technology changes as quick as this document is being written. The goal of this first writing is to get solid, sound practices out to the Macintosh forensic community, and to follow up with additional documents that continue with these techniques, and include more in-depth looks at technologies not able to be noted here.
Images in this document are either created via screen capture on a live MacOS X system, or via the trademarked icons thru Apple Inc. All mentions of companies and their technologies are copyright/trademark of the respective entity.
References from the Apple Inc. Developer website or Support website are noted at the beginning of the appropriate section. The document number is supplied for direct reference to the original writing.
No part of this document may be reproduced or utilized in any way without the express written permission of the author.
Tools Needed and Requirements of the Document
Target machine is assumed to be a Macintosh!
This guide is going to cover three different techniques to forensically “look” at the data of the target machine. Two techniques will involve directly using the target machine itself, while one will use another machine attached. To achieve all three of these forensic examinations, you will need to have with you:
Macintosh OS X based laptop for mobile forensics, preferably an Intel for greater flexibility.
Macintosh OS X based desktop for laboratory forensics, preferably an Intel system.
MacOS X 10.4 (or current) with the XCode tools installed.
LiveCD for both PowerPC and Intel.
Firewire cable with appropriate adapters.
USB Flash Drive, minimum of 1GB in size (4GB for creating a bootable USB drive).
Examination Notes information sheet.
This document will focus on OS X, heavily on version 10.4. Other versions will be mentioned and noted throughout.
Digital Examination Overview
Although crimes themselves have not changed, the methodology of committing them is everchanging. Our challenge is to keep pace with the digital aspect to all crimes. Investigations nowmust include a digital aspect as well as the traditional methods. Crimes of all levels are being plotted, planned or perpetrated with computers, PDAs, cell phones, USB flash drives, wrist watches,electronic pens, and others. The examiner needs to be cognizant of this, and trained to recognizethese items. Specialized Examiners need to be continually educated and trained on current forensic techniques to analyze the data on these high tech devices. It simply is not acceptable to turn ona computer and see what is there!
First Responders are critical in initial actions taken such as on-site viewing of evidence and/or thesecuring of digital evidence. For this person, a checklist is not acceptable. An understanding ofwhat needs to be done so one can adapt to the unique situations that present themselves is necessary. A loss of data or worse, corruption of data, at this point can severely jeopardize any case or situation.
Employers need to understand the importance of training, certification, and court presentation. Awell qualified examiner, whether a First Responder or Specialized Examiner, will constantly stay upto date in technology advancements and training. For law enforcement, the National White CollarCrime Center offers excellent courses for the perfect price, free. There are many other options fortraining, most of which will be a financial investment. “Investment” is stressed because taking acourse once is not good enough. Repeated training on newly emerging technology will be a must. Multiple colleges and universities have recognized and developed digital forensic classes, as well asdegree programs. Also, software companies such as Black Bag Technologies, Guidance Software,and Access Data offer classes that concentrate on their specific software, yet teach useful skills inanalysis. Courses and certifications that are publicly available vs. law enforcement only classes arepreferred. Techniques that can be reproduced by the digital forensic community at large are morerevered in a courtroom setting.
The conditions, in criminal circumstances, to consider a limited scope examination rather thanutilize a full laboratory analysis are:
Facilitate Arrest – You have a search warrant and need to find evidence at the crime scene to facilitate and arrest of the target.
Consent Search – You don’t have anything more than permission from the target to look, but the permission is the look on-premises only.
Exigent circumstances such as a missing person.
Field forensics is NEVER a substitute for a full-fledged, digital forensic laboratory. Working in anopen environment such as a target’s home or office presents dangers as well as opportunity formissed information. With that in mind, this guide is designed to safely and soundly guide the FirstResponder or Specialized Examiner to the data in a quick and forensically sound manner.
Three techniques are available to examine the target Macintosh. First, the Macintosh desktop/laptop/server can be booted into “single-user” mode. This state, as describe in-depth later, is a forensically sound state and allows for information to be gathered. In single-user mode, however, athorough working knowledge of UNIX will be needed. Second, the same target machine can bebooted from a LiveCD, such as MacOS X boot disk, a Knoppix distribution or Ubuntu LiveCD,and view the contents of the hard drive from it. Third, the target computer can be booted intoFirewire Disk Mode (Target Disk Mode) and viewed from a secondary computer. Each of thesetechniques have benefits as well as pitfalls.
Single-User Mode utilizes an already installed operating system, features established by Apple, andgreatest speed of previewing data. It also is command line driven, very much a manual process forsetup, and potentially has been shut off or maliciously altered. Using the suspect’s own operatingsystem is almost always a bad idea, leading to potentially mistaken results.
LiveCD offers a known boot media with a known operating system each and every time you conduct a preview. It offers a well-known, always available set of tools for each and every limited scopeexamination conducted. It also is RAM intensive, will not always work with the latest hardware, ormay not boot at all. Blackbag Technologies offers a subscription for a forensically sound Macintoshboot disk. It is also possible to create your own bootable disk that is both forensically sound andhas specific utilities installed. The downside to creating your own disk is the lack of support forfuture machines. Apple Inc. does tweak the operating system to take advantage of newer hardware.The specific changes from Apple come on a DVD with the specific computer. For instance, as ofthis writing, the MacOS X 10.4 box set available for purchase is for PowerPC Macintoshes only andwill NOT boot Intel based systems.
Target Disk Mode offers the greatest flexibility. You are able to use your laptop (or desktop) withchoice of operating system to look at the target machine. It yields the greatest speed and the widest variety of tools for examination. It also may not function at all on the target computer. Thistechnology is discussed further, later in the document.
Every digital examination should involve the following steps:
Physically secure evidence or conduct on-site preview (Collection)
Acquisition of digital media
Verification of acquired data
Archive of acquired data with verification
Analysis of acquired data
Reporting of results
Only the first two allow for the usage of original evidence. Special care is taken during these stepsto insure original evidence is not altered. This document is written entirely based on that care. Ifyou do not wander outside of the scope of this document, you will not be altering original evidence.All techniques outside of this document should be well tested in a controlled environment for forensic soundness before attempting use on evidence.
A on-site examination typically will yield only a fraction of the evidence on a target computer. Itmay yield 0% evidence. It is NOT a substitute for a full, in-laboratory analysis. Just because it wasnot found during a limited scope examination, doesn’t mean it’s not there.
“Absence of evidence is not evidence of absence.”
Apple has always been a very unique company, hence the operating system, file systems, and applications are also unique. Some basics to know and understand before looking at a Macintosh include the following:
HFS+ (and the older HFS) are the two predominant file systems found on any Macintosh. Without “something” to recognize this file system, you will be left looking at a seemingly unallocated drive with raw data only. Tools such as Encase from Guidance Software and BBT Forensic Suite fromBlackBag Technologies can appropriately interpret this file system and display the contents in auser friendly way. Also, the Macintosh itself knows how to display its own file system, and we usethis fact when using Single-User mode, LiveCD, or the target disk mode.
A Macintosh may contain other file systems, just as any other computer. With the release of “BootCamp” from Apple, Intel based systems could very well have NTFS, FAT32, EXT3, etc. The Intelbased Macintosh computers are very capable of running multiple operating systems with multiplefile systems. Always be aware of this when using techniques, and be aware of consequences.
MacOS X and MacOS 9 are the two dominant operating systems that will be found on any Macintosh. With the release of “Boot Camp” from Apple, any operating system that operates on Intelhardware can be successfully installed and run. Just because an “Apple Logo” is displayed on theside of the computer doesn’t mean an Apple operating system with be used. Apple has releasedWindows XP Service Pack 2 drivers as well as Windows Vista drivers, so expect those more often. Many hack websites have figured out how to use Boot Camp to install other operating systems andsuccessfully boot. Just as common will be virtualization software such as Parallels, VMWare or VirtualPC. With these, you will encounter a “file” that actually contains an entire hard drive worth ofdata from a different operating system.
With that said, an extremely high percentage of Macs will be running OS X or OS 9. This document’s focus will mostly be on the OS X based machines. OS X based PowerPC Macintoshes havethe possibility of containing OS 9 “within” the OS X installation. It is referred to as “Classic” andis run simultaneously to the OS X environment.
The Macintosh has used for several years, two “forks” to any file. They are the Resource fork andthe Data fork. Apple has recommended to developers to discontinue the use of the Resource fork. If a Macintosh file is copied to a File System that doesn’t support Resource forks, the fork will belost. As an examiner, this is extremely important to know. If a file with a Resource fork is copied to a Fat32 volume, for instance, the MacOS will handle the resource fork and open the file appropriately. However, the way in which it is handled is thru a hidden file. With an example file named “test.txt”, one will notice a hidden file in the same directory named “._test.txt”. This is the resource fork. MacOS X will copy this file from FAT32 correctly when the “test.txt” file is copied. Moving over to an operating system that doesn’t recognize this, such as Microsoft Windows, thesame copy will lose the Resource fork data. Resource forks can best be equated to Alternate DataStreams in the NTFS world.
Macintosh application files (or .app files) are actually not a single file at all. They are a folder, thatis displayed via the Finder as single custom icon, and appropriately launched. If you Control-Clickon an application file, you will notice the choice to “Show Package Contents”. This will actuallyopen the folder rather than launch the application. The contents have a small chance of being evidentiary in value, but the user data associated with an application is typically in the Home directory. Any folder can be made into an application by simply adding the “.app” extension to thename. However, when you double-click a self-made application, the Finder will likely give an errormessage because the application is not truly an application yet. Since an application is really just aspecialized folder, problems occur if it is copied to a File System and opened within another operating system. Viewing MyApplication.app in a Windows environment will show a folder with thename of MyApplication.app. Further, the folder will open in windows and the Package contentswill be seen, much like the “Show Package Contents” command.
Some applications actually use this package concept to create the data file. iWork has two applications, Keynote and Pages. They each save files in a Package format, and not a single flat file. Looking at MyDocument.pages on a FAT32 volume through Microsoft Windows will again result in afolder with the name MyDocument.pages and the folder will open when double-clicked. Be awareof this operation, and expect it when sharing files between operating systems.
Even more importantly, if you are examining a MacOS based system with a Windows tool, youWILL see package files differently than the intended view AND functionality. Certain portions ofa forensic examination of a MacOS based system will require a Macintosh. Plan accordingly!
One of the BEST features of each MacOS X based system is the help available. Specifically, theMAN pages available are perfect support documentation for any case. When you use a commandline function, consider making the MAN page for that command a part of your report. The MANpages are updated as system updates come out, making the output of the MAN page on the day ofusage important. An easy way to do this is an output redirect. For example, if you are about to usethe `dd’ command line utility, output the MAN page to a text file.
man dd > DD_MANPages.txt
This will output the MAN page entry to a text file. Save this text file in your case notes area forfuture reference. The best reference material an investigator can have is the materials supplied bythe company itself!
Mac OS X has some very robust technologies behind the Graphical User Interface. The operatingsystem is UNIX derived, which gives us the power and support of a huge online community. Theoperating system has both a GUI and command line available. Within the OS, Applescript andshell scripting can be done, both allowing for the automation of processes and tasks.
Bonjour, formerly Rendezvous, is a technology developed by Apple to make network configurationand setup seamless to the end-user.
Defined by Apple: Bonjour, also known as zero-configuration networking, enables automatic discovery of computers, devices, andservices on IP networks. Bonjour uses industry standard IP protocols to allow devices to automatically discovereach other without the need to enter IP addresses or configure DNS servers. Bonjour is installed by default on OS X based machines running 10.3 or later. It is also available fordownload for Windows 2000 or XP based computers.
AES-128 encryption. FileVault automatically encrypts and decrypts the contents of your home directory on the fly. FileVault is off by default after initial setup or installation, but can be easily enabled. More about this technology later in the document.
Spotlight is the indexing engine and search technology used to keep track of files and their metadata. A hidden file is created called “.Spotlight-V100” and contains the indexing data. Spotlightis enabled by default, and is not easily turned off for the entire system. More on Spotlight later in this document.
UNIX and the FreeBSD System
MacOS X, all versions, utilize the UNIX subsystem. This means, that for the first time, the MacOS is not only a GUI based system, but also is command line driven. This brings immense powerand flexibility, along with the time tested stability of UNIX to the operating system. When researching How-To’s on the MacOS X system, you can usually include generic UNIX information, aswell as Linux equivalents. Many times, a Linux source code will be able to compile on the Macintosh with little changes.
Microsoft Windows on a Mac?
Yes. If the Macintosh is an Intel based system, a beta of the software called “Boot Camp” may be installed and Microsoft Windows XP SP2 or Vista may be installed. In addition, on both PowerPCand Intel based Macintoshes, emulation and virtualization software can be run allowing for otheroperating systems to run. Microsoft VirtualPC (formerly Connectix) is for the PowerPC based systems. The software was recently discontinued (but can still be purchased) because PowerPC Macintoshes have been discontinued. Newer software for the Intel Macintoshes such as SWSoft’s Parallels Desktop or VMWare Fusion can run multiple, concurrent virtualized operating systems. These technologies will be discussed further.
Disk Arbitration is a daemon in OS X that mounts file systems. This is the feature that automatically mounts and displays your USB Flash drive when you plug it in for instance. Disk Arbitrationwill mount volumes read/write, which is bad in the forensic world. When utilizing an OS X basedMacintosh to preview another computer, Disk Arbitration needs to be “off “.
Activate/Deactivate Disk Arbitration
Make a backup of the file “/etc/mach_init.d/diskarbitrationd.plist”
Reboot your system and Disk Arbitration is now on.
As stated directly from the MAN pages:
BSD System Manager’s Manual
diskarbitrationd — disk arbitration daemon
diskarbitrationd listens for connections from clients, notifies clients of the appearance of disks and filesystems, and governs the mounting of filesystems and the claiming of disks amongst clients. diskarbitrationd is accessed via the Disk Arbitration framework.
Options: -d Report detailed information in /var/log/diskarbitrationd.log. This option forces diskarbitrationd to run in the foreground. The file /etc/fstab is consulted for user-defined mount points, indexed by filesystem, in the mount point determination for a filesystem. Each filesystem can be identified by its UUID or by its label, using the con structs “UUID” or “LABEL”, respectively. For example: UUID=DF000C7E-AE0C-3B15-B730-DFD2EF15CB91 /export ufs ro UUID=FAB060E9-79F7-33FF-BE85-E1D3ABD3EDEA none hfs rw,noauto LABEL=The\040Volume\040Name\040Is\040This none msdos ro
Results from a preview or analysis are only useful if everything has been conducted under forensically sound procedures. We must insure that everything done from start to finish guarantees unaltered data OR in a worst case scenario, results that are documentable, known changes to the targetmachine. We will NOT be purposefully trying to achieve the latter! The known changes anddocumentation should only be for a procedure attempted that did not result in the desired outcome. For instance, if you attempt to boot a target machine with a LiveCD and instead, the MacOS boots, you must document what happened.
Target Disk Mode (Apple Document 58583)
Target Disk Mode is a technology that allows a Macintosh computer to act as an external, firewiredisk. The computer will not access the file system or other data in this state until user interactioncauses this. Its an extremely useful tool for us. A separate note from Apple on this states:
Tip: FireWire Target Disk Mode works on internal ATA drives only. Target Disk Mode only connects to themaster ATA drive on the Ultra ATA bus. It will not connect to Slave ATA, ATAPI or SCSI drives.
This means we cannot access multiple installed drives with this method. If you know there are 2 ormore drives in the target computer, consider the LiveCD method.
In addition, the following models support the use of Target Disk Mode:
iMac (Slot Loading) with Firmware version 2.4 or later
iMac (Summer 2000) and all models introduced after July 2000
eMac (all models)
Mac mini (all models)
Power Mac G4 (AGP Graphics) with ATA drive
Power Mac G4 Cube
Power Mac G4 (Gigabit Ethernet) and all models introduced after July 2000
Power Mac G5 (all models)
iBook (FireWire) and all models introduced after September 2000
MacBook (all models)
PowerBook G3 (FireWire)
PowerBook G4 (all models)
MacBook Pro (all models)
Target Disk Mode Procedure
To use Target Disk Mode in a forensically sound manner, use the following steps:
Make sure that the target computer is turned off. If you are using a laptop as the target computer, you should also plug in its AC power adapter.
Boot the target computer while holding down the Option key. This will yield one of two results. Either you will see a list of bootable devices (partitions) or you will see a prompt to enter the Firmware password. If the latter occurs, you CANNOT use Target Disk Mode.
Use a FireWire cable to connect the target computer to your computer. The forensic Macintosh (your computer) does not need to be turned off.
Start up the target computer and immediately press and hold down the T key until the FireWire icon appears. The hard disk of the target computer should become available to the host computer and will likely appear on desktop.
When you are finished with the examination, drag the target computer’s hard disk icon to the Trash or select Put Away from the File menu (Mac OS 9) or Eject from the File menu(Mac OS X).
Press the target computer’s power button to turn it off.
Unplug the FireWire cable.
To remain forensically sound, the Macintosh being used to view the Target should have DiskArbitration turned OFF.
If your examination machine is Windows based, be VERY cognizant of the possible writes beingmade to any FAT or NTFS partitions. The firewire connection is not write blocked in any way. Forthis reason, it is not recommended to use Target Disk Mode with a Windows based computer.
The Macintosh Boot Process
[The following section has wording taken verbatim from the Apple Developer website]
Open Firmware and Extensible Firmware Interface
Open Firmware and Extensible Firmware Interface are similar to the function of BIOS and are used on PowerPC and Intel based Macintoshes respectively.
When the power to a Macintosh computer is turned on, the BootROM firmware is activated.BootROM (which is part of the computer’s hardware) has two primary responsibilities: it initializessystem hardware and it selects an operating system to run. BootROM has two components to helpit carry out these functions:
POST (Power-On Self Test) initializes some hardware interfaces and verifies that sufficientmemory is available and in a good state.
On PowerPC-based Macintosh computers, Open Firmware initializes the rest of the hardware, builds the initial device tree (a hierarchical representation of devices associated withthe computer), and selects the operating system to use. On Intel-based Macintosh computers, EFI does basic hardware initialization and selects which operating system to use.
If multiple installations of Mac OS X are available, BootROM chooses the one that was last selected by the Startup Disk System Preference. The user can override this choice by holding downthe Option key while the computer boots, which causes Open Firmware or EFI to display a screenfor choosing the boot volume.
Note: On some legacy hardware, the same version of BootROM can start either Mac OS 9 or Mac OS X.Most current hardware can start only Mac OS X.
Startup Manager (Apple Document 106178)
Startup Manager was introduced with these Apple computers and is present on these and all latermodels (including all Intel-based Macs):
iMac (Slot Loading)
Power Mac G4 (AGP Graphics)
Power Mac G4 Cube
BootX, boot.efi, and System Initialization
[The following section is taken verbatim from the Apple Developer website]
Once BootROM is finished and a Mac OS X partition has been selected, control passes to theBootX (PowerPC) or boot.efi (Intel) boot loader. The principal job of this boot loader is to load thekernel environment. As it does this, the boot loader draws the “booting” image on the screen.
BootX and boot.efi can be found in the /System/Library/CoreServices directory on the root partition. In addition, a copy of boot.efi can be found at /usr/standalone/i386/boot.efi.
In “exotic” boot situations such as booting from a UFS volume, a software RAID volume, and soon, a copy of the boot loader is stored on a separate HFS+ “helper” volume to get the system started. In some versions of Mac OS X, a copy of the kernel and mkext cache are also included on the helper volume. In these cases, the booter and other components on the root volume are unused.
The boot loader first attempts to load a pre-linked version of the kernel that includes all devicedrivers that are involved in the boot process. This pre-linked kernel is located in/System/Library/Caches/com.apple.kernelcaches. By linking these drivers into the kernel ahead oftime, boot time is reduced. If the pre-linked kernel is missing, out-of-date, or corrupt, the boot loader attempts to load thatsame set of device drivers all at once in the form of a single, compressed archive called an mkextcache.
If this cache is also out-of-date, missing, or corrupt, the boot loader searches /System/Library/ Extensions for drivers and other kernel extensions whose OSBundleRequired property is set to avalue appropriate to the type of boot (for example, local or network boot).
Once the kernel and all drivers necessary for booting are loaded, the boot loader starts the kernel’sinitialization procedure. At this point, enough drivers are loaded for the kernel to find the root device. Also from this point, on PowerPC-based Macintosh computers, Open Firmware is no longer accessible (quiesced).
The kernel initializes the Mach and BSD data structures and then initializes the I/O Kit. The I/OKit links the loaded drivers into the kernel, using the device tree to determine which drivers tolink. Once the kernel finds the root device, it roots(*) BSD off of it.
Note:As a terminology aside, the term “boot” was historically reserved for loading a bootstrap loader and kernel off of a disk or partition. In more recent years, the usage has evolved to allow a second meaning: theentire process from initial bootstrap until the OS is generally usable by an end user. In this case, the term isused according to the former meaning.
As used here, the term “root” refers to mounting a partition as the root, or top-level, filesystem. Thus, while theOS boots off of the root partition, the kernel roots the OS off of the partition before executing startup scriptsfrom it.
Prior to Mac OS X v10.4, the remaining system initialization was handled by the mach_init and init processes. During the course of initialization, these processes would call various system scripts (including /etc/rc), run startup items, and generally prepare the system for the user. While many of thesame scripts and daemons are still run, the mach_init and init processes have been replaced bylaunchd in Mac OS X v10.4 and later. This change means that launchd is now the root system process.
In addition to initializing the system, the launchd process coordinates the launching of systemdaemons in an orderly manner. Like the inetd process, launchd launches daemons on-demand.Daemons launched in this manner can shut down during periods of inactivity and be relaunched asneeded. (When a subsequent service request comes in, launchd automatically relaunches the daemon to process the request.)
This technique frees up memory and other resources associated with the daemon, which is worthwhile if the daemon is likely to be idle for extended periods of time. More importantly, however,this guarantees that runtime dependencies between daemons are satisfied without the need formanual lists of dependencies.
Note: While launchd does support non-launch-on-demand daemons, this use is not recommended. Thelaunchd daemon was designed to remove the need for dependency ordering among daemons. If you do notmake your daemon be launch-on-demand, you will have to handle these dependencies in another way, suchas by using the legacy startup item mechanism.
For more information about launch-on-demand and SystemStarter daemons and how to launch them, see “Daemons”.
As the final part of system initialization, launchd launches loginwindow. The loginwindow programcontrols several aspects of user sessions and coordinates the display of the login window and theauthentication of users.
Note:By default, Mac OS X boots with a graphical boot screen. For debugging the boot process, it is oftenuseful to disable this, revealing the text console underneath. This mode is known as verbose boot mode. Toenable verbose boot mode, simply hold down command-v after the boot chime.
The utility can be run on a Live Macintosh, but is not available without installation. In our case,the more useful option is to boot from a bootable disk with the utility installed and gather theneeded information. Typically, this information is the system date and time along with any otherlow-level information your agency elects to include. You will need to have created a forensicallysound boot disk (external hard drive, USB drive, DVD, etc.) and have this tool included.
Because of the lack of EFI documentation, single-user mode is probably the better way to gatherinformation such as date and time at this point.
Booting a Macintosh from the LiveCD
Booting from a LiveCD on a Macintosh is a rather straight-forward process, yet have many different paths that can be followed. We will not be discussing the specific directions for each LiveCD offered on a Macintosh. Your agency should develop specific operating guides for the tool(s) used. An internet search for Knoppix, Linux, and the likes on a Macintosh will yield many variations thatmight boot the target Macintosh. Be careful when selecting a LiveCD. You want to know what happens when the LiveCD is running. Some LiveCDs have the potential to alter the target disk, justas if you booted from the target disk itself. Do not make your first test during an actual limited scope examination.
Some available distributions:
PowerPC – Ubuntu LiveCD (discontinued development as of 02/2007)
Intel – Ubuntu LiveCD
Intel – Helix LiveCD
PowerPC and Intel – BBT Macquisition CD
From a LiveCD that is Linux based, the DD utility will allow for a bit for bit, forensic copy of theoriginal device. You will need to familiarize yourself with the console and GUI of each distribution. Each will have their own nuances that can potentially change what you are accustomed toseeing as output.
Imaging a Target Macintosh
Once it has been determined that you wish to make an image of the target Macintosh vs. collecting certain files and folders, steps need to be taken to insure the result is as expected. The steps that need to be taken will highly depend on the method/path chosen. We will deal with this here. We are going to use in this outline, the tools available from the typical install, and NOT specialized,downloaded tools. There are tools that will make some of these steps easier, or in fact combine thesteps creating shorter acquisition times altogether. Explore these tools after you are comfortablewith the well-known, established results of the steps taken here.
Target Disk Mode
In target disk mode, the target computer acts as an external firewire hard drive. The steps to acquire such a device are the same as any other firewire hard drive. Windows will alter a Macintoshin this mode if any writable partitions exist (FAT32, NTFS). Because of this, and the lack of upfront knowledge of whether or not these exist, it is recommended an acquisition of this type bedone with a forensic Macintosh. It is also possible to use Linux and image the drive with DD (diskdump). The procedure varies only slightly.
The specific steps for a Target Disk Mode acquisition with a forensic Macintosh are as follows:
Turn off DiskArbitration on your forensic Macintosh (alternately, use a specific partition on your forensic Macintosh that always has DiskArbitration off) [see Activate/Deactivate DiskArbitration]
Shut down your forensic Macintosh.
Start the target Macintosh following the Target Disk Mode Procedure outlined earlier.
Connect the target Macintosh to your forensic Macintosh via a firewire cable.
Boot your forensic Macintosh either to your forensic partition or with DiskArbitration turned off.
If all is well, you will see your boot drive on the desktop, but nothing else (because DiskArbitration is off).
Enter the Terminal and check for your attached Target Disk Mode Macintosh “hdiutil info” will yield device information [or] “ls /dev/disk?” to get a listing of recognized devices
Determine which disk you will acquire and create a digital fingerprint of the target device by running MD5 hash. Assuming the disk you will acquire is disk1, use the MD5 command as follows: md5 /dev/disk0 > /Evidence/targetMacintosh.md5_start
A “raw” disk, or rdisk, will acquire faster than is buffered disk counterpart. Assuming the disk you will acquire is “disk1”, use dd to make the acquisition of the raw disk as follows: dd if=/dev/rdisk1 conv=noerror,sync of=/Evidence/targetMacintosh.dd
The dd utility will not give an progress reporting, and will simply exit when it is finished. A notice on screen stating the number of blocks in and blocks out will be reported. They shouldmatch if everything was copied bit for bit as expected.
Create a second digital fingerprint of the target device to show nothing has been altered by the dd process. md5 /dev/disk0 > /Evidence/targetMacintosh.md5_end
Power down your forensic Macintosh.
Power down the target Macintosh by holding down it’s Power button.
Disconnect the firewire cable and you are finished.
Possible failures of this method include: lack of drive space on your forensic Macintosh to acquire,faulty firewire cable, or a physically failing target Macintosh.
Other tools to consider for this method would include DCFLDD and BBT Forensic Suite.
A LiveCD method for acquisition of a Macintosh is sometimes the preferred method. This involves booting the target Macintosh with a known, forensically sound CD. LiveCD’s can include acustom tailored Linux distribution such as Helix, SMART or a Knoppix variant. It can also include paid-for tools like BBT Macquisition.
Physical drive removal sometimes is the most complicated part of a Macintosh examination. Thecases of some Macintosh computers will seem like a security barrier as you try to open them. Others will open within seconds and present the internal drives very neatly. When choosing thismethod, you will likely want to use a physical write blocking device for the acquisition. Many companies offer a great selection of just such devices. The appropriate steps to take will be determinedby the physical write blocking device you choose to use. Once the disk drive is physically writeblocked, an imaging process can begin with any tool of your choosing, on any operating system.
Possible failures of this method include: a bad cable between the drive and the physical write blocking device, bad cable from the physical write blocking device to the forensic computer, and the imaging tool can’t recognize the file system of the target Macintosh hard drive and displays the disk asunallocated space.
Apple Partition Map
Macintosh computers will likely use one of two partitioning schemes. From the factory, PowerPCbased Macintoshes come with the Apple Partition Map. An Intel based Macintosh, however, willutilize the new GUID partition scheme. Do not confuse this with the file system of HFS or HFS+.The partitioning scheme is the basic definition of how a hard drive or other media is laid out for afile system to be applied. Here is a look at the disk structure of a typical PowerPC based Macintosh:
Disk Utility – Apple Partition Map
The image shows a 149.1 GB hard drive with model number ST3160023AS with a user given nameof “Moof ‘s House”. The Volume Scheme shows the drive having only one partition, and the format used is Mac OS Extended (Journaled). Note at the bottom, Apple Partition Map is the partition scheme used. What does all of this mean?
The left window pane shows us physical storage devices. Physical storage could also include aDMG that has been mounted as well. On this computer, only one hard drive is connected. Looking at the lower portion of the window, the drive is a Serial ATA or SATA drive. The VolumeScheme section gives information on the number and types of partitions available. The currentpartition map shows one large partition across the entire available drive. It has been named “Moof ‘s House” and is formatted using HFS+ with journaling enabled. More to come on Journaling later.
Now, let’s look at the same disk through the Terminal window using “hdiutil“.
Terminal Window – Apple Partition Map
The command used to give this view was “hdiutil partition /dev/disk0“. Notice the extra information we are now seeing as compared to the output of Disk Utility. Sector 0 is the boot sector witha size of 1 sector. Sectors 1 thru 64 is the Apple Partition Map defining the layout of the disk. Apple Free is a “padding” defined as being available for future use. The data section for a forensicanalysis finally shows up at the Apple HFS partition starting at sector 262208 and having a lengthof 3,122,319,590 sectors. There is one more Apple Free partition with a length of 10 sectors, againused as padding.
The Apple Free area is not normally where data will be found. It is not easily accessed by the casualuser. However, nothing prevents a more savvy user from hiding information there with the righttools. Also, information could be left over in these areas from a previous partition scheme.
GUID Partition Table
Next, let’s look at an Intel based Macintosh. Here is the Disk Utility information window.
Disk Utility – GUID Partition Table
The image shows a 74.5 GB hard drive with model number ST98823AS with a user given name of “Kubasiak World”. The Volume Scheme shows the drive having only one partition, and the format used is Mac OS Extended (Journaled). Note at the bottom, GUID Partition Table is the partitionscheme used. What does all of this mean?
The left window pane shows us physical storage devices. On this computer, only one hard drive isconnected. Looking at the lower portion of the window, the drive is a Serial ATA 2 or SATA2 drive.
The Volume Scheme section gives information on the number and types of partitions available. The current partition map shows one large partition across the entire available drive. It has beennamed “Kubasiak World” and has been formatted using HFS+ with journaling enabled. Again, more to come on Journaling later.
Now, let’s look at the same disk through the Terminal window using “hdiutil“.
Terminal Window – GUID Partition Table
The command used to give this view was “hdiutil partition /dev/disk0“. Notice the extra information we are now seeing as compared to the output of Disk Utility. Sector 0 is the boot sector witha size of 1 sector. Sector 1 is the Primary GUID Partition Table Header and sector 2 thru 34 contains GUID Partition Table data defining the layout. Notice that these two partitions are replicated at the end of the drive in reverse order. We will recognize the Apple Free partition and thefunction is similar in nature. The data we are interested in for an exam lies within the Apple HFS partition starting at sector 409,640.
For an even more in-depth look at this topic, read “Technical Note 2166 – Secrets of the GPT” on the Apple Developer website.
(Apple Document 107249)
“Journaling” is a feature that helps protect the file system against power outages or hardware component failures, reducing the need for repairs. Journaling was first introduced in Mac OS X Server 10.2.2, then to thenon-server OS in Mac OS X 10.3 Panther. This document explains some of the benefits of using this featureand how it works.
Journaling for the Mac OS Extended (HFS Plus) file system enhances computer availability and fault resilience, which is especially noteworthy for servers. Journaling protects the integrity of the file system on Xserveand other computers using Mac OS X Server in the event of an unplanned shutdown or power failure. It alsohelps to maximize the uptime of servers and connected storage devices by expediting repairs to the affectedvolumes when the system restarts.
Journaling is a technique that helps protect the integrity of the Mac OS Extended file systems on Mac OS Xvolumes. It both prevents a disk from getting into an inconsistent state and expedites disk repair if the serverfails.
When you enable journaling on a disk, a continuous record of changes to files on the disk is maintained in thejournal. If your computer stops because of a power failure or some other issue, the journal is used to restore the disk to a known-good state when the server restarts.
With journaling turned on, the file system logs transactions as they occur. If the server fails in the middle of anoperation, the file system can “replay” the information in its log and complete the operation when the serverrestarts.
Although you may experience loss of user data that was buffered at the time of the failure, the file system is returned to a consistent state. In addition, restarting the computer is much faster. Always remember to backup your data as frequently as necessary.
What does this mean for us as digital forensic investigators? Two thoughts need to be consideredwith every case:
Do I shut down this Macintosh normally or pull the plug?
Booting a forensically restored version of a Macintosh that has journaling will result in automatic correction to corruption.
The answers to these questions will depend on how you or your agency establish policies.
FileVault and MacOS X Security
FileVault Preference Pane
FileVault is the security technology available in MacOS 10.4 to secure a user’s home directory. When turned on, the user’s home directory will be encrypted using 128 bit AES encryption to a Sparseimage DMG file.
Security Preference Pane
The window shows the available security features from the Security Preference Pane. A description of each follows.
Master Password – This is the master password used to unlock a FileVault sparseimage when theuser has forgotten the password.
Turn On FileVault – Clicking on this button will enable FileVault for the currently logged in account. The sparseimage of the user’s home directory will be created and the user will be loggedout.
Require password to wake this computer from sleep or screen saver – will cause the computer toprompt for the currently logged in user’s password to wake or unlock the screen saver
Disable automatic login – Causes the Login Window to appear during the boot sequence. Whenthis is not checked, the selected user will automatically login during the boot sequence.
Require password to unlock each secure system preference – Forces a password to be entered before changes to security can be made.
Log out after X minutes of inactivity – Will cause automatic log of the currently logged in user (orusers) after the specified number of minutes.
Use secure virtual memory – causes the /var/vm/swapfile0 and other subsequent page files to be encrypted. When this is not checked, all pages of memory to disk are in clear text, offering an abundant source of user information. The swapfiles are deleted during boot, and NOT at shutdown orlogout!
It is important for a full analysis to include items such as the options listed above. For instance, itis not the same story when a system has the auto-login feature on vs. off. Having to know a password to get into the system narrows down the number of people that may have used a computerimmediately. In order to gain this information, “plist” files will need to be examined. A likely areafor system-wide setting to be stored is /Library/Preferences. Here is an example of the loginwindowplist file.
Property List Editor – com.apple.loginwindow.plist
Here we see that the Auto Login setting has been set, and the user moof will be used (UID 501).
sparseimage and User Home Directory
FileVault and the sparseimage file created is simply a DMG file that has been encrypted with 128bit AES encryption using the user’s login password. A sparseimage also will expand and compact assize requirements change for the “disk”. That is different from a DMG where the entire size is allocated up front. It will be named username.sparseimage and will be located in the user’s home directory. This file can be manipulated like any other file, and can be successfully mounted if thepassword is known. As with any DMG file, you should “Lock” the file before using it. This will ensure Read-Only privileges regardless of the level of account being used. Even “root” will not haveprivilege to write to this file when the HFS+ “Lock” is used. Here is a screen capture of a user’shome directory after FileVault has been turned on.
Terminal Window – User Home Directory with FileVault Enabled
In this example, the user dogcow has FileVault turned on. The home directory now contains only asingle file, dogcow.sparseimage is a DMG sparseimage that has been 128 bit AES encrypted. Youcan see that user 505 is the owner and its size is currently 71,430,144 bytes large. This file can becopied to another drive as any other file could. You will need an admin account to access anotheruser’s directory, and you will need the encryption password (login password) of the user dogcow tomount this file.
Acquire the Encrypted User Home Directory
When copying this file, do not forget to immediately set the “Locked” property in the Finder. Thiswill prevent any changes occurring to the file. Here are the steps to successfully acquire this file.
Open a shell in the terminal with root privileges. (BE CAREFUL!) Example “sudo sh”
Copy the file from its present location to your Evidence Collection directory. Example “cp /Users/dogcow/dogcow.sparseimage /Evidence”
Take ownership of the file. Example “chown yourusername /Evidence/dogcow.sparseimage”
Set the Locked flag to prevent any changes to this file. Example “chflags uchg /Evidence/dogcow.sparseimage”
Terminal Window – Forensically Copy sparseimage
Looking at the /Evidence directory after the steps have been completed will result in the following output.
Terminal Window – Attributes of sparseimage Properly Copied
Prior to mounting the sparseimage, looking at the contents will result in nothing but gibberish. Nothing useful can be gathered from the image itself except for one fact. The header of a sparseimage will show as follows:
Terminal – XXD View of sparseimage Header
Every sparseimage will have the header “encrcdsa”.
You should now be able to mount the Disk Image file in your evidence directory. If you have taken each of the steps from above, double-clicking on the file will result in the following dialog:
Finder – Authentication Dialog
Entering the login password for dogcow will result in the image mounting on your desktop.
If you get the following dialog instead:
Finder – Image Mounting Error Dialog
then you have not appropriately taken ownership of the image file with the “chown” command.
Once the Disk Image is mounted, you will recognize the user’s home directory:
Finder – dogcow User Home Directory
The image is locked, and can be verified with a Get Info from the Finder. All searches and file examinations are read-only at this point.
To be more complete in this examination, hash values should be computed prior to mounting theimage file, and after ejecting the image file.
DiskUtility and DMG Files
Disk Utility – Help Window
Disk Utility is a powerful application included with every Macintosh running MacOS X. If youhaven’t already, look at the Help file for this program and familiarize yourself with its many function. We are going to talk about a few specific areas of forensic value in this application. In orderfor Disk Utility to function, DiskArbitration needs to be enabled. As an examiner, you will want tohave acquired your image of the target first, then, with your examination computer, you can reenable DiskArbitration.
DMG vs. sparseimage
There are many types of “image” files. DD is a UNIX (or linux) utility that creates a Disk Dumpof the given device. Guidance Software’s Encase creates E01 files for it’s output. Disk Utilitynatively will create the DMG file or Disk Image file, as well as the sparseimage file. It has the ability to deal with many other file types that will not be dealt with here. The MAN page on hdiutilwill give you a wealth of knowledge on current and historical image file types. The biggest difference between the DMG file and sparseimage file is initial file size. A DMG file will have the filesize allocated up front in creation. For instance, when creating a DMG file of size 40MB, 40MBof disk space will used right away. When creating the sparseimage file of 40MB in size, about 10MB will be used initially, and the file will grow (or shrink) as necessary up to the maximum of 40MB.
Encrypted vs. Unencrypted
The encryption provided thru the Disk Utility program is AES 128 bit encryption. It is used by default when a user’s home directory is encrypted with FileVault, and can also be selected during thecreation of a DMG file. An encrypted DMG file or sparseimage file is near useless in today’s computing environment. A brute force attack with a dictionary or rainbow table may yield good results,but likely will give you what you started with, nothing. This section is not written to discourageyou from obtaining encrypted DMG or sparseimage files. It is to encourage you to pursue otherinvestigative measures in obtaining the password. The best encryption in the world is easilycracked with the password written on a sticky note.
DD and Raw Images
DD or Disk Dump is an old UNIX utility that was used to back up systems to tape drives originally. It turns out that DD creates a forensically sound image of a device for us. There are specialized versions of this program, such as DCFLDD that extend the original capabilities of DD. Manyprograms use DD as their underlying basis of operation. A DD image file is considered a raw imagebecause it will match the original device, but for bit, with no compression. Mounting a DD imagefile for analysis will show that the file is indistinguishable from the original and will produce thesame MD5 hash value. There is a known flaw with DD running on linux with certain versions ofthe kernel code. The flaw simply causes DD to miss the last sector of some odd-total-sector drives.This is rare to find, but worth noting in this section.
Conference on Digital Forensics, Security and Law, 2006
Marcus K. Rogers Computer and Information Technology Department Purdue University email@example.com
James Goldman Computer and Information Technology Department Purdue University
Rick Mislan Computer and Information Technology Department Purdue University
Timothy Wedge National White Collar Crime Center
Steve Debrota U.S. Attorneys Office Southern Indiana
With the proliferation of digital based evidence, the need for the timely identification, analysis and interpretation of digital evidence is becoming more crucial. In many investigations critical information is required while at the scene or within a short period of time – measured in hours as opposed to days. The traditional cyber forensics approach of seizing a system(s)/media, transporting it to the lab, making a forensic image(s), and then searching the entire system for potential evidence, is no longer appropriate in some circumstances. In cases such as child abductions, pedophiles, missing or exploited persons, time is of the essence. In these types of cases, investigators dealing with the suspect or crime scene need investigative leads quickly; in some cases it is the difference between life and death for the victim(s). The Cyber Forensic Field Triage Process Model (CFFTPM) proposes an onsite or field approach for providing the identification, analysis and interpretation of digital evidence in a short time frame, without the requirement of having to take the system(s)/media back to the lab for an in-depth examination or acquiring a complete forensic image(s). The proposed model adheres to commonly held forensic principles, and does not negate the ability that once the initial field triage is concluded, the system(s)/storage media be transported back to a lab environment for a more thorough examination and analysis. The CFFTPM has been successfully used in various real world cases, and its investigative importance and pragmatic approach has been amply demonstrated. Furthermore, the derived evidence from these cases has not been challenged in the court proceedings where it has been introduced. The current article describes the CFFTPM in detail, discusses the models forensic soundness, investigative support capabilities and practical considerations.
Keywords: Computer forensics, process model, triage, computer crime, cyber crime, digital evidence
Computer crime is an unfortunate artifact of todays wired and global society. It is no surprise that individuals involved in deviant and or criminal behavior have embraced technology as a method for improving or extending their criminal tradecraft. With the proliferation of technology, our notions of evidence and what constitutes potential sources of evidence are drastically changing. Gone are the days when evidence was primarily document based. Today, and going forward, evidence is becoming more electronic or digital based. This is true for all investigations, not just those we commonly associate with crimes that use or are directed toward a computer, network or IT infrastructure.
There have been several investigative models developed to assist law enforcement in dealing with the shift from document based to digital based evidence (cf. Carrier & Spafford, 2003; Beebe & Clarke, 2004; Reith, Carr, & Gunsch, 2002; Rogers, 2006; Stephenson, 2003). These various models have assumed that the entire investigative process for computer forensics would be undertaken (see Figure 1). This can be extremely time consuming given the volume of data to examine and in most cases it involves the transfer of the system(s) or a forensic copy(s) of the data located on the storage media to a lab environment for a thorough examination and analysis. While this method may work in situations where time is not overly critical, it is not sufficient in time critical situations. Examples of these time critical situations include child abductions, missing persons, death threats etc. In these situations the need for quick information and investigative leads outweighs the need for an in-depth analysis of all the potential digital evidence back in a laboratory environment.
Figure 1 Traditional Process Models
In order to meet the demand for timely information derived from digital sources a different process model is proposed that is based on forensically sound principles and at the same time is sensitive to time constraints (i.e., critical investigative information can be derived in a short timeframe). The proposed model can be conducted on scene which provides the added benefit of having a feedback loop with the investigators; this allows the computer forensics analyst to modify their searches based on input from the primary investigators and those in direct contact with the suspect.
The development of the current process model was guided not only by the perceived need by the law enforcement community, but also from the formalization of a novel investigative approach that was being used in real investigations by agents working with the Southern Indiana Assistant U.S. Attorneys office USADA Steve Debrota. This office had been involved in several cases where the quick and efficient examination of digital evidence was crucial to the case and the investigative leads that were generated on site (at the suspects dwelling) were critical to the success of the operation, in securing a conviction of the offender and to protecting future victims. The USADAs office approached the Cyber Forensic Program housed in the Computer and Information Technology Department at Purdue University and the National White Collar Crime Center for assistance. The successful and pragmatic approach needed to be articulated and structured into a formal process model in order for it to be replicated in other jurisdictions, and in order for it to be properly evaluated and matured. The approach has been formalized into the computer forensics field triage process model.
The formalization of the model was evaluated by 20 State and Local Law Enforcement Officers from Indiana who took part in a two-day seminar offered at Purdue University during the fall of 2005. The model was presented to the officers over the course of two days and the feedback was overwhelmingly positive.
3. PROCESS MODEL
The computer forensics field triage process model (CFFTPM) is defined as: Those investigative processes that are conducted within the first few hours of an investigation, that provide information used during the suspect interview and search execution phase. Due to the need for information to be obtained in a relatively short time frame, the model usually involves an on site/field analysis of the computer system(s) in question.
The foci of the model are to:
Find useable evidence immediately;
Identify victims at acute risk;
Guide the ongoing investigation;
Identify potential charges; and
Accurately assess the offenders danger to society.
While at the same time protecting the integrity of the evidence and/or potential evidence for further examination and analysis.
Being able to conduct an examination and analysis on scene, in a short period of time and provide investigators with time sensitive leads and information provides a powerful psychological advantage to the investigative team. Suspects are psychologically more vulnerable within the first few hours of their initial contact with police, especially when this contact occurs in their place of business or dwelling (Yeschke, 2003). They tend to be more cooperative and open to answering questions even after being Mirandized. This cooperation can be critical in certain cases such as abductions, sexual predatory offenses etc. What is crucial to the investigator during this initial time period is the knowledge of the full extent of the crime and/or involvement of the suspect and triggers that further increase the suspects willingness to talk and cooperate. These triggers may be found in the digital evidence located on the suspects system(s) (e.g., email correspondence, digital maps, pictures, chat logs). The CFFTPM uses phases derived from the Carrier and Spafford (2002) Integrated Digital Investigation Process model (IDIP) and the Digital Crime Scene Analysis (DCSA) model as developed by Rogers (2006). The phases include: planning, triage, usage/user profiles, chronology/timeline, Internet activity, and case specific evidence (see Figure 2). These six phases constitute a high level of categorization and each phase has several sub-tasks and considerations that vary according to the specifics of the case, file system and operating system under investigation, etc. The use of higher order categories allows the process model to be generalized across various types of investigations that deal with digital evidence. The need for a general model has been identified in several studies as a core component of a practical/pragmatic approach for law enforcement investigations (ISTS, 2004; Rogers & Seigfried, 2004; Stambaugh, H., Beaupre, D., Icove, D., Baker, R., Cassaday, W., & Williams, W., 2001).
Figure 2 – CFFTPM Phases
Before discussing each of the models phases it is important that qualifications be placed around the use of the CFFTPM, as the model is not appropriate for all investigative situations.
As with any other type of investigation there are several considerations that must be made prior to deciding the most effective and efficient method. Two primary areas of consideration are legal and technical/operational considerations. Legal considerations include the scope and particulars of the warrant or order. Does the warrant allow for the seizure and removal of the system(s)? Is there sufficient particularity in the warrant and application for the warrant that allows for an onsite or in situ examination? Are there any 4th Amendment issues that need to be addressed? What are the reporting obligations to the issuing magistrate or judge? Are there particular discovery issues present or anticipated? Another important consideration is whether conducting an onsite examination affects the integrity of the original evidence. It is only when these and other potential legal issues are sorted out that the feasibility of using the CFFTPM can be determined. These legal considerations obviously necessitate that investigators and legal counsel work together throughout the entire case.
Technical/operational considerations include but are by no means limited to: The type of case? How critical is the time factor? What are the skills and abilities of the computer forensic examiners? What type of technology is involved (standalone systems, complex networks etc.)? Can the scene be safely and effectively controlled? Can the systems in question be powered off or must they remain live? What is the technical skill and knowledge level of the suspect? Do the computer forensic examiners have the proper equipment for onsite examinations? As was stated with legal considerations, these questions need to be considered before deciding to use the CFFTPM approach.
t is also important to understand that the CFFTPM does not preclude transporting the system(s) or storage media back to a lab environment for a more thorough and exacting examination and analysis. The procedures used in the CFFTPM adhere to the forensic principles of minimizing the contamination of the original scene and evidence, maintaining the integrity of digital evidence, maintaining the chain of custody of evidence, and complying with rules of evidence for admissibility at the Federal and State levels. In many cases a two step process is appropriate and prudent, where step one is the CFFTPM conducted at the scene to provide time sensitive investigative and interview leads and then step two being a secondary more traditional examination and analysis back at the lab in order to make a more exact determination of events and evidentiary locations in a more controlled environment.
Due to length constraints the discussion will only provide a brief description of the six phases and key sub-tasks. The primary investigative/examination considerations that are pertinent for each of the phases will also be presented.
The first phase in the CFFTPM is proper prior planning. Ideally, a lead investigator will have a matrix that quantifies the various possibilities of the crime scene, the suspect and the digital evidence and qualifies the expertise of the various investigators on the investigation team. For the lead investigator, this matrix is used to define what is known and what is not known thus aiding in determining what is wanted to be known. Similar to a Situation paragraph of a military Operations Order (OpOrd), this matrix identifies the enemy and friendly situations providing preemptive case intelligence. In the OpOrd, the enemy is defined characteristically by collecting intelligence through the acronym SALUTE: Strength, Activity, Location, Uniform, Time, and Equipment. This same acronym can be used in gathering case intelligence about the enemy/suspect prior to arriving at the crime scene.
Strength initially determines the suspect count and any other involved cohorts (specific numbers can be helpful), but could also include known or possible capabilities of the suspect. Activity defines the specific actions of the suspect (even small details could later be important). Location is not only the physical location of the scene, but also the virtual possibilities of cyberspace. Uniform relates more to the military, but in terms of cyberspace it can include email addresses, Uniform Resource Locators (URLs), usernames, passwords, network domains and other related deterministic markings, symbols, or corporate or agency identifiers. Time obviously builds upon other previously gathered case intelligence providing the chronological scope for investigative searches. Finally, Equipment covers the various types of wired and wireless hardware devices and software applications that can be expected when approaching the digital crime scene. Dependent upon the case intelligence determined from the SALUTE, the lead investigator will have many specific decisions to make prior to arriving at the crime scene.
Once the enemy/suspect elements of the SALUTE matrix are determined, the lead investigator can then identify friendly information for attacking this crime scene. From the OpOrd, this section of the matrix includes the mission of the investigation, the identification of the necessary personnel to provide the expertise for the investigation, and the knowledge of how to handle the unexpected. The mission of the investigation is normally determined by the type of crime committed in turn determining the level of investigation and the level of expertise necessary for the investigation. If the crime warrants expertise in multiple physical and virtual locations, multiple wired and wireless networks, multiple OS, personal digital technologies, or other specific technical needs, the investigator can plan accordingly. However, if there are unknowns in the investigation, it is imperative that the lead investigator determines who else can be contacted to aid in the investigation. With this compiled situational case intelligence, both about the suspect and the investigative team, the lead investigator can then formulate a plan of attack for determining what evidence is to be sought after and used to further the investigation.
Once the appropriate planning has been completed, the investigative process moves to those phases that deal more directly with the actual suspect or crime scene (depending upon the case). For the sake of our discussion it is assumed that the scene has been properly secured and controlled. Here the scene refers to both the physical and the digital (cf. Carrier & Spafford, 2003; Lee, Palmbach, & Miller, 2001; Rogers, 2006).
Since time is a crucial factor in the CFTTPM, it is extremely important that some sort of initial prioritization be undertaken. An effective and time-tested approach is to follow the medical triage model. In the medical field triage refers to:
A process for sorting injured people into groups based on their need for or likely benefit from immediate medical treatment. Triage is used in hospital emergency rooms, on battlefields, and at disaster sites when limited medical resources must be allocated. (AHD, 2000)
For our purposes triage can be distilled down to:
A process in which things are ranked in terms of importance or priority. Essentially, those items, pieces of evidence or potential containers of evidence that are the most important or the most volatile need to be dealt with first.
The triage phase is fundamental to the process model and along with proper planning it is the foundation upon which the other phases are built. The investigator needs to re-verify that the CFFTPM approach is still valid. Potential containers of evidence (e.g., computer systems, storage media and devices) need to be identified and prioritized based on the criteria of potential relevant evidence that can be obtained in a reasonably short time frame, and/or evidence with a short time to live (e.g., data in volatile memory, process tables, routing tables, temporary files systems). The investigators and interviewers who are dealing directly with the suspect or witnesses need to be providing direct input to the computer forensic examiner at this stage. This ensures that correct prioritizations and assumptions are being made.
For the remainder of the discussion it will be assumed that the computer forensic examiner has access to a forensic examination workstation or laptop that they have brought, a hardware write blocker to ensure that any storage media that is examined is done so in read only mode (thus ensuring that no contamination is occurring), and the computer forensic examiner has access to software tools that allow them to conduct field examinations (e.g., EnCase, FTK, ProDiscover, Sleuthkit, Filehound).
4.3 Usage/User Profiles
Once a system or storage media has been identified and prioritized during the triage phase, the actual examination and analysis are conducted. When compelling evidence is found on digital media, it is essential to show a link between that evidence and a specific, identifiable suspect1. In some cases, this is almost a fait accompli; for example, when it can be clearly shown that only one person had physical access to a PC. In many cases, multiple persons have access to a PC, making it necessary to find and examine digital artifacts and their properties to ascertain which individual or individuals are responsible for, or even had knowledge of, incriminating data found on the storage media. Often it is necessary to place artifacts in context with verifiable real world events. The payoff can be significant. A suspect presented with clear evidence indicating that he or she, and no other person is responsible for evidence recovered during an interview may feel compelled to admit their guilt.
This challenge has always existed, and is an essential element of most traditional examinations of digital evidence. In the context of the computer forensics field triage process model, the challenge is not only to do this quickly, but to expeditiously determine if it can even be done within the time constraints. (In some cases, the specifics of the evidence can obviate the need for this evaluation, for example when contraband files are found only in a specific users home directory). A thorough knowledge of user profiles and artifacts relating to usage, are essential to accomplishing this goal.
It is not always necessary or fruitful to evaluate user profiles. In determining the need and the most time efficient approach, several questions need to be asked: How many people use (have access to) the PC? How many user accounts are there? The answers to the first two are often not the same, leading to a third question, how many or which accounts are shared by more than one individual? Obviously in any case where more than one individual is able to log in to the same account, evaluating user profiles in and of itself, will not be sufficient to establish culpability for, or even a suspects knowledge of incriminating artifacts. It may be necessary to use the dates and times associated with incriminating artifacts and put them in context with the dates and times a suspect had access to the PC, or could reliably said not to have had access to a PC. Special care must be taken when attaching significance to dates and times recovered from digital evidence. This will be discussed further in the Timeline section of this paper. At the other extreme, if it can be firmly established that only one individual had access to a PC, the examiner can dispense with evaluating user profiles, and allocate the time budgeted to more fruitful avenues of search.
Loosely put, a user profile is a collection of files, folders, registry keys, and file properties that are exclusively associated with a unique user account. The value of, and speed at which these items can be evaluated will vary widely depending on case specifics, available tools, and specific knowledge and experience of the examiner.
4.3.1 Home Directory
In Microsoft Widows operating systems, the most obvious user related artifact is the Home Directory. By default, the home directory is only accessible only by the associated user account. Also by default, the location of stored files associated with various applications is set to a subfolder inside the home directory. The presence of incriminating files in the suspects home directory or one of its subfolders (Including such notables as desktop my documents and favorites) is a reliable indicator that only the suspect (or anyone who could log onto that account) had access to those files.
1 The discussion will be constrained to standalone systems running a Microsoft Windows environment, since this represents the majority of the training and systems encountered by law enforcement investigators (Rogers & Scarborough, 2006).
Additionally, the creation of a subdirectory structure with unique subfolder names can go a long way towards showing knowledge of and culpability for evidentiary objects found in the subdirectory structure (DeBrota, 2005).
4.3.2 File Properties (security)
It may be useful and time-efficient to check ownership and security properties of objects with known evidentiary value. The ability to set and read security permissions is not available in FAT, and is off by default in Windows XP (National White Collar Crime Center, 2003), even when the NTFS file system is used. When NTFS is used, and the feature turned on, a files security properties, most notably owner and permissions may be useful in establishing which account had access to, or even created that particular file (National White Collar Crime Center, 2003). When a file is created, the user account logged on is recorded as the owner as part of the files security descriptor (This can be changed only if an Administrator takes ownership of the file, in which case the Administrator is recorded as the owner). Permissions may also be of limited usefulness in establishing culpability. Only those accounts with the permission to do so may access an object, however this can be one or more user accounts, and the accounts that have permission to the object may change over time. An account that had read access on the 25th of January might not have had that same access on the 24th.
The registry can be a trap, causing the needless expenditure of valuable time, if the examiner does not have a precise idea of what they are looking for and exactly where to go to find it. On the other hand, a knowledgeable examiner with a clear vision of what information they want to recover can find several highly valuable items in less than a few minutes (National White Collar Crime Center, 2005). For example, the HKEY_USERS\suspects SID\Software\Microsoft\Windows \CurrentVersion\Explorer\RecentDocs key and associated sub-keys contain a fairly comprehensive list of files that were opened while that account was logged on. This is a strong indicator that a suspect had knowledge of all files that were viewed, but requires that the examiner knows or can quickly and reliably identify the NTUSER.DAT file associated with the users account.
Depending on the circumstances and resources available, examining the user profile may be the most costly part of the examination in terms of time expended, however it is often an indispensable operation as well.
The chronological scope of the investigation can be defined by the case intelligence. In an investigation, digital evidence is defined by its temporal value, known as MAC times (Casey, 2004). Without going into a detailed narrative of the specifics of MAC times specifically to each OS, the following are some general guidelines for Windows MAC Times. Windows MAC times are defined in the FAT32 and NTFS file systems as:
Modification is defined by when a file contents has been changed
Access time is defined by when a file was viewed
Created time is defined by when a file was created
Although MAC times appear simple, it is well-documented (Casey, 2004; Farmer & Venema, 2005;Vacca, 2002) that there are many inconsistencies with MAC times and there are various other vulnerabilities when describing other vendor specific operating systems, such as those used on personal digital technologies devices (e.g., PDAs, Cellphones, MP3 players).
Once an investigator gains access to the files in question and their individual MAC times, they can start to qualify their searches, thus quantifying their evidence (Casey, 2004). For the CFFTPM, several quantifications should be examined by sorting the files on their various MAC times within the Conference on Digital Forensics, Security and Law, 2006 35 chronological scope of the investigation. The first such quantification includes the time periods of normal use by the suspect and other known users of the computer or device (Casey, 2004; Farmer & Venema, 2005). This can be obtained by correlating known users accessing the computer with files that have been modified, accessed or created during those times. Organization by user or by time period helps to quantify who was doing what during what time periods. Such organization may also provide time periods that stand out or look unique. These types of unique time periods could be studied outward in an attempt to find other significant relationships or value.
Another quantification includes the identification and analysis of software applications and data files used or accessed during qualified times of interest (Casey, 2004; Farmer & Venema, 2005; Vacca, 2002). Again, this can be obtained by correlating known users with MAC times possibly providing unique time periods that could be of significant value. Organization of applications or files within a certain time period quantify activities that occurred during these time periods. An application or file that is accessed prior to, during or after a criminal incident can be a major indication of involvement or intent.
Finally, the third quantification includes the identification and analysis of recent shortcuts and stored information (Casey, 2004; Farmer & Venema, 2005; Vacca, 2002). These could include, but are not limited to items on the desktop, commonly used software applications, and the various locations of Internet browser cookies, cache, and the index.dat file. Note that various Internet structures (cookies, cache and the index.dat file) can be very useful in determining chronological intelligence in that these provide much more time-based evidence than just MAC times. Specifically, each Index.dat file provides date-time stamps for each Internet server request.
For clarification, it should be noted that time is maintained differently in different operating systems and versions, system clocks do drift and are easily corrupted, and knowledge of time zones and time changes is essential to any digital investigation (Casey, 2001; Casey, 2004; Farmer & Venema, 2005; Vacca, 2002). Finally, in defining the case through chronology, there is a need to establish a provenance of the information and correlate events based on an absolute time determined by some piece of physical evidence (Casey, 2004; Vacca, 2002).
Almost every case will require an examination of artifacts associated with Internet activity, such as instant messaging (IM), e-mail and web browsing. The value, time cost, and time criticality will vary widely, depending on circumstances including the specific applications involved, type of activity being examined, and whether the PC being examined belongs to a suspect or a victim (e.g., in a missing persons case). An effective practice is for the computer forensic examiner to evaluate what type of Internet activities they believe the suspect (or victim) was involved in, and to evaluate if and how each of those activities relates to the case. Types of activities may include web browsing, e-mail, instant messaging, reading or posting to USENET newsgroups, trading files.
4.5.1 Browser Artifacts
While the specifics vary, most web browsing applications store some method for storing cookies, either as a file or as separate files, some means of storing temporary Internet files, and some means of storing user information and preferences, such as typed Uniform Resource Locator (URLs) and favorites. The specific content of individual cookies is determined by each individual website and is rarely of evidentiary value. In most cases, the evidentiary value of a cookie is limited to its name. Typically, the name of a cookie will match the URL of the site that deposited the cookie, indicating that the PC had visited that site at some point in the past. This does not go to show intent as the cookie will be created whether the browser was redirected from another site, or intentionally pointed to the site with a typed URL. Dates and times associated with cookies may help to determine when a site was visited and can be useful in creating investigative timelines.
Temporary Internet files are essentially cached copies of web page components (often graphics) stored on the local PC. The investigative value is that these files are stored locally without the intent or intervention of the user, and that some files, for example contraband images, are of evidentiary value in and of themselves. An investigator must keep in mind that these files are easily cleared out by most browsing applications, or with third party tools. Most importantly, investigators must weigh the potential value against the time it will take to search through even a moderately populated cache. Examiners should expect a search of temporary Internet files to take hours or days. In many cases, that requires more time than the examiner has.
A web browsers storage of user information and preferences can be a quick source of useful information. In cases where Internet Explorer is the browser, the index.dat file can contain a running record of sites visited, including access to web based e-mail (but not e-mail content), and even local files. The examples below (some information has been redacted) all represent data pulled from an index.dat file in less than five minutes, using a free third-party tool (see Figure 3). The User Name in each case, indicates the name of the windows account that owned the index.dat file in question.
============================================= URL : http://www.XXXXXX.com Title : New Page 1 Hits : 17 Modified Date : 10/4/2005 9:05:35 PM Expiration Date : 10/30/2005 9:05:36 PM User Name : xxxxxx ============================================= This example shows a user visiting a site 17 times, most recently on 10/4/2005
============================================= URL : http://images.google.com/images?q=kitties&hl=en Title : kitties - Google Image Search Hits : 7 Modified Date : 10/4/2005 9:09:46 PM Expiration Date : 10/30/2005 9:02:38 PM User Name : xxxxxx ============================================= This example shows that a user performed a google image search on the term kitties 7 times, most recently on 10/4/2005
============================================= URL : http://us.f307.mail.yahoo.com/ym/ShowFolder?rb=Inbox&reset=1&YY=85059 Title : Yahoo! Mail - firstname.lastname@example.org Hits : 21 Modified Date : 10/4/2005 9:06:37 PM Expiration Date : 10/30/2005 9:06:38 PM User Name : xxxxxx ============================================= This example shows a user accessing their yahoo account for the 21st time on 10/4/2005.
============================================= URL : file:///D:/Program%20Files/mIRC/logs/%23Beginner.EFnet.log Title : Hits : 1 Modified Date : 10/4/2005 9:44:39 PM Expiration Date : 10/30/2005 9:37:32 PM User Name :xxxxxx ============================================= This example shows the user accessing a file (in this case, an IRC chat log, but could be any type file) on the local drive for the first time on 10/4/2005.
Figure 3 – Index.dat Examples
4.5.2 E-mail Artifacts
E-mail artifacts may be of enormous evidentiary value, but can require a very expensive investment in time. Procedures for examining e-mail and extracting useful data are usually specific to the particular e-mail client, and can be time consuming to implement. If extraction of e-mail is successful, even a cursory screening of all the e-mail in a suspects mailbox could take many hours. If web-based e-mail is used, there is often no local storage of e-mail artifacts.
4.5.3 Instant Messaging Artifacts
Most instant messaging clients maintain some type of contact information, and have the capability to record and store logs of the conversations that take place between the user and his or her online contacts. In most cases, this logging capability is off by default but can, and often is, turned on by the user. Contact information for most IM applications is maintained at the server, and may not be found on the local PC. Chat logs can contain a wealth of data, including the conversation itself, as well as the screen names of other parties. A single chat log may contain hours of conversation. A thorough examination of multiple logs may bear a prohibitive cost in time. If it is necessary to examine chat logs, it is important for the examiner to have a clear idea of what he or she is looking for. String search tools should be implemented as much as possible.
A traditional examination would likely involve a thorough examination of all of these, and many other artifacts. The mandates of the CFFTPM require that the examiner judiciously evaluate the potential benefit of examining each of these artifacts with the time cost of doing so.
4.6 Case Specific Evidence
It is important for the computer forensic examiner to be able to adjust the focus of every examination to the specifics of that case. This is a skill set in and of itself, and requires the ability to reconcile a number of conflicting requirements in the manner most appropriate not just to a type of case, but to each specific set of circumstances. There are several practices that can facilitate an effective optimization of resources. A computer forensic examiner should be able to evaluate time resources, utilize pre-raid intelligence, customize search goals, and prioritize search goals.
Of all the resources available to the examiner, time is usually in shortest supply. One consideration when taking stock is whether the time requirement is bounded or unbounded. Is there a defined deadline (bounded) beyond which the search is halted, or the evidence loses all value? Is the mandate to find evidence as soon as possible, but even if it takes days (unbounded)? For example, a permissive search might only be allowed until the end of an interview, whereas the search of a missing persons PC might be conducted as rapidly as possible, but still go on for hours. Time is clearly of the essence in both cases, but the lack of a time limit in the unbounded case can justify some avenues of investigation that would not be feasible in a bounded situation. In all cases, time is an expensive commodity. The time cost of any examination activity must be weighed against the potential for fruitful results of that activity. As a general rule, it is usually best to perform those tasks which can be accomplished most quickly first.
The value of planning and pre-raid intelligence cannot be over-emphasized. Reliable information on search terms, contacts, types of activities, applications used, etc. in advance of the search can allow the examiner to develop at least some search strategies before arrival on scene. Every minute saved in this manner is potentially another minute available to conduct the search itself.
It is difficult to say with certainty which specific type of digital artifact is the optimum site to search for a given type of case; however some types of artifacts are generally more likely to produce relevant information for specific types of cases. The example cases summarized below are not intended to be a comprehensive list of the type of case or of all recommended approaches.
5. CHILD PORNOGRAPHY
The highest priority should obviously be given to actual instances of child pornography on the drive. A graphic viewing utility that quickly displays large quantities of thumbnails from graphic and audiovisual files can help speed up the task of searching the drive directly. It may be helpful to take a quick look at the directory structure, searching for indications of cataloged, sorted storage of contraband material. If Internet activity is involved, many web browser artifacts can be searched fairly quickly to identify contact with incriminating web sites. Instances of child pornography may potentially be found in temporary Internet files, however the time required to search through these files is likely to be prohibitive. If distribution of child pornography is suspected, it may be prudent to search for artifacts associated with IRC FServes or peer to peer file sharing applications (DeBrota, 2005). E-mail and USENET newsgroup postings may also be associated with distribution of child pornography; however this is often very time-consuming and should be considered carefully.
6. DRUG ACTIVITY
A quick search of the drive for spreadsheets, documents or databases is often a sensible use of time (unless the number of files found is prohibitive). These files may contain sales records, customer information, drug-making instructions, or lists of precursor chemicals. If time can be allotted to do so, it may be fruitful to examine Internet artifacts for Internet searches on drug-related terms, and for online transactions involving purchases of precursor chemicals or equipment. It may be possible to find drug-related e-mail or instant messaging artifacts, however this will be time consuming especially so because it will likely require manual screening of message content.
7. FINANCIAL CRIMES
A cursory search of the drive for documents and images (specifically images of checks or other potentially fraudulent financial instruments) might be at the top of the list. Documents could include invoices or other financial records. Installed financial applications, such as quicken or MS Money and their associated records may be a fruitful source of evidence. Within the constraints of the factors previously highlighted, the examiner must efficiently prioritize the search goals from the beginning. Some considerations will be constant. Time and speed will almost always be the most important consideration. Forensically sound practices must always be observed. System date and time, and time-zone information from the suspects system should always be examined and documented. To the extent practical, the examiner should prioritize search goals to focus on applications the suspect is known to have used or reasonably presumed to have used in relation to the suspected illegal activity based on available intelligence.
The computer forensic field triage process model (CFFTPM) is a formalization of real world investigative approaches that have distilled into a formal process model. At the heart of the model is the notion that some investigations are extremely time sensitive; hours can literally mean the difference between life and death for a victim or the escape of the suspect. Most law enforcement cases today involve digital evidence of some kind. We are truly a digital nation and as such our lives (the good and the bad) are reflected in technology and the bits and bytes. Correspondingly, digital evidence is a primary source of critical information and investigative leads that are required within the first few hours of many investigations.
While the investigative approaches that were used to develop the model came primarily from child pornography cases, the model is general enough to be used across a wide spectrum of investigations. The six primary phases of the CFFTPM (planning, triage, usage/user profiles, chronology/timeline, email & IM, and case specific evidence) are important in such diverse cases as financial fraud, identity theft, cyber stalking and murder. The various sub-phases or tasks under each primary phase need to be modified based on the specifics of each investigation. The tasks and considerations discussed under
each of the phases act as examples of the decision making process that needs to take place sensitivity of time vs. quality and importance of the evidence derived.
The CFFTPM is consistent with the various theoretical models that have been developed within the field of digital forensic science. By following the CFFTPM a computer forensic examiner has not precluded a more thorough traditional examination and analysis back in the lab. The procedures used on site are forensically sound, maintain the chain of custody, and comply with Federal and State rules for the admissibility of evidence.
One of the biggest advantages of the CFFTPM (very practical and pragmatic) is due to the fact the model was developed in reverse of most other models in the area. The investigators in the field matured their instinctive approaches based on actual trial and error, cases, court decisions and the direction from prosecutors. The CFFTPM merely aggregated these approaches and articulated them into a more formal methodology; still maintaining the investigative essence and the key components that have been battle tested.
Just as it has been said that one software tool does not a computer examiner make, only possessing one investigative process model is equally as limiting. Computer forensic examiners need a repertoire of tools and just as important, a repertoire of examination and investigative approaches. The CFFTPM is not the ultimate solution for every case; it should only be used where appropriate and only after carefully weighing the legal and technical considerations that were discussed. In those instances where it has been employed it has been extremely effective!
Education never ends, Watson. It is a series of lessons, with the greatest for the last (Sherlock Holmes, The Adventure of the Red Circle)
Beebe, N. & Clark, J. (2004). A hierarchical, objectives-based framework for the digital investigations process. Paper presented at the DFRWS, June 2004, Baltimore, MD.
Casey, E. (2001). Handbook of Computer Crime Investigation: Forensic Tools and Technology. San Diego: Academic Press.
Casey, E. (2004). Digital Evidence and Computer Crime: Forensic Science, Computers and the Internet. San Diego: Academic Press.
Carrier, B., & Spafford, E. (2003). Getting Physical with the Digital Investigation Process. International Journal of Digital Evidence, Volume 2 (Issue 2), 20.
DeBrota, S. (2005). Computer Forensic Analysis Checklist. US Attorneys Office, Southern District of Indiana checklist. Updated March 28, 2005.
Farmer, D., Venema, W. (2005) Forensic Discovery. Pearson Education, Inc, Upper Saddle River, NJ Carrier, B. (2005). File System Forensic Analysis. Addison-Wesley Professional.
Institute for Security Technology Studies. (2004). Law enforcement tools and technologies for investigating cyber attacks: A national research and development agenda. Retrieved Sept 9, 2004 from http://www.ists.dartmouth.edu
Lee, H., Palmbach, T, and Miller, M. (2001). Henry Lee’s crime scene handbook. San Diego: Academic Press.
National White Collar Crime Center. (2005). Registry Windows NT/2000/XP. Unpublished training presentation from Cybercop 301 course.
National White Collar Crime Center. (2003). Windows NT/2000/XP Security and Processing issues. Unpublished training presentation from Cybercop 301 course.
Reith, M., Carr, C., & Gunsch, G. (2002). An Examination of Digital Forensic Models. International Journal of Digital Evidence, Volume 1(Issue 3), 12.
Rogers, M. (2006). DCSA: Applied digital crime scene analysis. In Tipton & Krause.
(Eds.). Information Security Management Handbook. (pp. 601-614) New York: Auerbach.
Rogers, M. & Scarborough, K. (2006). Preliminary findings: 2006 law enforcement national digital evidence survey. American Academy of Forensic Sciences Annual Conference. Seattle, Feb 20-24.
Rogers, M., & Seigfried, K. (2004). The future of computer forensics: A needs analysis survey. Computers and Security(Spring 2004).
Stambaugh, H., Beaupre, D., Icove, D., Baker, R., Cassaday, W., & Williams, W. (2001). Electronic crime needs assessment for state and local law enforcement. Retrieved September 1, 2005 from http://www.ojp.usdoj.gov/nij/pubs-sum/186276.htm
Stephenson, P. (2003). Modeling of Post-Incident Root Cause Analysis. International Journal of Digital Evidence Fall 2003, Volume 2(Issue 2), 16.
The American Heritage Dictionary of the English Language – 4th Edition. (2000). Triage. Boston: Houghton Mifflin.
Vacca, J. (2002). Computer Forensics Computer Crime Scene Investigations. Revere, MA: Charles River Media.
Yeschke, C. (2003). The art of investigative interviewing – second edition. Boston: Butterworth Heineman.