Friday, February 22, 2008

Bypassing a Windows login password in order to boot in a virtual machine

I have seen several recent posts on the forensic list servers asking about how to get by a Windows logon password in order to boot an image in a VMware machine. Normally the approach I would take is to extract the SAM and the SYSTEM registry hive and then use a tool to load rainbow tables and try and obtain the password. If there is no Lanman password in the SAM file, this can put a serious dent in my plan because I currently don't have any large NT rainbow tables to use.

As a refresher, Windows 2000/XP/2k3 stores two hashes of a user's password by default. The first is the weak Lanman hash and then the second is the stronger NT hash. It is the Lanman hash that most rainbow tables are built for because of their inherent weakness and how they are stored, they are the quickest to attack. Windows Vista does not store the Lanman hash, only the NT hash. Windows 2000/XP/2003 will only store a Lanman password if the password is < 15 characters. So if a user sets a password greater than 14 characters, no Lanman hash is stored. In addition, there is a security policy that can be changed to stop storing the Lanman hashes even with passwords of any length. Many people use Nordahl's password recovery boot disk to either change or blank out a password. This technique works very well and I have used it many times.

I discovered two additional ways to get around passwords when the passwords are either too difficult for rainbow tables or when there is only a LM password and a brute-force attack will take too long. The techniques I am going to describe will not recover the password. It will merely let you login to the system with a specific user account. Getting access to the system using these techniques will not let you access any files that are protected via EFS in Windows XP or Vista since the password is used as part of the encryption/decryption process.

The first technique is embarrassingly easy and simply involves deleting the SAM file. In seems that in Windows 2000/XP/2003, if you simply delete the SAM file a new one is created upon boot with only the two normal built-in Administrator and Guest accounts, neither with a password. A variation to this is to simply rename the original SAM file and replace it with the one that is in the repair (2000/XP/2K3) or regback (Vista) folder. This copy of the SAM is from when the system was originally installed and the user accounts that were present at that time may not have had any passwords set. You could also try and use the ones from the various Restore Point captures to see if there is a capture of a time when no password was set for a specific user and then use that SAM file to boot.

The second technique simply involves faking Windows out. To do this, you open the SAM file up with a hex editor and find the data that represents the V file for the particular user account in the SAM file that you want access to. There is a data field in that data structure that represents or indicates if a password is set. Normally it have a value of 0x14 if a password is set. Simply change that value to 0x4 and then boot the machine. Even though there is a password hash present, it will login with no password entered. I have used this technique with Windows 2000, XP & Vista and it works well. I have encountered a few instances where the flag that indicated if a password is present (0x14) already had the value of (0x04). I am not sure if the SAM.log or transaction log changed the changes and used values stored elsewhere when the system was running to determine if a password was set, but the above technique will obviously not work in that situation.

In that case, I have been able to take a password hash from another user account that I was able to either crack or is blank and then "transplant it" into the V record of the account I want access to. By doing this, you are effectively swapping the password hash with a know password hash.

In the screenshot above the one-byte highlighted values of 0x14 are the length indicators representing that the lanman is 20 bytes in length and the NT is also 20 bytes in length. To bypass, simply change these to 0x4 with a hex editor. The highlighted data at the bottom of the screenshot is the Lanman and NT password hashes.

I need to do some more testing on all the various versions but to date, this has worked for me everytime without a problem.

An excellent resource for learning the data structure of the SAM file can be found here.

Here is a general guidline on how to determine if a password is set from inside EnCase:

1. A user in Windows has potentially two password hashes that are stored
(only one password, but two different hashes are generated). The lanman
hash and the NTLMv2 hash. Lanman is legacy and not always stored based
on either the local security policy or the domain policy (or registry

2. The "V" key in the SAM registry hive under the user's SID is where
the password is stored (remember that this is not a straight hash of the
users password, but rather a DES encrypted version, encrypted again
using the SYSKEY).

3. Starting from the very beginning of the V key, sweep 156 bytes. The
next 4 are the offset to where the lanman hash is stored in the V key
relative to a constant offset of 204. So for example if you look at
offset 156 and there is 64 01 00 00, which equals 356 in decimal, you
would add 356 + 204 = 560. Then, make note of the next 4 bytes (starting
at offset 160, which will either be 04 00 00 00, or 14 00 00 00). This
represents the length of the hash that is stored including a 4 byte
header. If the size is "4" then just the header is present and no hash
is stored (i.e. no password). If the length is "14" (20 decimal) then a
hash is stored, as well as the header (4 byte header, 16 byte hash) =

4. Then from the beginning of the V key, go 560 bytes (the sum of the
length + the 204 constant) and the next four bytes are the header (I
have seen 01 00 01 00 & 02 00 01 00 as headers) then the next 16 are the
lanman password hash, if present.

5. For the NTLM hash, start at the beginning of the V file again and
sweep 168 bytes. The next four are the offset to where the NTLM hash is
relative to offset 204 and then the next four are the length. Same rules
apply as above. If the length is "4" then no NTLM hash is stored and
only the header is present. If the length is "14", then there is a 16
byte password hash and a 4 byte header present. You would follow the
same procedure as step 3 above and take whatever value is at offset 168
+ constant of 204 = the offset to where the NTLM hash begins (actually
the header begins, then the hash)."

Good luck!


Anonymous Friday, 22 February, 2008  

Awesome stuff as usual. Thanks for the link to 'beginningtoseethelight', I have never seen this before.


Jeff Saturday, 15 March, 2008  

Long time e-stalker, first-time poster...

Utilizing the second method you described - telling Windows that no password is set for a given account - will this method disallow you from accessing the protected storage when doing a live boot? I know that blanking the password value would have this effect, but I'm curious what would happen if the password hash remains and you use a utility to dump the protected storage.

Thanks! And great blog, BTW.


Lance Mueller Sunday, 16 March, 2008  


I knew I felt a presence in the darkness ;)

That's a good question. I have never had the need to get access to protected storage this way so I have not tested it, but it would be a simple thing to test. As soon as I get a little time to test, I will post the results.

Anonymous Friday, 28 March, 2008  

Another (simple) way to get around user authentication is to use Dreampack :

To make it even more convenient there's a plugin to use it with BartPE.

Works flawless with XP, haven't tried it with VISTA yet...

Lance Mueller Tuesday, 15 April, 2008  

I did some followup testing on this and found that when there are encrypted files using the EFS feature, and a password is set on the user account, you can use the technique I described to bypass the password and you can STILL GET ACCESS to the encrypted files!

Anonymous Tuesday, 06 May, 2008  

you CANNOT access EFS encrypted files on XP and Vista if you hex edit the SAM and do the 0x14 to 0x04 SAM conversion trick.

Lance Mueller Tuesday, 06 May, 2008  


That is a very *strong* statement, and not entirely true. I have tested this and there are a couple of conditions that exist that allow you to access the EFS data using the techniques I described, and then ther are some conditions in which you can't.

I had not yet updated the blog to include them since I discovered them after my intial comment about being able to access EFS data.

You are correct that if a user has a password set and then encrypts some data using EFS then using the above technique does not give you access to the EFS data.

You are incorrect that if a user does not initialy have a password set then encrypts some data, then sets a password, the above technique will work.

Thanks for your comments

Lance Mueller Tuesday, 06 May, 2008

Anonymous Wednesday, 10 June, 2009  

This was a pleasure to read. Thank You!

Tauqeer Thursday, 23 July, 2009  

Thanks you very much for this useful information.
Please keep on blogging.
I am looking forward to read your next great article.SEO

digital investigator dude Wednesday, 27 June, 2012  

If the virtual machine is from a dd image of domain computer can these techniques even work considering that hashes are not stored in the sam for active directory users?

digital investigator dude Wednesday, 27 June, 2012  

If the virtual machine is from a dd image of domain computer can these techniques even work considering that hashes are not stored in the sam for active directory users?

DigiGeek Wednesday, 08 August, 2012  

I was really looking for this...GREAT.

00000000: 54 68 61 6E 6B 73

Post a Comment

Computer Forensics, Malware Analysis & Digital Investigations

Random Articles