Kerberos Authentication Protocol

Kerberos is an authentication protocol that is widely used in many operating systems and environments, but particularly in Microsoft Active Directory. Its name comes from a Greek mythology. Cerberus is the three-headed guard dog of Hades. Kerberos is the perfect protocol for dynamic corporate environments where there are constant changes being made in terms of users, applications and systems. It is a symmetric-key protocol that authenticates and allows communication in an environment where individual systems don’t inherently trust each other, but they commonly trust a third-party. This third-party is responsible for authenticating the users and giving them access to their requested system. So, how exactly does it do this? Let’s dive in to find out!

Background

First, let’s understand what Active Directory is. Simply put, Active Directory (AD) is an interconnection of systems and servers in a domain. Multiple domains of an organization make up an AD network. A domain controller (DC) is a Windows server that controls a domain. It handles authentication, authorization, access control etc. In Kerberos, DC is the third-party that all individual systems trust.

The DC has a Key Distribution Centre (KDC) which is responsible for handling ticket requests and issuing tickets. The KDC knows the passwords of all individual systems, services and servers. These are managed by an automatically created user account known as the KRBTGT and the passwords are stored in a file known as NTDS.dit. Keep this bit in mind; we’ll need it for context later.

Working

Now that we know what Kerberos is and we have a basic understanding of what an AD is, let’s see how Kerberos works. A user/client wants to access the File Server in an AD domain. Here’s how he does that:

1.?In the first step, the user logs on to his system. He then sends an Authentication Service Request (AS-REQ) to the domain controller. The goal here for him is to get a Ticket Granting Ticket or TGT from the DC. For now, just know that the TGT is required, you cannot proceed without it.

Let’s break down the AS-REQ. It is the request from the user to the Authentication Service (AS). The goal here is for the user to prove he is who he is and he can do that by producing his password. But if he sends his password over the network to the DC, it could be intercepted and abused. So, the password isn’t sent directly. The request is timestamped and encrypted with the user’s password and sent. As discussed above, KDC knows that user’s password. It will use the user’s password to decrypt the request. If the password is correct, the decryption will be successful, if not, it will fail. In this way, the KDC verifies and authenticates the user. So, upon decryption the request is processed and a TGT is prepared.

2.?In the second step, the KDC sends a TGT back to the user. This process is known as Authentication Service Reply (AS-REP).

Let’s break down the AS-REP. It is a reply to the user corresponding to his initial request. The reply is the TGT, which consists of two encrypted portions.

The first part contains some metadata and the session key. This part is encrypted with the user’s password, which the user himself knows, so he can decrypt it. The user’s password is a shared secret. It is known by two entities, the user himself and the KDC. Since no one other than himself and the KDC knew his password, this reply proves that it was actually the KDC that sent the user this ticket.

The other part is encrypted by the KDC itself with its own password, not decryptable or known to the user. It does this because it will need to verify this TGT later.

So as of now, the user has authenticated itself to the KDC & the KDC has authenticated itself to the user and the user now has the needed TGT and a session key.

3.?In the third step, the user can now request for a service ticket (TGS-REQ) which it will use to access the file server. The TGT is a pre-requisite to obtain the TGS. Since it has already authenticated itself, it now directly asks for the TGS.

Let’s break down the TGS-REQ. It contains the request to access the server the user wants (which in our case, is the file server) along with the TGT. Upon receiving the request, the DC first checks the authenticity of the TGT, to make sure that it is the one that issued that TGT and it wasn’t just forged by anyone else. How does it do that? If you recall, in pt. 2, I said that the second half of the TGT was encrypted by the KDC with its own password. Since the KDC is the only entity that knows its own password and no one else, it can verify that the TGT is legitimate.

4.?In the fourth step, the TGS is sent back to the user (TGS-REP). Breaking down the TGS-REP reveals that the DC first checks if the requested service is valid i.e., if the File Server actually exists in the domain or not. If the requested service actually exists, it sends a TGS for the requested service back to the user.

The TGS consists of two parts. The first part contains the session key, Privilege Attribute Certificate (PAC) data etc. It is encrypted using the service’s (i.e., the file server in this example’s context) password. The second part contains metadata relevant to service request.

5.?In the fifth step, the user sends the TGS to the server/system it wishes to connect to, which is the file server here. The file server checks the authenticity of the TGS by decrypting it with its own password. If it can decrypt it successfully with its own password, it knows that the TGS came from the KDC, the only other entity which could have known it’s password other than the File Server itself. The File server then checks the PAC data and validity and if everything checks out, it grants access to the user.

Kerberos Attacks

No security mechanism is perfectly immune to attacks and Kerberos is no different. We will now try and understand some Kerberos attacks and how they work.

1.?AS-REP Roasting

We know that the first step in Kerberos is the user authenticating himself with the DC. Successful authentication is required to obtain a TGT. Right? Well, kinda. Turns out that there is an option in the Domain Controller’s Users settings which says “Pre-Auth not required”. When this setting is enabled, a user need not necessarily authenticate himself with the DC to obtain a TGT. He will get a TGT without authentication too. If we recall, the TGT comprises of two parts, one of which is encrypted with the user’s password.

So now a threat actor has gained access to a legitimate user’s TGT without having to authenticate himself as the user. The threat actor will now brute force the user’s password and if it was a weak password that was ultimately cracked by the brute-forcing the user’s password and therefore the user’s account has been compromised. Therefore, anyone with a line-of-sight connectivity can gain access to a vulnerable account. This attack is known as AS-REP roasting.

2.?Kerberoasting

Normally, services are run by the computer under the system-service user known as NTService/service_name. Certain services can be deployed via user accounts. Ex: MSSQLSVC user can be used to run MSSQL on a server.?

As we know, any user with a valid TGT can request for a TGS. When Services are deployed via user-accounts, rather than system service accounts, the TGS obtained by a user can be exploited. How? If you can recall, the TGS contains a portion that is encrypted by the service’s password. If the service was running as a system service, it would have a very strong system-generated password that can resist brute-force attacks. But in the case of services deployed via user accounts, a human sets the password for the service. If that password is weak, it can be cracked by brute forcing the TGS’s service password encrypted portion. Therefore, the service’s password and thereby the service have been compromised. This is known as Kerberoasting.

3.?Golden & Silver Ticket Attacks

In the beginning of the blog, we noted that the KRBTGT account on the domain controller holds the password to all known systems in the domain, including its own password. If an attacker is able to compromise the domain controller, he can get the NTDS.dit file from which he can get the password hash for the KRBTGT account.

This is huge, because it is the KRBTGT that issues TGTs and TGSs. The attacker now basically owns the domain. He can create tickets to any system he wants to access, create new users or create new services which don’t even exist! The KRBTGT password never changes (by itself, it can be manually changed).?This makes these attacks persistence attacks. Even if the attacker is detected and kicked from the network, when he manages to gain access again, even if it is low level access, he can escalate his privileges and do literally whatever he wants because he owns the KRBTGT account.