alt Hacker NewsThe common asrep roast kerberos etype I see now is aes/18 (https://www.iana.org/assignments/kerberos-parameters/kerbero...).
I was looking at this guy's benchmark here: https://gist.github.com/Chick3nman/32e662a5bb63bc4f51b847bb4...
Etype 23 (rc4-hmac) gets ~3500 kH/s, 18 (aes256-cts-hmac-sha1-96) gets roughly 2500 kH/s. Big difference, but somehow I thought it would be much bigger? 2.5M guesses/second is still not so bad.
I've done kerberoasting and aseproasting a handful of times only, but from what I recall, RC4 can be cracked within reasonable time regardless of your password complexity. But with AES if you have a long and complex service account password, it will take decades/centuries to crack. But (!!) it is still quite common to use relatively weak passwords for service accounts, a lot of times the purpose of the service is included in the password so it makes guessing a bit easier.
My criticism is that Kerberos (as far as I'm aware) does not provide modern PBKDFs (keyed argon2?) that have memory-hardness in place. That might be asking too much, so why doesn't Microsoft alert directory administrators (and security teams) when someone is dumping tickets for kerberoasting by default? It's not common for any user or service to request for tickets for literally all your service accounts. Lastly, Microsoft has azure-keyvault in the cloud, but they're so focused on cloud, they don't have an on-prem keyvault solution. If a service account is compromised, you still have to find everything that uses it and change the password one by one. Where if there was a keyvault-like setup, you could more easily change passwords without causing outages.
Rotating the KDC/krbtgt credential is also still a nightmare.
From what bits I've heard, Microsoft expects its users to be using EntraId instead of on-prem domains (computers joined directly to entra-id instead of domain controllers). That's a nice dream, but in reality 20 years from know there will still be domain controllers on enterprise networks.
Replies
> I've done kerberoasting and aseproasting a handful of times only, but from what I recall, RC4 can be cracked within reasonable time regardless of your password complexity
That's not quite right. If the password is sufficiently strong, you won't crack it even when RC4 is used. The password space is infinite.
You might be thinking of the LM hash, where you are guaranteed to find the password within minutes, because the password space is limited to 7 character passwords.
> Rotating the KDC/krbtgt credential is also still a nightmare.
I also disagree there. Just change it exactly once every two weeks or so. Just don't do it more than once within 10 hours. See: https://adsecurity.org/?p=4597
What I wonder is why Windows isn't changing it itself every 30 days or so, just like every computer account password.
> why doesn't Microsoft alert directory administrators (and security teams) when someone is dumping tickets for kerberoasting by default?
Good question. Probably because they want you to license some Defender product which does this.
Kerberos has FAST for truly addressing the offline dictionary attack issues with PA-ENC-TIMESTAMP. FAST is basically tunneling, encrypting using some other ticket. With PKINIT w/ anonymous client's it's pretty easy to get this to be good enough, but Windows / AD doesn't support that, so instead you have to use a computer account to get the outer FAST tunnel's ticket, which works if you're joined to the domain, and doesn't work otherwise.
There's also work on a PAKE (zero-knowledge password proof protocol) which also solves the problem. Unfortunately the folks who worked on that did not also add an asymmetric PAKE, so the KDC still stores password equivalents :(
> Rotating the KDC/krbtgt credential is also still a nightmare.
I've done a bunch of work in Heimdal to make key rotation not a nightmare. But yeah, AD needs to copy that. I think the RedHat FreeIPA people are working on similar ideas.
> That's a nice dream, but in reality 20 years from know there will still be domain controllers on enterprise networks.
SSPI and Kerberos are super entrenched in the Windows architecture. IMO MSFT should build an SSP that uses JWTs over TLS, using PKI for server auth and JWT for client auth, using Kerberos principal names as claims in the JWTs and using the PKINIT SAN in server certs to keep all the naming backwards compatible. To get at the "PAC" they should just have servers turn around and ask a nearby DC via NETLOGON.