Microsoft EFS Recovery

Rich RumbleSecurity Samurai
OSCP certified, need I say more?
Microsoft EFS has gone through a few changes over the years, depending on the OS you're trying to recover EFS data from you may have to use different tactics. Overall however 3rd party recovery solutions like that of Passware or Elcomsoft's AEFSDR make recovery simpler by doing several steps for you. We will discuss the Microsoft EFS recovery tips, and then the 3rd party tips.

EFS is a seamless encryption that doesn't prompt you for keys or passwords (typically) and is fully integrated into every windows OS since win2k.That however does not mean that it is "secure" by default, in fact Microsoft tells you as much in many EFS KB articles: (Best practices for the Encrypting File System)

The article above list's several do's and don'ts the users are expected to know how to do. Exporting the keys/certificates to removable media being the single most important one from a security perspective. While this is a best practice it's also a little too much to ask or expect from a "user" to do. Creating recovery agent's is also a task not suited to users who probably don't use CLI tools like cipher.exe. EFS can often give people a false sense of security regarding their data. See my other article about choosing the right encryption for your needs.

The good news is, most people don't do any of those best practices, which makes recovery much more likely for system administrators and auditors. In addition to that, some people use file level encryption and not folder level encryption. The reason this makes recovery easier is that EFS makes a plain-text copy of the file that EFS opens, and if you lose power or suddenly turn the OS off, when you reboot you will find an EFS0.tmp (or an incremented 0-99 digit) file that is a plain-text copy of the EFS protected file. Once the file is closed, EFS "deletes" the temporary plain-text file, which could be recovered using any number of "undelete" utilities:

Again that is for File level encryption, folder level is the most common EFS scenario I encounter however. Pagefiles may also contain plain-text versions of EFS files, it's worth a look if you have a image of a drive.
This (above)article too states how the plain-text files are created over and over, it also states that the user being the administrator and the "user" (basically using the admin account) makes recovery a bit harder because that reduces the DRA's to one. More reason to keep the user from being the administrator of their PC's  :)

Using the cipher.exe tool to determine who the DRA's are for the EFS file:
 From a CMD prompt:
                       Listing c:\Intel\Logs\
                       New files added to this directory will be encrypted.
                      E IntelChipset.log ( E means encrypted, U means unencrypted)
                      c:\Intel\Logs>cipher /c
                       Listing c:\Intel\Logs\
                       New files added to this directory will be encrypted.
                      E IntelChipset.log
                        Compatibility Level:
                          Windows XP/Server 2003
                        Users who can decrypt:
                          pc01\richr [richr(richr@pc01)]
                          Certificate thumbprint: 7E32 54D8 2B06 1FF8 A8D8 E015 6A78 C9EF 423D E5FB
                        No recovery certificate found.
                        Key Information:
                          Algorithm: AES
                          Key Length: 256
                          Key Entropy: 256

Open in new window

While the above does not list the local administrator, the local admin is able to decrypt the folder. If this were a domain joined PC, the Domain Administrator would also be able to decrypt (and or add DRA's) the file/folder, with this caveat: If the domain joined PC was not on the domain, or unable to contact the domain controller(s) when the file/folder was encrypted, then the domain administrator will not be able to decrypt.

Recovering EFS data:
Microsoft only gives you the option of recovering by using a DRA (data recovery agent) or having a backup of the users or other DRA's private key. This is not easy to locate across a domain, and (nearly)impossible if the machine has been reimaged or wiped.

Users can't be expected to backup their keys when they have no idea how EFS works, or it's best practices:

3rd Party Software: Passware|AEFSDR

If running as an administrator no password needed as Elcomsoft can access the SAM database the same as the OS can and recover the files effectively. Depending on your situation, you may need to supply the SAM database, SYSTEM file and possibly a SYSKEY password/bootkey depending on the 3rd party software you purchase. AEFSDR can also search for the files it needs even if the administrator is not a DRA, AEFSDR will prompt you for a password of an account that is a DRA and or user who encrypted the file/folder.

The caveat to these products too is that they be used on Basic NTFS disk's and not Dynamic. If you can't install these products on the computer in question, then you will certainly need the password that was used when the EFS files were last accessed by a DRA. AEFSDR can also use a dictionary list if the password can't be remembered or that person is no longer at the company.

In my experience it's very easy to recover most EFS data, almost too easy using these 3rd party tools. There are also cases when you can't recover the data using all the tricks in the book, which can be a good thing, that's sort of the point of protecting the data. But it can also be a bad thing if you don't backup plain-text versions of the data. There is a GPO to turn off EFS on the domain or the local computer, and it may be a good idea for more Admin's to see the paradox and make the choice that best suits them. Users could be trying to do the right thing, but they may also be doing the wrong thing and keeping the administrator from being able to recover the data:

Note that enabling this option AFTER someone has used EFS will not cause it to be decrypted, check with your users first, or scan for EFS files/folders before implementing.
Rich RumbleSecurity Samurai
OSCP certified, need I say more?

Comments (0)

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.