This is the latest in a series of posts we’re calling “QOMPLX Knowledge.” These posts are intended to provide basic information and insights about the attack activity and trends that are driving malicious campaigns and that QOMPLX researchers encounter in our forensic work with customers.
Kerberoasting is a pervasive attack technique targeting Active Directory service account credentials. Advanced and lesser-skilled attackers alike favor Kerberoasting because the technique can be carried out by any user on a domain—not just administrators. It is also an “offline” attack that doesn't require any packets be sent to the targeted service—traffic that would be logged and quite possibly trigger alerts. Kerberoasting, instead, takes advantage of human nature nearly as much as it exploits known security weaknesses in Kerberos authentication for Active Directory. At its core, Kerberoasting is a password-cracking attack in which credentials are stolen from memory and cracked offline.
- Kerberoasting is a post-exploitation attack that extracts service account credential hashes from Active Directory for offline cracking.
- Kerberoasting is a common, pervasive attack that exploits a combination of weak encryption and poor service account password hygiene.
- Kerberoasting is effective because an attacker does not require domain administrator credentials to pull off this attack and can extract service account credential hashes without sending packets to the target.
How Kerberoasting Attacks Work
Like most attacks against Active Directory, Kerberoasting enables privilege escalation and lateral network movement. The technique was unveiled by researcher Tim Medin at the 2014 DerbyCon conference in Kentucky. Since then it has become a standard tool in the toolkit of advanced threat actors as well as penetration-testers and red-teams.
Kerberoasting is used by attackers once they are established inside an enterprise network and have begun reconnaissance for lateral movement. The technique allows the attackers, as valid domain users, to request a Kerberos service ticket for any service, capture that ticket granting service (TGS) ticket from memory, and then attempt to crack the service credential hash offline using any number of password-cracking tools, such as Hashcat, John the Ripper, and others.
Kerberoasting attacks are possible because of vulnerability in the architecture of Kerberos and another reliable element: insecure user behavior.
In Kerberos based systems such as Active Directory, the TGT (Ticket Granting Ticket) is the user’s authorization to request ticket granting service (TGS) tickets for various domain resources. By design, TGS tickets are encrypted with the service account’s NTLM hash. In Microsoft Windows, service principal names (SPNs) identify service accounts that are used to encrypt TGS tickets. They can be linked to either host- or domain user accounts.
Kerberoasting attacks work only against domain user SPNs. That is because host-based SPNs are secured with random 128-character passwords that are changed every 30 days. These long, random, and short lived passwords are practically unguessable, even with modern password cracking tools and hardware.
User account SPN passwords are a different story. These are chosen by human beings, may never expire, and may be changed only rarely. Given human tendencies, often these passwords are common, weak and easily guessable. Often they are also years old, making them easy targets for offline cracking.
This is where the architectural design limitation comes in. The design of Kerberos authentication allows authenticated domain users to request a TGS ticket for any service on the network. However, the domain controller the user is requesting the ticket from does not enforce whether the user has access to the service in question. The service itself does the enforcing, opening the door to an offline attack.
Elements of a Kerberoasting Attack
Here is how a Kerberoasting attack works in practice:
- To begin with, an attacker compromises the account of a domain user. The user need not have elevated or “administrator” privileges. The attacker authenticates to the domain.
- When the malicious user is authenticated, they receive a ticket granting ticket (TGT) from the Kerberos key distribution center (KDC) that is signed by its KRBTGT service account in Active Directory.
- Next, the malicious actor requests a service ticket for the service they wish to compromise. The domain controller will retrieve the permissions out of the Active Directory database and create a TGS ticket, encrypting it with the service’s password. As a result, only the service and the domain controller are capable of decrypting the ticket since those are the only two entities who share the secret.
- The domain controller provides the user with the service ticket that is then presented to the service, which will decrypt it and determine whether the user has been granted permission to access the service. At this point, an attacker may extract the ticket from system memory, and crack it offline.
- For password cracking, tools such as Impacket, PowerSploit and Empire contain features that automate the process: requesting service tickets and returning crackable ticket hashes in formats suitable for submission to cracking tools such as John the Ripper and Hashcat, which will pry plaintext credentials from vulnerable hashes.
Furthermore, advanced attackers are surgical about the services they choose to target, such as databases and or critical applications. They may request only a single ticket, or a handful leaving very few traces and lowering their chances of detection. Services that have been in place for some time likely have old, weak passwords, and those hashes can be taken offline and cracked.
Detection and Mitigation of Kerberoasting Attacks
The best mitigation defenders have at their disposal against Kerberoasting is to enforce robust password policies for service accounts. Organizations should mandate long, complicated passwords (25 or more characters) that are changed frequently. Length and complexity frustrates offline cracking efforts. Frequent password rotation, say at 30-day intervals, narrows the window of time attackers have to crack long hashes for an indeterminate length of time.
Deploying Honey Accounts
Detection of Kerberoasting attacks, meanwhile, requires logging and monitoring of activity.
Defenders can set traps within their Active Directory environment. Known as “honey accounts,” these work in a similar fashion to network honeypots: enticing advanced attackers doing reconnaissance through Active Directory with believable sounding service names. Once compromised, however, these accounts do nothing but trigger an alert if they are used to login or generate a service ticket request.
Technology such as Qomplx’s monitors for telltale signs of Kerberoasting attacks, such as domain user accounts requesting large numbers of service tickets (Event 4769).
In addition, QOMPLX’s Privilege Assurance tool reduces the likelihood of service accounts being over-permissioned. For example, these service accounts are often found to be members of the Domain Admin group or other groups that have been granted excessive permissions, far beyond what is required of them to access a service. Among other detections, QOMPLX:CYBER monitors for TGS-REQ packets via Windows Event Logs for suspicious actions (e.g. RC4 encryption), and compares transaction history with Domain Controller logs which provide coverage for establishing behavioral indicators of attempted Kerberoasting activity.
Here are the previous entries in our QOMPLX Knowledge series; look for more in our QOMPLX Knowledge series in the days and weeks ahead:
Other links to consider: