In our previous blog posts, we demonstrated how important it is for penetration testers to get credentials that grant administrative access over hosts within the organization to escalate their permissions. This week, we will discuss a relatively recent privilege escalation technique known as Kerberoasting, which pen testers and malicious hackers can use to crack weak network service account passwords.
Kerberoasting, released at DerbyCon 2014, has become a go-to technique for domain privilege escalation after gaining initial access. It takes advantage of a little-known feature of Microsoft Kerberos that allows domain users to request an encrypted version of specific service account passwords. If the passwords aren’t secure, pen testers can get access to them offline using a GPU-based password cracker.
Taking Advantage of Kerberoasting
To take advantage of this feature, a service account must be associated with a Service Principal Name (SPN) in the domain. Most SPNs are associated with computer accounts, which by default have strong randomly generated passwords that are automatically changed monthly. Service accounts, on the other hand, are user accounts designed for a specific purpose, so the password is usually set manually by an IT administrator. Whenever a password is set manually, there’s the potential for it to be easy to remember, and in turn, a potential vulnerability for pen testers or attackers to exploit.
Even though it is not common to associate service accounts with SPNs, we find that most large organizations tend to have several service accounts configured in this manner. Most commonly, we find Microsoft SQL (MS SQL) service accounts configured this way. A service account generally needs to have at least local administrative access over its associated host. However, many organizations find it easier to provide the service account with access to multiple hosts.
For example, if we find a MS SQL service account called “sqlAdmin,” there is a good chance that it has administrative privileges over all MS SQL servers in the organization. Occasionally, we even find that a service account has been granted excessive domain permissions, such as being placed in the Domain Admins group.
Furthermore, we find that service accounts are frequently configured once and then left alone for extended periods of time. Most service accounts that we compromise using this method were created several years ago and configured in a way that the password never expires.
How Kerberoasting Works
Kerberoasting does not involve abusing an unpatched vulnerability in Windows Domains; instead, it leverages normal Kerberos authentication. In short, the way Kerberos allows users to authenticate to domain services (file servers, MS SQL servers) is through Ticket-Granting Service (TGS) tickets. A portion of this TGS ticket is symmetrically encrypted with the password hash of the account for that service. For example, if a user wants to access a share, or a file on a file server named FS01, the user will request a TGS ticket for the CIFS service for host FS01.
This ticket contains all the information that the file server FS01 will need to validate if the user has access to the CIFS service. To prevent the user from modifying the authentication data in the TGS ticket, the data is symmetrically encrypted with the NTLM password hash for the account associated with this host’s CIFS service. By default, that would be the NTLM password hash for the file server’s computer account “FS01$.” Our pen testers can request this TGS ticket and try to brute force the account password. However, by default, the computer account password is a randomly generated powerful password that is changed monthly, so it would be next to impossible for us to break through. Even if it were to be cracked, the password would only be valid for the remainder of that month.
Not all services in the domain are associated with computer accounts. It’s highly dependent on the organization. But our operators can usually find at least one SPN that has been associated with a non-computer account. We go through the same procedure as before, but this time we convert the TGS ticket into a hashcat-compatible format that we can try to crack offline.
Another feature of this technique is that only internal network communication can take place between our compromised host and the Key Distribution Center (KDC), which is typically a Domain Controller. Requesting of TGS tickets is typical windows domain traffic, and no traffic is sent to the host running the service we are trying to access. This enables us to request these tickets for any service in the forest, not just our current domain. This is important because even if firewall rules prohibit lateral movement into another domain, we can still request TGS tickets that are encrypted with the password hash of service accounts in another domain.
Note that this technique is highly dependent on the service account using a weak password that we can crack during an assessment. Many organizations believe that the primary threat to weak service account passwords is an attacker attempting an online brute-force attack. In this case, the attacker would have a limited number of guesses before the account is locked out and security staff is alerted. Kerberoasting provides an avenue for the tester or attacker to conduct an offline brute-force attack. Many passwords guesses can be attempted in a short timeframe without the possibility of an account lockout. For instance, a single modern consumer-grade GPU can guess well over 100 million passwords per second.
Summary and Mitigations
Weak passwords that can be cracked quickly are the root cause for kerberoasting effectiveness. By having and enforcing a complex password (12 characters or more with a mix of numbers/letters/specials/upper/lower) policy for all users, especially for service accounts associated with SPNs, an organization can defend against these attacks. One way to mitigate some of the effectiveness of kerberoasting is by using Microsoft’s “Managed Service accounts.” Once set up, Managed Service accounts will automatically change passwords for these accounts every month, thus lowering the usefulness of any cracked passwords to a month at most. Additional reading on Microsoft’s service account setup and a step-by-step guide can be found here.
We will discuss phishing payload techniques in our next blog to wrap up our penetration testing blog series. In the meantime, catch up on our previous blogs and learn more about our pen testing services.