Understanding Kerberos and Kerberoasting

Introduction

Kerberos is the backbone of authentication in Active Directory environments. While robust, its design can be leveraged by skilled attackers. Kerberoasting is one such attack, targeting service accounts to extract their passwords offline. Understanding the full attack chain is critical for securing an AD environment.

1️⃣ Quick Recap of Kerberos

Kerberos relies on a Key Distribution Center (KDC) which handles two critical elements:

  • Ticket Granting Ticket (TGT): proves the user is authenticated to the domain.
  • Service Ticket (TGS): grants access to a specific service.

Typical authentication flow:

  1. User authenticates to the KDC → receives a TGT encrypted with their key.
  2. To access a service, the user requests a TGS from the KDC, presenting the TGT.
  3. The service verifies the TGS and grants access if valid.

Kerberos Flow

2️⃣ Kerberoasting Explained in Depth

Principle

An Active Directory user can request a service ticket for any service from the KDC. The KDC does not check the requester’s permissions; its role is only to provide the security information related to the user (via the PAC). It is the service itself that verifies the user’s rights by reading its PAC, a copy of which is included in the service ticket.

This means it is possible to request service tickets specifying arbitrary SPNs, and if these SPNs are registered in Active Directory, the KDC will return a piece of information encrypted with the secret key of the account running the service. The attacker can then attempt to recover the clear-text password of the account via exhaustive (brute-force) attacks.

Fortunately, most accounts running services are machine accounts (formatted as MACHINE_NAME$) with long, random passwords, so they are generally not vulnerable to this type of attack. However, some services are run by service accounts with human-chosen passwords. These accounts are significantly easier to compromise via brute-force attacks and are typically the primary targets in a Kerberoasting attack. Kerberoasting does not exploit a flaw in Kerberos itself, but rather how service tickets are encrypted with the service account’s NTLM hash.

Here’s the detailed step-by-step attack process:

Step 1: Reconnaissance and Targeting

  • The attacker, already authenticated on the domain, queries Active Directory to list all Service Principal Names (SPNs).
  • Each SPN corresponds to a service account tied to a service (SQL, Exchange, etc.).
  • Tools: ldapsearch, PowerShell Get-ADUser -Filter * -Properties ServicePrincipalName.

Step 2: Requesting Service Tickets

  • The attacker requests a TGS for each targeted SPN from the KDC.
  • The KDC responds with a ticket encrypted with the service account’s NTLM hash.
  • The ticket can be captured without knowing the account’s password.

Step 3: Exporting Tickets

  • Tickets are exported in a readable format (.kirbi or Base64) for offline processing.
  • This is key: the attack happens completely offline, leaving no domain-side alerts.

Step 4: Offline Cracking

  • The attacker extracts the hash of the service account password from the ticket.
  • Then runs offline attacks (brute-force, dictionary, or hybrid attacks) to recover the password.
  • Success depends on the complexity of the service account password.

Step 5: Post-Exploitation

Once the password is obtained, the attacker can:

  • Log into the targeted service directly.
  • Escalate privileges if the service account has elevated rights.
  • Pivot to other machines in the domain.

💡 Advantage for the attacker: unlimited offline attempts. Even complex passwords can eventually be cracked with sufficient resources.

Kerberoasting Flow

3️⃣ Advanced Mitigations

To reduce Kerberoasting risk in an AD environment:

  1. Strong, unique passwords for all service accounts.
  2. Regular password rotation and auditing for reused or historical passwords.
  3. Least privilege principle: avoid granting service accounts administrative rights.
  4. Monitoring and alerting: detect mass TGS requests or anomalous behavior.
  5. Pass-the-ticket mitigations: disable Do not require Kerberos preauthentication where possible, and consider Managed Service Accounts (MSA) or Group Managed Service Accounts (gMSA).

4️⃣ References & Further Reading