Problem solve Get help with specific problems with your technologies, process and projects.

Recovering encrypted files from an NTFS partition

To recover encrypted files from an NTFS partition, you need to understand how the encryption process works, and how the Encryption File System (EFS) encrypts files on Windows' NTFS file system.

One part of SearchWinComputing's Step-by-Step Guide: Data recovery revealed some techniques for recovering data...

from an NTFS partition. This article builds on that concept by showing how to recover encrypted files from an NTFS partition.

But first you need to understand how the encryption process works. The Encryption File System (EFS) encrypts files on the NTFS file system. The NTFS file system actually contains an encryption attribute that can be set for files and folders. When a file's encryption attribute is enabled, the NTFS file system stores the file as an encrypted cipher.

When a user with permission to access the file opens the file, NTFS performs a decryption transparently in the background. But the file itself is not actually decrypted; that would leave it vulnerable to others while it is being accessed. Instead, the EFS creates a decrypted copy of the file and hands it to the application that opened the file. Any changes made to the decrypted copy of the file are automatically passed on to the encrypted copy. When the user closes the file, all that remains is the encrypted copy.

EFS encryption is based on Public Key Infrastructure (PKI), which itself is based on the concept of key pairs. Each user is given a public key and a private key. A user's public key is available to anyone who asks for it; the private key is accessible only to the user who owns it.

When a user tells Windows he wants to encrypt a file, EFS generates a file encryption key. Windows uses this randomly generated key in conjunction with the Data Extended Standard X (DESX) algorithm to encrypt the file. (3DES encryption became an option in Windows XP SP1). The encrypted file is written to disk.

DESX is a standard algorithm used by anyone who attempts to decrypt the file. The trick is that DESX doesn't work without a file encryption key. Since the file encryption key actually resides on the same system as the encrypted files, this key is vulnerable to compromise. To help protect the file encryption key, EFS encrypts it using the user's public key.

This means that the file is encrypted, but the key to the file is also encrypted using a different key. So two keys are needed to open the file. The first is the private key of the user who encrypted the file. Only the user's private key can decrypt something encrypted using the user's public key. Once the file encryption key has been decrypted, it can be used to decrypt the encrypted file.

To recover encrypted files, you must know who encrypted the file in the first place. Because the encryption process is certificate-based, only a user with the appropriate certificate is allowed to decrypt the file. For example, if someone who is an administrator, but not a designated recovery agent, were to open a file's properties sheet and remove the encryption attribute, he would be unable to actually write that change to disk. Even though the administrator has full rights to the file system, he does not have the necessary certificate in this case, so Windows does not allow him to decrypt the file. In other word, even an administrator can not decrypt the file unless they have a copy of the certificate.

The good news is that it is pretty easy to find out who encrypted a file. Just because a file is encrypted, it doesn't mean that Windows hides the file's existence. You can still see the file's icon, even if you don't have the necessary certificate to decrypt the file.

To see who encrypted a file:

  1. Right-click on the file.
  2. Select the Properties command from the resulting shortcut menu.
  3. When the file's properties sheet appears, click the Advanced button found on the General tab.
  4. When you see the Advanced Attributes dialog box, click the Details button.
  5. You will now see the Encryption Details dialog box, which lists the users who can transparently access the encrypted file.

The information shown in this dialog box is valuable. If you had a disgruntled employee that encrypted a bunch of files and then quit, you could see what account they used for the encryption and then reset the password on that account, log in and decrypt the files.

The Encryption Details dialog box also lists a recovery agent -- another user who is authorized to decrypt the files. When a user is logged into a computer running Windows 2000 or XP as a domain user, the domain administrator automatically becomes a recovery agent.

This means if the authorized recovery agent were to log into the machine, they could transparently decrypt the files, even if the user who had encrypted the files had lost or destroyed their file encryption key.

Note: It is only the domain's Administrator account that is an authorized recovery agent, not accounts that are members of the Domain Admins group. Likewise, the domain Administrator is only an authorized recovery agent if the user was logged in with a domain account at the time that the files were encrypted.

In Windows 2000, if a user encrypted files while logged in locally to a machine (using a computer account, not a domain account), then the computer administrator was automatically designated as a recovery agent. I have seen Microsoft documentation indicating that machines running XP do not automatically designate a local recovery agent unless those machines were upgraded from Win2k. However, I have not been able to verify this.

Remember: The trick to recovering an encrypted file is that you must have an authorized private key and a file encryption key that was encrypted using the corresponding public key. Without these keys, there is no way to recover encrypted files.

About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server, Exchange Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. He writes regularly for and other TechTarget sites.

More information on this topic:


Dig Deeper on Windows Server storage management