During a technical interview, I was told definitively, categorically, unequivocally that it was impossible to recover deleted files from within an encrypted container, even if you possess the key. Windows was the OS of choice, and he insisted that he knew from personal experience as they use encrypted containers. He stated that all the file data would be garbled due to the encryption, so it didn't matter if you recovered it or not; the content would not be readable. File wiping was not part of the equation (I asked). This did not sit quite right with me, but I was in the middle of an interview and did not already know the answer, as I had not ever encountered that type of situation. I expressed surprise that that would be the case, but left it at that.
My thoughts:
Pondering it over on the way home, more and more it just didn't make sense to me. If they're created on the file system, the files themselves are not encrypted; the container is encrypted. It has to be mounted in order to access the files. When a file is deleted, the container is mounted and the file is in a readable state. Therefore it should exist in a readable state. If the container is deleted, that's a different matter, although it is feasible that the container could be recovered. All you should have to do is mount the encrypted container, and search within it for the file, which would still exist until overwritten.
I determined to test my theory as soon as possible. Of course, that took a little longer than I initially wanted, as I was “side-tracked” by continuing Dropbox research. However, I outlined a plan, and recently sat down to work through it. Initially, I thought of looking to the host file system, as the OS would provide access to the files through the encrypted container. As I continued the thought process and began testing, I realized this would not be exactly true.
The host OS' file system (ie, MFT) would not reference these files, as they only exist inside the container. The container has its own file system (and MFT), which would be the home for the files' information (and possibly the files themselves, if they were small enough to be resident. Then of course, there's unallocated space. The host OS' could potentially have residue in places like the pagefile or memory, but that should be it.
Now, I don't know what type of encryption they use, but I'm thinking in the end, an encrypted container is going to work the same, regardless of flavor. If I'm wrong, well, then the following is true at least for Truecrypt 7.0a. I approached this research from the standpoint that the files would have been created directly in the container, rather than on the host file system and subsequently moved into the container. Had it been the other way around, there could be artifacts or residue left on the host. I also assumed a fixed container size; with dynamic, the process might end up being a bit more complex.
The process:
The basic idea I had was to create some files inside an encrypted container. Confirm they existed there methodologically, confirm they weren't on the host file system. Then remove/delete them from the container, and try to identify their remains, attempt recovery. So here's the basic outline of my steps and actions; I've tried to retain some order to it and hope it makes sense:
1. Create a 500MB TrueCrypt container.
As a side note, I did this inside Dropbox and had no difficulty; some people have had trouble, and I think it might be related to creating a dynamic container, rather than fixed-size.
2. Create four (4) text files inside the container, filling with specific text from Altheide & Carvey's excellent Digital Forensics With Open Source Tools, since I had just read that.
3. Confirm files' association to host file system
a. Without mounting the container, extracted host system MFT using FTK Imager, mounted with Sanderson Forensics MFTView, exported to XLS & TXT, and searched for filenames. None present, as anticipated.
b. With container mounted, extracted host system MFT, mounted, exported and searched. Still nothing.
4. Confirm files' association to container file system
a. With container mounted, extracted logical drive's MFT (ie, for the container), exported, and searched. Files were identified, as anticipated.
b. As these files were small enough to be resident in the MFT, all content is visible.
5. Move all 4 files out to new location outside of the container(not securely). Obviously, the container is mounted.
a. Extract logical drive's MFT, mount with MFTView, locate resident files.
b. Viewing the hex/text of the entry in MFTView, was able to recover all 4 files to matching hash value.
6. What about larger files not contained in the MFT?
a. Copy entries.log file (4.23KB) - a Dropbox artifact – into container.
b. MFT contains entry but no contents for non-resident file.
7. Delete files (no wiping) from within mounted container and attempt recovery.
a. Mount logical file system in FTKi.
b. INFO2 file contains list of files.
c. Export "Dt1" etc files w/FTKi, hashes match original.
d. Exported MFT and mount in MFTView. Files are resident at “root” of MFT and in Recycler; fully recoverable from both locations.
As a side note, sometimes MFTView seemed to have difficulty displaying the file contents correctly, and thus the extraction of that data to recover the file would result in a hash not matching. This was did not occur all the time, and was observed to happen whether the file was live or deleted. Obviously, the file contents weren't actually stored that way, so it was some programmatic issue. I don't know whether MFTView is a current application or not, as I don't see it listed on the website any longer. I have not (yet) contacted Sanderson Forensics about it, as I don't think it matters for the purpose of this research. An example is below (first with issue, then normal):
Now back to the process...
8. Search host filesystem for files (pagefile, RAM)
a. Copied files back into container, reboot (this flushes my pagefile), open each file
b. Used FTKi, exported host system pagefile.sys and RAM
c. Ran Sysinternals strings (5-character minimum) and output to text files.
d. Loaded & searched in notepad++. Found all 4 test files' contents, plus large portions of entries.log.
Cut away from the outline for a moment. I re-deleted the files, imaged the logical FS and mounted in ProDiscover Basic to search for the files. Found them as they existed in Recycler, to be expected. I purged Recycler by drilling down, selecting all files and deleting again. Keyword searches in Unallocated space weren't turning up the files, and it finally dawned on me that it was because the files were resident in the MFT, so as long as the entries existed there, they wouldn't show up in Unallocated. I needed larger files across the board. So I copied back in the entries.log file, along with a DOC, XLS, and PDF. Deleted (the PDF was too large and was “permanently deleted”) and re-imaged.
9. Load image, search for files (using ProDiscover)
a. Content search: DOC, XLS, and TXT were in Recycler. PDF was in "Deleted" (too big for Recycler). INFO2 listed filenames. The .~Lock file for the DOC was also in Deleted.
b. Cluster search: Two hits on "SIFT" that appear to be related to a PDF file, and contain the filename.
10. Dig a little further (using ProDiscover)
a. Emptied Recycler (drilled down, selected all files and rt-click delete)
b. Re-imaged w/FTKi, reloaded, and Content search. All files found in "Deleted."
c. Searched Clusters, same PDF hit, found TXT file, possibly DOC/XLS (since binary).
11. Final push
a. Carved image with photorec, using default settings.
b. 4 files were recovered, the PDF, TXT, DOC, and XLS. The TXT file is ~1/2 the size, but since there's no header info, it's pretty incredible anyway. All except the text file hash match to the original.
Summary:
This was a fun little exercise, and I think I can categorically, definitively, unequivocally state that it absolutely is possible to recover deleted files from within an encrypted container when you have the key to the container. Obviously, there are variables. If the container size is dynamic, for instance, this could impact things, but I think the odds are still fairly good, and the process is essentially the same. The amount of time that has passed – as with any investigation – is important, but with close proximity it may even be possible to find the files' content (if previously viewed) in pagefile or RAM.
But the core is that it is possible to recover. Knowing the content and the filenames, I was able to easily recover deleted and purged (but not wiped) files from within an encrypted container. I was also able to carve the files without any use of filenames, contents, or type by an automated process. The process could be done more manually by using Sleuthkit or other utilities. Anyway, it can be done, and that's that.
No comments:
Post a Comment