Active Directory (AD) is central to modern enterprise networks, handling authentication, access control, and user management. But its complexity also makes it a prime target for attackers. One such attack is Kerberoasting, and understanding it is essential for defending your AD environment. In this third blog post, I will touch upon what Kerberos is, how it might be exploited and the importance of proper password policies, encryption algorithms and what one should consider when using Kerberos in Active Directory.
AD uses Kerberos as its primary authentication protocol. Kerberos It issues tickets to verify identities and authorize access to resources. These tickets include:
Service accounts, which are often privileged and used by applications, authenticate via Service Principal Names (SPNs), making them potential targets.
Kerberos Mutual Authentication Process
Client authenticates against the authentication server, and issues Ticket Granting Ticket (TGT).
TGS verified TGT and issues Service Ticket (ST) to Client.
Client sends ST to Service. Service verified ST and grants/decline access.
Kerberoasting takes advantage of how Kerberos handles service ticket requests. An attacker with domain access can request a service ticket for a targeted service account. Because these tickets are encrypted with the service account’s password hash, the attacker can extract them and attempt to crack the password offline.
Service accounts in Active Directory provide authentication and authorization for services and applications, allowing them to run with the necessary permissions without user credentials. They’re often used for automated tasks like backups or updates and typically hold elevated privileges, making them attractive targets.
Each service account can be associated with a Service Principal Name (SPN) — a unique identifier that allows Kerberos to authenticate services on the network. When a service account requests a Kerberos ticket, it includes its SPN to verify its identity to other services. While SPNs enable secure service authentication, misconfigured or poorly managed SPNs can become a vulnerability, exposing accounts to attacks like Kerberoasting.
Once a service account password is recovered, it often grants elevated access within the network, potentially enabling lateral movement, privilege escalation, or further attacks.
Common tools used in this attack include Mimikatz, Rubeus, and Impacket for ticket extraction, and Hashcat to perform offline password cracking.
This attack works because of several common weaknesses in AD environments:
Weak password policies: Inadequate complexity requirements or no enforced minimum lengths leave accounts exposed to brute-force attacks.
Lack of password rotation: Service account passwords often remain static, increasing the window of opportunity for an attacker to successfully crack a ticket.
Overprivileged service accounts: Accounts with excessive permissions increase the damage an attacker can do once credentials are obtained.
Misconfigured delegation settings: Delegation allows a service to act on behalf of a user. If poorly configured, it enables attackers to impersonate users and request tickets to other services.
Insufficient monitoring: Without alerting systems in place to flag unusual ticket requests or other anomalies, Kerberoasting attacks can go undetected.
Using the PowerView module, after identifying a potential victim, the ticket can be extracted into a format that can then be used in Hashcat to be cracked:
> Get-DomainUser -SPN | Get-DomainSPNTicket -Format Hashcat
Rubeus is also another tool that can automate this exploit. It is also possible to retrieve the ticket from memory using Mimikatz. Another way to identify possible vulnerable entities in the system is to use Bloodhound. This tool visually maps out relations, permissions, and connections. In this case, the kerberoastable account SQLSERVICE has Admin permissions to LABDC.
If the password is crackable, then the cleartext password can be used for authentication. In this case it could be used to access LABDC.
Protecting your AD environment requires a combination of preventative measures and proactive monitoring:
Enforce strong, complex passwords for all accounts, especially service accounts. Combine this with mandatory regular password changes.
Upgrade to AES256 encryption for Kerberos authentication where possible, eliminating weak algorithms from your environment.
Review and restrict delegation settings to the minimum necessary. Avoid unconstrained delegation wherever possible, as it broadens the attack surface.
Apply the principle of least privilege, ensuring service accounts have only the permissions required for their function.
Implement continuous monitoring for abnormal Kerberos ticket activity, such as a high number of service ticket requests or unusual account behavior.
Security assessments and audits play a key role here too. Tools like BloodHound can map attack paths and privilege relationships, while Microsoft Baseline Security Analyze (MBSA) can identify configuration flaws. Though built for offense, Kerberoast (the PowerShell tool) can be used defensively to find vulnerable accounts and Mimikatz remains valuable for testing ticket extraction protections.
Final thought: If you’ve lost track of your service accounts or aren’t monitoring their behavior, attackers might already be ahead. Time to audit, clean up, and lock them down.
Next up in this series: Delegation settings, and why you should be wary of anything “unconstrained.”