Skip to main content

Kerberoasting

Overview

The attacker uses a known username and password of a user on a domain.

A typical Kerberos workflow is:

  • Once a user logs into a domain-joined system, they get a TGT (ticket-granting ticket).
  • Then, they'll use that TGT to request a TGS (ticket-granting service) ticket any time they need to authenticate to a service.
  • The TGS is then passed to an application server on the network for authentication.

Any domain user can request a TGS. This is because:

  • The domain controller does not determine if a user can access a network service.
  • It simply provides a ticket to forward to a service and expects the service to determine permissions.

The important part here is:

  • A TGS contains a service principal's password hash.
  • Service principals are service accounts that run daemons on a server.

Kerberoasting works by requesting TGS, but:

  • The attacker does not forward the TGS to the server.
  • Rather, the attacker collects the Kerberos TGS hash and attempts to crack it to reveal a service principal's cleartext password.


What's the Flaw?

In many domains, service principals are incorrectly configured as domain administrators. If an attacker is able to crack a service principal's password hash and reaveal the service principal's password, it can be passed around to own other hosts.

This would mean elevation to domain administrator by way of the service principal's credentials.


The Attack

This attack will send ticket-granting service ticket requests to the domain controller and expose the Kerberos hashes of domain service accounts.

GetUserSPNs.py domain.tld/username:password -dc-ip <domain-controller-ip> -request
Back to top