ava i lab le a t www.sc iencedi rec t .com

journa l homepage : www.e lsev ie r . com/ loca te /d i in

d i g i t a l i n v e s t i g a t i o n 4 ( 2 0 0 7 ) 3 0 – 3 5

Applying a forensic approach to incident response,network investigation and system administrationusing Digital Evidence Bags

Philip Turner*

QinetiQ, Digital Investigation Services, Trusted Information Management Department, Malvern Technology Centre,

G Building, Room 311, St. Andrews Road, Malvern, Worcestershire WR14 3PS, UK

a r t i c l e i n f o

Article history:

Received 22 December 2006

Accepted 7 January 2007

Keywords:

Digital forensics

Digital Evidence Bags

Digital investigation

Network investigation

System administration

Incident response

a b s t r a c t

This paper questions the current approach to forensic incident response and network

investigations. Although claiming to be ‘forensic’ in nature it shows that the basic pro-

cesses and mechanisms used in traditional computer forensics are rarely applied in the

live incident investigation arena. This paper demonstrates how the newly proposed Digital

Evidence Bag (DEB) storage format can be applied to a dynamic environment. A DEB is a uni-

versal container for digital evidence from any source. It allows the provenance to be

recorded and continuity to be maintained throughout the life of the investigation. With

a small amount of forethought a forensically rigorous approach can be applied to incident

response, network investigations and system administration with minimal overhead.

ª 2007 Published by Elsevier Ltd.

1. Introduction

Many organisations and companies have their own computer

incident response teams and network investigators. These

teams are often assembled at very short notice when an in-

cident occurs or anomalous system behaviour is detected.

The problem with this is that within a very short time period,

personnel with the necessary technical skills have to start

working together to diagnose the behaviour, problem or

attack.

At the onset of the incident all that may be known is that

something on a system or network is not working as expected

and the whole aim is usually to restore the service, capability

or system to its normal level. In this first instance the System

Administrator (SA) would probably be either the first person to

detect a problem or the first person to start examining the sys-

tem as the result of a helpdesk call from a user. What the

eventual outcome may be is usually far from the thoughts of

the SA or examiner.

In most cases the problem may be benign or user error but

in the instance where a more serious problem is discovered

a more comprehensive and rigorous examination or investi-

gation may follow. This would especially be true if a system

had failed completely, or if it was discovered that information

had been lost or stolen.

The problem with this approach is that the SA may already

have inadvertently modified a system or lost the opportunity

to accurately record the system state that was discovered.

This puts them in a vulnerable position should the finger of

blame be pointed at them at a later date. In addition, it may

* Tel.: þ44 01684 895777; fax: þ44 01684 894365.E-mail address: pbturner@qinetiq.com

1742-2876/$ – see front matter ª 2007 Published by Elsevier Ltd.doi:10.1016/j.diin.2007.01.002

d i g i t a l i n v e s t i g a t i o n 4 ( 2 0 0 7 ) 3 0 – 3 5 31

be the case that the SA cannot get repeatable results when

they realise that there is a serious problem.

The aim of this paper is to raise awareness of the potential

problems that could be encountered and unite a thorough fo-

rensic approach with the incident response procedure or net-

work investigation procedure. The two procedures are not

mutually exclusive and it is not possible to ‘bolt on’ a forensi-

cally rigorous approach as an after thought. The forensic

aspect should be an integral part of any system administra-

tion role that is responsible for operating any business critical

or business operational system.

In this paper the term ‘System Administrator’ (SA) is used

to cover the processes, tasks or operations performed by the

system administrator, system operator, incident investigator,

security administrator, network investigator. anyone who

may have any role in determining the problem, cause or effect

of any abnormal or unusual system behaviour.

2. Common tools

The SA usually has a vast range of tools available at their

disposal to monitor system performance, determine system

configuration or to fault find system problems. The majority of

these tools and utilities are very focussed in the function they

perform and the information they provide. Many of these tools

are console applications and run as command line utilities. Fur-

thermore, they are often packaged with the operating system.

The problem with these tools is they are designed to pro-

vide information, but are not designed to provide any form

of integrity assurance or record when those utilities were

executed. From a forensic perspective they provide no audit

record about the timestamp or actions taken, or results

returned from running those utilities.

Admittedly the SA, if they had the forethought, could

choose to pipe the output to a log file but this still has no

mechanism to assure the integrity of the data output. Further-

more, the SA would rarely keep hand written notes of the

actions taken, or results obtained whilst trying to diagnose

and examine a system.

This typical scenario results in the SA being unable to jus-

tify or even demonstrate to colleagues the system state as

they found it, never mind being able to assure that they

were not the cause or a contributor to the problem or incident.

There are many tools that may be used to diagnose system

behaviour (Sorenson, 2003a,b; Carvey, 2001; Microsoft

Windows XP). In addition to this there are toolkits available

with many of these applications already compiled into a com-

pendium (Fense tool; Foundstone tools).

What is really required here is a way of uniting the rigorous

approach required from the forensic dimension with the flex-

ibility for each SA to be able to execute their favourite tools

and utilities. The proposed solution is the Digital Evidence

Bag (DEB) (Turner, 2005; Turner, 2005–2006).

3. Digital Evidence Bags

A DEB is a universal container format for digital information

from any source. It allows the provenance of digital

information to be recorded and continuity to be maintained

throughout the life of the investigation.

The main components of a DEB are the tag, index and bag

files (Fig. 1). The index and bag files together are known as an

Evidence Unit (EU). It is the EU coupled with the customisable

index definition that provides the tremendous flexibility

afforded by the DEB framework.

DEBs were originally conceived to be used in the traditional

role of static digital forensic investigations. In this role they per-

mit more advanced data capture techniques to be supported,

for example selective and intelligent imaging methodologies

(Turner, 2006). However, they can also be used to store forensic

images of command line utility output, digital media, memory

dumps, network packet captures and all associated meta-data.

This paper demonstrates how the DEB framework can also

be used in a more dynamic environment, i.e. that of incident

response, system administration and network forensics. The

data captured being in a compatible format with that obtained

in the static environment and thus permitting traditional

forensic analysis tools and techniques to be utilised.

When an investigation, or enquiry is commenced then

each investigator would use the DEB forensic incident re-

sponse tool. When they commence their examination of the

system a DEB is created which automatically logs the current

date and time. The DEB forensic incident response tool allows

files on the system to be captured into a single or multiple EU.

For example, each application’s log files could be captured to

separate EUs and configuration or registry files could be cap-

tured to yet another EU.

In addition to this the DEB forensic incident response tool

allows command line applications to be executed from a spe-

cial dialogue box. When the command is executed the output

from each command is captured in the DEB together with an in-

tegrity hash of the data and a timestamp of when the command

commenced and completed. When all the relevant system in-

formation has been captured the DEB is closed and sealed.

The following example (Fig. 2) shows the information

recorded in a DEB tag, index and bag files when acquiring in-

formation from a forensic incident response tool. When

a DEB is created a tag file is generated that is similar in content

to that used as a physical evidence tag.

The DEB tag file shown is an example of that created once

the evidence acquisition process is completed and the DEB is

closed. The tag file is a plain text file comprising four main

sections:

[DEB Header];

[Evidence Units];

[DEB Footer]; and

[TCB].

The DEB header contains information such as investigating

officer, timestamp of when the DEB was created, and descrip-

tion of what, where and when evidence was captured. Within

the DEB header the ‘Index Format’ line specifies the default

content sequence of the DEBs’ index files, and it may be spec-

ified per EU or apply to the DEB as a whole. The index file

format is defined by a sequence of meta tags. This allows

each EU to be customisable within the DEB thus enabling

a DEB to store information from a wide range of devices.

d i g i t a l i n v e s t i g a t i o n 4 ( 2 0 0 7 ) 3 0 – 3 532

.tag

. index1

.bag1

.index2

.bag2

.indexnn

.bagnn

.index0

.bag0

EU=1Systemconfig files

EU=2ApplicationLog files

EU=0Case Notes

.index3

.bag3

EU=3Commandline app

EU=nnNetworkPacketcapture

Digital Evidence Bag (DEB)

DEB Forensic IncidentResponse Tool

System config files

Application log files

Process ListsMemory dump

Network activity

Network connection info

User listSystem log files

Fig. 1 – Digital Evidence Bag framework.

There are many index file meta tags defined for use in DEBs

and these are a shorthand notation for the information they

represent. They broadly fall into four categories, some exam-

ples are:

� Labels – file name and path (F), origin description (P), file at-

tributes (Fa), command (C);

� Timestamps – last modified/completed (Tmod), accessed

(Tacc), created/started/commenced (Tcre);

� Numeric – physical sector (PS), logical cluster number (LCN),

file logical size (Fls), file physical size (Fps);

� Integrity – MD5 hash (Hmd5), SHA hash (Hsha).

The Evidence Units section of a DEB tag file is used to re-

cord all EUs created in the DEB. Each EU has its integrity

hash of the index file and an integrity hash of the bag file.

Evidence Unit 0 is reserved for case notes and case associ-

ated meta-data at time of DEB creation. It contains informa-

tion about the DEB forensic incident response tool used to

create the DEB, including revision number, and application

integrity hash. Additional case information can be included

in this EU, such as photographs and free-form text.

The content type of other Evidence Units is arbitrary and is

determined by the examiner, based upon the case require-

ments and / or configuration of the DEB forensic incident re-

sponse tool. In Fig. 2, Evidence Unit 1 contains files with

a defined category of ‘System Config Files.’ Evidence Unit 3

contains information captured from Command Line utilities.

There are a number of options that may be used to identify

the contents of a particular EU:

� ContentType-Sig¼<File Signature1>,<File Signature2>.

� ContentType-Ext¼<File Extension1>,<File Extension2>.

� ContentType-Cat¼<category Type>� ContentType-Manual¼<label> {contents are Manually

Selected}

� ContentType-CLI¼<label> {contents are from a Com-

mand Line Interface}

The DEB Footer section is used to record the number of EUs

within the DEB. The DEB is then sealed with a tag file integrity

hash written at the end of the file.

d i g i t a l i n v e s t i g a t i o n 4 ( 2 0 0 7 ) 3 0 – 3 5 33

.tag

[DEB Header] Investigating Agency : QinetiQ Investigating Officer : Philip Turner Exhibit : PT_1 Description : Incident Investigation ref:001 Location : Malvern Timestamp : 2006-03-17T12:02:02+00:00 [Evidence Units] EU=00 IndexHash=<Hash> BagHash=<Hash> ContentType=Case Notes EU=01 Index Format : F LCN PS Fa Tacc Tmod Tcre Fls Fps Hmd5 IndexHash=<Hash> BagHash=<Hash> ContentType-Cat=System Config Files EU=02 Index Format : F LCN PS Fa Tacc Tmod Tcre Fls Fps Hmd5 IndexHash=<Hash> BagHash=<Hash> ContentType-Cat=Application Log Files EU=03 Index Format : C Tcre Tmod Fps Hmd5 IndexHash=<Hash> BagHash=<Hash> ContentType-CLI=<command> . . . . EU=nn Index Format : C Tcre Tmod Fps Hmd5 IndexHash=<Hash> BagHash=<Hash> ContentType-CLI=tcpdump [DEB Footer] Evidence Units in DEB : nn Tag File Hash : <Hash>

F LCN PS Fa Tacc Tmod Tcre Fls Fps Hmd5SYSTEM 63+1286-1302,,... 1206-1270,... ArchiveFile 08/03/2006 08/03/2006 10:26:06 05/06/2001 09:45:53 6205440 6205440 658…SAM 63+1350-1362 1210-125 8 ArchiveFile 19/12/2005 04/05/2005 14:55:56 05/06/2001 10:25:52 24576 24576 F32……Filename offset+n-n,n-n,... n-n, n-n,... file attrib timestamp timestamp timestamp logical size phy size hash

.bag2

.index 2

.bag3

.index 3

1101000011001111000100011110000010100001101100010001101011100001…………………….……………………………………….…………………..

F LCN PS Fa Tacc Tmod Tcre Fls Fps Hmd5File1.log 63+4-6 606-617 ArchiveFile 08/03/2006 08/03/2006 10:06:34 08/03/06 10:06:22 4608 6144 DAF…File7.log 63+7-9 618-629 ArchiveFile 08/03/2006 08/03/2006 10:07:40 08/03/06 10:07:20 5120 6144 BAA...…Filename offset+n-n,n-n,... n-n, n-n,... file attrib timestamp timestamp timestamp logical size phy size hash

C Tcre Tmod Fps Hmd5ipconfig /all 08/03/2006 10:13:14 08/03/2006 10:13:16 972 E47….F7Fpingpath mailhost 08/03/2006 10:13:56 08/03/2006 10:14:34 720 037….C42…command timestamp timestamp phy size hash

1101000011001111000100011110000010100001101100010001101011100001…………………….…………………………………………………………..

110100001100111100010001111000001010000110110 00100011010111000 01…………………….…………………………………………………………..

EU=2

EU=3

.bag1

.index 1

EU=1

Fig. 2 – Example of Digital Evidence Bag.

Fig. 3 – DEB Application Wrapper utility.

d i g i t a l i n v e s t i g a t i o n 4 ( 2 0 0 7 ) 3 0 – 3 534

Tag Continuity Blocks (TCBs), although not shown in this

example, are subsequently appended to the end of the DEB

tag file when analysis of the evidence is undertaken. TCBs re-

cord the analysis application’s function, and signature, and

timestamp of when the DEB was accessed.

Since the tag file is a plain text file the integrity hashes

stored within it can be manually parsed and the contents

verified without the need for specialised tools to read its

contents.

The bag files within each EU contain a concatenation of the

information referenced by each entry in the corresponding

index file.

A bag file may contain either binary or textual information.

When the information is generated by a command line appli-

cation the output from that application would typically be tex-

tual. Therefore so long as no compression or encryption

option has been applied to the bag file, then it could be parsed

[DEB Header]

Investigating Agency : QinetiQ

Investigating Officer : Philip Turner

Exhibit : PT_1

Description : Example command line capture

Location : Malvern, UK

DEB Created Date & Time : 19/12/2006 21:24:30

Index Format : P Tcre Fps Hmd5

[Evidence Units]

EU=01

IndexHash=42DAAC161C9BD223227682D2D6A12EE6

BagHash=4B83C08FA11BF4A90780E20B8C1515DD

ContentType=Real-Time CMD Line

[DEB Footer]

Evidence Units in DEB : 1

Tag File Hash : 1C825023ADE23424F94332BBED714A08

Fig. 4 – DEB tag file – PT_1.tag.

without specialised tools. This would be advantageous over

approaches that embed captured data within a storage for-

mat. Obviously accessing the contents of the bag file directly

circumvents the audit facility inherent with the DEB frame-

work and so would not be an optimal solution; it does add a de-

gree of flexibility.

4. DEB Application Wrapper – a practicalexample

The following example shows how the command line utility

‘netstat’ could be used and the resulting contents of the tag,

index and bag files.

The netstat command is used to display protocol statis-

tics and the current TCP/IP network connections. It is pack-

aged as part of Microsoft Windows XP and is a typical tool

used by system administrators to monitor system connec-

tivity. The command ‘netstat -ano’ will be used, this dis-

plays in numeric form all connections and listening ports,

and displays the owning process ID associated with each

connection.

Fig. 3 shows the DEB Application Wrapper utility. It re-

quires certain information that is used to populate the DEB

tag file. This information includes Investigating Agency, In-

vestigating Officer, Exhibit reference identifier, Description,

and Location the capture took place:

Fig. 4 shows the generated tag file (PT_1.tag), note this is

plain text and therefore can be manually parsed without the

requirement for specialised tools.

Fig. 5 shows the generated index file (PT_1.index01). In this

case only a single command was entered into the command

dialogue box. The entry shows the actual command executed,

the timestamp of when the command was run, the number of

bytes of data returned as command output and finally in this

case an MD5 hash of the returned output.

Fig. 6 shows the contents of the bag file (PT_1.bag01), in this

case the output from the command ‘netstat -ano’.

netstat -ano 19/12/2006 21:24:49 1089 4B83C08FA11BF4A90780E20B8C1515DD

Fig. 5 – DEB index file – PT_1.index01.

Active Connections

Proto Local Address Foreign Address State PID TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 900 TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4 TCP 127.0.0.1:1036 0.0.0.0:0 LISTENING 2140 UDP 0.0.0.0:445 *:* 4 UDP 0.0.0.0:500 *:* 692 UDP 0.0.0.0:1026 *:* 1212 UDP 0.0.0.0:1032 *:* 1212 UDP 0.0.0.0:1040 *:* 1460 UDP 0.0.0.0:4500 *:* 692 UDP 0.0.0.0:6551 *:* 284 UDP 127.0.0.1:123 *:* 960 UDP 127.0.0.1:1143 *:* 960 UDP 127.0.0.1:1900 *:* 1264

Fig. 6 – DEB bag file – PT_1.bag01.

d i g i t a l i n v e s t i g a t i o n 4 ( 2 0 0 7 ) 3 0 – 3 5 35

5. Conclusions

This paper has demonstrated the application and use of

Digital Evidence Bags as an integral and essential part of an in-

cident response, network investigation or simply a system ad-

ministrator role trying to examine anomalous system

behaviour. Current tools whilst providing valuable system in-

formation, rarely place any reliance on maintaining the integ-

rity of the information captured. This is usually left to the

examiner having a practical process maintaining hand writ-

ten notes and audit information of when tasks were under-

taken and completed. This at best can lead to ad-hoc partial

logging of information. It places a great deal of reliance on

the competency and dependability of the individual. This is

often in situations when the examiner is under stress and

focussed on the investigation in hand, rather than remember-

ing to activate basic logging procedures.

In an ideal world all tools designed to be used in the inci-

dent response and network investigation arenas would have

some if not all of these basic evidence preservation character-

istics. As this is not the case, then in order to demonstrate

a diligent approach the DEB framework or similar methodol-

ogy should be utilised.

The form of Application Wrapper demonstrated in this

paper permits standard toolkits to record information in a uni-

versal Digital Evidence Bag format. It is capable of recording

user actions from the moment the SA commences their exam-

ination and should be adopted for every fault or problem

investigation undertaken.

r e f e r e n c e s

Carvey H. NT/2K incident response tools, <http://www.securityfocus.com/infocus/1294>; 2001-08-15.

Foundstone tools, <http://www.foundstone.com/index.htm?subnav¼resources/navigation.htm&subcontent¼/resources/whitepapers.htm>.

http://www.e-fense.com/helix/.Microsoft Windows XP Command line reference A–Z, <http://

www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/ntcmds.mspx?mfr¼true>.

Sorenson Holt. Incident response tools for Unix, Part One:system tools, <www.securityfocus.com/infocus/1679>;2003-03-27.

Sorenson Holt. Incident response tools For Unix, part two: file-system tools, <www.securityfocus.com/infocus/1738>; 2003-10-17.

Turner Philip. Unification of digital evidence from disparatesources (Digital Evidence Bags). In: Digital forensic researchworkshop, <http://www.dfrws.org/2005/proceedings/turner_evidencebags.pdf>; 2005.

Turner Philip. Digital Evidence Bag format definition; 2005–2006.Turner Philip. Selective and intelligent imaging using Digital

Evidence Bags; April 2006.