19

I've exploited test machines using metasploit and was able to get the hashes from the SAM file; I've tried running commands as SYSTEM to get them but am unable to do so. What is a more portable method to extract the hashes from the SAM file?

5 Answers 5

17

There is a simpler solution which doesn't need to manage shadow volumes or use external tools. You can simply copy SAM and SYSTEM with the reg command provided by microsoft (tested on Windows 7 and Windows Server 2008):

reg save hklm\sam c:\sam
reg save hklm\system c:\system

(the last parameter is the location where you want to copy the file)


You can then extract the hashes on a Linux system with package samdump2 (available on Debian: apt-get install samdump2):

$ samdump2 system sam
Administrator:500:aad3b435b51404eeaad3b435b51404ee:c0e2874fb130015aec4070975e2c6071:::
*disabled* Guest:501:aad3b435b51404eeaad3b435b51404ee:d0c0896b73e0d1316aeccf93159d7ec0:::
2
  • which windows flavors does this work on (or rather which does it not)? tried to tell from MSDN website but it doesnt list it (at least i didnt see it)
    – n00b
    Dec 21, 2018 at 17:13
  • 1
    this just dumps local accounts. to get cached domain creds you need to get SECURITY from the registry too. then you can run: python /usr/share/doc/python-impacket/examples/secretsdump.py -sam SAM -security SECURITY -system SYSTEM LOCAL to dump all cached creds.
    – n00b
    Dec 21, 2018 at 17:54
14

It's not a permission issue – Windows keeps an exclusive lock on the SAM file (which, as far as I know, is standard behavior for loaded registry hives), so it is impossible for any other process to open it.

However, recent Windows versions have a feature called "Volume Shadow Copy", which is designed to create read-only snapshots of the entire volume, mostly for backups. The file locks are there to ensure data consistency, so they are unnecessary if a snapshot of the entire filesystem is made. This means that it is possible to create a snapshot of C:, mount it, copy your SAM file, then discard the snapshot.

How exactly to do this depends on your Windows version: XP needs an external program, Vista and 7 have vssadmin create shadow, and Server 2008 has the diskshadow command. The page Safely Dumping Hashes from Live Domain Controllers has more details on this process, as well as instructions and scripts.

Alternatively, there are tools such as samdump which abuse the LSASS process from various directions in order to extract all password hashes directly from memory. They might be much faster than VSS snapshots, but have a higher risk of crashing the system.

Finally, Google brings out this snippet, whose usefulness I cannot rate having never used metasploit myself:

meterpreter> use priv
meterpreter> hashdump
2
  • What's the difference between the SAM\SYSTEM files and the SAM\SYSTEM registry subkeys (I'm referring to vmarquet's answer)? Are the contents the same? Feb 24, 2020 at 10:00
  • 1
    Yes, those files are actually where the registry database is stored – the file "SYSTEM" holds the data of HKLM\SYSTEM. (I mean, it has to be stored in some file somewhere, does it not?) You can look at HKLM\SYSTEM\CurrentControlSet\Control\HiveList to see which subkeys correspond to which files. Feb 24, 2020 at 10:16
6

Edit: I decided to edit after many years of abandonment.


The Windows SAM file is locked from copying/reading unlike /etc/shadow on Linux systems. Instead, to get around this tools will extract hashes from memory.

There are ways to get around this that I'll cover below:

Mimikatz

Run mimikatz with sekurlsa::logonpasswords.

fgdump

Similar functionality as mimikatz. Run it, and hashes will be dumped to local files.

hashdump

Built into meterpreter; extracts hashes from memory.

Registry

It's also possible to extract from the registry (if you have SYSTEM access):

  1. reg save hklm\sam %tmp%/sam.reg and reg save hklm\system %tmp%/system.reg
  2. Copy the files, and then run: samdump2 system sam

Backups

SAM file can also be stored in a backup location: C:\Windows\Repair\SAM

I should also mention that the tools will at a minimum require Administrator privileges; and most will not get all hashes unless SYSTEM access is attained.

2
  • Maybe I've misunderstood, but in what way are tools like Mimikatz or fgdump any more portable than C&A or different to it? As far as I can tell they're all third party tools that don't come packaged with Windows and need to be loaded separately. Also, for my own curiosity, what's the use case for hash-dumping tools when tools like Ophcrack exist? Oct 11, 2018 at 1:41
  • Can mimikatz be used to crack local hashes on a powered-off system via a bootable disk, or is it only designed to run on a powered-on system? Oct 11, 2018 at 2:11
2

Would like to specify additional method that is not described here, as lots of time in Red Teaming / Penetration Testing the most obvious ways are not accessible (denied, are monitored by Blue Team, etc.) and it's nice to know all available techniques.

One of workaround of accessing files, which system has handles on (cannot copy/remove as usual), is vssshadow.exe told above.

Second - esentutil.exe.

Exact command to take a copy of file with handle:

esentutl.exe /y /vss c:\windows\ntds\ntds.dit /d c:\folder\ntds.dit

This applies to SAM, SYSTEM, SECURITY, NTDS.DIT etc.

P.S. There's esentutl.py in impacket's package: https://github.com/SecureAuthCorp/impacket/blob/master/examples/esentutl.py

P.S.S. esentutl PoC image

0
1

Obscuresec method overcomes your dificulties locally on any windows powershell 1.0 enabled machine. Leaves out some targets i know, but hey, nice job ! (thank you Chris).

Note: Admin privileges are always needed to perform such an operation

You could use

http://gallery.technet.microsoft.com/scriptcenter/Get-PasswordFile-4bee091d

or from another source (more recent i might add)

https://github.com/obscuresec/PowerShell/blob/master/Get-PasswordFile

Advised reading:

For grabbing remote systems SAM and SYSTEM hives use the above mentioned in conjunction with

1
  • Links are broken.
    – e-info128
    Jun 14, 2021 at 1:29

You must log in to answer this question.