How to Guard Against Kerberoasting Attacks
The cyberattack method called Kerberoasting has been around for a while. But that doesn’t mean that cybercriminals love it any less. Kerberoasting remains one of the most pervasive and effective attacks against Microsoft Active Directory (AD).
In December 2020, the U.S. Department of Homeland Security issued a directive instructing federal agencies to guard against Kerberoasting as part of mitigating the danger of the SolarWinds attack. The technique has also been linked to ransomware attacks. For AD admins, Kerberoasting is a tactic they would regret overlooking.
As a quick primer: Kerberos is an authentication protocol that is used to verify the identity of a user or host. Clients receive tickets from the Kerberos Key Distribution Center (KDC) that they then provide to servers when connections are established. (Every domain controller has a KDC.) In Active Directory, the Ticket Granting Ticket (TGT) gives the user permission to request a Ticket Granting Service (TGS) ticket that can be used to gain access to domain-joined resources such as a file server.
Given its role in authentication, Kerberos is an obvious target of interest for attackers. The Kerberoasting tactic is one of the primary methods threat actors use to tighten their grip on their victims. Once attackers are inside the targeted environment, they execute Kerberoasting to steal hashes for service account credentials. These accounts, which often have administrator privileges, are frequently neglected and tend to have weak and non-expiring passwords. A benefit of the attack for cybercriminals is that they do not have to be logged on with elevated privileges to execute. The account of any domain user will do.
Here’s how Kerberoasting works:
- After compromising a domain user account and authenticating to AD, the threat actor receives a Ticket Granting Ticket from the KDC on their local domain controller. From there, the attacker requests a service ticket from the DC for whatever service they choose to target.
- The domain controller will create a Ticket Granting Service ticket, encrypt it with the service’s password, and then hand it off to the user. In normal cases, the user then passes the TGS ticket to the service, which will then decrypt it and either grant or deny access based on whether the user has the proper privileges.
- The threat actor doesn’t necessarily care about accessing the service; they already have what they need by receiving the TGS ticket. With this ticket, the attacker possesses the service account’s weakly encrypted password hash (remember, the hash was used to encrypt the contents of the ticket). The attacker can then extract the password hash from system memory via tools like Mimikatz and then crack it offline with tools such as Hashcat and John the Ripper. With the password hash cracked, the attacker can leverage the service account’s elevated privileges or continue domain reconnaissance.
Attackers can identify service accounts they want to target by enumerating Service Principal Names (SPNs) in the AD environment. SPNs are used to advertise services in AD so they can be easily discovered by users. All users that have authenticated to AD can query for accounts with an SPN. For practical reasons, only domain user SPNs are vulnerable to Kerberoasting. Host-based service accounts use a 128-character, randomly generated password that is changed every 30 days, and group managed service accounts (gMSAs) have random, complex, >100-character passwords that are changed automatically. SPNs tied to domain user accounts have passwords created by people and are therefore more likely to be weaker and easier to crack.
Fighting Back Against Kerberoasting
Mitigating Kerberoasting is difficult because the attack abuses the inherent functionality of Kerberos. For example, any authenticated domain user can request TGS tickets for a service on the network. The problem, however, is that the domain controller handling the request doesn’t care whether the user has access rights to the service for which they’re requesting the ticket. It’s the service itself that enforces access control, thereby creating the opportunity for the attack.
None of this means, however, that organizations don’t have the means to fight back. From the standpoint of detection, organizations should monitor for suspicious activity, such as a domain user account that requests an unusual amount of service tickets. Organizations can audit Kerberos Service Ticket Operations, though doing so will generate so many logs that the output will likely be useless without significant effort to establish a baseline for that specific environment.
Because of the amount of noise that approach might create, a better strategy for stopping these types of attacks might simply be to require stronger passwords for service accounts. Those passwords should have at least 30 characters and should also be rotated periodically to reduce risk. Random password generators are widely available, so it’s simply a matter of keeping track of them (preferably in a privileged access management solution).
In addition, organizations must ensure that they are properly monitoring and managing service accounts. Accounts with excessive privileges are particularly attractive targets for attackers. In the same vein, privileged accounts (such as Administrator) should never have SPNs associated with them.
Through good password hygiene and continual monitoring, organizations can reduce the threat of cybercriminals using the perpetually popular tactic of Kerberoasting to breach their Active Directory environments.