Windows 7 Unzip downloaded archives are Encrypted - EFS

Question

Basically when I download a zip archive, typically in chrome, but this happens in Mozilla as well, the files in the archive are encrypted (EFS) when I unzip them. Not password protected or anything related to the zip functionality but actually encrypted using Windows EFS.

I cannot for the life of me figure out what is causing this.

Screenshot:

However, if I back out to see the root folder, the base directory is not encrypted:

Just to be certain, the zip download is also not encrypted. Have double checked in the properties as well.

I use EFS in a few folders on this computer, but this happens no matter what folder I put the archive into. I can keep it in downloads, move it to my documents, desktop etc., and when I unzip it using the Windows built in application, the folders and files in the archive are always encrypted.

I've searched all over and cannot even find another example of this or what I need to look for to figure out why Windows is doing this when I unzip an archive.

To summarize:

Windows 7_64

Downloaded ZIP archive

Unzip using Windows 7 built in extraction application

Subfolders and files but not the root folder are always encrypted using my EFS credentials.

Windows is always kept up to date. Have always run Eset smart security on this computer. EFS is used in several folders on this computer, but never ones like desktop or downloads or my documents. Any suggestions or direction on this would be greatly appreciated.

Screenshots of the properties of these folders. This is for an archive that is kept in downloads.

Downloads folder properties:

Archive properties (unblocking doesn't change anything):

Properties after unzipped:

Properties of encrypted files:

Answer 1

tldr: Windows bug presumably fixed in Windows 8

We ran into this problem when trying to copy some old data from one Windows file server to a NetApp NAS. We kept running into a problem where ROBOCOPY would fail to copy files:

2020/05/23 19:49:43 ERROR 6000 (0x00001770) Accessing Destination Directory l:\Somepath\folder\__MACOSX\
The specified file could not be encrypted.

As with your experience, it turned out that the files had been encrypted. Looking at the file properties showed that the users themselves had encrypted the files. When we interviewed the users, they claimed that they did not do this on purpose and didn't remember performing the steps (I showed them) to perform the encryption.

After some research, I found a link to an old Microsoft blog post, which has since been removed. Here is a link to the article on the Internet Archive and the text below.

https://web.archive.org/web/20131110020048/http://blogs.msdn.com/b/asklar/archive/2012/05/03/why-do-zip-files-from-mac-os-show-up-as-green-encrypted.aspx

Why do .zip files from Mac OS show up as green/encrypted?

It’s kind of funny really. The ZIP specification mandates that a program/OS creating a zip archive include a tag informing about itself to the program trying to decompress the archive. This information is called “version made by”, and looks like this:

      0 - MS-DOS and OS/2 (FAT / VFAT / FAT32 file systems)
      1 - Amiga                     2 - OpenVMS
      3 - UNIX                      4 - VM/CMS
      5 - Atari ST                  6 - OS/2 H.P.F.S.
      7 - Macintosh                 8 - Z-System
      9 - CP/M                     10 - Windows NTFS
     11 - MVS (OS/390 - Z/OS)      12 - VSE
     13 - Acorn Risc               14 - VFAT
     15 - alternate MVS            16 - BeOS
     17 - Tandem                   18 - OS/400
     19 - OS/X (Darwin)            20 thru 255 - unused

Now, interestingly, it seems that Mac OS is tagging the zip archives it creates with the value 3 (UNIX). Ok, so far no problem, I guess.

The problem happens when Windows gets confused about how to interpret file/folder attributes. In FAT/NTFS, these values are stored according to this definition of File Attribute Constants. You’ll see that FILE_ATTRIBUTE_ENCRYPTED has a value of 0x4000.

The interesting part is how Mac OS is storing its file attributes in the zip archive. Mac OS, being a UNIX based OS, uses the UNIX file/folder attributes system (and permissions, but that’s a topic for another time…).. Well, it just so happens that in POSIX, the flag to describe a directory/folder (S_IFDIR) coincidentally also has the value 0x4000. So it turns out the zip decompression code wasn’t aware that there might be other operating systems out there that might create zip archives…

Bonus question: can you change this behavior. Answer: No; but you can clear the encryption flag from the extracted files/folders easily.

Related to this problem, when the EFS Service on the Windows File Server performed the encryption, a local user profile was created for the user that copied the file. This had also been a mystery (since users don't have access to log into the File Server or otherwise run programs).

At the bottom of the post in the comments, the post's author mentions that the bug was fixed in Windows 8. I tried to reproduce the problem on Windows 10 and could not.

Unfortunately in each of our cases, the users computers had been rebuilt and they no longer had access to the certificates used to encrypt the files. We've since added an EFS recovery key account to prevent this from happening again, but since everyone is on Windows 10 it shouldn't happen anyway.