The strange case of WinZip MRU Registry key

Published: 2016-05-22
Last Updated: 2016-05-22 13:38:01 UTC
by Pasquale Stirparo (Version: 1)
4 comment(s)

When we want to know if a document (.doc, .pdf, whatever) has been opened by the user, in a Windows environment our information goldmine place is the Registry and particularly its MRUs keys. However, it seems this is not always the case.
During the analysis of the Retefe case I wrote about in my previous diary, I came across a Registry behavior I did not expect, or at least I was not aware of, about how to verify if the file contained within the zip archive had been opened or not. Regarding WinZip, there are mainly two keys of interest in the NTUSER.dat Registry hive:

  • Software\Nico Mak Computing\WinZip\extract, which should contain the folders list where all archives have been extracted to
  • Software\Nico Mak Computing\WinZip\mru\archives subkey, which contains the list of every archive created, browsed or extracted (but no idea on how to differentiate among the three), plus the list of all file name within any of the listed archives.

In that specific Retefe case, from an initial triage via RegRipper 2.8, I could only find an entry in the mru\archives subkey, while the extract key was empty

However, I knew from the network IOCs that the .js file was run by the user, but from the registry it looks like the archive has not been extracted. This caught my attention: if a file is run within the WinZip explorer window, does it get stored in the MRU registry key as usually expected?
 

Analysis and Tests Results
I started searching online but the closest thing I got was a post from Patrick Olsen "WinZip MRU Tool Check" [1]: interesting read to understand a bit more about the registry key content, but not answering my question. Therefore, I made some tests myself with the following scenarios (running WinZip 20.0 on a Windows 7 machine):

  1. User receives a zip archive containing some .js/.doc/.pdf files.
  2. User double clicks on the .zip archive, which open the WinZip Explorer window, listing the files present inside the archive.
  3. The user double clicks on one of the files, therefore opening it. NOTE: the archive has not "officially" been unzipped/extracted.

Test results were the following:

  • Extract zip archive content via right-click menu "extract to here" or "extract to…", it creates two registry entries within
    • extract key, which lists the folder where the archive content have been extracted to
    • mru\archives subkey, which lists the archive name (full path) and the names of all files within the archive
  • Double-click on the zip archive, only viewing its content via WinZip explorer window and then closing WinZip (no archive extraction), it creates an entry within
    • mru\archives subkey, which lists the archive name (full path) and the names of all files within the archive
  • Double-click on the zip archive and then double click on the .doc file inside (no "official" archive extraction), it creates two entries within
    • mru\archives subkey, which lists the archive name (full path) and the names of all files within the archive
    •  \Software\Microsoft\Office\15.0\Word\Reading Locations\Document11, which is the Office Reading Location key (note: not the standard MRU keys we look for)
  • Double-click on the zip archive and then double click on the .pdf file inside (no "official" archive extraction)
    • mru\archives subkey, which lists the archive name (full path) and the names of all files within the archive

The case of the Office document is a particular one apparently. That is due to the so-called "Pick were you left" [2] feature introduced with Office 2013. On the other case, the pdf file is not listed in any MRU registry key or anywhere else. Moreover, since it is not extracted there were no traces on the MFT either.

Conclusion
If a user opens a document/file contained inside a zip archive by double clicking directly from the WinZip explorer view, it will not be recorded in the Registry. The only case you may have some luck is if all the following three conditions are met:

  1. the file is an Office document
  2. user is running Office 2013 or later
  3. the "Pick where you left" feature has not been disabled [3]

In such case, you will have evidence in the NTUSER.dat "reading locations" key (\Software\Microsoft\Office\15.0\Reading Locations\DocumentXY)

Are you aware of other files other than Office documents that may get stored somewhere else in the registry, for this WinZip scenario?

Happy Hunting
Pasquale


REFERENCES
[1] http://sysforensics.org/2015/03/winzip-mru-tool-check/
[2] http://dfstream.blogspot.ch/2014/01/ms-word-2013-reading-locations.html
[3] http://www.thewindowsclub.com/disable-pick-up-where-you-left-off-office

4 comment(s)

Comments

The lack or presence of an MRU entry for a particular file opened from within the WinZip explorer is dependent upon the assigned file handler. The WinZip explorer seems to behave the same as Windows Explorer, 7-Zip explorer and many other file system explorers in regards to file open operations. The recording of MRU is up to the assigned application. The WinZip file extractor seems to be doing it's part in recording the MRU for it's assigned file types (.zip) that it opens. In addition it seems to be recording additional info on the content metadata and extraction destination as applicable.

I think the question to be asked is: Which applications reliably record files they have opened and which do not?

From what you described, Office 2013 or later by default seems to record MRU reliably. You did not mention what application opened the .pdf file. Odds are it was some version of Adobe Reader.

I suspect the files opened from within an archive through WinZip explorer are extracted temporarily and deleted after closed and WinZip closes. There may be evidence of a temporary file with a unique name, but associating that name to the file opened may be a challenge. The file itself may be recoverable through an undelete procedure if it hasn't already been overwritten.
Thanks for your comment.

Regarding which application opened the .pdf, you are right I forgot to mention it but yes, it was Adobe Reader XI. Sorry.

I think this whole behaviour is not due to the application the opens the document, rather is an "issue" with anything else other than Windows Explorer as starting point. Just think that if I open a .pdf file from Windows Explorer, I will find an entry about this on the MRU key for pdf/AdobeReader, while doing the same from the WinZip Explorer window not. Moreover, I experienced a similar thing with Outlook when opening an attachment directly double clicking from the email, instead of saving it first on the file system and then opening it. But this Outlook behavior is still under testing.

About Office 2013 recording correctly an MRU value, watch out because the "Reading Locations" is not an MRU key. As mentioned in the post and also more in details in [2], it is a registry key related to the "Pick were you left" feature. In fact, if that is disabled you will not find any mention of the openend .doc file in the registry.

Thanks, Pasquale
Did you examine the registry keys for winzip in a registry viewer? I've found occasionally regripper can miss some things (as it only parses keys, and sometimes specific values, it knows about)

Also did you examine the recentdocs key?
Yes,

I did test the registry in the registry viewer as well, actually the subsequent tests have been done by searching for the specific file name in the registry viewer. I checked also the RecentDocs and it was not there, the only place where I found an entry was, as I wrote, on the "Reading Location" key, but this happen only in the case of Office file opened and not, for example, in the case of pdf.

RegRipper may miss things also because sometime there are no plugin for that specific location or because configuration. For example, by default the ReadingLocation plugin is not part of the "ntuser" plugin collection (what is the weird reason why? I don't know). RegRipper is good for triage and for known locations, but I agree with you that if RegRipper does not find it, it does not means the key/value is not there.

Diary Archives