{"id":55,"date":"2010-05-17T13:44:00","date_gmt":"2010-05-17T19:44:00","guid":{"rendered":"http:\/\/www.foofus.net\/?page_id=55"},"modified":"2010-05-17T13:44:00","modified_gmt":"2010-05-17T19:44:00","slug":"passwords-hashes","status":"publish","type":"page","link":"http:\/\/h.foofus.net\/?page_id=55","title":{"rendered":"Passwords & Hashes"},"content":{"rendered":"

Passwords & Hashes<\/h1>\n

I work a lot with hashes \u00a0(i.e. one-way encrypted hashes of passwords). This work includes password hash extraction, cracking of the hashes, and using them as-is. The following is a brief overview of the code I’ve developed for this work and some of the tricks to using it.<\/p>\n

Hash Usage: Gathering The Hash<\/h2>\n

This page focuses on two specific areas: LM\/NTLM password hashes (what tools like FgDump<\/a> extract) and LM\/NTLM challenge\/response hashes \u00a0(the actual authentication exchange performed over a network).<\/p>\n

LM\/NTLM Password Hashes<\/h3>\n

Microsoft Windows stores user passwords in the system\u2019s password database (called \u201cSAM\u201d) in an encrypted hash. The encryption schemes used are one-way, or non-reversible, meaning that this data cannot be decrypted through simple means. For example, the following is a sample entry from a SAM database:<\/p>\n

Administrator:500:207277225E983B147AC464727886BD82:90BBDB25BC6556610DAA4F03900FBE92:::<\/code><\/p>\n

This password database entry contains the older LAN Manager Network Protocol (LM) and NT LAN Manager (NTLM) encrypted hash for the account.<\/p>\n

To extract a system’s password database, I tend to rely on our FgDump application. FgDump is a wrapper application which pulls together our version of PwDump, in addition to several password-related utilities (e.g. cachedump). It also handles starting and stopping anti-virus applications, which can cause issues during this type of activity (e.g. crashing the system or sending up confusing alerts, but not typically stopping the activity).<\/p>\n

One of the issues with the Microsoft Windows account access mechanisms is that they use a token-based model to handle user authorization tasks. Once a user has been authenticated via logging in, they have a token associated with processes they are running. This presents an opportunity for a privileged user, such as an administrator, to physically read the memory associated with that process and extract the running user\u2019s token. With this token, it is possible to invoke other processes as that user, without the need for authentication at all. The net result in a scenario such as this is that a local administrator is able to elevate his or her privilege to that of any logged-in user, including, potentially, a Domain Administrator. Attackers can also extract from the token the account\u2019s LM and NTLM hashes. Unfortunately, these values are not salted as are the cached credentials.<\/p>\n

One of the most popular methods of abusing tokens is through the MetaSploit Incognito function, or using Incognito itself. While this is a fine approach, I’m a fan of the utility WhosThere. WhosThere is a free tool from Hernan Ochoa\/CORE TECHNOLOGIES<\/a> which “will list logon sessions with NTLM credentials (username, domain name, LM and NT hashes).” This is an incredibly powerful utility, as it allows you to extract domain account hashes from member servers. These hashes can then be used in pass-the-hash style attacks or simply cracked. While an excellent utility, WhosThere doesn’t function out of the box on all versions of Windows. It provides an option (i.e. -a) to specify known memory addresses for those versions which don’t automatically work. Unfortunately, as each version of lsasrv.dll will result in new memory addresses, tracking these can be a hassle. The patch provided here adds support to whosthere.exe to examine the system’s lsasrv.dll file (via SHA-1 hash) and select from a list of known addresses. This list is currently limited, but I plan to add to it as I encounter new versions. I’ve also modified FgDump to allow the running of WhosThere as part of its normal operation (revdump – reversible encrypted passwords – support is also included). The functionality is not currently included in the official FgDump release, due to a request to not redistribute the WhosThere application. However, the patches provided here are sufficient to build FgDump with these features for one’s own use.<\/p>\n

WhosThere SHA1 Patch<\/a><\/p>\n

FgDump – WhosThere\/RevDump Support Patch<\/a><\/p>\n

Challenge\/Response Authentication Exchanges<\/h3>\n

The challenge\/response authentication system currently employed by Microsoft products is an area of concern regarding how the current authentication schemes affect the security of a Microsoft Windows environment. Recent versions of Microsoft Windows-based operating systems support several methods to remotely authenticate network users, including LAN Manager (LM), LMv2, NTLMv1, NTLMv2, and Kerberos. These authentication mechanisms provide a means by which clients are able to prove their identities without actually sending a password to the server. It should be noted that LM and NTLM network-based authentication make use of the LM\/NTLM password hashes, but they are not the same algorithms. For additional background on the LM\/NTLM challenge\/response authentication process, please review the following documentation: LM\/NTLM Challenge\/Response Documentation<\/a>.<\/p>\n

There are a number of methods for capturing challenge\/response authentication attempts: MetaSploit, Ettercap, Cain & Abel, etc. My personal favorite is using a modified Samba server. In addition to logging the challenge\/response handshake, it provides the additional fun of responding to all broadcast NetBIOS name requests and uses a fixed challenge. All sorts of fun can be had by running this on an internal network or combining it with tools such as Karma. Redirecting mail clients, web-browsers, among other tools to this service via file:\/\/ or \\ URLs is also handy.<\/p>\n

Samba Fixed Challenge\/Auto NMB Response\/Hash Pass Patch (Samba 3.6.3)<\/a><\/p>\n

Example smb.conf<\/a><\/p>\n

Hash Usage: Passing The Hash<\/h2>\n

During the course of performing internal audits (yes, all legal), I’ve collected a significant number of sam._ and pwdump files. Hell, it’s hard not get them with all the fun toys vailable to us script kiddies these days. Unfortunately, conventional off-line password auditing tools can be painfully slow to crack the accounts. Also, it seems that the machines I pull the password hashes from are never the hosts I really want to have access to. Luckily, for us, people seem to like to use the same password everywhere. This is where “Passing The Hash” becomes useful.<\/p>\n

Let’s assume you successfully extracted a system’s local Administrator password hash(es). You want to know if that hash is good on any other hosts within the environment. This situation is exactly what drove the original creation of Medusa<\/a>. The following example reads the PwDump output and checks each account against a list of hosts. It’s worth noting that hundreds of systems can often be checked in only a few minutes using this approach.
\n% medusa -H hosts.txt -C pwdump.txt -M smbnt -m PASS:HASH<\/code><\/p>\n

Medusa v1.0-rc1 [http:\/\/www.foofus.net] (C) JoMo-Kun \/ Foofus Networks<\/p>\n

ACCOUNT CHECK: [smbnt] Host: 192.168.0.20 (1\/10) User: Administrator (1\/3) Password: 92D887C8010492C2944E2DF489A880E4:7A2EDE4F51BC5A03984C6BA2C239CF63::: (1\/1)
\nACCOUNT FOUND: [smbnt] Host: 192.168.0.20 User: Administrator Password: 92D887C8010492C2944E2DF489A880E4:7A2EDE4F51BC5A03984C6BA2C239CF63::: [SUCCESS]
\nACCOUNT CHECK: [smbnt] Host: 192.168.0.20 (1\/10) User: bar (2\/3) Password: 49D58563113416EBAAD3B435B51404EE:AA3AFE73B6E0C2D87B3A428BF696AE71::: (1\/1)
\nACCOUNT CHECK: [smbnt] Host: 192.168.0.20 (1\/10) User: foo (3\/3) Password: 92D887C8010492C2944E2DF489A880E4:7A2EDE4F51BC5A03984C6BA2C239CF63::: (1\/1)
\nACCOUNT FOUND: [smbnt] Host: 192.168.0.20 User: foo Password: 92D887C8010492C2944E2DF489A880E4:7A2EDE4F51BC5A03984C6BA2C239CF63::: [SUCCESS]<\/p>\n

“Passing The Hash” style attacks seem to have been talked about forever. Google<\/a> for it, if you haven’t heard of it. During my research on this subject, I stumbled on a public tool<\/a> which looked to be just what I wanted. Unfortunately, I’m too dumb to actually get the thing to work correctly. There’s also been talk of adding a little feature to SAMBA<\/a> to perform the attack. Of course, the only implementation<\/a> of this I could locate was from 1997. That really did not do me a whole lot of good since SAMBA wasn’t used for much more than file and print sharing<\/a> at that time. After a little bit of research, I found that a lot has changed regarding SAMBA since 1997. The ‘net’ command added in version 3 can do some fairly cool things. Below are several patches against SAMBA to implement LM, NTLM and NTLMv2 hash passing. Here’s how to have fun with them:<\/p>\n