Pass-the-Hash

Unlike encryption, hashing applies a mathematical algorithm to a password that is not reversible. Once a hash is created, it is theoretically impossible to get the original plaintext from it. Various combinations of hashes need to be generated from chosen plain-texts until eventually one is found that matches the hash. This is where tools like hashcat come in, and of course, the hashes must be gathered first.

When domain administrator access has been achieved, hashes of all the domain users for offline can be found in the C:\Windows\NTDS\NTDS.dit database file in the domain controller. These can then be dumped for further analysis. The OS uses it constantly, and it must be extracted using Domain Controller Replication Services, Native Windows Binaries or WMI.

After 15+ years, exploiting the Pass-the-Hash vulnerability is still the weapon of choice for most APT attackers. In 2014, a small cloud (Windows Update to Fix Pass-the-Hash Vulnerability?) threatened the clear blue sky, but no, the good weather held: Pass-the-Hash is Dead: Long Live Pass-the-Hash!

Pass-the-Hash is not an implementation flaw (but it is a vulnerability). It is inherent to the way that the Single Sign On (SSO) paradigm is supported in Windows. To support the SSO paradigm, the user’s identity and privileges are established through credentials verification on the initial authentication phase. Consequently, an SSO token is created and stored on that machine. For any follow up login activity where the user’s identity and privileges needs to be verfied again, for example when accessing a network resource, it’s done through the SSO token validation. As a result, if an adversary is capable of stealing the SSO token then the attacker is able to impersonate the user. The thing to note is that this issue is not related specifically to NTLM but to every authentication system that uses tokens in a similar manner. For example, Kerberos (NTLM’s successor authentication protocol) is vulnerable to the theft of its token, named Kerberos ticket, where the attack is appropriately called Pass-the-Ticket.
Windows authentication protocols do not include the option of binding their SSO token to the machine, and so enable attackers to reuse the SSO token on other machines. Windows can solve token theft problems by simultaneously augmenting these protocols to support such binding (or create a new authentication protocol) and disabling the existing vulnerable protocols.
Microsoft has been trying to eliminate NTLM for more than a decade, with a very limited success. Having this outdated authentication mechanism reside side-by-side along with the newer, more secure protocol, often eliminates the security merits of the latter.

In organisations, a practical option is to use compensating security controls to bind the SSO token to the machine to prevent its reuse on other machines. Such compensating controls can take the form of a security device that remembers which token was assigned to which machine and can alert or even block the use of that token from other machines.