Incidence Response Shooting Script

Jonathan Francis Roscoe <jjr6@aber.ac.uk> Department of Computer Science, Aberystwyth University January 10th 2011

Introduction
For the majority of the world technology is an ever present feature of our lives. Its not surprising that digital devices have come to be important in the world of crime. For instance digital communiqu may provide valuable evidence e for all manner of crimes such as theft and violence and could potentially defend or counter suspect alibis, or may be used to infer intent [2]. Acts of cyber crime are also now taken seriously and digital forensics are often crucial in building cases against a suspect for all manner of cases such as intellectual property theft and illicit fund transfers [4]. Mobile phones, fax machines, personal computers and GPS are a few examples of technology that can be forensically analysed to provide evidence. Many of the activities carried out on a digital systems is recorded in some form and if handled correctly, a timeline of events can be reconstructed by authorities as evidence. This paper details the steps that a digital forensics investigator should take when responding to a incident scene.

Hypotheses
As a forensics expert analyses a suspect system they should form hypotheses based on their observations. These hypotheses may be useful for inferring the actions of the a user and observation of their habits and technical awareness may prove useful in successfully isolating evidence. Ideally this shooting script would be used a checklist for the forensic examiner. These hypotheses can be reviewed after the gathering of evidence to reconstruct any crimes carried out on the system.

Software
The shooting script detailed in this paper includes examples where appropriate using Linux (or ports of) tools. In the examples $ is used to indicated a Linux promt and a Windows prompt. Examples may use arbitrary values as parameters, the reader is assumed to be aware of the usage of these tools and be able to competently adjust parameters appropriately. These tools are listed as part of the recommended toolkit in Appendix A. In some cases, reference to Windows applications may be made, but are not guaranteed. Backtrack 3 was the Linux system used in the examples. Forensic investigation could be necessary on any manner of system, fortunately many tools work well with across platforms. As much investigation is merely a matter of le analysis (e.g. searching for images or key text) analysis can be performed independent of the suspect machines operation system.

Data Aquisition and Physical Security

The rst step of response begins the chain of custody and is important for ensuring evidence is usable and recoverable. The physical area should be secured and evidence appropriately tagged. Evidence dynamics refers to the changes that can occur to evidence as a result of inuence from the wider world, this may include dead man switches or similar pre-arranged programs by a suspect, evidence deleted by victims or evidence corrupted by those in authority, such as police ocials who may have to make decisions at a crime scene. Volatile evidence may include data in working memory, swap space and similar data on running systems. Data can include evidence of recent communication and network activity which may be otherwise hard to trace. If possible such data be recorded swiftly and before less-volatile evidence is collected.

The chain of custody can be maintained through vigorous paperwork and documentation of all media collected from the crime scene. A Secure the Scene It is important that the soundness of evidence is respected by all those involved and ensure it is not corrupted. If a forensics expert is not immediately available authorities should seek expert advice concerning active computer systems. No equipment should be touched by a non-expert or a civilian. Photographs should be taken if they do not interfere with the scene. Once a forensics expert arrives on scene they should attend to any running system immediately. Typical system tools as listed in Appendix A can be utilised for analysis of a live system. B System State General information about the status of the system at the time of seizure should be recorded (more detailed analysis of some follows). This includes: Date and Time (contrast with known time) Uptime Logged on users DNS cache (ipconfig /displaydns on Windows or rndc dumpdb on Linux) Running process Open network ports. The examiner should use their own copies of the various system tools as software present on suspect machines may have been modied. C List Running Applications ps or top will list all processes and allow you to prioritise output by load, user or other options. They can be useful in determining applications that may compromise volatile data (for example, if a disk shredding application is being executed). Such programs can be killed, or investigated further if they may provide evidence (e.g. chat clients). D List Active Network Connections lsof is used to list open les (which includes notional networking ports). lsof -i -P Will list all open IP sockets on a Linux system. This can reveal communications with the outside world, any systems that may be associated with the suspect, or if the suspect computer is being used as a relay, perhaps running a back door. Some connections (particularly HTTP) may stay in an partially open mode for several minutes, due to the nature of TCP. This can shed some light on recent browsing activity or communications that may not be present in logs. As shown in this Windows example using netstat: > netstat -a Active Connections Proto TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP Local Address 127.0.0.1:54167 192.168.1.42:49184 192.168.1.42:49211 192.168.1.42:49520 192.168.1.42:54089 192.168.1.42:54091 192.168.1.42:54094 192.168.1.42:54096 192.168.1.42:54098 192.168.1.42:54100 192.168.1.42:54102 192.168.1.42:54115 192.168.1.42:54116 192.168.1.42:54120 192.168.1.42:54122 Foreign Address State activate:33367 TIME_WAIT persephone:microsoft-ds ESTABLISHED 84.53.133.210:http CLOSE_WAIT alt42:ssh ESTABLISHED lhr14s02-in-f104:http ESTABLISHED lhr14s02-in-f104:http ESTABLISHED text:http ESTABLISHED wy-in-f101:http TIME_WAIT stackoverflow:http TIME_WAIT stackoverflow:http CLOSE_WAIT stackoverflow:http CLOSE_WAIT gravatar:http TIME_WAIT gravatar:http TIME_WAIT wy-in-f102:http ESTABLISHED stackoverflow:http TIME_WAIT

TCP TCP TCP

192.168.1.42:54133 192.168.1.42:54134 192.168.1.42:54135

64.4.11.252:http 84.53.133.96:http 84.53.133.96:http

ESTABLISHED ESTABLISHED ESTABLISHED

E Disconnect System From Wider World Once volatile network related data has been gathered it is wise to disconnect the machine from any network it may be on, apart from a closed network with only the forensic workstation. This prevents any outside accomplice from interfering with the system. F Secure RAM The most volatile data is generally considered to be RAM. Preserving RAM is important given its volatility, but should be done after the system has been disconnected to ensure no outside tampering occurs as the process of copying several gigabytes of data such as this can be highly time consuming. If an administrator/root account is accessible this is often a trivial copy task that can be carried out with the dd. An example in Windows: > dd.exe if="\\.\Device\PhysicalMemory" of="e:\PhysicalMemory.dump" And Linux: $ dd if="/dev/mem" of="/media/external/mem.dump" In Linux both /dev/mem and /dev/kmem may be of interest, but access is typically disabled by kernel conguration for security reasons. kexec is a potential tool for resolving this problem by replacing the kernel. G Acquisition of Physical Media Once volatile data has been gathered the system should be powered down and transported to a secure location for examination of persistent data. All items of potential evidence should be securely bagged and labeled. This may include computers, external hard drives, USB devices, mobile telephones, ereaders, etc. Its important to note that certain evidence, specically, those pertaining to child pornography are often illegal to possess and so can only be secured and examined in police stations, not private forensic companies. Rather than inserting an external drive into the suspect computer and risking contamination of evidence, or malicious software, it would be benecial to transfer dumps over the network in many cases. Netcat is useful for this. On the forensic workstation: $ nc -l 1234 | dd of="/forensic_case/dump" And on the suspect machine: $ dd if="/dev/sda" | nc -c 192.168.1.1 1234

Data Acquisition

Once all physical media has been secured data must be placed into an appropriate form for analysis. This involves reproducing data so that it can be independently analysed and validated. Evidence is inadmissible if its source cannot be properly identied, so data in custody must be checksummed to maintain authenticity. G Disk Cloning Some software such as EnCase Forensic have an entire suite of tools for managing cases and evidence les through a graphical interface, here we copy a disk and generate a hash for validation using standard Linux utilities once again. The disk should be connected to a forensic system using a hardware write blocker to prevent the system from modifying timestamps or other metadata. Once connected the drive can duplicated as follows: $ dd if="/dev/sda" of="/dev/sdb" Where /dev/sda is the original and /dev/sdb is ideally a brand new hard drive of the same type. It is wise to congure block size and other specics for dd to use in the parameters. Once duplicated, the authenticity can be proven using md5 checksums, which should show identical output:

$ md5sum /dev/sda 78842815248300fa6ae79f7776a5080a $ md5sum /dev/sdb 78842815248300fa6ae79f7776a5080a This should be carried out for all other pieces of evidence. If desired, the cloned disks can be passed to software such as EnCase which will create special evidence les, or can be examined with system tools as we have been doing.

2.1

Collection of Tertiary Data

Systems not directly associated with the suspect computer may be able to provide evidence of activity, for example Intrusion Detection Systems (IDS) and network monitors on the same network. Evidence may also be provided by target systems or intermediate servers in such forms as access logs or received emails. The appropriate authorities of these systems should be contacted to provide appropriate witness statements.

2.2

Deleted File Recovery

Unless a secure delete (where used data blocks are overwritten with plain or randomised bits) is performed, le deletion is not necessarily permanent. Deleted les will only become non-recoverable when the blocks used are overwritten by new data, this happens naturally over the lifetime of a system, the speed varies with usage. Tools exist to recover these les that have not yet been overwritten. Once such les have been recovered they can be analysed as regular les as discussed in the following sections. H Recovering Deleted Files Scalpel is a popular open source application that is lesystem independent, and in the event recovery is not possible, may be able to provide valuable metadata or partial recovery. Conguration is extensive and is carried out through a conguration le, rather than through the command line: $ scalpel /dev/sda -o /forensics/scalpel A simpler tool that was the basis for scalpel is foremost: $ foremost -t jpg -i /dev/sda -o /forensics/recovered_jpegs

File Analysis

Once data has been appropriately and securely acquired it can be condently analysed under laboratory conditions. Forensic suites such as EnCase provide tools to search acquired evidence, alternatively an evidence drive can be mounted to a machine and searched using system tools. In many cases this is down to personal preference, but software like EnCase has many inbuilt features for automatically detecting le types, recovering delete les and collating them. In contrast, Linux tools can oer greater exibility in searching. I Email Investigation Emails are frequently presented in cases where digital evidence is used [1]. Emails may reveal cohorts, corroborate or contradict alibis or expose premeditation depending on various information such as content, senders and recipients and timestamps. Access to remote mailboxes may be subject to legal restrictions, but email clients often store local copies of read and sent email in common places. Clients vary, but the general task is to search for common database les, for example on a Windows system where a user may have sent email with Outlook Express: $ find /mnt/sda -name *.dbx /mnt/sda/Documents\ and\ Settings\archer\Mail\archer.dbx $ readdbx /mnt/sda/Documents\ and\ Settings\archer\Mail\archer.dbx /forensics/archer.mail $ grep -in "jonnie" /forensics/archer.mail 3:Envelope-to: jonnie@notquitegrownup.com 7: for jonnie@notquitegrownup.com; Sun, 20 Jun 2010 15:29:41 +0100 11:To: jonnie@notquitegrownup.com 27:Return-path: <jonnie@notquitegrownup.com> 28:Received: from jonnie by notquitegrownup.com with local (Exim 4.69)

29: (envelope-from <jonnie@notquitegrownup.com>) 35:From: Jonathan <jonnie@notquitegrownup.com> The le found can be converted to mbox (Linux) format. On a Linux system mbox les are typically stored in /var/spool/mail although some applications may use userspace. The examiner will need to search for common or conspicuous les. Mbox les can be analysed as text and there are many free tools to perform searches. J Browser History Browser history can be recovered in a very similar way, and the examiner must inspect for common history types. A tool known as Pasco from Foundstone can be used to print browser history. For example, to retrieve the history for an Internet Explorer installation: $ find /mnt/had -name index.dat /mnt/hda/Documents\ and\ Settings/archer/History.IE5/index.dat $ pasco "/mnt/hda/Documents\ and\ Settings/archer/History.IE5/index.dat" URL http://www.google.com/ Monday Aug 21 18:58:49 2001 URL http://www.evilbankofevil.com/ Monday Aug 21 19:02:30 2001 Mozilla Firefox uses an sqlite database le called places.sqlite, that can be investigated with the an sqlite client or the specialised FirefoxForensics tool. The techniques used for browser and email recovery can be used to all manner of logging programs, such as HTTP, FTP servers or clients, chat applications and more. The examiner simply needs to be aware of the software used on the suspect system so that such log les can be identied. K Hidden & Encrypted Files Many les may contain useful data, though users may go to lengths to hide them. A common technique is to rename les to change the extension, but there exist tools that can read le headers to deduce the le format. One such tool is the Linux program le which uses libmagic. For example, to nd all all JPEG images, including those with modied extensions we could use the command: $ find /dev/sda/home/archer -print0 | ./.mozilla/firefox/Cache/CA53B955d01: ./.mozilla/firefox/Cache/AF512168d01: ./.mozilla/firefox/Cache/CD02F851d01: ./51TNKPXE4AL._SL500_AA300_.exe: JPEG xargs -0 file | grep JPEG JPEG image data, JFIF standard 1.01 JPEG image data, JFIF standard 1.02 JPEG image data, JFIF standard 1.02 image data, JFIF standard 1.01

As for le encryption, suspects are legally obliged to divulge cryptographic passwords, but there are some brute forcing applications such as John the Ripper that can attempt to crack Unix passwords that may be used to encrypt home directories or les. Plausibly deniable cryptography is a lot more dicult to break due to diculty in detecting its existence. L Other Pertinent Filetypes On Microsoft Windows a le called Thumbs.db or Thumbcache.db is often created for folders with images. These les are used to generate a preview of a collection of images and sometimes go unchanged even if les within a folder have been removed - so they can provide a generalisation of images that were once present. vinetto is a free tool that can do this: $ vinetto -s -o /forensics/images "/mnt/hda/Documents\ and\ Settings/archer/My\ Documents/Thumbs.db" Filetypes that may be of interest and are easily analysed are word processing (.doc, .docx, .odt), images (.jpeg, .png, .gif), text (.txt) or any other type of le created to store user data.

Reconstruction

Once evidence has been successfully gathered it must be put together to determine the purposes for which the system was used. Assembling communications and work carried out by the users of the machines will give an indication of guilt, may reveal the location of further evidence or reinforce theories conrming the crime. M Timeline Construction Based on le timestamps (modication/access/creation) changes across the system can be tracked. Other timestamps in logs such as browser history can be collated to form a complete log of acitons carried out on the machine. The Java application Aftertime is designed to do this and works with the

logs of many applications. This timeline will provide a relational and temporal analysis of the users movements and behaviour which. Investigators need to take in data from other systems, or data from the physical world to see how the actions on the suspect machine may correspond to crimes. N Finalisation of Hypotheses With a timeline formed the contents of gathered les can be assessed and interpreted to formalise the hypotheses an examiner has formed during their work. An expert witness must be created to dene the actions performed and attribute them to a user within a time frame. The examiner can then draw on personal experience and professional knowledge to assess the suspects culpability and provide evidence in court.

Justication
I believe the 14 steps I have outlined are a sensible route for incidence response. The rst few steps ensure a system is secure from remote tampering before preserving volatile data. The data is then validated to ensure any evidence found is admissible in court. Remaining steps involve the systematic recovery and detailed analysis of data from to isolate pertinent information.

Toolkit

The following list is a suggested toolkit based on my interpretation of the forensic analysts needs that should be available to all investigators between the scene and laboratory. Laptop/Workstation Typical networking capabilities and interface leads (ethernet, USB, IDE, etc) Live forensic disk (typically a Linux distribution such as Backtrack or PHLAK) Cross-platform software tools, such as GNU coreutils and ported versions (eg. UnxUtils for Windows). As a minimum these tools should include: netcat & cryptcat md5sum dd (block copy) ps/top grep netstat Windows specic: arp, nbtstat, nslookup, ipcong, netdiag Any other specialist acquisition tools (e.g. enCase) Tool kit Write-blocker to prevent modication of data on hard drives External hard drive USB disks Camera (to record system setup) General computing spares (mouse, keyboard, monitor, in case system was damaged before police arrival) Paperwork/labeling equipment for seizure

References
[1] [2] [3] [4] E Casey. Digital evidence and computer crime, 2nd Edition. 2004. E Casey. Handbook of Digital Forensics and Investigation, 1st Edition. 2010. B J Grundy. The Law Enforcement and Forensic Examiners Introduction to Linux. 2008. A Yasinsac, R Erbacher, D Marks, Mark M Pollitt, and P Sommer. Computer forensics education. IEEE Security and Privacy, 1:1523, July 2003.