Kerberoasting

Stealing service account credentials from Active Directory

Introduction

Kerberoasting is an attack technique used against Microsoft Active Directory environments that allows an attacker to target accounts associated with Kerberos service principal names (SPNs).

Unlike many attacks that attempt to exploit a software vulnerability, Kerberoasting abuses a legitimate feature of the Kerberos authentication protocol.

The attacker requests a Kerberos service ticket for a service account and then attempts to crack the encrypted portion of that ticket offline – If the service account has a weak password, the attacker may eventually recover the account’s plaintext password.

This can provide the attacker with legitimate credentials that may allow further access to the organisation.

What is Kerberos?

Before understanding Kerberoasting, it is important to understand Kerberos.

Kerberos is the primary authentication protocol used by modern Windows Active Directory environments.

Rather than repeatedly sending a user’s password across the network, Kerberos uses tickets to authenticate users and services.

The main components of Kerberos include:

  • Client – The user or computer requesting access.
  • Key Distribution Center (KDC) – The Active Directory service responsible for issuing Kerberos tickets.
  • Authentication Service (AS) – Authenticates users and issues Ticket Granting Tickets.
  • Ticket Granting Service (TGS) – Issues service tickets.
  • Service – The application or server the user wants to access.

A simplified authentication process looks like this:

User → Domain Controller → Kerberos Ticket → Service

This provides strong authentication without repeatedly transmitting the user’s password.

Kerberos is named after Cerberus – The three-headed dog from Greek mythology that protected the gates to Hades to stop the demons escaping to the upper-world

A statue of Hercules fighting Cerberus

With Kerberos, there are three-challenges that must be passed before a device, or user gains access to a service.

Challenge 1

When requesting access to a service, the client sends a plaintext version of the user ID and the name of the requested service to the Authentication Server (AS) which is a part of the Key Distribution Centre.

The server checks the User ID in its database and sends a Session key to client encrypted with client’s key – The client decrypts message to retrieve session key

The server then sends a Ticket Granting Ticket (A.K.A. Golden Ticket) to the client which consists of A Session key, Client ID, Client network address, and validity period – This is encrypted with the Ticket Granting Service key

Challenge 2

The Client sends the ID of the requested service & the Ticket Granting Ticket to the Ticket Granting Server (TGS)

The Client also sends an authenticator message consisting of Client ID + Timestamp

The Server sends a Service Ticket (A.K.A. Silver Ticket) to the client which consists of Client/server session key, Client ID, Client network address, and validity period – This is encrypted with the TGS key

The Server sends a Client/server session key to the client encrypted with the session key

Challenge 3

The Client sends the Service ticket to the Service Server

The Client also sends the authenticator message consisting of Client ID + Timestamp to the Service server encrypted with the Client/server key

The Service server validates the Client data and returns the Timestamp from the Authenticator message encrypted with the session key

The Client validates the Timestamp data and then requests service(s) from service server

What is an SPN?

The key to understanding Kerberoasting is the Service Principal Name (SPN).

An SPN identifies a particular service running under a specific Active Directory account.

For example:

  • SQL Server
  • Microsoft Exchange
  • IIS
  • MSSQLSvc
  • HTTP
  • LDAP
  • Custom enterprise applications

An SPN might look similar to MSSQLSvc/sqlserver01.example.local:1433

The important point is that the service is associated with an Active Directory account. That account is commonly called a service account.

Why are service accounts important?

Service accounts are often created so applications can authenticate to other systems.

For example, an organisation might create svc_sqlsvc_backupsvc_websvc_exchange

These accounts may have permissions that ordinary users do not.

Unfortunately, service accounts have historically been given:

  • Long-lived passwords
  • Passwords that rarely change
  • Excessive privileges
  • Domain-level permissions
  • Predictable passwords
  • Passwords shared between systems

This creates an attractive target – If an attacker can recover the password associated with a privileged service account, they may gain considerably more access than they initially possessed.

How Kerberoasting works

A simplified Kerberoasting attack can be broken into several stages.

1. Gain access to the domain

The attacker first needs some level of access to the Active Directory environment.

This might occur through:

  • Phishing
  • Malware
  • Credential theft
  • Exploitation of another system
  • A compromised workstation
  • A compromised user account

The attacker does not necessarily need Domain Administrator privileges – A standard authenticated domain user can potentially request service tickets.

2. Enumerate service accounts

The attacker identifies accounts associated with SPNs – They are looking for services that have been configured to run using Active Directory accounts.

For example MSSQLSvc/sql01.company.localHTTP/web01.company.localMSSQLSvc/db01.company.local

The attacker is particularly interested in service accounts with valuable privileges.

3. Request a Kerberos service ticket

Once an interesting SPN has been identified, the attacker requests a service ticket from the KDC – This is a legitimate Kerberos operation.

The important distinction is that the attacker is not necessarily exploiting the Kerberos protocol, they are abusing a legitimate authentication mechanism.

The domain controller therefore sees something that can initially look like a normal request.

4. Capture the service ticket

The attacker receives the Kerberos service ticket. Part of the ticket is encrypted using a key derived from the password of the service account.

The attacker can therefore take the relevant encrypted material away from the domain environment for offline cracking

This is where the attack becomes particularly dangerous.

5. Crack the ticket offline

The attacker can now attempt to guess the service account’s password offline.

There is no need to repeatedly authenticate against the domain controller during this process – This means traditional account lockout mechanisms do not necessarily stop the password-cracking phase.

Why offline cracking matters

This is one of the most important concepts behind Kerberoasting. Imagine an attacker attempting thousands of passwords directly against an Active Directory account.

The organisation may have controls such as:

  • Account lockout
  • Failed-login monitoring
  • MFA
  • Authentication alerts

But Kerberoasting moves much of the password guessing offline – As such, the attacker can potentially perform large numbers of password guesses without generating corresponding failed authentication attempts against the service account.

What happens if the password is cracked?

If the attacker successfully recovers the service account password, they now possess legitimate credentials for the domain and an SPN – The consequences depend entirely on the privileges assigned to that account.

A low-privilege service account might provide limited access, but a a highly privileged service account could provide a path towards:

  • Sensitive servers
  • Databases
  • File shares
  • Application infrastructure
  • Additional credentials
  • Lateral movement
  • Privilege escalation
  • Domain compromise

This is why service-account privilege management is so important.

Why Kerberoasting is so dangerous

Kerberoasting combines several characteristics that make it attractive to attackers.

  • Legitimate functionality – The attacker is abusing normal Kerberos functionality rather than necessarily exploiting a vulnerability.
  • Low initial privileges – A domain user may be sufficient to request service tickets.
  • Offline cracking – Password guessing can occur away from the domain controller.
  • Long-lived credentials – Service account passwords may remain unchanged for years.
  • Privileged accounts – Some service accounts have considerably more permissions than ordinary users.
  • Difficult attribution – The initial ticket request may resemble legitimate activity.

Common Kerberoasting targets

Attackers may prioritise service accounts associated with:

  • SQL Server
  • Backup systems
  • Web applications
  • Database servers
  • Enterprise applications
  • Exchange
  • Monitoring platforms
  • Management systems
  • Legacy applications

Particular attention may be given to accounts that have:

  • SPNs
  • High privileges
  • Weak passwords
  • Old passwords
  • Password reuse
  • Broad access

Kerberoasting vs brute force

Kerberoasting is sometimes confused with a traditional brute-force attack, but they are fundamentally different.

In a Brute force attack, The attacker repeatedly attempts authentication against a target.

In a Kerberoasting attack, The attacker obtains a Kerberos service ticket and performs password guessing against the ticket offline.

This difference is extremely important from a defensive perspective.

Detecting Kerberoasting

Security teams can monitor Active Directory and Windows events for unusual service-ticket activity. One particularly important event is Security Event ID 4769 – A Kerberos service ticket was requested.

A single request does not necessarily indicate an attack, and Kerberos generates large amounts of legitimate traffic.

Instead, defenders should look for patterns and anomalies.

Potential indicators include:

  • A user suddenly requesting large numbers of service tickets
  • Requests for unusual or rarely used services
  • Numerous SPNs being queried in a short period
  • Service-ticket requests from unusual workstations
  • Requests involving privileged service accounts
  • Unusual encryption types
  • Activity occurring outside normal working patterns
  • A user requesting tickets for services they have never previously accessed

Encryption types matter

Historically, Kerberoasting has often targeted service tickets using RC4-HMAC. Modern Active Directory environments should prefer stronger Kerberos encryption mechanisms, particularly AES-based encryption.

However, simply disabling RC4 does not eliminate the underlying risk – A weak service-account password can still represent a significant security problem.

The most important defence remains to Use strong, unique, appropriately managed service-account credentials.

How organisations can prevent Kerberoasting

Several controls can significantly reduce the risk.

  • Use strong service-account passwords – Service accounts should use long, random and unique passwords.
  • Use Group Managed Service Accounts – Group Managed Service Accounts (gMSAs) can significantly reduce the risks associated with manually managed service-account passwords.
    Windows can manage the password automatically, reducing the likelihood of weak or forgotten credentials.
  • Apply least privilege – Service accounts should receive only the permissions required to perform their function. E.g. – A service account running SQL Server should not automatically have Domain Administrator privileges.
  • Remove unnecessary SPNs – Unused services and accounts should be reviewed regularly. If an SPN is no longer required, it should be removed.
  • Prefer AES Kerberos encryption – Organisations should move away from legacy Kerberos encryption mechanisms where possible and ensure systems support modern encryption. Legacy compatibility requirements should be carefully assessed rather than blindly maintaining weaker protocols.
  • Monitor Event ID 4769 – Security teams should monitor Kerberos service-ticket requests and establish a baseline for normal activity. Detection should focus on behaviour rather than simply counting tickets.

Conclusion

Kerberoasting is a powerful example of how attackers can abuse legitimate Active Directory functionality. Rather than attempting to brute-force an account directly, an attacker can request Kerberos service tickets associated with service accounts and then attempt to crack the encrypted material offline.

The danger comes from what happens next – If a weak service-account password is recovered, the attacker has obtained legitimate credentials that may provide access to sensitive systems and potentially enable further lateral movement and privilege escalation.

The most effective defences are therefore not based on simply blocking Kerberoasting. Organisations need to address the underlying weaknesses that make the technique effective:

strong service-account credentials, least privilege, modern Kerberos encryption, effective Active Directory monitoring, and proper service-account lifecycle management.