10.1.1.83.6733

7/30/2019 10.1.1.83.6733

1/14

Tool review e remote forensic preservationand examination tools

Eoghan Casey*, Aaron Stanley

Stroz Friedberg LLC, United States

KEYWORDSRemote digital

forensics;Live digital forensics;Incident response;Electronic data

discovery;Computer forensics

Abstract Forensic tools are emerging to help digital investigators preserveevidence on live, remote systems. These tools are applying the precepts of digitalforensics to incident response, enterprise policy enforcement, and electronic datadiscovery. This paper discusses the strengths and shortcomings of ProDiscover IRand EnCase Enterprise Edition in the context of the overall digital investigationprocess. In addition, a test scenario of a security breach involving a Windows rootkitis used to evaluate the capabilities of these tools. Based on this review,a comparison table is provided and several enhancements are proposed for toolsused to process digital evidence on remote, live systems. 2004 Elsevier Ltd. All rights reserved.

I have spread my dreams under your feet;Tread softly because you tread on my dreams.

(Yeats, 1899)

Introduction

Although digital investigators commonly have toobtain evidence from remote live systems, this

process controverts best practice guidelines suchas the Good Practices Guide for Computer BasedElectronic Evidence (ACPO, 2003). There arecertainly risks when acting on a live system: the

operating system may be compromised to hidevaluable evidence, and evidence may be inadver-tently altered or destroyed during the investiga-tion of the system. There are also risks incollecting evidence remotely: those under investi-gation may be alerted by investigators activities onthe remote system, communications with the re-mote system may be observed or subverted, andthe remote access may introduce a vulnerabilitythat exposes sensitive data. However, data in

memory are critical in some cases and it may notbe feasible to gain physical access to the com-puter, particularly in distributed network environ-ments and international investigations. Therefore,digital investigators need tools to obtain thisevidence while minimizing the associated risks.

Until recently, when responding to incidents,digital investigators relied primarily on a loosecollection of utilities to preserve evidence from

* Corresponding author.E-mail address: [email protected] (E. Casey).

1742-2876/$ - see front matter 2004 Elsevier Ltd. All rights reserved.doi:10.1016/j.diin.2004.11.003

Digital Investigation (2004) 1, 284e297

www.elsevier.com/locate/diin
mailto:[email protected]://www.elsevier.com/locate/diinhttp://www.elsevier.com/locate/diinmailto:[email protected]

7/30/2019 10.1.1.83.6733

2/14

live systems. For instance, information about pro-cesses on a Windows 2000 system could bepreserved using a combination of fport (www.foundstone.com), handle (www.sysinternals.com), pmdump (www.ntsecurity.nu/), cryptcat(sourceforge.net/projects/cryptcat/), andmd5sum (www.cygwin.com). Experienced investi-

gators painstakingly compile a virtual toolbox oftrusted executables for various operating systems,to be prepared for all eventualities.

From a forensic perspective, using various util-ities that are not designed with evidence preser-vation in mind is risky. Something as basic asaltering file access times can hamper a digitalinvestigators ability to determine what occurredon the system. In one case, a utility crashed andcreated a user.dmp file on the subject system,destroying potentially useful digital evidence. Infact, during this tool review, the handle toolrepeatedly crashed when run on the compromised

test system, possibly due to the presence ofa rootkit. Fortunately, this utility provides a warn-ing and option between closing and debugging theprogram as shown in Fig. 1.

Few investigators have the time or skills toverify that each tool they download from theInternet has not been maliciously modified. Fur-thermore, even trusted executables in an inves-tigators toolkit could be undermined by alteredlibraries or kernel loadable rootkits, resulting inincomplete information about files, processes,network connections, and other items on the

subject system. The complexity of this arrange-ment can make remote live examination incom-patible with evidence preservation efforts.

As more organizations realize the importance ofproperly preserving digital evidence relating toserious incidents involving their IT systems, thereis an increasing demand for forensic tools thatfacilitate the incident response process. Two toolsthat integrate incident response and computerforensics are compared in this paper: ProDiscoverIR 3.5 (PDIR) and EnCase Enterprise Edition 4.19a(EEE). Some features of the upcoming EEE version 5are also described for completeness of comparison.

These tools are specifically designed to preservedigital evidence from remote hosts, while minimiz-ing the changes made on the subject system.

The tools compared in this paper have manyapplications beyond handling computer securitybreaches, including investigating fraud and intel-lectual property theft, and dealing with policy

violations such as sexual harassment and employeemisuse of IT systems. PDIR is designed to examineone system at a time and is useful for focusedinvestigations involving a small number of com-puters. Conversely, EEE is designed to integratewith enterprise security architecture, providingenhanced access control and audit functions, andenabling digital investigators to process manysystems on a network simultaneously. As a result,EEE is currently the tool of choice for enterprise-wide digital investigations, security audits, andelectronic data discovery and subpoena compli-ance. In addition, EEE extracts more data from

memory of remote systems than PDIR, providinginvestigators with details about processes andnetwork connections that are often useful indigital investigations.

This paper provides a review of technical fea-tures for the single purpose of incident response,shortcomings for this purpose are discussed, andthe paper closes with a comparison chart. Thispaper focuses on examining Microsoft Windowssystems, but both PDIR and EEE can be used toexamine Linux and Solaris hosts.

Test scenario

To test the tools in this paper, the followingunauthorized access scenario was created. Anintruder gained access to a Windows host namedpeeker with IP address 192.168.0.5 on the targetnetwork via VNC. The intruder then installed a root-kit and used this system as a launch pad againstother systems on the organizations network. Inaddition to an internal hard drive with two parti-tions (C:\ and D:\), this host had a network share(E:\), a USB thumb drive (G:\), and a PGP disk (Z:\).

Figure 1 Error message and prompt generated when the handle utility crashed on the compromised host.

Remote forensic preservation and examination tools 285
http://www.foundstone.com/http://www.foundstone.com/http://www.sysinternals.com/http://www.sysinternals.com/http://www.ntsecurity.nu/http://www.cygwin.com/http://www.cygwin.com/http://www.ntsecurity.nu/http://www.sysinternals.com/http://www.sysinternals.com/http://www.foundstone.com/http://www.foundstone.com/

7/30/2019 10.1.1.83.6733

3/14

Installing a servlet

To initiate the connections between the examinermachine and the subject computer, a piece ofsoftware must be loaded into the memory of thesubject computer. Because this program startsa process on the subject computer that listens

for outside connections, it is referred to asa servlet. Sometimes the most challenging partof performing a network-based forensic examina-tion or acquisition is determining how to install theservlet on the subject computer. This sectionsummarizes the available installation methodsand their ramifications.

Host-based considerations

The examiner must have Administrator-level ac-cess to the subject computer to install the servlet.Both the EEE and PDIR servlets can be run either

directly from memory or as an installed service.Installing the servlet as a service keeps theapplication running all the time, even when theremote system is rebooted. This installationmethod has the added advantage of permittingconnections even when the user is not logged intothe remote machine. However, this method placesthe servlet on the remote systems hard drive andmodifies the Registry. This situation can beavoided by storing the servlet somewhere otherthan on the subject hard drive, and loading itdirectly into memory. For instance, launching the

servlet from removable media will avoid the needto save the executable on the subject hard drive.

The servlets can be deployed either manuallywhile sitting at the computer or via the network ifsufficient access methods are available. In a corpo-rate environment, the installation can usually beaccomplished via a logon script in the case ofWindows or a remote execution in the cases of bothWindows and UNIX operating systems. A logon pushwould require the subject to logout and log back onto their computer. If the examination is an immedi-ate need, this method usually takes too much time.

Many corporate networks utilize some form ofdesktop management solution that can push theservlet on a computer without the user knowingabout it. The servlet can be deployed in much thesame way that system security patches are de-ployed in an enterprise. When such push technol-ogy is not available, examiners can use toolslike psexec (www.sysinternals.com), Dameware(www.dameware.com), Secure Shell (SSH), or eventhe built-in Windows scheduler (at). As long asAdministrator-level privileges are obtained, theseprograms can make the deployment simple.

One word of caution e after the servlet isinstalled on the subject computer, it could besusceptible to alteration by a clever user. Any timea servlet is installed on a subject computer for anextended period of time, the subject has theability to replace the servlet program with a trojan-ized version, or faulty version that reports false

data. The authentication architecture of EEE isdesigned to thwart this type of tampering, usingpublic key cryptography between the servlet anda system called the SAFE (Secure Authenticationfor EnCase) that must be on the network toauthenticate and encrypt all communications be-tween the examiner and subject computer. Al-though the PDIR servlet does not implement thistype of authentication, the servlet is digitallysigned with Thawte certificate to enable investi-gators to verify its integrity. However, with theexception of the EEE Linux servlet, both the EEEand PDIR servlets utilize libraries on a subject

computer as a standard part of the operatingsystem and data acquired from the servlet maybe altered if those libraries have been tamperedwith.

With these risks in mind, corporate investigationdepartments may want to weigh the decision toinstall a servlet as a standard part of the corporatedesktop image.

Network-based considerations

Having a network connection to the subject com-puter is necessary to examine and acquire datafrom the remote computer. That network connec-tion, however, must be free from port restrictionsand access control mechanisms that might preventthe examiner from connecting to the servlet on thesubject computer. Router Access Control Lists,internal firewalls, and personal firewalls can allcreate barriers that prevent the examiner fromconnecting to the servlet. In the case of the EEEservlet, it must run on port 4445 of the subjectcomputer. If the computer is running anotherprogram that is bound to this port, access will beimpossible to obtain. The EEE examiner computerand the subject computer must be able to com-municate on port 4445 with the SAFE system toauthenticate the connections. While the PDIRservlet can be configured to operate on practicallyany port, the port must be accessible to theexaminer and a personal firewall installed onthe subject computer can block this access nomatter which port the servlet is configured tooperate on.

286 E. Casey, A. Stanley
http://www.sysinternals.com/http://www.dameware.com/http://www.dameware.com/http://www.sysinternals.com/

7/30/2019 10.1.1.83.6733

4/14

Review of functionality

To resolve critical incidents in an organizationeffectively, digital investigators must be able todetect the problem, determine the severity andextent of the damage, and preserve the associ-ated evidence. Two approaches to detecting pro-

blems that are relevant to this discussion are:(1) detecting suspicious processes on a host, and(2) triggering actions based on IDS alerts. Both EEEand PDIR can detect a suspicious process on a re-mote host as detailed in the next section. EEE alsocan be integrated with Snort to acquire volatiledata from a remote host when certain attacks aredetected. This feature was not reviewed for thispaper but it is worth noting that the upcomingrelease of EEE version 5 can be integrated withexternal databases, permitting enhanced IDS in-tegration and incident response.

Memory inspection

In the test scenario, we captured information aboutvolatile data on the target host peeker using PDIRand EEE. The Find Unseen Processes feature inPDIR detects processes that are hidden by rootkitson Microsoft Windows systems as shown here:

Remote system (192.168.0.5)

root.exe [Unseen Process]

ApntEx.exe [Seen Process]

Apoint.exe [Seen Process]CmLUC.exe [Seen Process]

PGPtray.exe [Seen Process]

PcfMgr.exe [Seen Process]

winvnc4.exe [Seen Process]

HKServ.exe [Seen Process]

JogServ2.exe [Seen Process]

vmware-authd.exe [Seen Process]

explorer.exe [Seen Process]

CMD.EXE [Seen Process]

CSRSS.EXE [Seen Process]

LSASS.EXE [Seen Process]

mstask.exe [Seen Process]

PGPServ.exe [Seen Process]

regsvc.exe [Seen Process]

SERVICES.EXE [Seen Process]

SMSS.EXE [Seen Process]

spoolsv.exe [Seen Process]

svchost.exe [Seen Process]

TASKMGR.EXE [Seen Process]

vmnat.exe [Seen Process]

vmnetdhcp.exe [Seen Process]

WINLOGON.EXE [Seen Process]

WinMgmt.exe [Seen Process]

The root.exe process at the top of the list isflagged as unseen, indicating that a rootkit maybe installed on the remote system. In somesituations, the technique that PDIR uses to detecthidden processes modifies the last access times offolders on the remote system but leaves file lastaccessed times unchanged. PDIR does not provide

the path name for the associated executable orfiles and ports that it has open so furtherexamination is required to locate and identifythe rootkit components.

The Snapshot module in EEE captures a list ofprocesses and associated information such as filesand ports that each process has opened. Severalfilters are available in the Snapshot module,including unknown and unauthorized processes.Before EEE can classify processes as unauthorizedor malicious the user must create applicationdescriptors (using MD5 hash values of files) andcategorize them as unauthorized or malicious.

In addition to these general categories, an orga-nization can create profiles of approved processesfor different types of systems in their enter-prise to facilitate the detection of unapprovedprocesses.

Fig. 2 shows the results of running the Snapshotmodule on peeker and applying the unautho-rized processes filter. A portion of the full processtree on the remote host is visible in the upper leftpane of Fig. 2(a), and the other panes containinformation about the WinVNC process that hasbeen classified as unauthorized. The bottom Re-

port pane includes the path, command line, andstart time of the process, and this information canalso be viewed by scrolling to the right in the upperright Table pane. Fig. 2(b) shows the hiddenroot.exe process detected by EEE version 5. Thetechnique used by EEE version 5 to detect hiddenprocesses does not alter the file system of theremote system, and shows the full path of theexecutable C:\eoghan\root.exe and any associ-ated command line options are also provided.

The EEE Snapshot also captures informationabout network connections and ports. For in-stance, Fig. 3 shows ESTABLISHED network con-nections on peeker, including the intrudersVNC connection on port 5900, the EEE connectionon port 4445, and what appears to be a NetBIOSsession with the file server in the test scenario(192.168.0.2). The NetBIOS session indicates thatanother system may have been breached butfurther investigation is required to determine ifanything sensitive or valuable on the secondsystem was exposed.

As another example, Fig. 4 shows the Suspi-cious Ports filter being applied to an EEE Snapshot


7/30/2019 10.1.1.83.6733

5/14

of a Linux system running the t0rnkit rootkitwith the backdoor SSH server configured to listenon port 31337. Currently, neither EEE nor PDIRhave the ability to detect hidden processes onLinux or Solaris systems.

Using these tool features, organizations cancheck all systems on their network periodicallyfor signs of intrusion or misuse. The EEE Snapshotmodule can be configured to capture volatile datafrom multiple systems in one sweep whereas PDIRrequires the user to query each system individu-ally. The additional information about processesthat is presented in EEE enables examiners to com-bine process information from multiple systemsto create a timeline, find identical processes onmultiple systems, or discern other patterns suchas the sequence of events in an attack. The Snap-shot module in EEE also preserves informationabout user accounts on remote hosts with associ-ated filters. This can be useful for determiningwho was logged into a given host at a particular

time or which machines were accessed using agiven account.

Storage media examination

Once a digital investigator finds a system that de-serves further attention, he/she generally wantsto examine the disk contents to determine theseverity of the incident. For instance, he/she maywant to perform a keyword search to determine ifany sensitive data were exposed (e.g., credit cardnumbers, intellectual property, medical informa-tion). Both PDIR and EEE can preview a remotesystem, providing access to physical disks andlogical volumes on those disks. In addition, EnCaseprovides access to RAM disks such as the PGP diskshown in Fig. 5. Mounted network drives are notdetected by either tool.

Both PDIR and EEE can interpret FAT, NTFS, ext2/ext3, and UFS file systems, enabling examination

Figure 2 (a) The results of running the EEE Snapshot module and applying the suspicious processes filter. (b) Theroot.exe process detected using EEE is flagged as Hidden and has a red mark on the top left of its associated icon.


7/30/2019 10.1.1.83.6733

6/14

of active and deleted files, as well as slack andunallocated space as shown in Fig. 6.

Both tools can perform keyword searches or MD5hash comparisons on a remote system. A hash

comparison can be used to exclude known goodfiles from a search or to detect known bad files onthe disk. For instance, the AFX rootkit whichincludes the hidden root.exe process detected

Figure 3 EEE Snapshot of volatile data from peeker filtered to show established network connections.

Figure 4 EEE Snapshot of volatile data from a compromised Linux host filtered to show malicious ports.


7/30/2019 10.1.1.83.6733

7/14

earlier, was identified on peeker using bothPDIR and EEE by searching for the MD5 values offiles in this rootkit. The hidden directory namedeoghan was visible in both PDIR and EEEbecause they process the raw file tables withoutrelying on the remote operating system. The Find

Suspect Files feature in PDIR found the AFXrootkit files based on MD5 values specified in aninput Hash Set, and included the following resultsin the report:

Evidence of interest:Total Evidence Items of Interest: 2

\\192.168.0.5\PhysicalDrive0, Hard Disk C:

List of Files:

\\192.168.0.5\PhysicalDrive0\C:\eoghan\hook.

dllMD5 Checksum: B0F9E41EF7C0B5D1EFA8FAC854C4DAFE

Created: 10/07/2004 21:05 Modified: 10/16/

2004 11:50 Last Accessed: 10/16/2004 20:56

\\192.168.0.5\PhysicalDrive0\C:\eoghan\root.

exe

MD5 Checksum:C54C622E3E10F724243D3D806712099A

Created: 09/22/2004 03:11 Modified: 09/22/

2004 03:11 Last Accessed: 10/16/2004 17:59

\\192.168.0.5\PhysicalDrive0, Hard Disk

C:: Evidence of Interest: 2

The same approach of using Hash Sets wasimplemented in EEE to detect the rootkit files asshown in Fig. 7.

An added feature in PDIR called Find UnseenFiles will flag files that are hidden by rootkits onWindows system.

Once a file of interest is located on the remotesystem, PDIR and EEE can copy the contents to theinvestigators system. Logical files can be copiedfrom the remote host onto the examination systemeven if a file is open and in use on the remote

system. If a file is modified while a remote livesystem is being examined, EEE and PDIR can onlycopy the altered data after the remote operatingsystem commits the changes to disk. Because offile system caching, file modifications may not bewritten to disk for extended periods, causing PDIR

and EEE to copy the original data associated withfiles that are being edited.

When an incident involves multiple systems, itcan be useful to combine information from allsystems in a single view to create a timeline, findidentical files on multiple systems, or discern otherpatterns. As an example, Fig. 8 shows files fromthree remote hosts combined and sorted by theircreation time. In this scenario, at 10:30 PM the AFXrootkit was uploaded on to 192.168.0.2, at 10:35PM two files were copied from 192.168.0.2 to192.168.0.5, at 10:37 PM the IIS Web server on

192.168.0.8 was compromised from 192.168.0.5,and at 11:02 PM psexec.exe and nc.exe wereuploaded on to the Web server.

This type of correlation cannot be performedusing PDIR because it only connects to one remotehost at a time. In addition, PDIR does not havethe ability to combine file listings from mul-tiple images, so each one must be examinedindependently.

If digital investigators decide that it is necessaryto preserve the entire contents of a hard drive orpartition of a remote host, PDIR and EEE canacquire a forensic image over the network. Be-cause things can change during a sector by sectorcopy of an active hard drive, the MD5 hash valueof the drive prior to the acquisition may differfrom the MD5 value of the forensic image. There-fore, the concept of a forensic image of livesystems differs from that of a dead system. Alive forensic image can only be verified againstitself whereas a dead image can be verifiedagainst the original media. When processing a livesystem, it is useful to know if large amounts ofdata are being added or destroyed. Neither PDIR

Figure 5 Acquiring a PGP disk (Z:\) on a remote system using EnCase.


7/30/2019 10.1.1.83.6733

8/14

nor EEE give clear information about what ischanging on the remote system while it is beingacquired or examined.

In remote preview and image capture modes,both PDIR and EEE did not alter the metadata offiles on the subject system, and preserved themetadata when copying the file to the clientcomputer. To test this, a USB flash drive wascreated with various files having different create,modified, and accessed times. The flash drive was

then imaged to be restored after each test run.PDIR was used to load the flash drive remotely andopen and copy some of the documents on it. Themetadata were not changed on the flash drive andremained consistent on the client system as well.This process was repeated with EnCase EnterpriseEdition with the same results.

Both PDIR and EEE have other features forexamining storage media that are beyondthe scope of this review. For instance, the EEE

Figure 6 (a) Preview of remote file system on USB thumb drive using ProDiscover IR. (b) Preview of remote filesystem on PGPdisk using EnCase.


7/30/2019 10.1.1.83.6733

9/14

decryption module provides various methods forextracting data encrypted using the NTFS Encryp-ted File System (EFS), and PDIR can interpretmetadata within EXIF files.

Investigative considerations

There are several important considerations whendealing with digital evidence on remote livesystems: the original evidence should be accessedin read-only mode, the remote operating systemshould not be trusted, forensic tools should not

overload the remote system, and evidence and the

remote system should be protected from unautho-rized access. This section reviews EEE and PDIR inthe context of these issues.

Treading softly e investigativeconsiderations

Generally, both EEE and PDIR do not alter data onthe remote system when performing operations onthe subject system via servlet. Although the EEEand PDIR servlets occupy memory on the remotehost, they appear to be designed not to useswap space, thus minimizing the changes made to

potential digital evidence on the remote system.

Figure 7 EEE using Hash Sets to detect AFX rootkit.

Figure 8 Combining data from multiple remote systems in a single view using EEE.


7/30/2019 10.1.1.83.6733

10/14

However, as mentioned earlier, PDIR changes lastaccessed datejtime stamps of folders when per-forming the Find Unseen Processes, and FindUnseen Files operations. Also keep in mind thatwhen the EEE and PDIR servlets are installed ona system it will make changes to the Registryand disk. Therefore, some organizations install

servlets on important systems as part of normaloperations, enabling them to monitor these systemsperiodically and respond to critical incidents moreeffectively.

Recall from the introduction that even trustedexecutables in an investigators toolkit can beundermined by altered libraries or kernel loadablerootkits, resulting in incomplete information aboutfiles, processes, network connections, and otheritems on the subject system. The EEE and PDIRservlets on Windows, Linux, and Solaris requirecertain libraries on the subject system. To mitigatethe associated risks, it is advisable to bring trusted

copies of these libraries to the subject systemalong with the servlet.

Security

When responding to an incident, digital investiga-tors should assume that the network they are usingcannot be trusted. A user or intruder may have fullcontrol of the system under investigation, and maybe monitoring system activities and network trafficto determine if he/she is being investigated. A

malicious offender may even take evasive actionto disrupt investigators. Therefore, all communi-cations should be encrypted, and all tools used for

remote evidence processing should not introducevulnerabilities on subject systems.

The PDIR online documentation recommendsthat the servlet only be run when needed tomitigate the security risks of leaving it runningfor extended periods of time. PDIR has optionalencryption and password protection that are not

enabled by default. When the servlet is installedon the remote host as a service, it can beconfigured with a password, and encryption canbe enabled only after a connection is established.Although encryption cannot be enabled prior toauthenticating with the PDIR servlet, the passwordis not transmitted in plain text and therefore is notplainly visible in network traffic. However, be-cause the password is provided as an argument tothe PDIR servlet, it can be obtained by users whocan view the Registry or process details of thesubject system. There does not appear to be a limitto the number of password attempts that the

servlet will accept, and anyone with PDIR canattempt to guess the password of the servlet.However, PDIR uses Global Unique Identifiers torestrict a servlet to one client per session and toprevent tampering with the network communica-tions.

EEE uses a dedicated system called the SAFE tomanage security. The SAFE protocol uses a combi-nation of public, private, and session keys toensure that all connections to remote servletsare authorized and encrypted. Attempts to con-nect to a servlet in another EEE implementation

were unsuccessful. In addition, separate useraccounts can be created for different roles,and the SAFE enforces access permissions and

Figure 9 Screenshot of audit trail.


7/30/2019 10.1.1.83.6733

11/14

maintains an audit trail for these accounts (seeFig. 9). Although this configuration makes theinstallation of EEE more complicated, it results ina more secure environment. In addition to restrict-ing who has remote access to certain hosts, thereis a high degree of control over what each accountcan do on each system. This control is advanta-

geous in an enterprise that separates roles. Forinstance, some organizations do not permit in-cident responders to view the file system of anyhosts, only acquire the evidence and pass theimages to forensic examiners.

Although the clients of both EEE and PDIRaccept connections from the network, attemptsto crash them by connecting to their listening portwere unsuccessful. However, the EEE client andservlet disconnect unauthorized connections im-mediately whereas the PDIR client and servlet donot, potentially making the latter more suscepti-ble to denial of service attacks.

Performance

The impact that the remote examination processhas on performance of the subject system andnetwork may be a concern for some users. If theservlet utilizes all available resources on the sub-ject system, this may be unacceptable froma business continuity standpoint if it rendersa critical server unusable. This situation may alsobe undesirable from an investigative standpointbecause it could alert users on the system.

Similarly, if the remote forensic tool makes thenetwork sluggish, this may be an unacceptablehindrance to the organization or investigation.

Both EEE and PDIR exhibited different networkbehaviors during the pre-acquisition and acquisi-tion phases. While previewing a remote computer,PDIR was measured to use an average of 340 kb/sof network bandwidth. This led to a time measure-ment of 4 min to open a 2 MB bitmap file stored ona USB drive. Because EEE employs a processwhereby it reads the disk configuration and filestructure of the subject system prior to allowingthe examiner to preview the data, the same fileopened almost immediately during the EEE test,but EEE did take a few minutes to read the deviceat first. When reading the device initially, the EEEclient was measured to use approximately 5.2 MB/sof network bandwidth. After the initial reading in,browsing through the subject system had nonoticeable impact on network usage. BecauseEEE relies on the SAFE, which stores the encryptionand decryption keys for the examiner and subjectsystem to authenticate with each other, there isconstant communication between the examiner,

subject computer, and SAFE machine. In testing,the SAFEs network utilization never exceededapproximately 50 kb/s.

PDIR, in acquisition mode, was measured to usea maximum of 5.5 MB/s of network bandwidthduring an acquisition. Acquisitions using EEE tooklonger than PDIR when the initial time spent

reading the device is taken into account. Duringthe acquisition, however, the network usage drop-ped to 3.5 MB/s.

To test whether an intruder who was controllinga subject system via VNC would have any idea thatthe system was being profiled, monitored, oracquired, a VNC connection was maintained andmonitored at points during the bandwidth testing.With VNC connected, the overall network usage ofthe subject system fluctuated between 3.5 MB/sand 4.8 MB/s. The only noticeable slow down fromthe perspective of the intruder would be duringtimes when the examiner was acquiring or reading

data from the hard drive of the subject system. Ifthe intruder is also running a disk-intensive pro-cess, the competition for the hard drive resourceswill limit the speed at which the intruder can reador write. This was exhibited by using Eraser todelete a 30 MB file by performing a single-passoverwrite. Without any other disk activity, theerase procedure took 0.81 s. With EEE performingan acquisition of the drive, that time increased to1.08 s, a 33% increase.

Keyword searching, hashing and other processessuch as Find Unseen Files cause the CPU load on

remote system to increase for as long as the searchtakes. PDIR has the option to search content(logical) or clusters (physical). Cluster searchesof remote hosts did not have a significant impacton the performance of the remote system butcontent searches were more CPU intensive, possi-bly because file system structure must be takeninto account when performing a logical search. EEEperforms both logical and physical searches simul-taneously but can be configured to just searchlogical files. Overall, EEE completed keywordsearches more quickly than PDIR but placed moreCPU load on the remote system. EEE also obtainsinformation about processes more efficiently be-cause it extracts data directly from memory of theremote system, whereas PDIR parses the remotefile system and compares the results with infor-mation available through the remote operatingsystem, placing more load on the remote system.Neither tool has a rate limiting feature to enablethe user to control how much load is placed on theremote system.

Arguably, a remote forensic servlet should notbe visible to a user or intruder on the subject


7/30/2019 10.1.1.83.6733

12/14

system. The EEE and PDIR servlets do not usesophisticated concealment techniques and an alertoffender may detect their presence. To evaluatethe overall stealthiness of the servlet applications,the Windows task manager and the netstat com-mand were employed to monitor process andnetwork port activity during the acquisitions. The

EEE servlet can be run from the command line onthe subject system, or can be installed as a servicethat runs at the System level. Running the serviceat the System level makes it more difficult forusers of the subject system to terminate theprocess.

The PDIR servlet can be run stand-alone withoutinstallation and has a menu option to switch toStealth Mode. This stealth mode simply hidesthe application window that the PDIR servletinitially opens, using the same process name andport. When installed as a service, the PDIR servletruns at the Administrator level on the subject

system. This allows a user with administrativeprivileges on the system to end the processmanually, thus terminating the examiners con-nection. In addition, PDIR opens up a large numberof ports on the subject system, most of them thatsit in TIME_WAIT status, which could alert anintruder or user on the remote system.

Limitations

This section summarizes the main limitations of

PDIR and EEE. Both tools require Administrator-level privileges on the subject computer, whichmay prevent their use in some investigations.Firewalls can also block communication betweenclient and servlets, preventing investigators fromutilizing these tools in some situations.

Investigators cannot access certain informationfrom remote systems using EEE and PDIR. Forinstance, neither tool can acquire process memoryor view data on mounted network shares, limitingthe amount of information that can be obtainedfrom the system remotely. Neither tool gives anindication of how much data are changing on theremote system while they are being examined oracquired. Although the EEE Snapshot module givesinformation about which files are open, this in-formation is not available when viewing the asso-ciated file system, making it more difficult todetermine if any documents are being edited. Inaddition, PDIR does not detect mounted RAM disks(e.g., PGP disks).

Although both tools make an effort to minimizechanges to the original evidence, running a processin memory or installing a service necessarily alters

the system. These minor changes are a necessarytradeoff when examining a live system but everyeffort must be employed to prevent such changes.Because of the Windows API behavior on somesystems, the PDIR Find Hidden Process andFind Hidden Files functions may change lastaccessed times of folders. Although these oper-

ations do not alter file accessed times, the mod-ification of folder accessed times may bedetrimental in some investigations. It is alsoimportant not to trust the remote operatingsystem. With the exception of the EEE Linuxservlet, the servlets in both tools rely on librarieson the remote operating system, which could bealtered to hide data or provide false information.

While PDIR and EEE are designed to detecthidden information on computers, they do notemploy advanced concealment techniques. Serv-lets are not hidden from users on the system beingexamined and can be killed by users in some

circumstances. An added limitation that appliesto all remote forensic examination tools is thatoffenders may modify DNS or change their IPaddress, causing investigators to connect to thewrong system.

Summary

Both ProDiscover IR and EnCase Enterprise Editionare bridging the gap between computer forensicsand incident response. Although both tools em-

phasize preservation of digital evidence, each toolhas a different design philosophy and technicalimplementation. PDIR is designed for examininga small number of systems involved in an incidentwhereas EEE is designed to integrate with enter-prise security architecture and examine a largenumber of systems simultaneously. PDIR onlypresents data that are verifiably complete andaccurate to a high degree of confidence whereasEEE provides the most information possible, in-cluding information provided by the subject sys-tem (e.g., process and network connectiondetails). There are exceptions such as PDIR chang-ing folder last access times under some conditionsbut this is distinctly labeled as an incident re-sponse operation as opposed to a forensic func-tion. Similarly, EEE has an add-on remediationmodule to remove malicious programs but thiscapability is clearly distinguished as an incidentresponse function.

Table 1 summarizes aspects of PDIR and EEEdiscussed in this review.

Digital investigators will continue to encountersituations that are not suitable for these integrated


7/30/2019 10.1.1.83.6733

13/14

remote forensic tools. For instance, when inves-tigators do not have Administrator privileges, orwhen dealing with Macintosh systems it may not bepossible to install a servlet on the computer.

Therefore, it is necessary to remain conversantwith the various utilities that exist for examiningsystems as described in the beginning of thispaper.

Table 1

Feature EnCase Enterprise Edition ProDiscover IR

Integrated graphical user interface U U

Servlet

Ability to run servlet in memory from read-onlymedia

U U

Ability to install servlet as a service U UConfigure servlet to listen on alternate port x UHide servlet from users of the remote system x xAuthentication between client and servlet PKI Password (optional)Encrypted communication between client

and servlet128-bit AES 128-bit AES /

256-bit TwofishDetect malicious alterations to servlet Client only connects to

servlets approved by PKIManually verifydigital signature

Servlet does not rely on local libraries ofremote system

Linux servlet isstatically compiled

x

Storage Media and File Systems

FAT/NTFS U UEXT2/EXT3 U U

UFSU U

View information about file systems on remotecomputers without altering file system metadata

U U

Identify malicious or known files on remote systemusing MD5 hash values

U U

Copy individual files or folders while preservingmetadata

U U

Indicate in file system view which files are openfor editing

x x

Capture forensic image of remote computers U U

Memory Inspection

View information about processes on remotecomputers

U U

Obtain process details without altering remotefile systemU

x

Reveal hidden processes on remote system Windows only Windows onlyProvide executable paths for processes on remote

computersU x

List open files on remote computers U xAcquire memory of processes on remote system x xProvide information about network connections

on remote systemsU x

Miscellaneous

View mounted RAM disks (e.g., PGP Disk) U xView mounted network shares x xCombine and correlate data from multiple remote

systems

U x

Integration with Snort intrusion detection system U xUser options to control the load placed on remote

system during preview, acquisition, search, orother operations

x x


7/30/2019 10.1.1.83.6733

14/14

Acknowledgements

EnCase Enterprise Edition: Brian Karney, RichCummings, and Michael J. Staggs, Guidance Soft-ware (http://www.encase.com).

ProDiscover IR: Christopher Brown and TedAugustine, Technology Pathways (http://www.

techpathways.com).

Bibliography

Association of Chief Police Officers. Good practices guide forcomputer based electronic evidence. National High TechCrime Unit: United Kingdom; 2003.!http://www.nhtcu.org/ACPOGuidev3.0.pdfO.

Yeats WB. He wishes for the cloths of heaven. In: The windamong the reeds; 1899.

http://www.encase.com/http://www.techpathways.com/http://www.techpathways.com/http://www.nhtcu.org/ACPOGuidev3.0.pdfhttp://www.nhtcu.org/ACPOGuidev3.0.pdfhttp://www.nhtcu.org/ACPOGuidev3.0.pdfhttp://www.nhtcu.org/ACPOGuidev3.0.pdfhttp://www.nhtcu.org/ACPOGuidev3.0.pdfhttp://www.nhtcu.org/ACPOGuidev3.0.pdfhttp://www.techpathways.com/http://www.techpathways.com/http://www.encase.com/

Documents

10.1.1.83.6733