3

Recent ransomware events often include data theft in addition to just encrypting data. The Encrypting File System on Windows Pro/Enterprise editions encrypts individual files using a private key stored alongside certificates for that user account. The file is therefore unreadable by anyone except the logged-in user account. When you copy the file to a flash drive, it remains encrypted. The only way to read the file on another computer is to also copy the certificate + private key.

Therefore, if ransomware simply uploads your files, wouldn't they remain encrypted with EFS and thus unreadable by attackers?

This wouldn't prevent the ransomware from encrypting your files, but would it prevent threats of public leaks/selling of stolen data?

Edit: Assuming Windows 10, and assuming ransomware runs on the user account that can access the EFS-encrypted files.

  • Great question! I am curious to know the answer! One minor quibble: *" The only way to read the file on another computer is to also copy the certificate."* -- you probably mean *certificate + private key* as described in this question: [What is the difference between a certificate and a private key?](https://security.stackexchange.com/q/226747/61443). In the Windows Certificate Manager, it's actually the *private key* that is non-exportable, not the certificate. – Mike Ounsworth May 26 '21 at 15:29
  • Just to clarify - When you say **EFS** here, you are talking specifically about the old style *Microsoft Encrypting File System* vice the generic concept of an encrypted file system that incorporates Bitlocker, LUKS, Veracrypt, and others? – user10216038 May 26 '21 at 16:36
  • @user10216038 Specifically Microsoft Encrypting File System. It is still present on current Windows. –  May 26 '21 at 17:36
  • @MikeOunsworth I'll defer to your expertise on that –  May 26 '21 at 17:37

3 Answers3

3

When you copy the file to a flash drive, it remains encrypted

When EFS-encrypted file is copied to a drive that do no support encryption (FAT/exFAT families), the file is decrypted before copied and copy is unencrypted. I believe that only NTFS-formatted drives support encrypted file copy.

If you attempt to ZIP the file, it is decrypted first and then zipped (encrypted files does not support compression). In other words, transferring EFS files removes the encryption.

This means that if attackers run something under your account which can decrypt the file, then attacker can get to raw unencrypted content.

The purpose of EFS is to provide security for offline (when you are not logged on) and other user access (locally or remotely).

Crypt32
  • 5,901
  • 12
  • 24
  • 2
    In other words, EFS is transparent to applications running under your user account ("transparent" meaning that the application sees plaintext files). Since malware runs as an application under your user account, that means the malware has access to the plaintext files. Correct? – Mike Ounsworth May 26 '21 at 15:30
  • I just tested, and copying an EFS-encrypted document to a FAT32 drive does NOT remove the encryption like you suggested. Zipping the file using Windows's send to compressed folder option or 7zip does remove the encryption. –  May 26 '21 at 17:59
  • I believe that EFS support for FAT32 came only in Windows 10 and not available in previous versions. – Crypt32 May 26 '21 at 18:04
  • If the user who copied the files isn't the user who encrypted it, then the file cannot be decrypted without that user's password. If you run a malware.exe under your current user(the user who encrypted the files), then yeah its essentially plaintext. So if your account is "bob" and a "alice" account logs in and copies all your files, there should be protection. – john doe May 26 '21 at 18:07
  • @Crypt32 My mistake I should have specified Windows 10. Regardless, if zipping the files removes encryption, I suppose malware could easily zip files before upload if they don't already, rendering this moot. –  May 26 '21 at 18:09
  • `If the user who copied the files isn't the user who encrypted it` -- it won't work, another user will get `Access Denied` error when attempts to copy the file. EFS driver doesn't give access to encrypted bits written on a disk. Instead, you need a low-level bare metal copy of the disk to see actual encrypted bits. – Crypt32 May 26 '21 at 18:15
  • 1
    `I suppose malware could easily zip files before upload`. If malware is executed under your account (EFS file owner and decryption key is installed), then malware don't need to bother with zipping, it can simple FTP file over a network for example. But any application that runs under another user account won't get encrypted data, nor can decrypt the file. – Crypt32 May 26 '21 at 18:17
  • @Crypt32 Technically you're wrong that the file system driver doesn't give access to the encrypted bits - you can use [`ReadEncryptedFileRaw`](https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-readencryptedfileraw) to get that data, following an `OpenEncryptedFileRaw` call - but the normal Win32 file APIs (and everything built on top of them) won't expose them. Even the actual `NtCreateFile` system call doesn't seem to offer the option to bypass EFS, though you might just have to explicitly specify the encrypted file "stream". – CBHacking May 29 '21 at 08:48
0

Does EFS protect against data theft by ransomware?

Yes. Data encrypted with EFS will be protected from data theft as long as the following points are met.

  1. If a compromised user account has access to the EFS encrypted file then one must be sure:

    • Ransomeware didn't decrypt the file using the compromised credentials.
    • Steal the EFS encryption private key for the compromised account.

  2. Certificates allowing Data/Key Recovery must not have been stolen.

  3. The files were properly encrypted using strong ciphers on an NTFS file system as @Crypt32 pointed out.

phbits
  • 1,032
  • 2
  • 5
  • 12
0

No, it does not. EFS is transparent encryption (and decryption). If you try to read the file - possibly to upload it to a server, but also possibly just to read it in Notepad - and you're running as a user with access to the key, then the OS will obligingly decrypt the file contents for you as part of the ReadFile system call.

You say "simply uploading a file" but that's not really a thing. You usually only upload file data to a new file (or to something else, like an S3 bucket or in-memory analyzer or database or whatever). If the destination is in fact a new file, it can (totally optionally) have the same name and other metadata (timestamps, etc.) as the original file, but for that to happen the uploading utility would have to deliberately send that metadata along because it's part of the file system and you are not uploading a file system object, you're uploading a stream of bytes (which are typically just the file contents).

There exist networked file systems that support transferring data as logical files rather than just as blobs of bytes. Windows even supports a few of them out of the box. Of those, though, only Windows Networking is likely to have any support for maintaining EFS across a transfer. Additionally, "copying" or "moving" a file to any of those from an internal drive is - just like moving a file from a flashdrive to a HDD - just automating the "tell destination file system to create a file with this metadata, send over the contents as binary blob" process. The fact that Windows supports recognizing when a destination file system supports encryption and transferring the data encrypted (rather than transferring the plaintext) is cool, but it only works if the OS drivers are doing the transfer. If it's being transferred by the extremely vast majority of user-mode software - e.g. if you use a web browser or FTP client (even one built into Windows!) to transfer "a file" between two file systems (or even between two processes on the same machine!) - the data will be decrypted before being exposed to the process, and only re-encrypted (by EFS) at the destination if the destination process tries to write the received data to an EFS file.

Since ransomware has absolutely no reason to jump through the hoops necessary to read the encrypted data directly off the drive (skipping the transparent decryption on read), and since it almost certainly isn't using SMB to transfer the files (it's not a great idea to expose SMB to the internet at all, its security is... outdated), the file contents will surely be decrypted by the OS before the malware uploads them.

CBHacking
  • 42,359
  • 3
  • 76
  • 107