What harm is there in obtaining password hashes in a Windows environment?

Question

ArsTechnica posted this article recently talking about how the power grid has been penetrated:

Hackers lie in wait after penetrating US and Europe power grid networks

Excerpt:

One tactic involved using the publicly available Phishery toolkit to send targets a Microsoft Word document that was programmed to download a template from a predetermined server controlled by the attackers.

The server would then query the downloading computer for SMB credentials that many corporate networks use to restrict access to verified users.

In many cases, the downloading computers would respond and in the process provide the attackers with the user name and a cryptographic hash to the targeted network.

But getting hashes is not the same as obtaining actual passwords.

So my question is: What harm is there in obtaining password hashes in a Windows environment?

---

For reference about those emails: The Phishery Toolkit

Answer 1

TL;DR: Because of how Windows authenticates network users in a non-Kerberos (non-Active Directory) scenarios, password hashes work just as well as passwords for authenticating network users.

Long version: There are two traditional ways to use a password to authenticate someone:

• The client sends the password to the server (traditionally, in cleartext, although newer protocols use encryption). The server takes the password, hashes it, and compares it to the password hash it has stored. If the hashes match, then the client is assumed to have the correct password and is treated as authenticated.
• Challenge-response: The server generates a challenge (a random byte sequence) and sends it to the client. The client takes the challenge, combines it with the client's password, hashes the result, and sends the hash to the server. Meanwhile, the server takes the challenge, combines it with the password it has stored, and hashes the result. If the two hashes match, then the client is treated as authenticated.

Note that, under a challenge-response scheme, the password is never actually sent to the server (which is good), but the server needs to know the password (which is bad). The first approach is the traditional Unix approach; the second is the traditional Windows approach.

To mitigate the "server needs to know the password" disadvantage of challenge-response, many challenge-response implementations use a hash of the password. In other words, instead of comparing the hash of (challenge + password), implementations compare the hash of (challenge + hashed password). However, in this case, the hashed password is still all you need to access the service (because a malicious client can send the hash of (challenge + hashed password) even if it doesn't know the cleartext password). So hashing passwords under a challenge-response scheme make it harder to get a cleartext password that could presumably be used to attack other services, but it makes no difference in terms of the security of the service itself.

Further reading and references:

• https://www.toshellandback.com/2017/02/11/psexec/

  Once hashes are obtained, cracking them to uncover the plaintext password can be a long and arduous task (assuming the passwords don’t succumb to wordlists or rainbow table attacks). Luckily for us, Windows will gladly accept NTLM hash values in many situations, such as accessing a network resource by its IP address (vs. hostname) or connecting to a device that isn’t joined to the Domain. The only only time hashes would not be exchanged would be when requesting network resources in a Kerberos-exclusive environment, but that type of implementation is rare and can be problematic for many organizations to implement.

• https://en.wikipedia.org/wiki/Challenge%E2%80%93response_authentication

  Many (but not all) challenge-response algorithms… require both the client and the server to have a shared secret. Since the password itself is not stored, a challenge-response algorithm will usually have to use the hash of the password as the secret instead of the password itself. In this case, an intruder can use the actual hash, rather than the password, which makes the stored hashes just as sensitive as the actual passwords.

• https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/passdb.html#id2588057

  The UNIX scheme typically sends clear-text passwords over the network when logging in. This is bad. The SMB encryption scheme never sends the clear-text password over the network, but it does store the 16-byte hashed values on disk. This is also bad. Why? Because the 16 byte hashed values are a “password equivalent.” You cannot derive the user's password from them, but they could potentially be used in a modified client to gain access to a server. This would require considerable technical knowledge on behalf of the attacker but is perfectly possible. You should therefore treat the data stored in whatever passdb backend you use (smbpasswd file, LDAP) as though it contained the clear-text passwords of all your users.

Answer 2

getting hashes is not the same as obtaining actual passwords

It can be just as good as obtaining the actual passwords, though, for typical users. This article is about workers at power companies. Do you think your average power company technician has a 9-word fully random diceware phrase for their login password at work? More likely it will be "MyDogFido!7" (because they've had that password for 7 password changes) at best. They only really need to crack one hash to get a beachhead established in the system; with enough employees, if they can get the hash of all employees, I'm sure they'll get at least one.