±Forensic Focus Partners

±Your Account


Nickname
Password


Forgotten password/username?


Membership:
New Today: 0
New Yesterday: 4
Overall: 27389
Visitors: 38

±Follow Forensic Focus

Join our LinkedIn group

Subscribe to news

Subscribe to forums

Subscribe to blog

Subscribe to tweets

Evidentiary Value of Link Files

Evidentiary Value of Link Files



by Nathan Weilbacher

I have been reading the posts in Forensic Focus for about a year now and on many occasions I have followed with great interest the threads of discussion on many topics. There are many people posting that have offered suggestions and ideas that have directly influenced the direction of an investigation I was doing. I am submitting this article mainly because I got the email asking for submissions and I wanted to pass on a little info that could possibly help others in their investigations. This isn't written to be a tutorial but a simple recounting of what I did on a previous case.

Late last summer our office was contacted by a law firm that had a client that suspected one of its employees had stolen company data prior to his resignation. We were given a laptop used by the employee, a list of key words, a time window and instructions to look for any information which would indicate that the employee had copied company data to an external media device. Like any case there was much more to it than just that but I am only focusing on what pertains in this article. A forensic image of the laptop hard drive was made and I spent several hours just poking around the files getting to know the suspect's computer habits. What I noticed right off was what I call "a violation of cardinal rule number one".

- When an employee leaves a company, preserve the data on his drive; image it, archive it, or shelve it.

The company had passed the laptop to another employee that used the laptop for several weeks thus changing the MAC times on many files. So for all you security people out there remember the three "P's" of evidence "preserve, package, protect".

In this case one of the requirements was to determine if any company data had been copied to external removable media (i.e. USB) by the employee. Sense it was unlikely that the suspect would leave himself a reminder to "copy secret documents to thumb drive before I resign" on the drive I needed to look for other indicators of his nefarious deeds. I had read from several sources about the evidentiary value of the link (.lnk) files that windows creates when applications are installed, short cuts made or documents opened. Unfortunately I was unable to locate any detailed information on the subject of link files just tidbits here and there. What I was looking for was:

- What information is in a link file
- Under what circumstances are they created
- Can they be associated to a user
- Do they have MAC times

Using that frame work I started my research piecing together what I could about the nature of link files. In order to better understand link files I found a good primer (The Windows Shortcut File Format as reverse-engineered by Jesse Hager) and read it several times. If you don't already have it I recommend you locate and download it. The document went a long way to explain to me why some shortcuts had information that others did not. Additionally in the description of the .LNK file header information I was able to see information that allowed me to locate and carve link files from unallocated space on the hard drive by using the header information.


Basic File Structure
The file is structured like this:
File header
Shell item ID list
Item 1
Item 2
etc..
File locator info
Local path
Network path
Description string
Relative path string
Working directory string
Command line string
Icon filename string
Extra stuff


.LNK File Header
Offset Size/Type Contents
0h 1 dword Always 0000004Ch 'L'
4h 16 bytes GUID of shortcut files
14h 1 dword Flags
18h 1 dword File attributes
1Ch 1 qword Time 1
24h 1 qword Time 2
2Ch 1 qword Time 3
34h 1 dword File length
38h 1 dword Icon number
3Ch 1 dword ShowWnd value
40h 1 dword Hot key
44h 2 dwords Unknown, always zero


Finally the answer to my fourth question (Do they have MAC times) was answered when I saw that this document specified that link files maintain MAC times as part of the data in the file header. Of course anyone using either EnCase or FTK is used to seeing how those applications present .LNK file information but it us useful to have another source backing up what is being reported by the application. In case you are not a user of FTK or EnCase, I have included a couple of examples here so you can see how those applications present .LNK files.


FTK Shortcut File

Link target information
Local Path C:\Documents and Settings\126020\xxxxx\xxxxx
Volume Type Fixed Disk
Volume Serial Number 04CE-2410
File size 0
Creation time (UTC) 6/2/2005 12:08:05 PM
Last write time (UTC) 6/2/2005 12:14:27 PM
Last access time (UTC) 6/2/2005 12:14:54 PM
File attributes
Directory
Optional fields
Relative Path ..\..\..\..\Documents and Settings\126020\xxxxxxt\xxxxxxx
Target system information
NetBIOS name xxxxxxx1025
MAC address 00-0c-xx-6c-xx-d4


Armed with this information I used EnCase and ran the (Link File Parser) script that is an option when you sweep a case. Much to my dismay I found that there were approximately 4500 link files found. Those files were bookmarked and a report was exported.

Using the find abilities of MS Word I searched for the word "REMOVABLE" within the report and found five instances of that word in the exported report. These link files were created in the time window I was looking for. A check of the SID's associated to the link files verified that they were in fact created by the user account assigned to the suspect.

That was the answer to my third question (Can they be associated to a user). I was able to document the SID of the user account assigned to the suspect and further show that SID listed as the file owner were one in the same

Below is an example from EnCase of one of the link files in report view.


Link File: xxxxxxxxxxxxx\C\System Volume Information\_restore{A80475B6-CF6D-4B3A-BD21-B16C67DB5304}\RP59\A0044910.lnk
Link File Offset: 0
Link File Size: 315
File Flags: HASITEMID | ISFILEORFOLDER | HASWORKINGDIRECTORY
File Attributes: ARCHIVE
ShowWindow Value: SW_NORMAL
Created Date: 06/28/05 08:07:26AM
Last Written Date: 06/28/05 10:37:10AM
Last Accessed Date: 06/27/05 05:00:00PM
Volume Label: USB MEMORY
Media Type: Removable
Volume Serial: 9E 95 C3 A1
File Length: 49152
Base Path: E:\xxxxxxxxxxxxxxx.DOC
Working Directory: E:\


As you can see the media type listed is "Removable" and other information includes MAC times, Volume Label, Path and File name. I still wanted to know all the possible ways that a link file could be created so I did a little more research on the subject and found several articles on the subject but nothing that really told me when they are created automatically by user actions. Basically I wanted to know if the link files I was seeing were created by the suspect copying the files to a USB device or by something else.

I decided that I would run a few tests myself and see what the outcome was but first I wanted to check the Windows registry for any entries indicating the insertion event of a USB device. FTK has a nice registry quick reference chart that I consulted to find what the registry keys I was interested in were. I then ran the Registry Scan in EnCase and looked up what I could find in the "\USBSTOR" key. Below is a portion of what I found which indicated that USB device was present in the system at the time the .LNK file was created.


Value: Kingston DataTraveler II USB Device
Name: Disk&Ven_M-SysT5&Prod_Dell_Memory_Key&Rev_5.00
Last Written: 06/28/05 09:32:42AM
Name: 07C0DB4092638892&0
Last Written: 06/28/05 09:32:46AM
Name: Device Parameters
Last Written: 06/28/05 09:32:46AM
Name: MediaChangeNotification
Last Written: 06/28/05 09:32:42AM
Name: LogConf
Last Written: 06/28/05 09:32:42AM
Name: DeviceDesc
Type: String
Value: Disk drive
Name: Capabilities
Type: Integer
Value: 0x00000010 (16)
Name: UINumber
Type: Integer
Value: 0x00000000 (0)
Name: HardwareID
Type: String List
Value: USBSTOR\DiskM-SysT5_Dell_Memory_Key_5.00 USBSTOR\DiskM-SysT5_Dell_Memory_Key_ USBSTOR\DiskM-SysT5_ USBSTOR\M-SysT5_Dell_Memory_Key_5 M-SysT5_Dell_Memory_Key_5


OK, so now I had some link files that were created at the right time and could be associated to the suspect by his User Account ID. I had an entry in the Windows registry that indicated that a USB memory device had been inserted at about the same time and I had the names of several files that were listed within the link files. What I had to do next was determine how these link files were created.

I started off by installing a fresh copy of Windows XP on another lab computer. I imaged the disk and then used EnCase to generate reports on link files present and the Windows registry. The next thing I did was create some test files on the test system and copy them to different locations on the local drive then I inserted a new 64 MB USB memory stick and copied the files to it. I shut down and imaged the test system again. Using Encase, I checked the test system again for link files but did not find any for the files I copied around the local drive or to the USB memory stick. Finally, I opened the files located on the USB memory stick and those on the local drive. This action created entries in the recent menu. Shutting down the test system and imaging it a final time I had a good idea what I would find. This time I was able to locate link files for both the files viewed on the local drive and the files on the removable drive.

My opinion is that the mere act of copying a file to a removable device did not create the link file on the test system but the act of opening and viewing the file and its contents did in fact create the link file. I cannot state that my opinion will hold true on every system because I only tested on one system using only one type of file. Time permitting I would test on several systems using several file types but I had one final step to take and that was locating the actual files referred to by the link files.

File names themselves do not constitute confidential company data. It was necessary to locate the actual files and see what they contained. I had to rely on a key word search using the file names specified within each link file. Unfortunately nowhere on the suspect laptop did these file names exist except with association to the link files themselves. This prompted the forensic examination of a server the suspect could access. Needless to say the files in question were located (based on matching file names) as attachments to an e-mail message he had received prior to the creation of the link files.

The best evidence in this case would be the USB memory device itself. Sense that device was not available for analysis expert opinion will have to be used. It will have to be determined if the link files containing the file names of company data, the time stamps of the link files, and the "removable" media type, constitute clear and convincing evidence that the files had to have resided on a USB device in order for those links to have been created in the first place.

I hope this article turns out to be helpful to some of you in your investigations and that you kindly receive its content as created by one of the good guys trying to stay a step ahead of the bad guys.


Nathan Weilbacher
Forensic Examiner
Digital Works, LLC
nathan@digital-works.net




Nathan Weilbacher is a forensic examiner with Digital Works, LLC located in Dallas, Texas USA. The company has been in business for over five years and primarily deals in civil litigation and e-discovery. Nathan holds a Masters Degree in Computer Business Information Systems and Bachelors in Computer Science. His many industry certifications include CISSP, CCNP, MCSE, MCT as well as several others. He has worked in law enforcement, security, and the computer industry for over 25 years and taught computer forensics in both the University and private sector. He has worked on many cases involving the Windows, Novell, Mac, and Linux OS developing an aptitude for EnCase, FTK, X-ways, Paraben, MMPC, and Helix.