This document is for people who want to learn to the how and why of password cracking. There is a lot of information being presented and you should read it all before you attempted doing anything documented here. I do my best to provide step by step instructions along with the reasons for doing it this way. Other times I will point to a particular website where you find the information. In those cases someone else has done what I attempting and did a good or great job and I did not want to steal their hard work. These instructions have several excerpts from a combination of posts from pureh@te , granger53 , irongeek , PrairieFire , RaginRob , stasik , and Solar Designer . I would also like to thank each of them and others for the help they have provided me on the BackTrack forum.
I will cover both getting the SAM from inside windows and from the BackTrack CD, DVD, or USB flash drive. The SAM is the Security Accounts Manager database where local usernames and passwords are stored. For legal purposes I am using my own system for this article. The first step is to get a copy of pwdump. You can choose one from http://en.wikipedia.org/wiki/Pwdump.
I used to use pwdump7 to dump my passwords, however I have come across a new utility called fgdump from http://www.foofus.net/fizzgig/fgdump/ This new utility will dump passwords from clients and Active Directory (Windows 2000 and 2003 for sure, not sure about Windows 2008) where pwdump7 only dumps client passwords. I have included a sample hash.txt that has simple passwords and should be cracked very easily.
Some anti-virus software packages flag pwdump* and fgdump as trojan horse programs or some other unwanted program. If necessary, you can add an exclusion for fgdump and/or pwdump to your anti-virus package so it won't flag them. However it is better for the community if you contact your anti-virus vendor and ask them to not flag the tool as a virus/malware/trojan horse.
You can find the latest version of this document at http://www.backtrack-linux.org/
The LM hash is the old style hash used in MS operating systems before NT 3.1. It converts the password to uppercase, null-pads or truncates the password to 14 characters. The password is split into two 7 character halves and uses the DES algorithm. NT 3.1 to XP SP2 supports LM hashes for backward compatibility and is enabled by default. Vista supports LM hashes but is disabled by default. Given the weaknesses in the LM hash it is recommended to disable using LM hashes for all MS operating systems using the steps in http://support.microsoft.com/kb/299656
NTLM was introduced in NT 3.1 and does not convert the password to uppercase, does not break the password
apart, and supports password lengths greater than 14. There are two versions of NTLM v1 and v2. Due to a
weakness in NTLM v1 is should not be used. Microsoft has included support for NTLM v2 for all of its
operating systems either via service pack or the Directory Services client (for windows 9X). You enable
NTLM v2 by following the instructions at http://support.microsoft.com/kb/239869. For maximum security
you should set the
LMCompatibility
to 3 for Windows 9X and
LMCompatibilityLevel
to 5 for NT, 2000, XP,
and 2003. Of course you should test these changes before you put them into a production environment.
If LM hashes are disabled on your system the output of pwdump and/or the 127.0.0.1.pwdump text file will look like:
Administrator:500:NO PASSWORD*********************:00AB1D1285F410C30A83B435F2CA798D:::
Guest:501:NO PASSWORD*********************:31A6CAE0D36AD931B76C59D7E1C039C0:::
HelpAssistant:1000:NO PASSWORD*********************:BF23C2595478A6279F7CB53EF76E601F:::
SUPPORT_3845a0:1002:NO
PASSWORD*********************:0C8D62E10A6240BACD910C8AB295BB79:::
ASPNET:1005:9F07AE96CA4310752BDC083AAC960496:A99C1C3DB39E3C732EF5C2F63579AF96:::
The first field is the username. The second field is the last four numbers of the SID for that username. The SID is a security identifier that is unique to each username. The third field is the LM hash. The forth field is the NTLM hash.
If you do not have a ASPNET user account do not worry about it. If you do have a ASPNET user account do
not change the password as I am told that will break something. What I did was delete the account and then
recreate it using:
%systemroot%\Microsoft.NET\Framework\v1.1.4322\aspnet_regiis.exe /i
To make it more difficult to crack your passwords, use syskey. For more information on syskey see http://support.microsoft.com/kb/310105. The short version is syskey encrypts the SAM. The weakest option but most convenient is to store a system generated password locally; locally means the registry. The up side is the SAM gets encrypted and you can reboot the server remotely without extra equipment. The next option is password startup. This is slightly more difficult to get around, but if you remotely reboot the server, it will stop and wait for someone to enter the password. You will need a KVM over IP or a serial port concentrator so you can enter the password remotely. The most secure option is the system generated password stored on a floppy disk. The downside to this option is floppy disks fail, you misplace the floppy disk, newer equipment does not have a floppy disk drive, no remote reboots, and you will probably leave the floppy in the drive so you can remote reboot and that defeats security. I use a system generated password stored locally, weak but better than not doing it. To disable syskey use chntpw and follow its instructions.
# mount /dev/hda1 /mnt/XXX
mount your windows partition substituting hda1 for whatever your windows partition is
if the syskey password is stored locally you need to extract it from the registry so you can decrypt the
SAM. If syskey is setup to prompt for a password or the password is on a floppy, stop now and read the
syskey documentation in this document for more information about syskey. If you installed windows to
something other
C:\WINDOWS
please substitute the correct path.
the path is case sensitive. The filenames of sam, security, and system are case sensitive. On my system these files are lowercase. I have come across other XP systems where they are uppercase. On the Vista system I have used the filenames are uppercase.
BackTrack 2 users use the following:
# bkhive-linux /mnt/XXX/WINDOWS/system32/config/system syskey.txt
BackTrack 3 users use the following:
# bkhive /mnt/XXX/WINDOWS/system32/config/system syskey.txt
# samdump2 /mnt/XXX/WINDOWS/system32/config/sam syskey.txt >hash.txt
samdump2
will dump the SAM to the screen and the > character redirects the output to a file called
hash.txt
you can also run
samdump2
with the -o parameter to write the output to a file
# samdump2 -o hash.txt /mnt/XXX/WINDOWS/system32/config/sam syskey.txt
Stasik told me it is much easier to crack the NTLM hash if you know the character set. This way you do not need to bruteforce all possible characters combinations. Once you have TESTTEST, feed a custom character set of tesTES to john and it will return the proper case password much faster than if you did not limit the character set. The issue is john has no easy way to limit the character set. You will have to modify the john.conf file and include the following code that Solar Designer has kindly published to the john-users mail list:
[List.External:customcharset] int running; // Are we already running? int last; // Last character position, zero-based int c0, c[0x100]; // Cyclic charset void init() { int length, cm, i; length = 10; // password length c[c0 = 't'] = 'e'; // change the t and the e to the first and second letters of the custom character set c['e'] = 's'; // change the e and the s to the second and third letters of the character set c['s'] = 'T'; // change the s and T to the third and fourth letters c['T'] = 'E'; // etc c['E'] = 'S'; // etc c[cm = 'S'] = c0; // change the S to the last letter of the character set // If you cannot see the pattern then do not bother with this trick. // If you can make the necessary changes to suit you environment. running = 0; last = length - 1; i = 0; while (i < length) word[i++] = cm; word[i] = 0; } void generate() { int i; i = last; while ((word[i] = c[word[i]]) == c0) if (!i--) { if (running++) word = 0; return; } }
Once you make the necessary changes begin cracking using:
# /usr/local/john/john -external=customcharset --format:NT hash.txt
Some notes from Solar Designer :
Being an external mode, this is not the fastest way to generate candidate passwords, although its
performance is acceptable. Some further optimizations are possible (e.g., cache the last character
outside of the
word[] array
). Also, be careful when you edit it (such as for a different charset) - errors
in the way the cyclic charset is defined may result in the "while" loop in generate() becoming endless.
In order to actually crack an NTLM hash with this, you need a build of JtR with support for NTLM hashes. You may do a custom build with the latest jumbo patch (john-1.7.2-all-9.diff.gz), which means that you will need to install Cygwin on your Windows system, or you can download such a build made by someone else (one is linked from the JtR homepage - it is for an older version of the patch, though, so it is many times slower at NTLM hashes).
On a modern system, with a recent jumbo patch, and with the proper "make" target for your system, this should complete its work against an NTLM hash (or against many such hashes) in just a few minutes.