Since Microsoft did a number to confuse the issue of "Pass the hash" attacks in their whitepaper, I think it's time for a brief refresher on what exactly a "Pass the hash" attack is.
So, please bear with me whilst I go over a few definitions. I'm going to gloss over some of the details and elaborate where I feel I must. I include a link to wikipedia with tons more info...
Cryptographic Hash Function (from Wikipedia)- "... an algorithm that takes an arbitrary block of data and returns a fixed-size bit string, the (cryptographic) hash value, such that an (accidental or intentional) change to the data will (with very high probability) change the hash value"
In small words, this means that you take a block of text (for example, a password) and run it through some magic function, and if you made a small change to the password, you would end up with a completely different value. Passwords are often stored using a hash function to make them more difficult to crack prevent the password from being stored in plain text.
NTLM (from wikipedia) - "... a suite of Microsoft security protocols that provides authentication, integrity, and confidentiality to users". For implementation details, read the page on NTLM from the Davenport Project.
NT hash - the 16 byte result of the Unicode password sent through the MD4 hash function
LM hash - old (NT old) hash read about it on Wikipedia
Kerberos - Microsoft's default authentication mechanism for Active Directory (originally from MIT). (Wikipedia)
Now that you have some background...
A "pass the hash" (PTH) attack can happen when just the password hash is sufficient to authenticate a user to a system. NTLM is a good example. For both NTLM version 1 and version 2, the password for the user requesting services is hashed and then that hash is used for the rest of the challenge-response based authentication process. Note other platforms have suffered from a PTH attack (e.g. coldfusion) so Microsoft doesn't own the patent on this class of vulnerability.
 |
| What normal authentication looks like |
 |
| Hash only authentication |
So, what does this mean? In essence, if an attacker has password hashes (multiple ways of obtaining hashes, more than likely another blog entry... ) and access to a service which allows NTLM to authenticate, the attacker can authenticate using a username and a hash with a modified client.
What services can use NTLM to authenticate? Well, IIS, Exchange (to include SMTP, POP3, IMAP), file and print services, MSSQL, and many other services related to gathering information from an Active Directory environment can use NTLM to authenticate. There are even a couple of ways to obtain code execution using PTH with either winexe (psexec clone) or WMIC, depending on how you're feeling. There are modified clients to do all of this from Linux and there are even ways to coax a Windows client to do it. For more info, please see the rest of the blog entries, our Blackhat 2012 talk, or the demo vids ;-)
But, you may say, "We use Kerberos, your puny PTH won't work against us!". You would be incorrect. In order for Kerberos to work properly, several conditions need to be met. Among the big ones 1) both ends of the connection need to be in the same Active Directory domain (or trusted) and 2) each end of the connection needs to refer to the other side by DNS name. There are more conditions (read the NTLM wiki link above for all the conditions of when NTLM is used instead of Kerberos)
If Kerberos cannot be used, by default NTLM is used as the fail over. Uh oh....
WAIT! I thought PTH meant....
The MS whitepaper confuses the meaning of PTH with a couple of different attacks than what I described earlier.
One attack that MS calls "PTH" is using a local account hash from a computer to privilege escalate on that computer or move laterally to other machines. So, let's decipher this a little bit.
When a new Windows computer is stood up it is built with an account that has administrative privileges. Then, at some point, the computer has to be added to the domain. So what happens to the admin account on that machine after it gets added to the domain?
On older Windows systems (XP/2003) the local administrator account (also sometimes known as the 500 account) is created when the computer is stood up. This account is used for administrative tasks, such as backups, patching, installing software, etc... The hashes for this account are stored locally in the SAM database. When the computer is added to a domain, this account remains and is still available for network logins. Since admins are often lazy, many of these built-in admin accounts share the same password across multiple machines. If one of these machines is compromised, and the local hashes are dumped out of the SAM, an attacker has now gained administrative access to potentially more machines on the network. While the attacker doesn't have privileged domain credentials, the local "system" account on these machines has access to the computer account for the domain. This is sufficient to query the AD for more information, such as a list of users or groups. This extra info leads to further attacks later.
Newer versions of Windows (2008/Vista / 7 ) by default disable the built-in administrator account and instead creates an account that is in the "Administrators" group local to the machine. This account can also be used to administer the workstation and its information is also stored in the SAM. When the computer is added to the domain, by default (assuming UAC is enabled) these accounts are NOT accessible from the network. So while the hashes provided could be cracked or recycled for other accounts, this information isn't as useful as it would be on older versions of Windows. However, it is worth noting that this behavior can be overridden by registry settings or GPO settings, so beware.
The MS whitepaper calls using these accounts a PTH attack. Meh. I sorta see what they are going for, but aside from hashes being involved, this isn't really a separate attack vector... More like an availability of hashes sort of issue...
Tokens!
In either case, if an attacker could get to a point where they can dump the local hashes, then more than likely they'd be more interested in whatever security tokens are available. Tokens will be addressed in a later blog post about Windows authentication, however the gist is that a token gets created when a user logs in. The token also contains the user's login name, the user hashes (NT / LM) and the domain (if applicable) the user is authenticated to. To keep things interesting, tokens often persist in memory for a long time, even after a user has disconnected from the computer. If that wasn't enough, in many cases the plain text password (mimikatz) can be recovered as well.
If that doesn't give you nightmares nothing else will... of course if I have a plain text password is it really a PTH attack now?
Not to be confused with...
Another form of attack which is often confused with PTH is called SMB relaying. Although, this is even a bit of a misnomer. This attack deals with hashes, but not with the NT or LM hashes used by the traditional PTH tool suite. The hashes involved are the response hashes to the challenge issued by a server when attempting to authenticate using one of the versions of NTLM.
Because of a poor design in the NTLM protocols, if I can get an authenticated person to attempt to use NTLM authentication against a computer I control (say, via a web page requesting NTLM authentication) I can act as a Man-in-the-Middle for any other service using NTLM, such as file shares. If I initiate a connection to the file server, I can feed the challenge I get from the file server back to the web page as my challenge and use the results to authenticate against the file server. Essentially I'm using an already authenticated connection to authenticate to a different service. So, without knowledge of the password, I am able to access additional services by "passing the hash".
There has been a lot of semi-recent conversations about SMB Relaying. A couple of links:
In Summary...
I've tried to lay out the foundation to understanding what a PTH attack is. I've also tried to explain what MS is calling a PTH attack and what other folks are calling PTH attacks. Next post will be all about Windows authentication.... Questions? Comments? Feel I need clarification? Hit me up on twitter or post comments to the blog and I'll try to answer as best I can...
