Kerberoasting and AS-REP roasting
Two Kerberos settings turn a password into something that can be guessed offline.
Kerberoasting. A service account has a service principal name. Any domain user can ask for a service ticket for that name. The ticket is encrypted with the service account's key. If that password is short, it can be guessed later, off the domain controller.
AS-REP roasting. An account is set so it does not require Kerberos pre-authentication. Anyone who can reach the domain controller can ask for a ticket for that account and guess the password offline. They do not need a password to start.
I'm not publishing a request-and-crack lab on this page. There are no tool commands here.
What I check
I check that pre-authentication is required on user accounts. I check that a service account with a service principal name uses a long random password, or a group managed service account. I check that the domain is not still issuing RC4 tickets for those accounts.
How to see it
- A burst of service-ticket requests (Windows event 4769), especially with RC4 (encryption type 0x17), from one account toward many service names.
- Authentication-ticket requests (event 4768) for accounts that should have required pre-authentication, with no matching failed logon from that person.
Those events also fire for normal Kerberos. Volume and encryption type are the signal. One ticket is not.
How to stop it
- Require pre-authentication. Turn the exception off unless you have a written reason.
- Move service accounts to group managed service accounts.
- If you can't, set a long random password and rotate it.
- Prefer AES. Stop issuing RC4 where the forest allows it.
- Keep Tier 0 accounts off machines where a normal user can run code.
Related reading: how these settings sit inside a directory review and AD CS auditing.