SAM Cracking using Ophcrack and Encase

EnCase, with the decryption suite is OK at determining the password hashes for user accounts, but only if you have it and only for the currently used SAM/ SYSTEM file pair. PRTK can be used for any pair you want to give it, but takes a few steps to add them and often takes quite a bit longer to crack the passwords. It's certainley not a bad piece of software, but I've managed to set up a virtual machine of a suspect computer, boot it to a live CD of ophcrack and crack the passwords whilst waiting for PRTK, such is the advantage of using rainbow tables. Even so, it's a bit of an effort doing it that way and their Windows based version is just as capable so I now use that.

If I was only interested in the users and passwords at the time the computer was imaged then that would be fine. I'd pick my tool, crack the passwords and off I go. But that's a bit one dimensional. Often I'd want to know if there were any other accounts in use in the past, whether the passwords had always existed or not and what they were. The current SAM/SYSTEM pair just doesn't give me that history.

Thankfully, the Restore Points in the System Volume Information folder hold past pairs of files under the names _REGISTRY_MACHINE_SAM and _REGISTRY_MACHINE_SYSTEM. These can be extracted and cracked just like the current files using your favourite cracking software. If you are blessed with many pairs covering a long period of time, you could have lots of good information but going through the process of extracting them and adding them could take a long time particularly if, like with ophcrack, each pair must be renamed to sam and system. It may even be a fruitless exercise if, as is often the case, there are no changes to accounts or passwords between restore points.

I've written an EnScript that will process selected files for sam/system file pairs, including those from restore points, and send them to ophcrack from within EnCase. It doesn't automatically start the decryption, for a number of reasons:

1. It spawns a new instance of ophcrack for each sam/system pair (which could be a fair few)
2. It's always worth removing the accounts you're not interested in, such as HelpAssistant
3. It's always worth configuring which rainbow tables you'll use (there's no point trying to crack an NT hash when there's an easier LM hash available)

The script requires that the path to the opchcrack exe and the root rainbow tables folder is set and only the SAM file needs selecting (although you could always blue check everything and see how many windows pop up!).


Further info on Restore Points in general can be found at Mandiant's website and Stephen Bunting's page.

Trevor Fairchild has an EnScript to reconstruct the Restore Point and, of course there's plenty of information from Harlan's blog.

Ophcrack Enscript here.

Alternative clock drift calculations

Sometimes knowing the exact time of an event is key to an investigation. Often it isn't (it's all relative after all) but it's always important to check how reliable the times you see, are.

The easiest method is to check the computer clock against a calibrated clock, a GPS clock or radio controlled clock are ideal. If this is done reasonably soon after the 'incident' or seizure of the computer, the difference will give an accurate measure of how much time to add or subtract from the times seen during the analysis. If you don't have the original machine, can't get to the system clock or leave the computer off for an extended period without checking, you may have to work harder.

Firstly a note about what is seen, even when a valid time is obtained.

• Daylight Saving- Remember that the use of daylight saving time may have changed since the computer was last used. This is normally quite obvious with a clock being about an hour out (for many of us), but it's worth checking the date of the last use of the computer to be sure, as other factors may also be in play.
• Type of Operating System- Windows will set the computer clock to the local time so that if DST is applied, the time on the computer will be moved forward an hour. Other OSs can maintain the computer clock in local time or UTC . Dual boot systems would make things trickier still!

Event Logs

The Windows event logs can provide clues as to how accurate the clock is, or was. Stephen Bunting has some information on detecting changes in the clock settings, but it's also possible to show when Windows has synchronised with a time server.

In the System Event log, filter for W32Time as the source and look at event IDs 35 and 37. If the computer is set to automatically update the time and is regularly able to contact the time server, then the clock is likely to be reasonably accurate. The registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time contains more details of the settings.

Yahoo pages

Web pages from Yahoo contain a really handy line at the end of the page source that shows when that page was served. It looks something similar to this:

!-- p18.www.ird.yahoo.com compressed/chunked Wed Apr 17 21:20:10 GMT 2009 --

Whilst understanding that there may be a slight delay between this stamp and the creation of the associated internet history record, this provides a great way of determining the clock offset at this time. Just compare the internet history record, created from the computer's clock with the time stamp, created from the web server and you have your value. If you can compare a number of web pages from around the same time you can start having more confidence by averaging out the slight transmission delays.

Of course this relies on the belief that Yahoo's web servers are accurate (apparently 74% of web servers were within 10s for one study), but if this is combined with time stamps in other webpages (look for unix times, but test their relevance!) and other sources of evidence such as event logs or even good old fashioned witness accounts, you can start to have much more confidence in the times that you are including in your reports even if the case doesn't hinge on a split second degree of accuracy.

I've written a basic EnScript that looks in selected files for the Yahoo time stamp and displays that, along with the created date of the file in the console. It doesn't do anything fancy and the code is probably awful but I'll make it available here (note that it only works in EnCase 6.13 and later).