Dear Reader,
Today we will not discuss OWA again. Rather we will discuss a peculiar case of a temporary file that lead into a journey of discovery into Microsoft internals.
I was working a case Lockheed Martin v L-3, et al (6:05-cv-1580-Orl-31KRS), which has since settled, which involved amongst other things several files that were contained on a CDROM and accessed on a laptop. On this CDROM were lots of files and one of the issues in the case revolved around which if any of those files had been accessed on the laptop showing which information may have been exposed and/or transferred to the rest of the company.
So like a good computer forensic investigator I reviewed all of the recently used registry entries, the lnk files and the user assist records regarding any of the files known to have come from that CD. One of the files in particular had an extension of 'shs'. 'shs' files are scrap files made when a user is copy and pasting items such as powerpoint slides, in this case it was a powerpoint slide. So I found the entries referencing that this specific shs file, which when loaded into powerpoint is a single slide, was accessed on three occasions. At times corresponding to these accesses I found a temporary file on the desktop that contained keywords relevant to the case and appeared by content to be a powerpoint document but no matter what tool I used it would not open it. All of my file signature tools regarded the file as 'data' with no specific file type.
The opposing investigator had the system this CD was burned form and thus had one significant advantage over me, he knew that the temporary file was related to the scrap file contained on the CD. Sure enough when I renamed this temporary file that no tool regarded as anything to an extension of 'shs' it opened up right away in powerpoint revealing the same slide as contained in the shs file on the CDROM. This left the question, how did this file get created on desktop?
So I keep reiterating the CDROM for a reason, normally when temporary files are created in office documents they are created in the same directory as the file you are working with. When you are working on a file in a read only directory, like a CDROM, it will instead create the temporary file on the desktop. So mystery of why the file exists solved! We already knew the scrap file was accessed and now we have corresponding temporary files to show that on the desktop.
The opposing expert was not deterred so easily, he pointed out that the temporary file sh60.tmp had the numeric 60 in it meaning in his opinion that it had in fact been accessed many more times than 2 since the 60 is actual hex for 96 so he claimed it was accessed approximately 95 times. This would a very large amount of accesses for a single powerpoint slide no matter what the contents so I was skeptical. We did some research to determine what creates the temporary file and found out it was a shared Microsoft library that many, many applications use including the application of hotfixes and service packs. Each time a temporary file is created by anything that uses this shared temporary file library the counter is incremented thus explaining how we had such huge jumps between our temporary files left on the desktop and the discrepancy of the offset to the number of times the rest of the forensic artifacts showed the file being accessed.
So the morale of the story is, sometimes a temporary file isn't just a temporary file so be careful out there and always test your assumptions. In this case both myself for assuming the temporary file was just a temporary file and the opposing expert for assuming that nothing else would change the counter on the temporary file got to learn an important lesson.
