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