Kerberos Explained
Kerberos is a stateless protocol that allows users to authenticate on the network, and access services once authenticated.
Kerberos is used whenever a user wants to access some services on the network. The user won’t need to type his password every time and the server won’t need to know every user’s password. This is centralized authentication.
Kerberos requires 3 main entities:
- Client, a user/service of any software.
- Service, where the kerberos protected resource/service is hosted
- KDC (Key Distribution Center) which is a service running in Domain Controller
The idea behind kerberos authentication is that when a client wants to access a service, no password will be sent over the network, thus avoiding password leaks that could compromise the network.
Key terms of Kerberos:
- Authentication Service (AS)
- Ticket Granting Ticket (TGT)
- Application Request (AR)
How Kerberos Works:
Authentication Service (AS)
AS_REQ
- Client first needs to authenticate on the KDC by sending a KRB_AS_REQ (Kerberos Authentication Service Request) requesting for a Ticket Granting Ticket (TGT) along with the below information in the request encrypted with a hash derived from the password of the client.
* name/ID
* request timestamp
2. KDC will check if client username is in the database, it will then retrieve client’s hashed password from ntds.dit database to decrypt encrypted timestamp
3. if KDC is able to decrypt the timestamp and timestamp is not a duplicate, It will generate a unique session key for the user which is limited in time.
AS_REP
KDC then sends a KRB_AS_REP (Kerberos Authentication Service Response) along with the below information
→ session key, encrypted with client’s hashed password. So that client can decrypt to get the session key for further use
→ TGT (encrypted with the krbtgt key, only the KDC is able to decrypt and read the ticket), containing various information like:
* Client’s username
* Timestamp
* Domain
* Session key
* IP address of the client
* Privilege Attribute Certificate (PAC) which contains client specific information like security identifier (SID) and groups.
Ticket Granting Ticket (TGT)
TGS_REQ
If the client wants to access any services (like WWW, CIFS) running on SERVER1 in the network, then client should request for Service Tickets from KDC which is called KRB_TGS_REQ (Kerberos Ticket Granting Service Request) with the below information
- TGT from AS_REP
- Service along with the host ex: WWW/SERVER1
- authenticator, which contains client’s username and current timestamp encrypted with the session key from AS_REP
Authenticator is sent to make sure that it is that client is making the request. To do this, the KDC will compare TGT and authenticator contents. Since only the KDC can read TGT content, it could not have been tampered with. The KDC will read TGT content, including the TGT’s owner and the associated session key. Then it will decrypt authenticator content with the same session key. If the decryption works, and the data in the authenticator matches the data in the TGT, then client is who it claims to be. The KDC is assured that whoever made the request has the TGT and knowledge of the negotiated session key.
TGS_REP
now KDC was able to verify the client, it will respond back with information that will allow the user to make a request to the Application service. This message is the KRB_TGS_REP (Kerberos Ticket Granting Service Response). It includes the following elements:
- A ticket containing the name and host of the requested service (WWW/SERVER1), client’s username, the PAC, and a new session key which is only valid for communications between client and server1 for a certain period of time. This ticket is encrypted with the service’s key (i.e. the host key, since WWW service runs under the host account);
- The new session key
These two pieces of information (the ticket and the session key) are encrypted with the first session key, the one that was initially exchanged between the KDC and the client.
The client will receive this message, and will be able to decrypt the first layer to get the session key created for communication with the service, as well as the ticket generated to use this service. This ticket is commonly called Ticket-Granting-Service (TGS).
Application Request (AP)
AP_REQ
Client will then generate a new authenticator which will encrypt with this new session key, along with the TGS. This is the same process as with the KDC
WWW service receives the TGS and can decrypt it with its own secret. Since only the DC knows its secret, DC rests assured that this TGS is authentic. This TGS contains the session key it will use to decrypt the authenticator. By comparing the TGS and authenticator contents, the service can be certain of the user’s authenticity.
Attacks on Kerberos
- AS-REP Roasting: If Kerberos pre-authentication is not configured, anyone can send a AS-REQ to the AS on behalf of any user. Upon obtaining the AS-REP one can crack user passwords through offline brute-force methods.
- Kerberoasting: The attacker steals the password hash of a service account. Upon obtaining them, can crack user passwords
- Kerberos Delegations: A Kerberos delegation is “a setting that allows applications to request end-user access credentials to access resources on behalf of the originating user.” These can be leveraged by attackers to get unauthorized access to resources, systems, or data and even Privilege Escalation.
- Golden Ticket: Attackers can forge a Ticket Granting Ticket (TGT) with arbitrary access privileges, essentially granting them full control over an Active Directory domain.
- Silver Ticket: Another forged authentication ticket. The Silver ticket is often a forged service ticket that enables access to resources on the target service.
- Pass-the-Ticket: A Pass-the-Ticket attack focuses on lateral movement, stealing the TGT or TGS.
Mitigation
- AS-REP Hardening: Don’t set users with Kerberos pre-authentication disabled, and protect accounts with strong passwords.
- Kerberoasting: use long and complex passwords whilst limiting privileges of serviced accounts.
- Delegation abuse: disable unconstrained delegation and place users into the Protected Users Group where possible.
- Golden ticket: limit the number of admin accounts and utilize Multi-factor authentication.
- Silver ticket: ensure service accounts have strong passwords with a complexity of 25 or more characters and rotate regularly.
- Pass-the-Ticket: closely monitor events and check any users requesting new TGTs or TGSs outside of normal operations.
Conclusion
Kerberos protocol is a vast protocol prone to lot of attacks. Its designed to authenticate users or service without passing the password over the network.
Reference: