Post Exploitation, Metasploit and Windows Hashes

What is a Windows hash?

A Windows hash is a non-salted algorithmic encoding of a plaintext password.  Windows has used two different algorithms for hashing to date, the result being an  LAN Manager (LM) hash, or an NT hash.  In a Microsoft Windows network, NT LAN Manager (NTLM) is a suite of protocols used to provide authentication, integrity and confidentiality to users.  NTLM is the successor to LAN Manager (LANMAN), and attempts to provide backwards compatibility with LANMAN.

In the world of cryptography, salting is a known piece of additional random data that is “mixed in” as an additional input to the one way hashing function.   The advantage of salting is that the hashed representation of a password will never be the same for the same plaintext string.   Unfortunately this technique is not used with stored hashes in Windows.

The LANMAN hash is constructed as follows:

• The plaintext password is padded with NULL characters to a length of fourteen bytes, and converted to all uppercase.
• The resulting string is split into two seven character strings.  Each string is used as a key to encrypt the constant string value of “KGS!@#$%”. The data encryption standard (DES) algorithm is used for encryption.
•  The resulting ciphertext is concatenated into a sixteen byte hash value.

The NT hash is constructed by using the MD4 hashing algorithm over the plaintext string.   A plaintext password, used to construct the NT hash, can be up to 256 characters in length with mixed case and special characters.  Unlike the LM hash, special characters, upper and lower case are all preserved with an NT hash.

How is a Windows hash passed across the network?

From a network transmission perspective, there are two different challenge response algorithms in use.   The LANMAN, and NTLMv1 algorithm operates as follows:

1)    Workstation client initiates authentication

2)    Server responds with a random challenge

3)    Client formulates and sends a response to the challenge by:

a)    Padding the LANMAN/NT hash to 21 bytes

b)    Splitting the hash into three seven character pieces

c)    Using each piece as a DES key to encrypt the server challenge.

NTLMv2 challenge/response is significantly more secure, and operates as follows:

1)    Workstation client initiates authentication

2)    Server responds with a random challenge

3)    Client formulates/sends a response by:

a)    Creating an HMAC-MD5 string using the username, domain name, and NT hash as a key.  This result is called the NTLMv2 one way function (OWF)

b)    Combining the HMAC-MD5 string, server challenge, timestamp, and client challenge into a response. 

Obtaining Hashes during a Penetration Test

In a post exploitation scenario, and assuming you have administrative access, it is useful to be able to retrieve the hashed representation of passwords. Windows hashed passwords are stored in the Security Accounts Manager (SAM) registry hive which is a file named “%SystemRoot%\System32\Config\SAM”.   By default, the SAM file is locked on a running system, and inaccessible to all users including administrative users.  If an NT file system recovery was performed in the past, and the Administrator has not removed the backup data, you might be able to find the SAM file in the “%SystemRoot%\repair” directory.

Since you cannot read the file directly on the disk volume, there are a few alternative tricks to get hold of the data.   The local security authentication sub-system process (LSASS.EXE) on a running windows system reads this data and caches it in memory.

Method 1: Meterpreter “hashdump” command 

The hashdump command is an in-memory version of “pwdump”.   Hashdump allocates memory inside the LSASS process, injects assembly code, and executes it using the CreateThread() function.   The injected assembly code is designed to read the hashes out of LSASS memory, and print them out.   No files are written to disk, thus detecting the technique without using memory forensic techniques is difficult.

In January, 2010, HD Moore noted that Anti-Virus, and host intrusion prevention (HIPS) vendors had developed techniques to detect the API calls made by the meterpreter hashdump command, and block the calls.   In the process of detection however, LSASS will often crash leading to system instability.

Method 2: Meterpreter “hashdump” post module

The hashdump post module (post/windows/gather/hashdump.rb) uses a registry based technique to directly access the SYSKEY, and decrypt the raw LANMAN, and NT hashes.      The significant advantage of this technique is that there is no in-memory manipulation of LSASS with its potential for instability.

The caveat is that a SYSTEM token is required to use the technique.  An account in the local administrators group does not have read access to the SAM registry tree that contains the hashes.   If you have exploited a system service, or perhaps something like a DCERPC vulnerability, you are in great shape.   Alternatively you can consider migrating your meterpreter to a service process, or load the incognito module, and impersonate a token.

Method 3: Meterpreter “smart_hashdump” post module

Carlos Perez improved further on the hash extraction techniques in the sense of automating some of the additional steps, and logic required before the actual hashes are extracted.   The “smart_hashdump” post module works as follows:

• Determine the privilege level, operating system, and test if the target is a domain controller
•  If you have the right privileges, specifically a SYSTEM token, smart_hashdump will read the hashes from the SAM registry hive.
• If the system is a Domain Controller, smart_hashdump will always inject assembly code into LSASS to obtain hashes.
• If the target is a Windows 2008 server, and the process has administrative privileges, smart_hashdump will:
• Attempt to gain SYSTEM by using “getsystem”.
• If it fails to get system, smart_hashdump will attempt to automatically migrate to a process that has system privileges.
• Inject the LSASS process with assembly code to dump the hashes
• If the target is a Windows 7+ system with UAC disabled and the process has administrative privileges, smart_hashdump will run “getsystem” and use the registry reading method.If the target is a Windows 2000/2003/XP system, “getsystem” will be used followed by the registry reading method.

The take home point with “smart_hashdump” is that it will do the work for you to obtain SYSTEM privilege and prefer reading the SAM registry hive if at all possible.  The downside with this and all methods, is that within the context of a Domain Controller, you are still required to inject assembly code into LSASS in order to obtain hashes.   As pointed out above, this is a dangerous technique and can result in a crash which your client would certainly not appreciate.

Method 4: Extract hashes from Volume Shadow Copies of the file system

In 2011, Tim Tomes, and Mark Baggett were performing research on the topic of hiding malware in Volume Shadow Copies.   As a result of this work, they realized that by creating a volume shadow copy, or using a pre-existing volume shadow copy, the NTDS.DIT, SAM and SYSTEM files could be directly copied from a running system.

In summary, the process involves:

●      Creating a volume shadow copy using system tool “vssadmin” or Tim’s visual basic script called “Vssown.vbs”

●      Downloading the NTDS.DIT, SAM, and SYSTEM files

●      Downloading and compiling tools from http://www.ntdsxtract.com/downloads/ntds_dump_hash.zip

●      Using esedbdumphash to extract the database from NTDS.DIT

●      Using dsdump.py, or bkhive2, and samdump2 to dump hashes.

The largest single advantage with using an offline method to extract hashes after copying from a volume shadow is the fact that you do not have to inject anything into the LSASS process on a running domain controller.   The disadvantage is that in a larger environment, you are faced with exfiltrating some potentially large files, and downloading them for analysis.  It is possible that network defenders might detect the network activity of a large data transfer, and/or a large file being written to disk on a workstation.

Choosing the right tool for the job

Which method of hash extraction you decide to use depends on the context of your test.  If you are dealing with an individual system that is not a domain controller, then the “smart_hashdump” module is a good solid choice.   If you are working with host based IPS or Anti-Virus that is detecting LSASS injection attempts, you are taking a significant risk when injecting assembly into this process.   In the context of a domain controller, a volume shadow copy extraction is the best approach to ensure stability.   It is apparent that the original LSASS injection process in meterpreter can be risky, and should probably be avoided.

While this article focuses on hashes, it would be remiss not to mention that LSASS also caches some plaintext data for other security service providers.  These include WDigest for HTTP authentication, Kerberos, and Terminal Services.  If you have administrative access on a local system, LSASS plaintext security service provider memory can be accessed using the Mimikatz or Kiwi extensions enabling the extraction of plaintext information to screen.  Kiwi can be thought of as the upgraded (version 2) release of Mimikatz and includes some excellent new functionality.

References

●      http://pauldotcom.com/2011/11/safely-dumping-hashes-from-liv.html

●      http://web.textfiles.com/hacking/sam_files.txt

●      http://www.darkoperator.com/blog/2011/5/19/metasploit-post-module-smart_hashdump.html

●      https://community.rapid7.com/community/metasploit/blog/2010/01/01/safe-reliable-hash-dumping