If you’ve watched my video on Kerberos Pre-Authentication and how Impacket’s GetNPUsers script takes advantage of that being disabled, you’ll be aware that by default user accounts are not vulnerable to this kind of attack. I also mentioned in the video that in 8 years of Windows network admin in various organisations, I’ve never actually seen anyone disable kerberos pre-auth. So in the real world, 99% of the time we’re probably going to come up against accounts where pre-auth is enabled and we can’t use something like the GetNPUsers script. However, the pre-auth feature itself actually gives us another avenue of attack.
Think about what we’re doing when we exploit pre-auth being disabled (watch my video if you’re unsure of how it works, linked below). With pre-auth disabled we’re not actually getting the user’s password or even a hash of it sent to us – we’re just getting some data that was encrypted using the user’s password as the encryption key. Then we are just brute forcing that encrypted data with a word list, until we find a password in that list that gives us valid data when we use it to decrypt the encrypted data.
Now think about what pre-authentication does. It encrypts the current time and sends it to the server (as part of the initial kerberos AS-REQ packet) but it encrypts it using the user’s password as the encryption key.
Are you starting to see where this is going? We can just do the same thing we were doing before – brute force that encrypted data with a word list until we get valid data decrypted.
There is a big caveat to this though, and that is that we need to capture network packets of a user authenticating with Kerberos first before we have this encrypted data. Not always the easiest thing to do… but if you do ever find you’re in a situation where you can either capture network traffic between machines, or have something like a Wireshark packet capture file that contains some kerberos auth packets in it, then you can perform this kind of attack and get the user’s password. This of course is assuming they don’t have a real long complex one that your word list / password cracker combo cannot guess in a reasonable amount of time (but the same applies for the original GetNPUsers method when pre-auth is disabled too).
Let’s look at an example. Here we have a wireshark capture from a user just accessing an SMB share on their network and I’ve highlighted the part we are interested in (encrypted data timestamp used for pre-auth):
I started looking into exactly how to crack this data with hashcat and found this blog post: https://improsec.com/tech-blog/asreqroast-from-mitm-to-hash
However, their method did not work for me. It looks like their example data that can be cracked with hashcat mode 7500 is using the RC4 encryption type (kerberos encryption type 23).
In our example though we can see that the encryption mode being used is 18 (which wireshark handily tells us means AES-256).
So we can’t use hashcat mode 7500 as that is expecting the RC4 encryption type, which we know because the example hash on the hashcat site has 23 as its second parameter. I did try running mode 7500 but with 18 as the second parameter just in case, but as expected that fails.
The mode we want to use is 19900 as that is described as “Kerberos, etype 18, Pre-Auth”. Sounds like exactly what we want! Unfortunately when I tried to use that mode, I just get told the mode does not exist.
Turns out this mode is only available in the BETA version of hashcat, which can be downloaded here: https://hashcat.net/beta/
After downloading that, I was able to use mode 19900 and paste in our cipher text that we see in the wireshark trace:
hashcat.exe -m 19900 "$krb5pa$18$tstar$SCRM.LOCAL$743757ff43af01f3670b5d152c8d6b24270890ac42f8e40aa11c25f4963a820b 0c35f320a9f6964128db578e8f6964d21a3313a765ab52a5" rockyou.txt
As you can see, we get the user’s password! In this example it was just “passw0rd”.
The other text that we passed in before the cipher text ($krb5pa$18$tstar$SCRM.LOCAL$) is a list of parameters for hashcat to use, separated by a $ symbol.
The first two are just part of the hashcat format for this hash type. Krb5pa meaning kerberos 5 pre-auth, and 18 meaning kerberos encryption type 18 (AES-256) as discussed above. The next part is the username (which we can get from examining the rest of the kerberos AS-REQ packet in wireshark) and the last part is the domain name (again is just in plain text in other parts of the kerberos packet).
So there we go. Even if pre-auth is enabled, we can still easily get passwords as long as we have a way to capture network traffic.
For more info on kerberos pre-auth, see my video here:
EDIT: I’ve also now released a video covering all of the information in this article: