Dump Windows password hashes efficiently - Part 2

[co4ie]

Conclusions on Windows Security Account Manager

In the previous post of this series, I briefly explained what the Windows Security Account Manager (SAM) is, how to dump Windows local users' password hashes from SAM having physical access to the target system or following a remote compromise of the machine, post-exploitation.

Remotely, there exist three possible techniques: legacy, volume shadow copies and in-memory dump. Lastly, I highlighted the most widely used tools for the in-memory hashes dump and I collected and released them in this spread-sheet along with other tools that I will discuss later.

I want to reiterate the following concept: given file transfer ability between your machine and the target system, always prefer to copy the SAM and SECURITY files over from the target and extract the password hashes offline afterwards.

Although, this safe approach to password hashes dump does not guarantee that you are going to obtain all Windows local accounts' hashes. If you suspect that this is case, you will have to dump the hashes via in-memory dump and merge the results. Odd, but I have seen this happening quite a few times already and I am still discussing standalone Windows workstations, not part of a Windows domain.

Preferred tools

Personally, my first choice for standalone SAM hashes dump is pwdump7: it works on all Windows version from 2000 on both 32-bit and 64-bit systems. However, this tool does not perform a real in-memory dump and could miss out hashes. I always run two or three tools to avoid this from happening: fgdump, gsecdump and PWDumpX along with pwdump7 cover both techniques across all Windows versions and architecture and carefully launched once at a time should not crash the LSASS process.

When I have got a Metasploit Meterpreter shell onto the system, I rely on the post-exploitation module smart_hashdump by Carlos Perez, falling back to its predecessor post-exploitation module hashdump when it fails.

Active Directory

Definition from Wikipedia:

Active Directory serves as a central location for network administration and security. It is responsible for authenticating and authorizing all users and computers within a network of Windows domain type, assigning and enforcing security policies for all computers in a network [...] when a user logs into a computer that is part of a Windows domain, it is Active Directory that verifies his or her password [...]

This definition comes into play when you have compromised a system part of a Windows domain. In order to quickly extend your control over the whole domain, the goal is to compromise the root domain controller. If you are within a child domain, the final goal is to achieve Enterprise Domain Administrator level access onto the root domain controller of the Windows forest's parent domain. There are plenty of resources on the Internet discussing domain escalation and this is out of the scope of this post series. A blog post that summarizes the best techniques and goes straight to the point is written by pentestmonkey.net. Alternatively, you can pass the local users' hashes obtained from your entry point machines to keimpx and spray them against the domain controllers: if the system administrator reuses the same local Administrator password across all machines, you are in!

Regardless of how you have compromised a domain controller, preferably the root domain controller as it is the first to get updated with changes to user accounts, the important is that you have got an administrator (local or domain) shell onto it.

Database file NTDS.DIT

The goal now is to dump the domain users' password hashes. These are stored, along with nearly all the information that is accessible in the Active Directory (user objects, groups, membership information, etc), in a binary file, %SystemRoot%\ntds\NTDS.DIT.

This file is locked by the system. You can use the volume shadow copies technique illustrated in the previous post to copy it along with the SYSTEM file over to your machine.

Alternatively, use the ntdsutil snapshot facility introduced in Windows Server 2008. It will create a snapshot of the active directory database allowing you to copy ntds.dit and SYSTEM file. This technique is detailed on a Microsoft TechNet article.

Extract hashes from NTDS.DIT

You can use the passcape's Windows Password Recovery tool to extract hashes from ntds.dit.

Alternatively, you can use a couple of tools (ntds_dump_hash.zip) developed by Csaba Barta and documented in his paper titled Research paper about offline hash dump and forensic analysis of ntds.dit. These tools are used to:

1. Extract the required data from ntds.dit: esedbdumphash.
   
2. Decrypt the hashes and interpreting other information regarding the user account: dsdump.py, dsdumphistory.py, dsuserinfo.py.
   

Download and compile the tool:

   wget http://csababarta.com/downloads/ntds_dump_hash.zip
    unzip ntds_dump_hash.zip
    cd libesedb
    ./configure && make

Use esedbdumphash to extract the datatable from ntds.dit:

    cd esedbtools
    ./esedbdumphash -v -t /tmp/output
    $ ls -1 /tmp/output.export/
    datatable

Use dsdump.py to dump the hashes from the datatable file using the bootkey (SYSKEY) from the SYSTEM hive:

   cd ../../creddump/
    chmod +x *.py
    ./dsuserinfo.py /tmp/output.export/datatable
    ./dsdump.py /tmp/output.export/datatable --include-locked --include-disabled > domain_hashes.txt

Like standalone machines, you can use the in-memory technique too to dump the domain users' hashes. The tools are the same and work equally. Just be cautious when injecting into the LSASS process of a domain controller: in the worst case scenario, you will have to reboot an infrastructure-critical server.

I have added these tools and improved the spread-sheet.

Sursa