Shift-delete of top level folders.
There's no artifact to prove/disprove - gonna have to water-board.
In my opinion, there is no other reasonable explanation other than the computer user intentionally shift-deleting top level folders of content and then putting the laptop to sleep.
Shift-delete of top level folders.
There's no artifact to prove/disprove - gonna have to water-board.
In my opinion, there is no other reasonable explanation other than the computer user intentionally shift-deleting top level folders of content and then putting the laptop to sleep.
Hi pbobby
If I could replicate the deletion in windows explorer I would be more comfortable with that explanation. I thought I had but the actual files on the desktop were also deleted including the program shortcuts. The folder structure remained intact on the desktop but the files were deleted.
Not only top level folder contents were deleted either…the delete process went into each folder and subfolder on the desktop and deleted files within them and all in one go. This was not a user browsing around deleting files as they go. We are talking over 3000 files in 51 seconds all from the desktop and subfolders.
To add to this, the delete process skipped a handful of files. About 11 files were skipped in different folders and remained in folders on the desktop after deletion.
I know it is bizarre. I just cant logically put this together in my mind that the User did this….but he might have.
Update
Decompressed the hiberfil.sys file and used Volatility to check for Commands entered through a console shell (cmd.exe) but there were no returns. I confirmed that the computer did hibernate after the incident and checking the process list I can see processes executed before and after the incident but none out of the ordinary.
Please if anyone has any other ideas let me know. What are your feelings here?
So if the machine hibernated after all (it was put into hibernation mode, not sleep) that should give you quite some more valuable information. That's the reason why I specifically asked about this initially.
Now I am wondering how you decompressed hiberfil.sys? Volatility is a great tool for memory analysis by all means, but I am aware of a possible bug in their decompression of hibernation files. Just to rule out that this possible bug has played you a trick, I would strongly suggest you make a decompression (memory reconstruct) with another tool and compare the output file hashes. I am aware of 2 other tools that can do this
Hibernation Recon
Hibr2bin
When you have verified that the decompressed memory reconstruct are good, then you should re-do the analysis in Volatility. Said differently, if the outputs differ, you would rather trust the output of that other tool.
Hi Joakims
Yes the machine slept but then later did hibernate. I tried what you said. I used Hibe2Bin but got the same output. I tried running the same commands using Volatility (cmdscan and consoles) but got nothing at all in the output. Other commands did produce output like plist etc. Any other suggestions? Thanks so much for your time.
There's at least 2 good things
1. You have a complete memory dump that could still have good clues in there. This is a really valuable source of information.
2. You can try to reproduce the situation and draw some conclusions from there. Try running such delete commands as suggested earlier, then put machine to sleep and then later to hibernation mode, and finally analyze in Volatility. What do you find now?