Kerberoasting may sound like a complicated cyberattack, but in reality, it is a straightforward technique that preys on human behavior and system vulnerabilities. This attack targets Active Directory service account credentials, which are used to run specific services on a network. These service accounts have passwords that are often weak, easily guessable, and rarely changed.
The technique works by requesting a ticket-granting service (TGS) ticket for any service, capturing it from memory, and then attempting to crack the service credential hash offline using password-cracking tools. This attack can be carried out by any user on a domain, not just administrators, making it a pervasive threat that can easily fly under the radar.
One of the main reasons Kerberoasting is so effective is because of the vulnerability in the architecture of Kerberos authentication. Kerberos was designed to allow authenticated domain users to request TGS tickets for any service on the network, without enforcing whether the user has access to the service in question. The service itself does the enforcing, leaving the door wide open for an offline attack.
Kerberoasting attacks are a favorite of advanced threat actors, as well as penetration testers and red teams, because they enable privilege escalation and lateral network movement. Once attackers are established inside an enterprise network and have begun reconnaissance for lateral movement, they can use this technique to move laterally throughout the network and gain access to additional resources.
Imagine
Picture this: a hacker has infiltrated your organization’s domain user account. They don’t need to have any special privileges, just a foot in the door. Once they’re in, they authenticate to the domain and receive a ticket granting ticket (TGT) from the Kerberos key distribution center (KDC) that is signed by its KRBTGT service account in Active Directory. This is where the real danger begins.
The malicious actor requests a service ticket for the service they want to compromise. The domain controller retrieves the permissions out of the Active Directory database and creates a TGS ticket, encrypting it with the service’s password. Only the service and the domain controller can decrypt the ticket since they are the only ones who share the secret.
The domain controller hands over the service ticket to the user, which is then presented to the service. The service decrypts it and determines if the user has permission to access it. But here’s the scary part: at this point, the attacker can extract the ticket from system memory and crack it offline.
To make matters worse, there are tools like Impacket, PowerSploit, and Empire that automate the process of cracking passwords. They request service tickets and return crackable ticket hashes in formats that are suitable for submission to cracking tools like John the Ripper and Hashcat. These tools can pry plaintext credentials from vulnerable hashes, making it easy for attackers to gain access to critical systems.
What’s even more concerning is that advanced attackers are becoming surgical about the services they choose to target, like databases or critical applications. They may request only a single ticket or a handful, leaving very few traces and lowering their chances of detection. And services that have been in place for a while likely have old, weak passwords, making them even easier targets.
Kerberoasting attacks, along with other threats against Active Directory like Golden Ticket and Silver Ticket attacks, pose a significant risk to organizations. It’s important to stay vigilant and take proactive steps to protect your systems from these types of attacks.
Test AD Environment
The following going to be my test environment.
The forest root (MARVEL.local) has one dc and one computer. The child domain (ALPHA.MARVEL.local) had one dc and two computers.
MARVEL.local
- DC — Win 2019
- Computer — win 10 (computer1$)
ALPHA.MARVEL.local
- DC — Win 2016
- Computer — win 10 (computer2$, computer3$)
We also have a few users on each domain.
Let’s Attack
- Find user accounts used as Service accounts (using Powerview)
2. Request a TGS
.\Rubeus.exe kerberoast /outfile:hashes.kerberoast
3. Crack it
hashcat -m 13100 --force -a 0 ticket passwords_kerb.txt 
We got the password for the account.
Since service accounts are typically over-permissioned in many enterprises, often with weak passwords, this is an easy way for an attacker to go from domain user to domain admin.
Tips and Tricks
If you have enough permissions over a user you can make it kerberoastable:
Set-DomainObject -Identity <username> -Set @{serviceprincipalname='just/whateverUn1Que'} -verboseConclusion
So, what can organizations do to protect themselves against Kerberoasting attacks? One key step is to implement strong password policies and ensure that all service accounts have strong, unique passwords that are changed regularly. Additionally, organizations should consider implementing two-factor authentication, which would make it more difficult for attackers to steal TGS tickets.
Another important step is to monitor network traffic and look for signs of suspicious activity, such as multiple TGS ticket requests for the same service account. This type of activity could indicate that an attacker is attempting to steal credentials through Kerberoasting.
Ultimately, the best defense against Kerberoasting attacks is a multi-layered approach that includes strong passwords, two-factor authentication, network monitoring, and regular security awareness training for employees. By taking these steps, organizations can better protect themselves against this pervasive and dangerous attack technique.
Hay Yay!!!
Please give me a clap if you found it to be useful and follow me to get more hacking knowledge.
