Here is the scenario
Looking at the dd image of an NTFS Windows 2003 server data drive. Pissed off user resigned and deleted their folder before leaving. Should be a simple recovery right? Not.
When I look at any file in their directory in the hex view the file is just zeros. All the expected files are seen by FTK, they are just full of zeros. No headers nothing.
If I recover any of the files I get files of various sizes full of zeros. Export a Word document, I get a file that opens in Word with pages of zeros. Not gibberish, just zeros.
If this was on the users local computer I would say the file was wiped but the entry in the MFT remained pointing to the file. I do not believe I have seen a file wiped like this on a server without local a local admin being involved.
Even if I run Data Carving function it does not return any of the files from the user's folder.
Thoughts or theories?
Check in the list of programs for something like PGP Desktop, Eraser, CCleaner or another application that has the ability to wipe unallocated or securely 'shred' files?
Check in the list of programs for something like PGP Desktop, Eraser, CCleaner or another application that has the ability to wipe unallocated or securely 'shred' files?
Nothing like that on the server. And from what I have see most of those programs write random data not just zeros. Plus if you are shredding a file most of the wiping programs remove the MFT entries as well. I am still waiting on the users computer to check it for wiping programs.
I have not experimented with wiping files on a mapped drive or UNC, but would think that random data is more likely to be seen than zeros. Also, my impressions is that the user is not savvy enough to use dd to write zeros to the remote folder.
Thinking out loud (some might think too loud 😉 ) - given the scenario, is it possible that said users account was removed from the server at the time of his departure and that perhaps some operation that happened at this point, on the server, by the administrative user caused what you are seeing ? There is the option of "deleting user files" when removing a user - I don't know what effect this would have in such a server environment.
Oh and … no backups ? 😉
Thinking out loud (some might think too loud 😉 ) - given the scenario, is it possible that said users account was removed from the server at the time of his departure and that perhaps some operation that happened at this point, on the server, by the administrative user caused what you are seeing ? There is the option of "deleting user files" when removing a user - I don't know what effect this would have in such a server environment.
Oh and … no backups ? 😉
User account was not disabled or removed (although at the very least it should have been disabled). Backups??? lol. Client, "Well we thought we were backing up to tape every night." Guess not. But that's why we all have jobs.
Have you looked at other files in the case recently? I've seen FTK seem to forget where the image is located. The case will still load and open. All the lists are populated, but there is no data, just zeroes.
Reloading the case will sometimes solve the problem. Other times it requires restoring a backup of the case. Still other times the backup case won't even work and it requires the entire case be reloaded.
Oh joy, yet another FTK failure mode I've thankfully not run into yet. Good to know about it in advance.
-David
Have you looked at other files in the case recently?
The only files that are zeroed are the files in the "suspect" directory. Other files appear correctly, even the deleted files (ie viewed in hex I at least see the headers). The other oddity is that all the files have what seems to be a reasonable logical size based on file type.
On a side note, I have had issues where the entire case crashes in FTK and has to be restored from backup and re-indexed, certainly a time consuming PITA. But hey 2.0 is so much better. Right???
Greetings,
FTK crashes.
<Access Data> - Oh, turn off carving.
FTK crashes
<Access Data> - Turn off everything.
FTK crashes
<Access Data> - Oh, there's a bad file in there, tell FTK to skip it.
Each of these runs takes a minimum of 8 hours to get through, tying up the analysis workstation in the process.
And 2.0? Yea, right.
-David
Just a quick update After a little further digging based on further examination of the drive the client admitted that they had their "regular" IT guy try to recover the data to the C drive on the server. I started examining that drive and found the recovery folder which contains some of the files and folders the IT guy tried to recover. What a mess. I have not found the program he used but it mangled the recovered files. Nothing that was "recovered" is usable.
Why do we never get the whole story to start with? Arrrrrg.