Kerberos exist for a long time and it has been the default authentication protocol for Windows, Active Directory.
Attackers have been abusing the Kerberos protocol for a while, but it’s not that Kerberos is immediately insecure. It’s the way how it has been designed.
Before we’re diving into the ways of how an attacker can exploit the functionalities of Kerberos. Lets first have a basic understanding of what Kerberos is and how it works.
Kerberos is a network authentication protocol that was developed in 1980 by MIT. This protocol’s cryptography has the purpose to ensure a secure authentication to a client, so it can prove it’s identity to a server (and vice versa) without sending unencrypted secrets over an insecure network connection.
One of the reasons why Kerberos is widely deployed is, because of the Single-Sign-On (SSO) feature that it contains. Kerberos uses ”tickets” to retain authentication, so after a user has authenticated once. They don’t need to re-enter their credentials again to access resources on the network, such as a SQL database or a fileshare.
All the Kerberos tickets are stored in the LSASS process memory.
Kerberos in a Windows domain
Every time when a user wants to authenticate. A secret needs to be provided to a client machine to proof the identity of a user. This can be done by entering a password or other authentication methods, such as a Smartcard, Windows Hello, and so on.
After a user has provided it’s secret. The Kerberos client on the machine will convert it text into an encryption key, and pass it through a one-way hash function. The encryption key of a user is derivative from a user’s logon password hash, which is primary known as the NT(LM) hash of a user. Sometimes also referred as the master key of a user.
A one-way hash is an algorithm that turns a message or text into a random value. ”One-way” means that it is very hard to convert the hash back into it’s original plain-text.
Here is an example, when we are converting a plain-text into a NT(LM) hash. Keep in mind that it’s still possible to brute-force the NT(LM) hash to obtain the plain-text password.
After a user has logged on and their secret has been converted into an encryption key and passed through a one-way hash function. It will use the encryption key to encrypt the current timestamp and send it as an authentication server request to the Key Distribution Center (KDC).
The KDC will then verify the credentials of a user by decrypting it’s NT(LM) hash and validates that it could verify the timestamp as well. The timestamp proves that the message wasn’t a replay, but that it has recently been generated.
The KDC will now perform an authentication server reply, which means that it will create a logon session key and a Ticket-Granting-Ticket (TGT). A copy of the logon session key is attached with a TGT, and the TGT is encrypted with the KDC’s master key, which is derivative from it’s NT(LM) hash.
Krbtgt is the security principal that acts as a service account for the Key Distribution Center (KDC) in Active Directory.
So, we know that a copy of a logon session key is attached to a TGT, but another copy needs to be made as well, which is making a copy of the logon session key itself, and encrypting it with the user’s NT(LM) hash.
This means that the KDC will send a TGT with an encrypted logon session key to the user as we can see here.
Here is an example of a TGT from the user, Carol. It has been encrypted with the Krbtgt security principal that acts as the KDC, and a session key has been attached to the TGT. A user’s NT(LM) hash is used to decrypt the session keys that it receives from the KDC.
A session key forms both an encryption and decryption key that is randomly generated to ensure that the communication between a user and a computer remains secure.
We have now obtained a Ticket-Granting-Ticket. A TGT is a small encrypted file that contains the user authentication token that is issued by the KDC. This TGT is equivalent to a user’s credentials. A TGT allows a client machine to perform actions on behalf of a user, which is in this example, Carol. A TGT is stored locally on a client machine to avoid that a user needs to provide a secret all the time.
With a TGT, it’s possible for a user to request Service Tickets to access a specific resource on the network. A user will need to present a TGT to the KDC first to obtain a Service Ticket (ST) for the resource it wants to access.
Service Tickets are encrypted with the NT(LM) hash of the associated service account. The NT(LM) hash is both known to the Domain Controller and the service, so the service is able decrypt the service ticket, validates the PAC, and determine what access should be granted to the service. This can be both a user account that is configured as a service account or just a regular computer account itself.
Every Service Ticket (ST) has an extension that’s called a PAC. A Privileged Attribute Certificate (PAC) is a piece of data that includes authorization data of a user. You can think of group memberships and user rights that have been assigned.
Service Principal Names
A Service Principal Name (SPN) is a concept from Kerberos. It’s an identifier for a specific service offered by a particular host within Active Directory.
This is something that has been very confusing for most IT Admins, but lets dive into a few examples to give you a better understanding.
Lets start with the TERMSRV/EXCHANGE002.IDENTITY.local – This is a SPN associated with the EXCHANGE002 server. TERMSRV is a service that is used for Remote Desktop Services.
If a user wants to use this RDP service on the EXCHANGE002 server. It first needs to provide a TGT to the KDC to obtain a service ticket for the TERMSRV service. This Service Ticket is then encrypted with the associated computer account NT(LM) hash and it will decrypt the service ticket if it could validate the PAC.
Lets assume that we do have access and we can RDP into the EXCHANGE002 server.
Now when taking a look in the memory of the EXCHANGE002 server. We can see the Service Ticket of our user Carol that has been provided for the TERMSRV service.
The MSSQLSvc is a service for the Microsoft SQL Server. This one is located on the AADConnect server. As you can see, it has a SPN associated with it, which is MSSQLSvc/AADConnect.IDENTITY.local
If you are a DBA or have been one in the past. You might be familiar with the SQL Server Management Studio (SSMS) GUI that provides you an interface to all your SQL databases.
This GUI can be installed locally on a workstation to directly connect to a SQL database without having local admin access on the server itself, which is in our example the AADConnect server.
In this case we already have access, so we only need to press the connect button to have access to our SQL databases.
After we have pressed the connect button, we’re in and we have access to our SQL databases.
Under the hood, we just have requested a Service Ticket for the MSSQLSvc service of AADConnect and as you can see. It is stored locally on our machine. We did the exact same thing like the previous step. We gave our TGT to the KDC to obtain a ST for the MSSQLSvc. We present it to the AADConnect server and the associated computer account NT(LM) hash decrypts the service ticket and validates the PAC. Access is granted if it could determine that we do have access.
Common Internet File System (CIFS) is a network filesystem protocol used for providing shared access to files and printers between machines on the network.
This is how it looks like when we are accessing a fileshare on a remote server. We would probably type something in like \\FILESERVER\Fileshare, and boom. We have access.
Same like the two examples above. We present our TGT to the KDC to get a ST for the CIFS service on the FILESERVER. We present it to the FILESERVER and the associated Computer account will decrypt the service ticket if it can validate the PAC.
- Attackers Timeline
Every time when a user logs in to a workstation. A Kerberos Ticket-Granting-Ticket (TGT) is stored locally on the machine to provide the Single-Sign-On (SSO) experience for the user.
An attacker with administrative privileges on the machine is able to extract all the Kerberos TGT’s and use it to move laterally across different machines in the network.
In the following example. An attacker has compromised the workstation of Carol and decided to dump all the Kerberos TGT’s.
After all the Kerberos TGT’s has been exported. It looks like Alice has recently logged on the workstation of Carol.
With the extracted the TGT of Alice. An attacker can use this TGT to act on behalf of the user Alice and access resources on her behalf.
Pass the ticket (PtT) is a method of authenticating to a system using Kerberos tickets without having access to an account’s password. Kerberos authentication can be used as the first step to lateral movement to a remote system.
We are now going to execute a Pass-the-Ticket attack to access the account of Alice, which gives us then the ability to access resources on her behalf.
It seems that Alice has access to the FILESERVER. This might be interesting target for us.
Now we need to move laterally to the FILESERVER.
We have now established a foothold on the FILESERVER.
Since we now have a foothold on the FILESERVER. We can dump all the Kerberos TGT’s on this server as well.
It seems that our user Bob has recently logged on this server, which means that we can now access Bob’s account.
After we have obtained the TGT of Bob. We can now do the same thing, like we did before. Which is executing a Pass-the-Ticket to access the account of Bob.
It seems that Bob is a Domain Admin or equivalent, because he has access to a Domain Controller.
This means that we now can move laterally to the Domain Controller as the user Bob, which means that we have compromised the entire network now.
Detecting Pass-the-Ticket is quite a challenge for most EDR or SIEM solutions, but if you have Microsoft Defender ATP or planning to afford it. MDAPT will catch this alert!
In my previous post, Pass-the-Hash is still a threat. I’ve blogged about how the Microsoft Administrative Tier Model can mitigate this attack. Pass-the-Hash and Pass-the-Ticket are both similar techniques that is frequently used a lot to attack corporate networks.
I would recommend to check out my previous blog post on how you can implement this security architecture in your networks.
Pass-the-Hash and Pass-the-Ticket are both techniques that are misunderstood by most people. The first thing is that Mimikatz is not the problem behind PtH & PtT. There are other other tools as well that can execute this attack. A great example is the Windows Credential Editor that was used a lot in the past.
The second thing is that Credential Guard will not prevent this attack. Sure, Credential Guard will make it harder for an attacker, but keep in mind that. A determined user with administrative rights can bypass Credential Guard.
Last, but not least. PtH & PtT are both techniques that can’t be fixed by rolling out a security patch. You still can get owned by these techniques, despite the fact that you had a fully patched environment.
Pass-the-Hash and Pass-the-Ticket are described as an operational vulnerability. What that means is, that it depends on how an IT Admin has set-up the environment. Where are the Domain Admins login in? It should only be the Domain Controller and perhaps other Tier 0 assets, but in most cases. DA’s are login everywhere from workstation to server. Spreading their credentials across the entire network, which also explains why it’s easy for an attacker to obtain Domain Admin credentials.
What I also want to mention is, that people often forget about the Single-Sign-On (SSO) feature in Active Directory. Credentials needs to be cached in memory to provide the SSO experience for a user. Once a user is authenticated. It can use one set of credentials to access resources on the network without receiving a prompt for entering a password again. End users are loving this, and you probably as well.