Posting this because I'm running short on ideas on my current investigation and hopefully one of you wonderful people could point me to somewhere I haven't thought of looking.
The background of this case is standard corporate theft. Guy leaves the company for greener pastures but is suspected of having plundered the network shares for information (it's always the same isn't it roll ). I took the image , loaded it up in AccessData FTK and I extracted a timeline using the log2timeline tool within SIFT Workstation. Operating System is Windows XP.
Going through the timeline I notice 5 moments in time during the last working week of this user , where each time hundreds upon hundreds of entries get created in one of the index.dat files .
They either point to the temp folder or the network share where some very confidential stuff resides.
I included two of the typical entries FTK parsed from the index.dat file(I replaced username and the filename on the network drive by something bogus)
URL2012052820120604 username@file///C/Documents and Settings/username/Local Settings/Temp/{B207B3ED-0F74-4893-B998-4258D99443C3}.html
accessed time 5/06/2012 53952 +0000
modified time 29/05/2012 115017 +0000
checked time 30/11/1993 124701 +0000
expiration time 15/08/2011 155256 +0000
hits 1
use counts 0
URL2012052820120604 username@file///L/Confidential Folder/Confidential File.doc
accessed time 5/06/2012 53952 +0000
modified time 29/05/2012 95513 +0000
checked time 30/11/1993 124701 +0000
expiration time 11/06/2003 144648 +0000
hits 1
use counts 0
So there are about 2000 of these entries in index.dat for each moment in time. This happens about 5 times during the last week, often outside regular business hours. All 2000+ entries always have the same "accessed" timestamp. I interpreted this as a file copy from the network via the laptop to somewhere else.
Am I making the right assessment here ? What do these entries pointing to the network drive and the Temp folder mean ? What is my next move ?
A couple of thoughts…
One…*which* index.dat are you referring to? It is kind of important, as the location of the index.dat file can tell you something about the nature of the information maintained in that file.
Another thought…have you considered looking at shellbags and other Registry information for the user? Recent *.lnk files? RecentDocs from the Registry? "Mapped Network Drives MRU" key data? MountPoints2 data?
> I interpreted this as a file copy from the network via the laptop to somewhere else.
Where would that "somewhere else" be? Have you looked at USB devices?
> What do these entries pointing to the network drive and the Temp folder mean ?
Again, to which index.dat file are you referring?
HTH
Hello Harlan D ,
The index.dat file for the pattern on 05/29 is located under C\Documents and Settings\username\Local Settings\History\History.IE5\MSHist012012052820120604\
One of the first things I do in an investigation is parsing out the registry files from the NTUSER, SYSTEM and SOFTWARE hives with the standard RegRipper plugins. Did not see anything suspicious but i'm going back to it now.
And regarding to the USB device - i'm literally clueless. I located two devices last used after these occurrences and both of them I was able to retrace to another user that logged on the laptop after the person being investigated left oops
I first thought this could be a CD burn , because just before these moves I see the IMAPI service starting, running and then stopping. But there's only 7 seconds between the start of the run and the stop.
I saw this pattern occurring 244 times from january the 1st on with always those 7 seconds in between. There also nothing in the CD Burning staging area so I dismissed the possibility of a cd burn.
What I'm now looking for is the presence of SD cards and I was able to locate one.
Thanks a lot,
You didn't reply to the part of Harlan's reply concerning link files? Have you carved for link files? There would often be link files created at the same time as the file/// entries.
I would also be tempted to do a string search for some of the html file names just to see if they came up somewhere else and that lead to a clue as to their origin.
H
@coax,
I'm with both of these guys with their suggestions. A couple things have come to mind and to reiterate what harryparsonage and keydet89 said, check the lnk files. I had a similar case where greener pastures came into play with a little vengeance, and I was able to show the evidence through a lnk file.
I would suggest to get a keyword list and compare that to any lnk files (working backward). The data may not have gone through the "suspect's"access, they could have used another employees access (cyber engineering). Another thought was the data was possibly d/l to the laptop and sent to a cloud storage like dropbox.
I have carved for link files and do not see any link files corresponding with the files I have on record during the moves.
Nothing noteworthy in the shellbags.
I've did a bunch of similar cases already where the evidence was clear cut and obvious but in this instance I cannot safely conclude a file copy took place. I do not understand at this point what caused this specific file pattern.
Diving back in.
Does the company/victim know the name of the files that were believed to have been d/l? If so I would still conduct my index search for the files. One of the things I have come to notice with FTK; lets say you have a phrase like - my photos on the beach. FTK will look for those words individually and provide a results, often an overwhelming amount. With the case I worked (as stated previously), I put the file name in quotes - [ex] - "my photos on the beach" without the extension. This provided much different results and DID provide the results I was looking for. In addition, do you have access to something like Digital Detective or Internet Evidence Finder to check the HTML?
Another thought was the data was possibly d/l to the laptop and sent to a cloud storage like dropbox.
I agree. It may be helpful to take another look at the browsing history to see if anything jumps out as being related to a cloud-storage provider. With some providers, you don't have to have a separate app installed to be able to upload files. In those cases, your most telling evidence will likely be in the browsing history, cache, etc..
Do you have access to the file server that the confidential files reside on? I would image the system drive of that server and look for entries in the Windows event logs that coincide with the times you suspect he was downloading files. In addition to the File Share or Logon/Logoff events, you might get lucky with the sysadmin having enabled file access auditing to some extent.
Nothing noteworthy in the shellbags.
I'm just curious…what tool did you use to parse and present this information?