Recovering EFS Files from a VMware Virtual Disk

The VM is gone — deleted, corrupted, or replaced — but the .vmdk file survived, maybe with a snapshot or two attached. Somewhere on that disk are EFS-encrypted files, and mounting the disk doesn’t make them readable. This covers recovering files from a VMware virtual disk with RS Partition Recovery, and why finding the right certificate matters more than the recovery step itself.

Contents

1. Recovering Files from the Mounted VMDK
2. Where the EFS Certificate and Private Key Actually Live
3. Getting the Certificate: The Part That Actually Determines Success
   • A Snapshot Still Boots
   • The VM Is Completely Gone
   • Different Snapshots, Different Certificates
   • Exporting a PFX from the Bootable Snapshot
4. Domain-Joined VMs: What's Different for EFS Recovery
5. Common Difficulties Recovering EFS Files from a VM
   • Certificate Doesn't Match
   • Exported Without the Private Key
   • Disk Files Locked or In Use
   • Wrong Snapshot State Selected
6. What to Do If You Don't Have the Certificate

Recovering Files from the Mounted VMDK

Once the .vmdk is mounted, recovering files from it works exactly like recovering files from any other drive. What’s different here is getting to that point.

Recovery and decryption are separate steps. RS Partition Recovery mounts the VMDK and extracts recoverable file data. It can decrypt EFS files when supplied with a usable matching key; mounting and scanning do not recover that Windows key or bypass EFS.

Work from a consistent copy of the VM’s disk files, and use another working copy for boot attempts. Keep the originals unchanged while you recover files and look for keys.

Open RS Partition Recovery and choose Mount Disk instead of selecting a physical drive. Under Virtual machine images, pick VMware Workstation / vSphere (*.vmdk) and point it at the VM’s folder. If the disk has snapshots, the tool lists each one separately — labeled Active, Snapshot #1, and so on — along with its size and creation date, so you can pick the exact state you need instead of guessing which raw file corresponds to which point in time. You can also select more than one state at once if you need to compare them.

A snapshot file is not self-contained — it only records changes relative to its parent, and depends on its parent files to reconstruct a working disk state. Copy the entire required chain: the base .vmdk and its data files, plus each required snapshot’s descriptor and data files. Preserve their directory relationships so the parent references can still be resolved. A snapshot file on its own, without its parents, won’t mount. Keep this disk set even if you export encrypted files; their EFS metadata also matters for later decryption.

From here, scanning and recovering deleted or encrypted files works the same as on a physical drive — see Recovering EFS-Encrypted Files: Causes, Certificates, and Practical Recovery for the full walkthrough, including what the “Encrypted files found” notice looks like and how the Add Decryption Data dialog works.

Where the EFS Certificate and Private Key Actually Live

Finding the certificate entry is the easy part. What matters is whether its private key can still be used. With a typical software key, Windows has to unlock a chain of dependent pieces, and RS Partition Recovery’s Import from Windows option relies on the logged-in account having access to that key.

The certificate itself — the public half, plus a reference to its private key — sits in the user’s personal certificate store. Open certmgr.msc and look under Personal → Certificates; PowerShell exposes the same current-user store as Cert:\CurrentUser\My. Its normal registry backing is under HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates, so collecting one apparent certificate folder from an offline profile is not a complete backup. Microsoft documents these store locations.

For a software RSA key, the private key is commonly stored separately as a DPAPI-protected blob under AppData\Roaming\Microsoft\Crypto\RSA\<SID>. It isn’t readable on its own — it depends on a master key under AppData\Roaming\Microsoft\Protect\<SID>, normally protected using the account’s Windows credentials. Other key providers can use different storage locations. The dependency is what matters: certificate → private key blob → DPAPI master key → credentials or a recovery mechanism. Getting to the private key requires that chain to remain usable. A PFX export packages the certificate and private key into a portable, password-protected backup; the raw profile files cannot simply be imported in its place.

Getting the Certificate: The Part That Actually Determines Success

Recovering the file structure from a mounted VM disk is the easy half. Every EFS-encrypted file recovered this way still needs a matching private key — and unlike a single physical machine, a VM can have several different certificate states depending on which snapshot you’re looking at. Which path applies depends on whether any version of that VM still boots and whether the original user’s key is accessible.

Do not reset the original account’s password just to get into the VM. A forced reset can make DPAPI-protected keys inaccessible. Boot a working copy and preserve the original profile and credentials before attempting account repair.

Exporting a PFX from the Bootable Snapshot

Inside the booted guest, open certmgr.msc under the original user’s account and go to Personal → Certificates. Find the entry whose intended purpose includes Encrypting File System, check its thumbprint, then choose All Tasks → Export. Select Yes, export the private key and Personal Information Exchange — PKCS #12 (.PFX). Protect the export with a password and save it outside the source virtual disk. Leave any option to delete the private key after export unchecked.

PowerShell gives you the same export without stepping through the wizard. Open Windows PowerShell as that same user and inspect the personal store:

 class="language-powershell">Get-ChildItem -Path Cert:\CurrentUser\My | Format-List Subject, Thumbprint, EnhancedKeyUsageList, HasPrivateKey

Find the EFS entry and copy its thumbprint. If several EFS certificates are present, match it to the file as described below; the first entry is not necessarily the right one. Then export the selected certificate. The example assumes E:\EFS-Backup already exists on a separate destination; change the path before running it.

 class="language-powershell">$thumbprint = (Read-Host 'Matching EFS certificate thumbprint') -replace '\s', ''
$efsCert = Get-Item -LiteralPath "Cert:\CurrentUser\My\$thumbprint" -ErrorAction Stop
if (-not $efsCert.HasPrivateKey) {
    throw 'This certificate has no associated private key.'
}
$pfxPassword = Read-Host 'Password to protect the PFX' -AsSecureString
$export = @{
    Cert        = $efsCert
    FilePath    = 'E:\EFS-Backup\efs-user.pfx'
    Password    = $pfxPassword
    NoClobber   = $true
    ErrorAction = 'Stop'
}
Export-PfxCertificate @export

HasPrivateKey confirms an associated key, but export can still fail if the key is inaccessible or non-exportable. If that session can open the files, save decrypted copies to a separate destination from within the guest. The PFX password protects the export and will be needed when importing it. Microsoft’s Export-PfxCertificate reference covers the export options; -NoClobber prevents overwriting an existing backup.

Domain-Joined VMs: What’s Different for EFS Recovery

That password dependency — master key unlocked using the account’s credentials — behaves differently depending on whether the user had a local or domain account, and it’s worth getting right before concluding a VM is a dead end.

A self-service password change through Ctrl+Alt+Del normally preserves access: Windows updates the DPAPI protection using the old and new credentials. An administrator forcibly resetting the password is different — on a local account, it can leave the existing master keys inaccessible with the new password. The original password or a usable backup may still matter. On a domain account, Active Directory provides a separate backup mechanism. Where the relevant domain backup is available, Windows can recover access to the protected master key through the original domain without the old password. Microsoft’s DPAPI backup-key documentation explains that mechanism.

A domain DPAPI backup key is not a PFX for Add Decryption Data. It is used in a separate recovery procedure with the surviving profile and key material. A restored logon against the original domain is one route; an authorized specialist may also assess offline recovery. Ask the domain administrator to handle this step. The backup key cannot recreate a missing private-key blob.

Speaking of which: that AD backup key and a Data Recovery Agent are not the same thing, and it’s worth checking for both rather than assuming one covers the other. The backup key is domain-wide, generated during domain creation, and supports recovery of domain users’ backed-up DPAPI master keys — it isn’t EFS-specific. A DRA is EFS-specific and works through an EFS recovery policy: the file must contain a recovery entry for that DRA, and the corresponding private key must survive. Creating a new DRA after the incident does not give it access to old files. A domain without a usable DRA doesn’t necessarily lack a DPAPI recovery route.

One more domain-specific option worth asking an administrator about: credential roaming. If it was enabled via Group Policy, a user’s EFS certificate and private key get replicated into Active Directory and follow the account onto participating domain machines — which means the certificate may be recoverable independently of this particular VM entirely, through the domain rather than through the disk you’re holding.

Common Difficulties Recovering EFS Files from a VM

Most of what goes wrong here isn’t RS Partition Recovery failing — it’s one of a handful of mismatches between the file, the certificate, and the disk state. These are the ones worth checking first.

When the encrypted file is accessible on a Windows NTFS volume, inspect it from Command Prompt or PowerShell:

cipher /c "D:\Recovered\Budget.xlsx"

Use the reported user and recovery certificate thumbprints to check the candidate key. The command needs the file with its EFS metadata; it cannot inspect a file that is visible only inside RS Partition Recovery’s scan results. Microsoft documents /c in the cipher reference. Once the key is accepted, check a readable preview where supported, save to a different destination, and open a saved file in its normal application. A damaged recovery can still fail even with the correct key.

What to Do If You Don’t Have the Certificate

If no snapshot boots and no PFX backup turns up, preserve the original profile before concluding the key is gone. For a local account, surviving key material and the original credentials may still support a separate recovery assessment. For a domain account, check the AD backup key, a matching DRA, and any roamed or archived key with the administrator.

If every usable private key and recovery route is permanently lost, the files cannot be decrypted. RS Partition Recovery may still recover the encrypted file data and filesystem information; the contents will remain encrypted.

See What to Do If You Don’t Have the Certificate in the main EFS recovery guide for the general reasoning behind that limit. Keep the original VMDK chain while any key search is still in progress.