incidence response script

8/3/2019 Incidence Response Script

1/6

Incidence Response Shooting Script

Jonathan Francis Roscoe 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 deviceshave come to be important in the world of crime. For instance digital communique may provide valuable evidencefor all manner of crimes such as theft and violence and could potentially defend or counter suspect alibis, or maybe used to infer intent [2]. Acts of cyber crime are also now taken seriously and digital forensics are often crucial inbuilding 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 forensicallyanalysed to provide evidence.

Many of the activities carried out on a digital systems is recorded in some form and if handled correctly, a timelineof events can be reconstructed by authorities as evidence. This paper details the steps that a digital forensicsinvestigator 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. Thesehypotheses may be useful for inferring the actions of the a user and observation of their habits and technical awarenessmay prove useful in successfully isolating evidence. Ideally this shooting script would be used a checklist for theforensic 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. Inthe examples $ is used to indicated a Linux promt and a Windows prompt. Examples may use arbitrary valuesas parameters, the reader is assumed to be aware of the usage of these tools and be able to competently adjustparameters 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 inthe examples.

Forensic investigation could be necessary on any manner of system, fortunately many tools work well with acrossplatforms. As much investigation is merely a matter of le analysis (e.g. searching for images or key text) analysiscan be performed independent of the suspect machines operation system.

1 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 orevidence corrupted by those in authority, such as police officials 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 caninclude evidence of recent communication and network activity which may be otherwise hard to trace. If possiblesuch data be recorded swiftly and before less-volatile evidence is collected.

1


2/6

The chain of custody can be maintained through vigorous paperwork and documentation of all media collected fromthe crime scene.

A Secure the Scene

It is important that the soundness of evidence is respected by all those involved and ensure it is notcorrupted. If a forensics expert is not immediately available authorities should seek expert adviceconcerning 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 (moredetailed 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 suspectmachines 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 adisk shredding application is being executed). Such programs can be killed, or investigated furtherif they may provide evidence (e.g. chat clients).

DList 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 outsideworld, any systems that may be associated with the suspect, or if the suspect computer is beingused as a relay, perhaps running a back door. Some connections (particularly HTTP) may stay inan partially open mode for several minutes, due to the nature of TCP. This can shed some lighton recent browsing activity or communications that may not be present in logs. As shown in thisWindows example using netstat:

> netstat -aActive Connections

Proto Local Address Foreign Address StateTCP 127.0.0.1:54167 activate:33367 TIME_WAITTCP 192.168.1.42:49184 persephone:microsoft-ds ESTABLISHEDTCP 192.168.1.42:49211 84.53.133.210:http CLOSE_WAITTCP 192.168.1.42:49520 alt42:ssh ESTABLISHEDTCP 192.168.1.42:54089 lhr14s02-in-f104:http ESTABLISHEDTCP 192.168.1.42:54091 lhr14s02-in-f104:http ESTABLISHEDTCP 192.168.1.42:54094 text:http ESTABLISHEDTCP 192.168.1.42:54096 wy-in-f101:http TIME_WAITTCP 192.168.1.42:54098 stackoverflow:http TIME_WAITTCP 192.168.1.42:54100 stackoverflow:http CLOSE_WAIT

TCP 192.168.1.42:54102 stackoverflow:http CLOSE_WAITTCP 192.168.1.42:54115 gravatar:http TIME_WAITTCP 192.168.1.42:54116 gravatar:http TIME_WAITTCP 192.168.1.42:54120 wy-in-f102:http ESTABLISHEDTCP 192.168.1.42:54122 stackoverflow:http TIME_WAIT

2


3/6

TCP 192.168.1.42:54133 64.4.11.252:http ESTABLISHEDTCP 192.168.1.42:54134 84.53.133.96:http ESTABLISHEDTCP 192.168.1.42:54135 84.53.133.96:http ESTABLISHED

E Disconnect System From Wider World

Once volatile network related data has been gathered it is wise to disconnect the machine from anynetwork it may be on, apart from a closed network with only the forensic workstation. This preventsany 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 itsvolatility, but should be done after the system has been disconnected to ensure no outside tamperingoccurs 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 outwith 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 kernelconguration for security reasons. kexec is a potential tool for resolving this problem by replacingthe kernel.

G Acquisition of Physical Media

Once volatile data has been gathered the system should be powered down and transported to a securelocation for examination of persistent data. All items of potential evidence should be securely baggedand 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 areoften illegal to possess and so can only be secured and examined in police stations, not private forensiccompanies.

Rather than inserting an external drive into the suspect computer and risking contamination of evidence, or malicioussoftware, it would be benecial to transfer dumps over the network in many cases. Netcat is useful for this. On theforensic 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

2 Data Acquisition

Once all physical media has been secured data must be placed into an appropriate form for analysis. This involvesreproducing data so that it can be independently analysed and validated. Evidence is inadmissible if its source cannotbe 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 evidenceles through a graphical interface, here we copy a disk and generate a hash for validation usingstandard Linux utilities once again. The disk should be connected to a forensic system using ahardware write blocker to prevent the system from modifying timestamps or other metadata. Onceconnected 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. Itis 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:

3


4/6

$ md5sum /dev/sda78842815248300fa6ae79f7776a5080a

$ md5sum /dev/sdb78842815248300fa6ae79f7776a5080a

This should be carried out for all other pieces of evidence. If desired, the cloned disks can be passedto software such as EnCase which will create special evidence les, or can be examined with systemtools 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 exampleIntrusion Detection Systems (IDS) and network monitors on the same network. Evidence may also be provided bytarget systems or intermediate servers in such forms as access logs or received emails. The appropriate authoritiesof 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 areoverwritten by new data, this happens naturally over the lifetime of a system, the speed varies with usage. Toolsexist 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 recoveryis not possible, may be able to provide valuable metadata or partial recovery. Conguration isextensive 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

3 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 bemounted to a machine and searched using system tools. In many cases this is down to personal preference, butsoftware like EnCase has many inbuilt features for automatically detecting le types, recovering delete les andcollating them. In contrast, Linux tools can offer 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 ascontent, senders and recipients and timestamps. Access to remote mailboxes may be subject to legalrestrictions, but email clients often store local copies of read and sent email in common places. Clientsvary, but the general task is to search for common database les, for example on a Windows systemwhere 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.mail3:Envelope-to: [email protected]: for [email protected]; Sun, 20 Jun 2010 15:29:41 +010011:To: [email protected]:Return-path: 28:Received: from jonnie by notquitegrownup.com with local (Exim 4.69)

4


5/6

29: (envelope-from )35:From: Jonathan

The le found can be converted to mbox (Linux) format. On a Linux system mbox les are typicallystored in /var/spool/mail although some applications may use userspace. The examiner will needto search for common or conspicuous les. Mbox les can be analysed as text and there are manyfree tools to perform searches.

J Browser History

Browser history can be recovered in a very similar way, and the examiner must inspect for commonhistory types. A tool known as Pasco from Foundstone can be used to print browser history. Forexample, 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 2001URL 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 ansqlite client or the specialised FirefoxForensics tool.

The techniques used for browser and email recovery can be used to all manner of logging programs, such asHTTP, FTP servers or clients, chat applications and more. The examiner simply needs to be aware of thesoftware 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 commontechnique is to rename les to change the extension, but there exist tools that can read le headers todeduce 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 | xargs -0 file | grep JPEG./.mozilla/firefox/Cache/CA53B955d01: JPEG image data, JFIF standard 1.01./.mozilla/firefox/Cache/AF512168d01: JPEG image data, JFIF standard 1.02

./.mozilla/firefox/Cache/CD02F851d01: JPEG image data, JFIF standard 1.02./51TNKPXE4AL._SL500_AA300_.exe: JPEG image data, JFIF standard 1.01

As for le encryption, suspects are legally obliged to divulge cryptographic passwords, but there aresome brute forcing applications such as John the Ripper that can attempt to crack Unix passwordsthat may be used to encrypt home directories or les. Plausibly deniable cryptography is a lot moredifficult to break due to difficulty in detecting its existence.

L Other Pertinent Filetypes

On Microsoft Windows a le called Thumbs.db or Thumbcache.db is often created for folders withimages. These les are used to generate a preview of a collection of images and sometimes gounchanged 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.

4 Reconstruction

Once evidence has been successfully gathered it must be put together to determine the purposes for which the systemwas 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 acitonscarried out on the machine. The Java application Aftertime is designed to do this and works with the

5


6/6

logs of many applications. This timeline will provide a relational and temporal analysis of the usersmovements and behaviour which. Investigators need to take in data from other systems, or data fromthe 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 formalisethe hypotheses an examiner has formed during their work. An expert witness must be created todene 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 andprovide 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 systemis secure from remote tampering before preserving volatile data. The data is then validated to ensure any evidencefound is admissible in court. Remaining steps involve the systematic recovery and detailed analysis of data from toisolate pertinent information.

A Toolkit

The following list is a suggested toolkit based on my interpretation of the forensic analysts needs that should beavailable 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] E Casey. Digital evidence and computer crime, 2nd Edition . 2004.[2] E Casey. Handbook of Digital Forensics and Investigation, 1st Edition . 2010.[3] B J Grundy. The Law Enforcement and Forensic Examiners Introduction to Linux . 2008.[4] A Yasinsac, R Erbacher, D Marks, Mark M Pollitt, and P Sommer. Computer forensics education. IEEE Security and Privacy ,

1:1523, July 2003.

6