An Introduction to Kerberoasting
In today’s blog, we will be taking a high-level look at a popular attack called Kerberoasting. Kerberoasting is used by attackers to escalate privileges once they gain initial access to an internal network. As penetration testers, we regularly use this attack vector during engagements and are generally successful in doing so. Let’s take a look at some background information on the Kerberos protocol first.
Kerberos
Kerberoasting takes advantage of weaknesses within the Kerberos authentication protocol in a domain environment. The diagram below is a high-level look at how Kerberos works. In order to ensure a user is authorized to access the application server in the diagram below, the user first authenticates to the domain controller with valid credentials (steps 1 and 2 below). In step 3, the user requests a ticket to use the application server, which is granted in step 4. This ticket granting service (TGS) contains the hashed credentials of the service requested, or the service account, as part of the ticket. This is by design and is used to ensure the user only gets access to the service they were authenticated for. However, using this process, any domain user can request service account tickets from the Domain Controller that contain a password hash for those service accounts.
Kerberoasting
Service principal names (SPNs) are used to identify each instance of a Windows service. To enable authentication, Kerberos requires that SPNs be associated with a service logon account i.e. the account specifically tasked with running the service.
In a Kerberoasing attack, an attacker can run a script to obtain all of the SPN’s on the domain, and then request a service ticket for each service, which as mentioned earlier, contain the password hash of the service account. These password hashes can then be taken offline and cracked.
It is quite common that the passwords for these service accounts are rarely changed, and as companies change and improve their password policies, these service accounts are often left behind. The image below is an example from a recent engagement, and as you can see, the MSSQLSvc account’s password was last set in 2012!
Therefore, although this particular company had recently introduced a very strong password policy with a significantly increased minimum length, some of the service accounts hadn’t been changed in so long, they still had very weak passwords set.
Due to these weak passwords, Triaxiom was able to crack several of the gathered hashes in less than an hour. Some of these service accounts happened to be members of the ‘Domain Admins’ group, and at that point Triaxiom had obtained full control over the domain.
Remediation
To protect against kerberoasting, service accounts should have long, complex passwords set, as they don’t have to be manually entered in by a user. These service account passwords should be changed annually as part of a regular process. Finally, restrict the permissions of service accounts to the least necessary and avoid putting them in the Domain Admins group whenever possible. Hopefully this blog gave you a better understanding of the Kerberos protocol and how it can be abused to launch a Kerberoasting attack. If you have any questions or are concerned that you may be vulnerable, feel free to reach out and we’d be happy help!
