What if I told you that in most networks these days, you don’t have to bother with cracking the passwords? With most networks with Active Directory, you can use the stored hash obtained via Mimikatz or a WPAD attack to authenticate. How, you may ask? It’s because of the wondrous bit of mis-engineering that is the Windows NT Login Challenge and Response. I’m going to dive into this a bit, so that we understand just what it is that we’re exploiting.
Login systems in simple
1. Client sends password to server 2. Server checks if the password is good. If yes, Server lets client in. In the beginning, this was how logins worked. I’m looking at you, FTP, and Telnet…and SNMP…There were, shall we say, issues with this. Namely, the credentials were vulnerable to interception and replay attacks. If you thought to yourself, “Huh?”, then keep reading. Otherwise, skip to “How NTLM Challenge/Response Works”. Since these login protocols weren’t encrypted, anyone who could intercept the network traffic could recover the password. Add to that the possibility that an attacker could simply “replay” the already captured credentials, and we now see the problem.
How NTLM Challenge/Response Works
The designers of NTLM Challenge/Response had a couple of constraints that they wanted to solve for:
- Be resistant to interception and replay attacks
- Fit within the Windows ecosystem with minimal additional efforts
- Support transparent single sign-on
- Use a minimal amount of system resources to operate
The designers chose to leverage what’s called a challenge/response system. By design, the password should never be sent in the clear over the network. Only the hash should be sent. In the various versions (yes, there have been several versions of the protocol, each more secure than the last, but in the interests of backwards compatibility, older versions are often still enabled on enterprise networks), the process generally takes the form of the server issuing a challenge number, the client picking a number and doing some math so that the password has is never actually sent across the wire.
This was great…when the protocols were developed, and it was assumed that the hashes would be reasonably protected, and not available to attackers. Since then, I think we’ve pretty well proved that hashes can be obtained trivially, both at rest, and in flight, by a wily attacker (or pen-tester) through a variety of means and attacks.
So what can we do with the hashes?
Due to this peculiarity of the design, if we have the password hash, we can use it just as effectively as the password itself. More effectively, in fact, than the password (since we’d probably have to crack the hash to make it useful). One of the many wonderful features of Core Impact is the intelligence that is built into our exploit modules. Let’s suppose that we want to exploit MS14-068, which is a Kerberos Checksum remote privilege escalation exploit. Impact is intelligent enough to grab an identity (cracked or not) from the Identity store of the current workspace and leverage it to exploit the vulnerability automatically. All without ever having to know what the underlying password is. This is a useful trick to have up your sleeve. What’s even better: almost every authenticated exploit that can use NTML, can take advantage of already captured hashes. That’s a pretty effective time saver for your pen-tests.
Looking for more tips to save time and energy for your pen-testers?
Download our eBook A Guide to Successful Penetration Testing