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:
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.
Using the cipher.exe tool to determine who the DRA's are for the EFS file:
From a CMD prompt:
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:
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 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: