Kerberos ticket abuse is a significant issue for organizations that use Active Directory. Kerberos is the default authentication mechanism in Active Directory environments, and if an attacker can compromise or forge Kerberos tickets, then they may be able to gain a solid foothold in the domain. This post is primarily aimed at testers who perform, or will be performing, internal network penetration tests. I’ll be going over two common methods for exploiting Kerberos tickets and highlighting a third. First, I’ll discuss AS-REPRoasting, in which an attacker is able to obtain a Kerberos Ticket Granting Ticket (TGT) on behalf of a user configured to not require Kerberos pre-authentication before the Domain Controller issues the TGT. After that, I’ll go through the well known and loved Kerberoasting attack, which abuses user accounts configured with Service Principal Names (SPNs) used to run services. One drawback to the Kerberoasting attack is the need for existing user credentials. This is especially true if you, as a tester, are struggling to find a way into the environment and other methods of gaining access to a user account have failed. Which brings me to the ”third” attack…Kerberoasting through the AS-REPRoastable user. I put third in quotes because this is not a completely separate and distinct attack, but a combination of the two. This alleviates the need for user credentials to obtain service tickets for those user accounts being used to run services. Since many times services run with elevated permissions, if you can crack the password hash of one of those accounts, you could very well end up not only snagging user credentials, but potentially user credentials for an account that can do some things! It should be noted that the exploit methods outlined in this article are not particularly stealthy, so “red teams” and anyone else concerned about not getting caught by defenders should think twice before following along with these steps. I’ll also discuss mitigations and detections for these abuses, but the primary focus is on the testing/exploit aspect of these issues.

Before getting into further discussion of Kerberos ticket abuse, it’s important to define some terms.

Terms

1. Domain Controller (DC): A server that manages access to network resources in a Windows domain, including authentication and directory services.
2. Key Distribution Center (KDC): A component of the Kerberos protocol responsible for issuing tickets and authenticating users and services.
3. Authentication Service Request (AS-REQ): A request sent by a client to the KDC to obtain an initial authentication ticket.
4. Authentication Service Response (AS-REP): The response from the KDC to the client’s AS-REQ, containing the ticket granting ticket (TGT).
5. Ticket Granting Service Request (TGS-REQ): A request sent to the KDC to obtain a ticket for a specific service, using the TGT.
6. Ticket Granting Service Response (TGS-REP): The response from the KDC providing the ticket for the requested service.

A Simplified Overview of Kerberos Authentication

Kerberos is complicated, and the complete inner workings of the protocol is outside the scope of this article. For a shared understanding on how Kerberos authentication works, I want to share an analogy I heard recently. I had the privilege of attending a workshop put on by Tim Medin from Red Siege (who incidentally discovered Kerberoasting in 2014). Before this workshop, the main analogy for Kerberos authentication I had heard was that of going to a theme park. However, Tim’s analogy resonated a lot more with me, so that’s the one I’m going to use here.

Movie Pass was a service that allowed customers to go see unlimited movies in theaters. For this analogy, consider the following:

1. A customer sends their credit card number to Movie Pass. After verifying that the credit card number is valid, Movie Pass sends the customer back a card they can carry in their wallet that they can use at participating theaters. Think of this as the user sending an AS-REQ to the KDC, and the KDC verifying the user’s hash and sending back a TGT in an AS-REP message.
2. The customer takes the Movie Pass card to the theater and presents it to the person working at the counter and tells them what movie they want to see. The worker behind the counter checks the movie pass card and then gives the customer a paper ticket for the movie they want to see. Think of this as the user sending their TGT to the KDC and requesting a TGS for a specific service in the domain via a TGS-REQ, then the KDC sending back a service ticket in a TGS-REP message.
3. After they get their ticket and take out a second mortgage on their house for a large popcorn and a drink, the customer takes the paper ticket over to the 16-year-old kid at the specific auditorium where the desired movie is showing. The kid takes the ticket, rips it in half, and allows the customer to enter the auditorium to watch the movie. This is the equivalent of the user presenting their service ticket to the desired domain service.

What is AS-REPRoasting?

Note that the only time the user needs to present their credit card number (password hash) is when they initially purchase the Movie Pass (AS-REQ). It’s the same in the AD environment; the only time a user needs to present their password is during the initial authentication step. This is known as Kerberos pre-authentication, and its main purpose is to ensure the user who requests the TGT is who they say they are. It is possible, however, for users to be configured that they do not require Kerberos pre-authentication to retrieve a TGT. When users are configured this way, any other user may request a TGT on that user’s behalf. Because the AS-REP message contains a portion that is encrypted with the user’s NT hash, it is possible to perform an offline brute force password attack with a tool like Hashcat. This attack is known as “AS-REPRoasting”.

What is Kerberoasting?

Kerberoasting is very similar to the attack outlined above, except that instead of targeting users configured to not require Kerberos pre-authentication to get a TGT on their behalf, the Kerberoasting attack abuses the fact that any authenticated domain user can request a service ticket for any service in the domain. In Active Directory, services are distinguished by a Service Principal Name (SPN). When user accounts are configured with an SPN, they effectively function as service accounts.

The major issue arises if those user accounts acting as service accounts have weak passwords set. The TGS-REP message contains an encrypted part which is encrypted with a key derived from the password of the service account (the service account’s NT hash). Since any authenticated user can request a service ticket for any service in the domain, that includes those user accounts with SPNs that may be using weak passwords. Although Kerberoasting is similar in principle to AS-REPRoasting, it could potentially be far worse because service accounts often have some degree of elevated privileges (not always, but often), whereas normal user accounts probably don’t.

The Attacks

To demonstrate these attacks, we’ll be using Game of Active Directory (GOAD), which can be installed using the instructions here. The following table highlights the relevant infrastructure:

IP	Description
10.4.10.11	Domain Controller

AS-REPRoasting

The following snippet shows the AS-REPRoast attack in action. Here, I’m using the GetNPUsers.py tool from the Impacket toolkit.

Let’s break this command down a bit:

• -dc-ip: This is the IP of the target DC.
• -usersfile: This is the list of usernames to test. This can be a list enumerated through other means, such as anonymous RPC, brute forcing usernames with a tool like Kerbrute, etc.
• north.sevenkingdoms.local/: This is the target domain.

Note that the brandon.stark user does not require Kerberos pre-authentication and we’re able to obtain the hash from the AS-REP message, which again, is encrypted with a key derived from the user’s password (NT hash). I ran into this on a recent internal network penetration test where I was able to obtain AS-REP hashes for two users, which subsequently cracked and gave me access to a bunch of other resources in the domain. I’ll circle back to this shortly, but before I do, let’s briefly discuss Kerberoasting.

Kerberoasting

The following snippet shows this in practice:

Awesome, we were able to obtain TGS hashes for several users configured with SPNs. For the purpose of demonstration, we can dump the jon.snow user’s TGS hash into a file and perform an offline password attack with hashcat. In this case, it cracks quickly.

Cool, but cracking is not the point of this blog post. At this point I should highlight a couple of things:

• In the recent engagement I mentioned, the two AS-REPRoastable user account hashes “cracked”, and I was able to retrieve the plaintext passwords which I could use for additional domain enumeration.
• Here is a good point to reiterate that Kerberoasting can often be more impactful than AS-REPRoasting by virtue of the likelihood of service accounts having elevated privileges that “normal” user accounts probably don’t have. There’s a catch though…to perform a Kerberoasting attack, the attacker needs to already have a set of valid domain credentials.

Skip the Line

So… what if you’re on an engagement and you’ve identified an AS-REPRoastable user, but despite your best hashcat-fu, the sucker just won’t crack. What if no amount of other AD trickery has yielded another domain account that you can use either? The answer is: Kerberoast through the AS-REPRoastable user. Going back to our (Tim’s) original analogy:

• Imagine Bob has won a contest where the prize is a free Movie Pass. Since Movie Pass has it in their system that Bob is not required to provide credit card information to receive the nifty card to put in his wallet, Alice can go to Movie Pass and say, “I’m Bob, please send me a nifty card that I can put in my wallet”. Since this exists in a world where no other forms of identification exist, Movie Pass says, “Sure, here’s your nifty card!” Alice can now go see as many movies as she wants.

That’s essentially what we’re doing here. For this example, I’m going to tell the DC, “I’m brandon.stark…give me all the service tickets!” Since the brandon.stark user doesn’t require pre-authentication, the DC KDC says, “sure, here you go!”

This is the Kerberoasting through the AS-REPRoastable user attack in practice:

Brilliant! Now we have a service ticket that we can try to crack without first needing to have valid user credentials. The only real difference between this and the previous command is the -no-preauth flag, which takes the name of the account that does not require Kerberos pre-authentication.

Mitigation

Knowing the attack is great, but that doesn’t do our customers any good. So how do we mitigate this?

AS-REPRoasting

AS-REPRoasting is categorized in the MITRE ATT&CK Framework underneath “Steal or Forge Kerberos Tickets”, with technique ID T1558.004.

To mitigate the risk associated with AS-REPRoasting, we recommend the following measures:

• Require Kerberos pre-authentication to the maximum extent possible. Pre-authentication is enabled by default; if it is necessary to disable pre-authentication, ensure that a strong password is set for the user.
• Enable AES Kerberos encryption rather than RC4 wherever possible. Attackers generally prefer RC4 because it is much easier to crack than AES. Although requiring AES may not necessarily prevent AS-REPRoasting from occurring, it will make it easier to detect.

Kerberoasting

Kerberoasting is also categorized in MITRE ATT&CK under “Steal or Forge Kerberos Tickets”, with the technique ID T1558.003.

To mitigate Kerberoasting, we recommend the following:

• Enable AES encryption for all Kerberos requests and limit the use of RC4 as much as possible.
• Consider implementing Group Managed Service Accounts (gMSAs) rather than configuring user accounts with SPNs to run services. This will go a long way to mitigating the use of weak passwords. Unlike normal user accounts, gMSAs are managed by Active Directory and their passwords are randomly generated and automatically rotated every 30 days. If implementing gMSAs is not possible, ensure strong passwords are set for all accounts…especially those configured with SPNs used to run services.
• Adhere to the principle of least privilege and restrict service accounts to the lowest possible privilege level.

Detections

Detections methods for these attacks include:

• Monitor for anomalous activity, particularly accounts making a high number of Kerberos ticket requests in a small amount of time. Microsoft Event IDs 4768 (A Kerberos authentication ticket (TGT) was requested) and 4769 (A Kerberos service ticket was requested) should be monitored.
• Look for requests made using RC4 encryption (type 0x17). This is a reasonable indicator of a potential attack, but it should be noted that there might still be times when Windows uses RC4. If the environment is configured to use AES for tickets, then the use of RC4 should stand out and be investigated.
• Consider the use of honey accounts. An example of this could be a legitimate-looking account configured with an SPN that isn’t used for anything. If you go this route, make sure a very strong password is set. Any service ticket requests for this account should be considered a high-fidelity indicator of an attack and should absolutely be investigated.

Summary

AS-REPRoasting and Kerberoasting are two common Kerberos ticket attacks. The misconfigurations that allow these attacks could have serious implications on their own, but the combination of the two attacks could be especially bad because the presence of a user account that does not require Kerberos pre-authentication removes the requirement for an attacker to have valid user credentials before being able to request service tickets.

The following table highlights the key components of each attack, their requirements, and their mitigations:

Attack	Misconfiguration	Requirements	Mitigations
AS-REPRoasting	User accounts configured to not require Kerberos pre-authentication	Network access	Require Kerberos pre-authentication for all accounts whenever possible. If it is necessary for an account to be configured without pre-authentication, ensure a very strong password is set for the account.   Restrict the use of RC4 encryption as much as possible. This will make ticket requests that use RC4 stand out more to defenders.
Kerberoasting	User accounts configured with SPNs being used to run services	Network access and valid domain account credentials	Limit the use of RC4 as much as possible.   Consider using gMSAs where possible instead of configuring user accounts with SPNs   Adhere to the principle of least privilege for all service accounts

Next time you’re stuck on a test, and you’ve identified an AS-REPRoastable user, consider Kerberoasting service accounts through that user. You may get lucky if those service accounts are configured with weak passwords, and then you’re off to the movies!