john:articles:EFS_Recovery [Openwall Community Wiki]

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: http://support.microsoft.com/kb/223316 (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.

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: http://support.microsoft.com/kb/963046 http://technet.microsoft.com/en-us/library/cc962103.aspx https://www.tunesbro.com/data-recovery.html

Again that is for File level encryption, folder level is the most common EFS scenario I've encountered however. Pagefiles may also contain plain-text versions of EFS files, it's worth a look if you have a image of a drive.

http://technet.microsoft.com/en-us/library/cc875821.aspx 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 for everything) 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: (the folder “Logs” hass EFS enabled)

c:\Intel\Logs>cipher

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

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: http://technet.microsoft.com/en-us/library/cc722672.aspx 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: http://support.microsoft.com/kb/241201

3rd Party Software: Passware|AEFSDR http://www.lostpassword.com/efs.htm http://www.elcomsoft.com/help/aefsdr/how_aefsdr_works.html

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 etc.

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: http://technet.microsoft.com/en-us/library/cc759804%28v=ws.10%29.aspx

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.

Work has begun for JtR to support not only cracking EFS files and folders so there is an open-source alternative to the proprietary recovery platforms. more to come* -rich