Investigating Explorer's temporary ZIP folders and retrieving files

2022-12-14  Cyber Security

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:

C:\Users\user\AppData\Local\Temp\Temp1_zipname.zip\

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
Looking for the comments? My website doesn't have a comments section because it would take a fair amount of effort to maintain and wouldn't usually present much value to readers. However, if you have thoughts to share I'd love to hear from you - feel free to send me a tweet or an email.