No products in the cart.
by Mark Garnett
|
What you will learn:
|
|
What you should know:
|
With the advent of computer systems, new evidence is now available for any investigator to find if an offender has used a computer system to facilitate an offence. With this new found treasure trove of information there is a downside, even though evidence may exist, it can be like searching a needle in a haystack. Not only is data volume an issue, but as computer users become more and more savvy they are finding more novel ways to make a computer examiners life harder. They can do this by destroying or hiding crucial information. It is fair to say that most of today’s computer users know that when they “delete” a file from a computer system, it is not really deleted. As a result, they have that repository of all answers, Google, available to them that they can use to research ways in which to cover their tracks and prevent computer examiners from finding evidence that may get left behind from any wrongdoing. Whilst this may be the case, computer systems and operating systems are extremely complicated systems and there are generally many exceptions to every procedure used to remove evidence and as a result, it is still common for these procedures to not be one hundred per cent successful.
This article will discuss one such case, a case of stolen intellectual property in which the suspect was under the mistaken belief that he had done all that was necessary to remove any evidence that he had actually stolen intellectual property. This case is particularly interesting as the stolen intellectual property, consisting of electronic documents, was never actually found. All of the critical evidence consisted of information that inferred the previous existence of the intellectual property, but the offender was successful in removing evidence of the documents themselves.
THE SCENE
My client consisted of a large corporate entity that had just received the resignation of a very senior sales executive, who had decided to commence work with a competitor organisation. This particular executive was very well respected within the organisation and was considered an exemplary employee and executive manager. Like all senior executives, he was issued with a laptop computer and a large external USB external hard disk drive on which to store documents. This executive was expected to work away from the office from time to time and as a result, he needed the ability to have a portable storage device. This of itself was no cause for alarm for the business and was considered standard operating procedure.
When the executive resigned, senior management, as a matter of process, decided to review the executive’s laptop computer just to make sure that he had not sent any confidential information to his new employer. In addition to this, they also wanted to confirm that he had not stolen or unlawfully removed any confidential documents from the business prior to resigning.
As a result, representatives of my client attended the executive’s home to collect all equipment currently issued to him. At this time, the executive returned his laptop computer but not the external USB storage device. The company had failed to realise, at this time, that the executive was actually issued with the storage device and as a result, the representatives that attended at his home did not realise that this piece of equipment was not returned.
The following day, the senior executive contacted his ex-employer and indicated that he had forgotten to return the external storage device and asked if somebody could attend at his premises to collect it.
Both the laptop computer and the external hard disk drive were subsequently provided to me for forensic analysis. It is relevant to note here that the organisation configured all computer systems with the Microsoft Windows XP operating system using the NTFS file system.
THE DATA CAPTURE
My initial brief was to undertake an analysis of both the laptop computer and electronic storage device and determine what, if any, intellectual property had been unlawfully removed from the organisation. I commenced my analysis using FTK Imager, which I used to obtain forensic images of both hard disk drives. FTK Imager is easy to use, robust, lightweight (in terms of computer resource requirements) and very reliable.
Selecting “File->Create Disk Image”, I chose the “Physical Drive” option in the subsequent dialog box. In my view, imaging a physical drive in instances where you are undertaking an analysis of a single disk drive system (i.e. laptop, desktop or external storage device) is much more preferable than logical imaging in cases such as these.
In short, physical disk imaging is a process in which a “bit for bit” or exact copy of the entire contents of the hard disk drive is obtained in such a manner so as to:
-
Prevent any alteration to the original data;
-
Create a true copy of the source drive; and
-
Capture all data, including current, deleted and unallocated data.
Current data includes all files that currently exist on the hard disk drive and are “visible” to the operating system. Deleted data includes those files that have been previously deleted by a user or through the normal operation of the computer and have not yet had any portion, including filename entries, overwritten by another file. The unallocated portion of a hard disk drive is space that is marked as available for use by the operating system. This area can contain data that has previously been deleted.
As much evidence relating to the operation of a Microsoft Windows file system is very volatile, it is not uncommon to find critical information about file activity in the unallocated portion of the computer’s file system. As I am sure all readers are aware, logical disk images do not capture “deleted” information.
Having said this, there are some instances where physical disk images are simply not necessary or are not desired by the client. Physical or logical imaging of multi-disk storage systems is a matter for each engagement and the merits of each approach should be considered prior to determining what type of image is required.
With respect to image type, I chose “Raw/dd” as this image can be mounted, if required, to behave as an attached disk drive. Mounting images has the advantage of allowing an examiner to navigate the forensic image as if it was an attached disk drive. Whilst not applicable in this particular case, it is good to get into the habit of choosing an image format that provides you the most flexibility in conducting your examination.
After selecting an image format, I completed the necessary evidence information dialog box with the details of my particular case. I have noticed some examiners fill in “placeholder” text into these fields however I cannot stress enough the advantage in completing this dialog box in full with as much information as possible. Whilst an examiner may be able to track a small number of cases, it does not take long for this to become completely unwieldy. Once completed, choose a destination in which to save the forensic image, along with the image fragment size and compression format. These options are open to interpretation and most examiners will have their own preferred size and compression format with which they are comfortable.
As with all forensic matters, the use of a hardware write-blocking device was crucial in obtaining a pristine copy of the source data. A hardware write-blocking device ensures that no information is altered on the source hard drive when it is connected to your forensic machine for the purposes of imaging. Operating systems, such as Microsoft Windows, will routinely alter, however slightly, the data contained on a disk drive when connected to it via USB, for example. Even though the changes may be slight, they may be critical if they inadvertently destroy data that you could otherwise rely on.
In this particular case, there were no issues experienced during imaging process and this was confirmed when completed by selecting the “File->Verify Image” from within FTK Imager. The “Verify Image” option ensures that the stored hash value inside the image matches the computed hash value at the completion of the forensic verification process.
Prior to returning the equipment, other information was obtained such as the accuracy of the clock contained within the laptop. This is an important step if relying on the dates and times associated with files.
THE ANALYSIS
I commenced my analysis by examining the forensic image of the USB external storage device. I noted upon previewing the image that the external storage device contained no user files and had been previously formatted the day prior to it being provided to me for analysis.
The process of formatting a disk for use does not actually delete any “data” contained in files on the disk itself. The process simply recreates a series of system files and discards the old system files that were present before the formatting took place. All of the data that existed on the disk would now reside in the unallocated area of the disk.
During the formatting process, the Microsoft Windows operating system prepares the media by writing a series of system files to the disk that assist the operating system to store files and organise data on the disk. One such file written to the disk at this time is called the Master File Table (MFT). The MFT records information about files and directories stored on the disk including the name of the file, the date the file was created and where on the hard disk the file resides. Each file and directory contained on a hard disk has an entry in the MFT.
Each time a disk is formatted, new system files are created and the old system files, such as the old MFT file, are discarded. When examining the actual data contained within the MFT, each entry contained within it is preceded by the characters “FILE” followed by information about the file or directory, such as the file name. This also enables the easy identification and location of MFT entries in unallocated space.
The below screenshot provides an overview of the type of information you can expect to find:
Figure 1. Type of information you can expect to find.
The header for the MFT entry “FILE0” can be clearly seen along with the filename, in this instance, “helpinstall_english.7zip”.
I determined that the disk drive had been formatted the day before being provided to me by examining the date and time that the MFT was created. Generally speaking, the date and time that the MFT was created is a good guide with respect to the date and time that a disk was formatted. This is dependent on the accuracy of the clock in the computer on which the disk drive was formatted.
This of itself was again not a blatant red flag as the senior executive had indicated to his employer that he had not used the external device to store any company files, only personal information, such as photographs and personal documents. As a result he said he reformatted the disk drive to remove any trace of the personal data prior to returning the equipment. Acting within my instructions from the legal team, I commenced a search of the external storage device in order to locate any files that may have been created using Microsoft office or Adobe Acrobat and previously stored on the external hard disk drive.
A very quick “scroll” through the information contained on the external storage device revealed that it did contain “old” data in unallocated space, although from my initial view, I was unable to locate much, if any, “humanly readable” text. The data all looked as if it had been compressed or once formed part of binary files.
I subsequently used my analysis software to look for any previous files on the storage device that contained headers common to documents created using Microsoft Office or Adobe Acrobat. The organisation in question was using a version of Microsoft Office prior to 2010 and as a result, I was not concerned with any documents created using the (then) new Office Open XML format. In particular, the header I was searching for consisted of the hexadecimal bytes “D0 CF 11 E0 A1 B1 1A E1” for Office files and “25 50 44 46” for Adobe Acrobat files.
In addition to this, I also searched for Lotus Notes databases (bytes 1A 00 00 04 00 00) (the organisation in question used Lotus Notes for email) and compressed archives, such as ZIP (bytes 50 4B 03 04) and RAR (bytes 52 61 72 21 1A 07 00). As outlined earlier, I noticed large amounts of what looked like compressed data on the disk from a cursory visual inspection. Expecting to see results when my search was completed, I was surprised when I did not locate any instances of the above file types whatsoever.
As a result, I subsequently undertook a search of the forensic image for file extensions in the event that files may not be present, but file name entries may be, for example in an MFT that existed on the hard disk drive prior to it being reformatted. I used simple search terms for this purpose, such as “doc”, “xls”, “pdf”, “ppt” etc.
I noted that I identified several thousands of instances of filename entries. Upon closer examination, I noted that each of these filename entries existed in, what appeared to be, entries in a previously deleted MFT. The MFT is structured in a particular way and consists of a series of entries in the following segments:
|
|
|
|
|
|
|
|
Figure 2. MTF Structure.
The following figure also illustrates the structure of an MFT entry:
Figure 3. MTF Structure. Source: http://www.cs.bgu.ac.il/~os042/assignments/Ex3/NTFS_background.html
The “standard Information” segment consists of several data items including, but not limited to, the entry header (i.e. FILE), the allocated size of the MFT record (i.e. 1024 bytes) and a flag indicating whether the item is a file or directory. I note that this is not an exhaustive list, the totality of which is beyond the scope of this article. The file or directory name is stored as Unicode text and the data/index information consists of various aspects of the file or directory. For the purposes of this case study, it sufficient to understand that the following relevant information is stored in the “data block” of the MFT entry:
-
The file creation date, stored as a 64 bit Little Endian format number. For example, the hex bytes 40 29 AF 60 6C 50 C7 01 would decode to 14 February 2007 at 19:41 hours UTC time;
-
The date and time that a file was modified, again stored as a 64 bit Little Endian value; and
-
The date and time that the MFT entry relating to this particular file was last changed.
By decoding the MFT entries identified as a result of my searches, I was able to generate a list of approximately 11,000 files that, up until the day before the portable hard disk drive was returned, existed on the device. By cross-referencing the file attribute information outlined above with file listings from the corporate file servers, I was able to match those files which appeared to have been copied from the business servers onto the portable device.
Now that it appeared as if the senior executive had acted unlawfully, next came the task of attempting to determine what actions he had performed in order to remove the information from the business. Given that now it was possible to prove that corporate data existed on the portable device, I now had to determine what the senior executive had done in order to “cover his tracks”.
I subsequently undertook a closer review of, what appeared to be, binary data on the hard disk drive. I determined that the information that I was viewing appeared to be compressed video data and sought to extract the data to determine if this was correct. I manually carved entire “chunks” of data from the unallocated portion of the portable hard disk drive and noted that, when saved as a discrete file, was recognised as a video by an MPEG video player and appeared to be recording of a popular British television comedy.
Upon further analysis, the same series of bytes, approximately one hundred megabytes of data, was repeated consistently across the entire length of unallocated space. This meant that, prior to the portable hard disk drive being formatted it contained hundreds of duplicate files of the same television episode.
I also undertook an analysis of the laptop computer provided by the senior executive. Upon an examination of the recycle bin on that computer, as opposed to the portable hard disk drive, I identified a large volume of video file entries with names such as “De785.mpg”, as well as documents created with Microsoft Office and Adobe Acrobat, such as “De621.doc”.
When a file is deleted by a user using an operating system, such as Windows XP on a disk drive formatted using the NTFS file system, by dragging and dropping the file into the recycle bin, the following process is carried out by the operating system:
-
The file is moved to the recycle bin by the operating system; and
-
When the user empties the recycle bin, the file is renamed using the convention “d” + drive letter of origin + unique index number. For example the file name “De785.mpg” means the file was emptied from the recycle bin it originally existed on the “E” drive and was provided with the index number “785”.
All portable hard disk drives connected to a computer system are given a unique drive letter by that computer system. It is my experience that a portable hard disk drive connected to a computer will generally be given a unique drive letter such as “E”, “F” or “G”.
As a result of this, I was able to conclude that the following series of events had taken place prior to the portable hard drive being provided to me for analysis:
-
The portable hard disk drive was provided to the senior executive for business use;
-
At various points in time after the senior executive commenced using the portable hard disk drive, he copied several thousand files from the corporate file server onto the portable hard disk drive. This was evidenced by the filenames recovered from the previously deleted MFT;
-
Prior to the portable hard disk drive being provided to me for analysis, the business related files were deleted from the portable hard disk drive. This was evidenced by the fact that the business related files no longer existed and that a large volume of entries existed in the Windows recycle bin on the laptop computer relating to Microsoft Office and Adobe Acrobat type documents;
-
After the business related files were deleted from the portable hard disk drive, a single video file was copied onto the drive many multiples of times to overwrite the data contained in the previously deleted business related files. This was evidenced by the fact that the data relating the video was still located in the unallocated portion of the portable hard disk drive and that no data from the documents that previously existed on the device still existed;
-
The video files contained on the portable hard disk drive were then deleted. This was evidence by the fact that the video files no longer existed on the portable hard disk drive and that a large number of instances of video files were located in the Windows recycle bin on the laptop computer system; and
-
The day before the portable hard disk drive was provided to me for analysis it was reformatted. This was evidenced by the creation date of the current MFT on the portable hard disk drive.
As a result of the actions of the senior executive, his employer decided to question him at which point he admitted to copying vast amounts of information from the corporate file server onto the portable hard disk drive provided to him prior to his resignation. He then indicated that he copied those files from the portable hard disk drive onto another device, which was owned privately by him and using a computer privately owned by him. From this point, the senior executive agreed with the sequence of events as outlined above. Litigation resulted and a judgment was found against the senior executive.
The data stolen by the executive consisted of confidential information corporate information such as policy documents, financial information, customer data, product campaign information, business performance documents and other organisational material. The material was all contained within Microsoft Word, Microsoft Excel, Microsoft PowerPoint and Adobe Acrobat formatted files. The files were all named I accordance with corporate file naming guidelines and so it became an easy task to compare the names of the files that once existed on the external USB hard disk drive and the files that currently existed on the corporate fileserver. This comparison of names was crucial in identifying the nature of the data that once existed on the external USB hard disk drive.
CONCLUSION
As the old saying goes, “a little bit of knowledge is dangerous”. In this instance, a user, who believed himself to be computer savvy, sought to remove all traces of his unlawful behaviour by overwriting data that had been previously been deleted. He was fully aware that deleting a file from a hard disk drive does not actually delete the file, and that formatting a hard disk drive does not delete files. He mistakenly believed, however, that merely overwriting “previously deleted” data would cover his tracks. Whilst his actions did indeed render it impossible to recover any actual files during this analysis, he was not computer savvy enough to remove all traces of a file’s existence, namely entries relating to files as contained in previously used MFT. The existence of the old MFT and the information contained within the Windows recycle bin on the laptop computer, enabled a detailed timeline to be constructed with respect to the sequence of events that led to the relevant information being destroyed on the portable hard disk drive. This also serves to highlight a very relevant point, and that is that it is not always necessary to recover the actual files that are suspected to have been stolen, only information about those files and a plausible and defensible explanation as to how they came to be deleted.
The most important things I learned during the course of this analysis were to never underestimate the importance of ancillary information when trying to prove that data once existed on a device. Just because you don’t have the files themselves, does not mean you cannot build a robust case outlining a chain of events as to what a computer has, or has not done, on a computer system. In addition to this, persistence, never give up, you may be surprised at what you can find if you take the time to sit back and look.
About the author-----------------------------------------------------------------------------------------------------
Mark Garnett is a Partner of McGrathNicol Forensic, the leader of its Forensic Technology team and specialises in seizing and analysing digital evidence, data recovery, electronic discovery, electronic evidence preservation and conducting other computer related and fraud investigations.
A qualified investigator and forensic technology practitioner with 14 years experience as a Detective in the Queensland Police Service and over nine years specialist forensic experience, Mark has led a broad range of matters in Australia and overseas involving digital evidence recovery and analysis, network intrusion, asset tracing and misapropriation.
Author
Latest Articles
Our AuthorsFebruary 19, 2018Meet our expert - Cordny Nederkoorn
BlogJuly 11, 2017For the Love of The Game by Jessica Gulick
BlogJune 29, 2016Finding Advanced Malware Using Volatility
BlogJuly 3, 2015Banana Pi Pro - Review