Generating SAM dumps from an external HDD

[Abyssion]

Hey guys,

Given that this is a bit of a grey area, and knowing that this forum is against any kind of malicious cracking, I shall let you know the situation.

I took the hard drive out of my old laptop the other day and connected it via a HDD enclosure to my current machine. I was looking for some files on the drive that contain sensitive information. However, it turns out that I had encrypted the files using Windows EFS, which utilises a key derived from the user password in the (symetrical, I presume) encryption process.

As such, I am trying to generate a dump of the NTLM hashes stored on the disk in the SAM file. I am not looking to crack the hashes, and I have no interest in software which is able to do so, because I've narrowed the possible user password down to a list of 7 or so potential candidates. The plan is to use online tools to generate NTLM hashes of these possible passwords and compare it to the hashes stored in the SAM hive. So technically, I'm not looking to crack anything. Hopefully you guys believe me when I say I am trying to access my own data!

The issue that I'm having is that most SAM-dumping utilities perform a local dump on a live operating system. I've copied the SAM from the external HDD over to my current laptop and it is now sitting on my desktop. However, I can't find any utilities that are able to dump NTLM hashes from a non-local SAM file (i.e. one that isn't in system32). I would've thought that dumping from a live OS would be more difficult and that the number of tools available for dumping from an "external" file would be plentiful. As I say though, I've looked around and I can't seem to find a tool to suit my needs.

If anyone knows of any applications that can achieve this (preferably portable,) then please do give us a shout! Once a dump is generated and the password is found by comparison with hashes of my potential passwords, the plan is to change my user password on my current machine to that password to access the files. (Will this work? Short of that, is it perhaps possible to supply LSA with a custom password for decryption of DPAPI blobs as opposed to it defaulting to the current user's password?)

Many thanks for your time,
It's always appreciated!

Abyssion

EDIT: Oh, if anyone is feeling helpful, but doesn't want to suggest tools that could be used nefariously in a public place, feel free to P.M. me. Thank you!

[Elkvis]

In any good security-minded system, passwords are hashed with a salt. It's highly probable that Microsoft does this with Windows passwords. So even if you know the password and the hash generated from it, it's very likely that changing your password to the "correct" one will not achieve the results you desire.

[Abyssion]

Many thanks for the reply, Elkvis.

A salt was indeed something that I considered previously; I thought that perhaps a salt unique to each OS license would be appended to the passwords prior to the hash. However, looking into it, one of the most popular programs available for actually cracking the hashes (Ophcrack (feel free to remove that, Admins)) claims to do so efficiently by using rainbow tables. This must surely mean that unique salts are not used during the hashing procedure. Perhaps salts unique to each generation of operating system or to specific service packs are used, but then, in addition to a greater chance of my current system using the same salt as my old system (both ran Windows 7), the salt itself must be stored in a consistent location and would hopefully therefore be easy to locate and (very temporarily,) replace.

Did that make some sort of sense?
Cheers.

[jdragyn]

I have had to do something similar when my old laptop died. I did not use encryption though, so it may not be applicable here if Windows EFS uses the hardware to generate the key somehow? Anyways, I just plugged the drive into another computer as the only drive and booted (I only had one SATA cable or I would have just slaved it). It wouldn't boot into Windows at first and took a bit of work to get the drivers needed, and when I finally did get it working enough for video to display it complained about Windows not being genuine (I assumed because the laptop had an OEM licence, so the new motherboard it saw wasn't kosher). I was able to offload my data to a thumb drive with this.

However, if that works for you then you can just log in and there's no fussing with breaking the encryption or anything.

[Abyssion]

jdragyn, many thanks for your reply! This is certainly one of the more elegant options available and I appreciate the suggestion; I may put some work into it and see how far we can get. I did, initially, try to boot from the drive when I first removed it from my old machine but I was informed that, for one reason or another (probably hardware differences, ala your situation), the new machine just couldn't boot from the old drive. At the time, I was only trying to boot from it to see if it was actually bootable; I didn't really have any immediate use for it. As such, I gave up trying to boot from it, copied every file and folder on the drive into a new folder (as a rudimentary "backup") and continued to use the drive as an external storage device. However, from reading your post, I now regret this; I thought that overcoming such boot problems on a new machine would prove impossible, whereas you were able to accomplish it. (Kudos!)

So I guess now my question is "would it be possible to recommission my old drive as bootable for a new machine, even given that I have altered the filesystem somewhat?" My initial (very theoretical) approach pertains to partitioning the drive in such a way that it's original content comprises the primary Windows partition. Then I'd go ahead and try to alter the partition (specifically, it's drivers,) (similar to the process that you mentioned performing above to boot from an old drive,) to try to get things up and running. Then, as you say, login and access files etc.

Does this sound like a reasonable approach, or have I totally fluffed everything up by using the device as an external storage medium?
Whilst I have altered the filesystem as a whole, after I moved the original contents of the disk into a new folder, I haven't touched or changed it. (Well, I've read the contents of the folder, but I have never written to it.)

Thanks again jdragyn, your post was very helpful!

EDIT: Oh, and I'm pretty sure that NTLM hash generation is entirely software based, although someone with more knowledge of Windows systems may be able to correct me on that.

[Elkvis]

Did you try booting up in safe mode? That usually bypasses non-standard drivers, and just about any installed windows operating system will boot up in safe mode on just about any hardware, so long as it meets the system requirements.

[jdragyn]

How do you mean you "altered the filesystem somewhat"? If you only copied the files to a different drive without actually modifying files on that old HD then your file-system should still be intact and useful. If you added additional files then you're probably still ok, but if you modified files that Windows used for system files, you may be out of luck.

Attempting to boot from that hard drive would not necessarily cause problems. It would appear to that Windows installation that the boot process simply failed, no different from if your old laptop was interrupted in the midst of booting up.

Assuming you did not damage the windows system, try booting from that drive and going into Safe Mode, or make a Virtual Drive Image from it and use a Virtual Machine to avoid monkeying around inside the new computer. You might even find someone in the Virtual Machine's Forums that tried to do something similar.

[Abyssion]

Sorry for the late response; I have been swamped for the past few days.

I shall try booting in safe mode from the old drive, thanks for the suggestion Elkvis.
See, I always thought the term "filesystem" referred to the formatting of the entire contents of a drive. As I say, the only thing I did with the initial contents of the drive was to move them (i.e. copy/paste) to a new folder in the root of the drive. Then I added other directories to the root of the drive, alongside the original OS installation. So the actual operating system's "Windows" directory is unchanged. The virtual machine thing is a very good idea. To follow up, I shall copy the original contents of the drive back into it's root and remove the extra directories that I stored on there, leaving the drive in exactly the same state it was in when it was removed. Then I shall try both the safe mode idea and, failing that, the drive image idea.

Many thanks for the help; I shall let you know how it goes!