Book updates - NukeOnDelete and SysProt AntiRootkit

Now that my book is available, I'll be posting things like updates and errata here in the blog.

As I mentioned before, one of chapters in the book addresses alternative analysis methods, and mentions the use of Mount Image Pro to mount the image as a read-only file system. I see this as a great opportunity for analysis for several different reasons...malware scanning, etc.

One of the things that didn't make it into the Registry Analysis chapter was a Registry key that controls the Recycle Bin. The following key is the one in question:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
\CurrentVersion\Explorer\BitBucket

If there is a value beneath this key named "NukeOnDelete" (DWORD) and the value is set to "1", then the Recycle Bin on the system is effectively disabled. This value isn't there by default, it must be added.

So how would we use this information in our analysis? Well, first off, just the fact that the value was added may indicate that (a) the user is sophisticated, or that (b) the user has used one of the privacy tools available on the Internet (we can correlate this to other data, as well).

Next, notice that the key is in the HKEY_LOCAL_MACHINE hive, meaning that it applies to the entire system, rather than just a single user. This doesn't mean that you should expect to see the Recycle Bin for each user (in the case of more than one user) empty, with a really small INFO2 (my book includes code for parsing the INFO2 file) file. Had the value been set after a user had sent files to their Recycle Bin, that INFO2 file should still contain the entries. We can then corrrelate those dates and times with the LastWrite time on the Registry key to determine approximately when the key was modified.

Okay, so does disabling the Recycle Bin slow down a forensic examiner? Not any more! We all know that deleted files aren't really gone.

Another update that I need to add for Chapter 7, Rootkits and Rootkit Detection is SysProt AntiRootkit. This one wasn't out before the book/chapter went to production, so I didn't have time to add it, but it's definitely worth looking at and adding to your toolkit.

One of the core concepts of my book is that by understanding how artifacts are created and modified, we see that the absence of an artifact where we expect to see one is, in itself, an artifact. Checking for this value and then correlating what you find to other findings on the system will provide clues not only to what happened on the system and when, but also to the technical sophistication of the user.

One final word...the book includes a DVD that contains an updated copy of my Registry spreadsheet, which contains several worksheets that list Registry keys and values of interest, why they are interesting for forensic analyists, and references to their function (where applicable). Be sure to add this one to your copy of the spreadsheet.