I have a folder of keys from a Windows 10 laptop where the OS is no longer bootable. In the recovery console, even after logging into the system with the correct username/password, the folder returns 'Access Denied'.
How can I get access to this folder?
This turned out to be significantly more complex a problem than I bargained for, however I did find the solution. I had a suspicion that malware had damaged my machine, so completed all work in a Windows 10 virtual machine inside a VirtualBox VM. For this I created a user account with the same username and password as the failed machine. I'm not sure if that was necessary.
Challenge 1: Getting the files. The failed machine's drive was installed in a USB case to make the partitions accessible in a running machine. The virtual machine needed direct access to the drive, connecting through a shared folder was not enough. Once the USB drive was available in the VM, robocopy was used in a Admin permission elevated command prompt, using the /efsraw modifier as per this question to allow copying raw encrypted files to a local location. Without Admin privileges, error 57/87 would occur even often error 0.
Once the files were local it was possible to take ownership and full access permissions in the file security editor.
Challenge 2: getting the certificates. As suggested in an answer to this question, the certificates are stored in the failed machine user's AppData folder, for example
C:\Users\bob\AppData\Roaming\Microsoft\Crypto
\Protect
\SystemCertificates
I ended up copying the whole Microsoft folder just in case I needed anything else.
Challenge 3: Tools. As per this answer, the tool mimikatz available through GitHub is very powerful and can extract all of the certificate information required. However Windows Security (perhaps rightfully), and most browsers, declare this a virus and will refuse to download or get any access to the files. I needed to diable all sorts of security in the VM to allow the download and continue to diable protection to allow the application to run. For security I disabled all VM networking in case anything leaked out from a potentially malicious tool.
Challenge 4: Getting the Digest ID. The first thing that mimikatz needs is the thumbprint/digest number for the file. In some cases it was not possible to see this, however I believe this was due to attempting to view the files on a VM shared folder. The value can be seen in the file properties, looking at the Attributes>Advanced... window and getting Details. This should show a certified user (username and original machine name), and a thumbprint value.
Challenge 5: Getting the keys. I followed the documentation for mimikatz, and also downloaded one of the Windows binary openssl installers (FireDaemon OpenSSL x64 3.2.0). All steps upto and including generating the cert.pfk with the recovered EFS certificate. This started from the thumbprint, then finding the container ID, certificate file, decrypting the public and private keys using the original user password, and finally reformatting the keys into a new certificate. With all this however, Windows 10 did not like the format of this certificate.
Challenge 6: Installing the certificate. The last step of the mimikatz help is the command
openssl pkcs12 -in public.pem -inkey private.pem -password pass:mimikatz -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx
however Windows 10 is not happy with this certificate and will not recognise any password provided, including none at all. This was both in the Windows GUI for importing the certificate and using the documentation suggested certutil. Various errors including 'bad network password' 'file not found'. Using the answer to this question facilitated recasting the certificate backup command to
openssl pkcs12 -in public.pem -inkey private.pem -certpbe PBE-SHA1-3DES -keypbe PBE-SHA1-3DES -nomac -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx
noting the key difference in the SHA1 format specifiers and the -nomac call. This allowed certutil to install the certificate to
User>Personal>Certificates
in the certmgr.msc control panel widget. Still however, the files were not decryptable.
Challenge 7: Using the certificate. This page gave the final answer to using the certificate.
The key task is to use Windows to export the new certificate from certmgr.msc in PKCS12 format. It will be possible to export the certificate with its private key, and as per the instructions, required. Finally, using the Windows GUI to reinstall this certificate, with the password made in the export, and allowing it to install the certificate in the automatic location for its type under the User profile (as opposed to Computer or Local Machine). The certificate will end up in the same location as it started (User>Personal>Certificates), however attempting to export this certificate will not allow exporting the private key.
This is the end of the last step and now the files are decryptable. Note that seeing updates in certmgr.msc usually requires closing and reopening it.