Kerberoasting
Kerberos is the preferred authentication protocol in Active Directory networks for domain accounts.
Last updated
Kerberos is the preferred authentication protocol in Active Directory networks for domain accounts.
Last updated
Kerberos focuses on the use of tickets that allow a user to be authenticated on the domain. The most common use of the Kerberos protocol is by users and services, the latter being the most widely used. To access a service, you need to request a service ticket. You need to specify an attribute called Service Principal Name (SPN). For example, to access a computer's HTTP service, you would request the service as follows: HTTP/computer.
An attacker can take advantage of this protocol to obtain user passwords:
An attacker authenticates to a domain and obtains a ticket-granting-ticket (TGT) from the domain controller, which will be used for subsequent ticket requests. This request is called KRB_AS_REQ (Kerberos Authentication Service Request). The TGT requested by the client is a piece of encrypted information containing, among other things, a session key and user information (ID, name, groups, etc.). To make this TGT request, a user sends his name to the KDC (Key Distribution Center), along with the precise time of the request (which he encrypts with his secret) and some other information in clear text.
The KDC will then receive this name, and check that it exists in its database. If it finds it, it will retrieve the hash of the user's password, which it will use to attempt to decrypt the timestamp sent. If it fails to do so, the client is not who it claims to be.
The KDC will then send the user various elements in its response (KRB_AS_REP) :
The session key, encrypted with the user's hash;
The TGT, containing various pieces of information, the main ones being :
User name
Validity period
The generated session key
The Privilege Attribute Certificate (PAC), which contains specific information about the client, enabling us to identify his or her rights (ID, groups to which he or she belongs, etc.).
The attacker uses his TGT to issue a service ticket request (TGS-REQ) for a particular Service Principal Name (SPN) of the form sname/host, e.g. MSSQL_Svc/EXAMPLE.com to access the SQL service. This SPN must be unique in the domain and is stored in the ServicePrincipalName field of a user or computer account. During this request process, the attacker can specify which Kerberos encryption types he supports (RC4_HMAC, AES256_CTS_HMAC_SHA1_96, etc.).
If the attacker's TGT is valid, the domain controller extracts the TGT information and inserts it into a service ticket. Next, the domain controller looks up which account has the requested SPN registered in its ServicePrincipalName field. The service ticket is encrypted with the hash of the account for which the requested SPN is registered, using the highest encryption key supported by the attacker and the service account. The ticket is returned to the attacker in a service ticket response (TGS-REP). It's important to understand that most services are registered to machine accounts, which have automatically generated 120-character passwords that change every month, so cracking their hashes is impractical. However, services are sometimes assigned to ordinary user accounts, managed by individuals, who may have weak passwords. Their password hashes are therefore weaker and can be cracked to recover user passwords.
The attacker extracts the encrypted service ticket from the TGS-REP. As the service ticket has been encrypted with the hash of the account linked to the requested SPN, the attacker can crack this encrypted piece offline to recover the account's plaintext password. In this way, he will be able to break the user's NTLM fingerprint and subsequently impersonate him.
