Recovering Deleted Data from VeraCrypt: 3 Practical Scenarios

Encryption changes the data recovery workflow in an important way.

With an ordinary NTFS, exFAT, or FAT volume, recovery software can analyze filesystem metadata and unallocated space directly. With VeraCrypt, the filesystem is hidden behind an encryption layer.

So the recovery process becomes:

physical storage or container → VeraCrypt volume → decryption → filesystem → deleted data

Recently, we tested this workflow with several practical VeraCrypt data-loss scenarios.

The goal was not simply to mount a healthy encrypted volume. We wanted to see what happens when files are deleted, when a hidden volume is involved, and when the partition information itself is removed.

Disclosure: I work with Hetman Software. The recovery examples in this article use Hetman Partition Recovery, which is software we develop. The focus here is on the recovery workflow and the behavior of VeraCrypt volumes rather than a product comparison.

Test environment

For the tests, we prepared three scenarios:

1. A VeraCrypt file container protected with a password, custom PIM, and keyfile, with several files deleted from its filesystem.
2. A USB flash drive containing a standard VeraCrypt volume and a hidden VeraCrypt volume.
3. The same USB drive after its partition information was removed with the Windows diskpart clean command.

The important distinction in this test is clean versus clean all.

clean removes the disk's partitioning information, but it does not overwrite the entire addressable storage area. The data inside the former partitions may therefore still remain available for recovery.

clean all, by contrast, writes zeros to every sector exposed by the disk. Once the previous sector contents have been overwritten, conventional sector-level recovery of those contents is no longer possible.

Before performing data recovery on a real device, the safest approach is to stop writing to it and create a sector-by-sector image whenever possible.

Why VeraCrypt recovery is different

A VeraCrypt volume does not expose the filesystem until its volume header has been successfully decrypted.

That means a recovery application cannot meaningfully interpret the NTFS, exFAT, FAT, or other filesystem inside the encrypted area before the encryption layer has been unlocked.

You therefore need two things:

1. The encrypted volume or enough information to reconstruct its boundaries
2. The correct authentication data

Depending on how the VeraCrypt volume was created, this may include:

• a password;
• a non-default PIM;
• one or more keyfiles.

A VeraCrypt keyfile is not simply a second password. Its contents are processed together with the password when deriving the information required to unlock the volume.

Similarly, PIM affects VeraCrypt's key derivation process. If a custom PIM was specified when the volume was created, the same value is normally required when opening it.

Scenario 1: Recovering deleted files from a VeraCrypt container

The first test used a file-hosted VeraCrypt container.

Several files were copied into the mounted container and then deleted. After unmounting it, we attempted to analyze the filesystem inside the encrypted container directly from the recovery application.

The first step was to add the container as a disk image / RAW disk.

Then the encrypted volume could be unlocked.

The test container used three authentication components:

password + PIM + keyfile

All of them had to be supplied before the encrypted volume could be opened.

Once the volume header was successfully decrypted, the situation changed significantly.

Instead of seeing an opaque block of encrypted sectors, the recovery application could expose the filesystem contained inside the VeraCrypt volume.

At this point, the workflow became essentially the same as ordinary filesystem recovery.

For recently deleted files, we started with a quick filesystem scan.

If the required files are not found, or if filesystem metadata is damaged, a deeper analysis can be performed.

The important point is that filesystem scanning happens after VeraCrypt has been unlocked, not before.

Scenario 2: Standard and hidden VeraCrypt volumes

The second test was more interesting.

The USB drive contained an outer standard VeraCrypt volume and a hidden volume inside it.

A hidden VeraCrypt volume is deliberately designed so that its existence cannot be determined simply by examining the encrypted data.

Unused space inside a VeraCrypt volume already appears as random data. The encrypted hidden volume is stored inside that area, so without the correct credentials there is no obvious structure saying:

"A hidden filesystem starts here."

Instead, the password determines which volume VeraCrypt attempts to open.

When the password for the outer volume is supplied, the outer filesystem is opened.

When the hidden-volume credentials are supplied, VeraCrypt attempts to decrypt the reserved hidden-volume header area. If decryption succeeds, the header provides the size and location of the hidden volume, allowing its filesystem to be exposed.

For recovery, we therefore treated them as two separate targets.

First, the standard volume was unlocked and scanned.

After examining its files, we returned to the encrypted device and unlocked it again using the credentials for the hidden volume.

The result was a different logical volume with its own filesystem, directory tree, and files.

This leads to an important recovery rule:

Finding and unlocking the outer VeraCrypt volume does not mean that a hidden volume has also been analyzed.

If a hidden volume is known to exist, it must be opened using its own credentials and analyzed independently.

Scenario 3: The VeraCrypt partition was deleted

The third test simulated a more destructive user error.

We ran the Windows DiskPart clean command against the USB device.

Afterward, Windows Disk Management showed the flash drive as unallocated.

This is where encrypted storage creates an interesting recovery problem.

On an ordinary partition, a recovery tool can often search for recognizable filesystem structures and use them to determine where the lost volume begins.

A VeraCrypt volume is different.

Encrypted sectors are intentionally indistinguishable from random data. There may be no conventional NTFS or exFAT boot sector visible at the original partition boundary because that filesystem exists inside the encrypted volume.

So before filesystem recovery can begin, the lost encrypted volume itself has to be addressed.

In our test we knew the original partition layout, so we manually reconstructed the expected partition boundaries.

In our test, we reconstructed the partition beginning at sector 2048, corresponding to a 1 MiB offset with 512-byte logical sectors. This is a common partition alignment, but it should not be assumed for every disk.

Knowing the correct start offset is critical. Unlike an ordinary filesystem partition, a VeraCrypt volume does not expose a recognizable filesystem signature while it remains encrypted. If the original partition boundaries are unknown, determining the correct start and size can be one of the most difficult parts of the recovery process.

This created a virtual representation of the original partition without writing a new partition table to the source drive.

We then attempted to unlock that virtual partition using the original VeraCrypt credentials.

When the volume header decrypted successfully, the filesystem inside the previously "lost" partition became accessible again.

From that point, the filesystem could be scanned for both existing and deleted files.

The hidden volume could also be opened separately using its own password.

Watch the complete test

The video below shows all three scenarios, including the VeraCrypt container, the standard and hidden volumes, and recovery after the partition table was removed.

What the tests demonstrate

The most useful conclusion from these tests is that VeraCrypt recovery should be considered a layered problem.

You are not initially recovering files.

You are first trying to restore access to the storage layer that contains the filesystem.

The sequence is roughly:

Physical disk / image / container
            ↓
Find or reconstruct encrypted volume
            ↓
Decrypt VeraCrypt volume header
            ↓
Expose decrypted logical volume
            ↓
Detect filesystem
            ↓
Analyze filesystem metadata
            ↓
Locate existing and deleted files
            ↓
Recover files to another device

Final thoughts

VeraCrypt adds another layer to data recovery, but it does not fundamentally change what happens inside the encrypted filesystem.

The critical difference is the order of operations.

First, the encrypted volume must be located or reconstructed.

Second, its header must be decrypted using the correct credentials.

Only then can the filesystem inside it be analyzed for deleted or damaged data.

The three scenarios we tested — deleted files inside a container, standard and hidden volumes, and a deleted encrypted partition — all follow this same model.

For me, the most interesting case was the deleted partition because it demonstrates why encrypted volumes have to be approached differently from ordinary filesystem partitions: there may be very little recognizable structure available until the encryption layer has been successfully opened.

If you work with VeraCrypt, disk forensics, or data recovery, I'd be interested to hear about other failure scenarios worth reproducing in the lab.