Hello Reader,
This was a fun challenge, the clue here really was the specific version of OSX I referenced, 10.8 which added a new feature called 'Revert to Last Save' featured here: https://www.apple.com/osx/whats-new/features.html under Auto Save and detailed in the Apple support article here: https://support.apple.com/kb/HT4753. While there have been some interesting security writeups on this artifact we haven't found much forensic writeup on this feature.
If you watched the Forensic Lunch on friday we even talked about this feature at the end of it. Of the submissions I received only one person clued into this feature and that was Dave Pawlak who submitted a very nice writeup that I'm attaching in this post.
The Challenge:
Your suspect is running OSX 10.8 Mountain Lion, he has wiped a document from his system that you know was downloaded from his google drive that by his internet history name appears to be related to a business plan and ends with a iWork extension. Based on the recent items plists it would appear as though this document was edited on this system but there is no time machine backups.
What can you do recover any of the contents of this wiped document?
The Winning Answer:
Dave Pawlak
@meatball4rensix
Here is the text of his answer:
Solution:
More recent versions of Mac OS X have a document revision directory which can be very significant to investigations. The reason for their significance is not only due to the fact some document details can be recovered but because snapshots of documents are taken which can later be individually reviewed to allow the investigator a peek into the users mindset.
Using Terminal type sudo sh to enter a privileged user shell. Enter your user password to grant access and follow along.
Change directories to root by typing cd / and pressing return.
To view a listing of hidden files type ls -alF.
We see a hidden directory titled “.DocumentRevisions-V100/”. We know it’s hidden beca
use of the “.” preceding the directory name.
Change directories by typing cd .DocumentRevisions-V100/.
View the files in the directory by typing ls -alF.
The content we are looking for and hoping to find is buried in the PerUID directory. Change directories by typing cd PerUID/. The User ID (UID) relates to OS X security identifier like user ID system. Rather than using the 1000 range of identifiers, Mac OS X assigns the first user the number 501.
Note: If there was more than one user account on the particular Mac OS X installation who has edited and saved a document expect to see more than one UID listed here. My box currently has only one installed user account thus only one UID is present. You can check the users on a Mac OS X system by entering a sudo shell and navigating to /private/var/db/dslocal/nodes/Default/users.
Change directories into the correct UID. In this example we’ll use 501. Type cd 501/ then press enter. Type ls -alF to review the directory contents.
Here we see a number of files by changing the command to include a pipe through sort option by typing | sort we can arrange the output to be in some relative order.
Change directories to 13/ by typing cd 13/ and pressing enter. List the directory contents and find the com.apple.documentVersions/ directory.
Change directories to com.apple.documentVersions/. List the directory contents and see the file identified with a unique identifier containing a “.pages” file extension which is a
n iWork file extension.
Type open C03FD46F-0D9B-4440-81C5-89AD9EF7F70A.pages-tef/
Additionally, using the GUI you can navigate to:~/Library/Mobile Documents/com~apple~Pages/Documents or /iWork Previews
It’s possible the user has his/her iWork documents set to backup to iCloud. In which case these locations may be fruitful. In this case, a thumb from the iCloud interface could be located. Clicking the file and pressing the spacebar to activate the quick look feature reveals the iCloud thumb.
You might also try carving for Apple Pages documents if it really came down to it. Look for the file header “PK” which is /x50/x4B/x03/x04/x14/x00/x00/x00/x00/x00
The footer changes but it appears from limited testing the footer is “index.xmlPK” which is /x69/x6E/x64/x65/x78/x2E/x78/x6D/x6C/x50/4B followed by 14 bytes which are variable in value before the end of the file.
Great work Dave! There is more here to know involving how to use the Sqlite db maintained by 'Versions' to match clusters stored to generational documents and we will talk about it during this weeks Forensic Lunch and in future blog posts!
Also Read: Daily Blog #91
Post a Comment