Kerberos
In enterprise authentication, Kerberos is the ticket-based protocol that Active Directory uses to prove identity between clients and services without sending passwords over the network. Understanding its ticket exchange is a prerequisite for understanding most of what happens in an internal intrusion on a Windows estate.
How it works
Version 5 of the protocol is specified in RFC 4120. A key distribution centre, which in a Windows estate is the domain controller, runs two services. The authentication service verifies the user at logon and issues a ticket-granting ticket, encrypted so that only the centre can read it. The ticket-granting service then exchanges that for a service ticket whenever the user needs to reach a specific service.
The service ticket is the interesting part. It is encrypted with a key derived from the password of the account the service runs under, and the client presents it to the service, which decrypts it with its own key. Nothing about the user’s password crosses the network, and the service never has to contact the domain controller to validate the ticket. That last property is what makes ticket-based attacks so durable.
What goes wrong
The design is sound; the deployments around it are what we exploit. Because any authenticated user may request a service ticket for any account with a service principal name, and because that ticket is encrypted with a key derived from a password, the domain will hand out crackable material to anyone with an ordinary account. That is kerberoasting, and it works because service accounts have human-chosen passwords, not because Kerberos is broken.
Accounts with pre-authentication disabled give up equivalent material without any credential at all, which is AS-REP roasting. Compromise of the account that signs tickets lets an attacker forge them outright, which is a golden ticket and is why that account’s key is the crown jewel of the domain. And legacy encryption types left enabled for compatibility make offline cracking dramatically faster than the modern ones.
Where this shows up in an audit
On an internal test we enumerate accounts with service principal names, the encryption types the domain will issue, and the accounts with pre-authentication disabled, because those three lists predict most of what follows. The report is written against the accounts and the policy, never against the protocol, and the recommendations are managed passwords, removal of stale service principal names and retiring legacy encryption where the estate can take it. This is part of how we test Active Directory authentication from the inside.