Investigating Explorer's temporary ZIP folders and retrieving files
If I was to describe how often malware is downloaded within ZIP archives, “common” would be a huge understatement. A key artefact in these investigations is the temporary directory Windows creates when a user opens an archive in Explorer, but I recently realised I’d never actually run a proper test to see when the folder is created, when it is not, and when it is deleted. So to clear that up, here’s a quick blog post.
ZIP archives on easy mode
There was a time when a ZIP archive was an indecipherable box that Windows couldn’t see inside. To access the files within, you’d have to download third-party software, like a trial version of WinZip that would incessantly prompt you to buy a licence whenever you downloaded something from the internet.
That all came to an end with - I think, although I may be slightly mistaken - Windows XP, when Microsoft added native capabilities within Windows Explorer to zip and unzip files. This is now a near-seamless experience, with the user able to open a ZIP archive as though it were a normal folder, as seen below.
But what’s going on behind the scenes when this happens, and what artefacts does it leave behind for forensicators and responders? With so much malware downloaded from the internet and attached to emails inside ZIP archives, knowing where to look can be a powerful tool in tracing user actions.
The amazing disappearing folder
This focus of this post is the temporary directory that Explorer creates, quietly unzipping parts of the archive on demand in the background so that it can present the user with that seamless interface on the front end. It’s located within the user’s AppData
Temp
folder, under a path like this:
But when exactly is the folder created? I previously assumed, wrongfully, that it would be created as soon as the user double-clicked the ZIP file in Explorer and viewed the directory listing within. However, that is not the case, and as long as the user stays within Explorer only, no folder is created.
As an aside, I’ve noted that this also applies to nested folders within the ZIP archive - the user can browse them without triggering the Temp1
folder creation. However, if the ZIP archive contains another ZIP archive and the user opens that with Explorer, a Temp1 folder is created for the parent archive.
The most common way a user will trigger the Temp1 folder’s creation, however, is by opening a file within the archive. This will create the folder and populate it with only the file the user has actually opened. Subsequent files are copied to the folder as they are opened by the user, but it’s worth noting that the Temp1
folder will not contain all files from the archive unless the user opens them all.
These files are persistent regardless of whether the user closes them or opens other files. Interestingly, if the user makes changes to a file within the archive, by default the Save As dialogue box shows them the Temp1
folder, meaning an inattentive user might actually end up saving their edited copies to the same location (although this is unlikely, as they would have to give their file a different name).
Once the Temp1
folder is created, it remains in place for as long as the user has any ZIP archive open in Explorer. This is simple enough when working with one archive - the user closes the ZIP file and the Temp1
folder disappears. But if the user opens files within a.zip
and b.zip
, then closes b.zip
, the Temp1
folders for both archives will remain until a.zip
is also closed in Explorer.
It’s also worth noting here that the folder deletion doesn’t care about the files inside - it’ll happen whether they’re still open or not. The only scenario I could find where specific files matter is if the user saves an edited copy of a file (with a different name, since the originals are read-only) inside the Temp1
folder or moves a new file inside. If there’s a file that “doesn’t belong” at the time folder deletion is triggered, Explorer deletes the original files but leaves the directory and the “custom” files where they are.
Another short note, this time on naming: The temporary folders almost always start Temp1
. In the previous example, there would be two folders named Temp1_a.zip
and Temp1_b.zip
. The only time the number increments is when dealing with two archives with exactly the same name. If the user opens files within two archives, both called a.zip
, at the same time, Explorer creates Temp1_a.zip
and Temp2_a.zip
.
Summary
Using the newfound knowledge from our experiments, we can draw up a rough guide to this behaviour and what your observations from log- and disk-based investigations might mean. As always, it’s best not to rely completely on this information and cross-reference with other artefacts wherever possible.
Observed | Inferred |
Temp1 folder created |
User opened a file within the ZIP archive with Explorer |
File inside Temp1 folder |
User opened this file from ZIP archive OR manually wrote it to folder |
Temp1 folder present |
User still has at least one ZIP archive open OR manually wrote a file inside |
Temp1 folder deleted |
User closed all open ZIP archives in Explorer |
Temp1 folder not created |
User did not open any files from ZIP archive in Explorer |
Temp2 folder created |
User opened files inside two identically named ZIP files with Explorer |