Irfan Farooq
← All posts

Kerberoasting

5 min read

Hello everyone, I am Irfan Today we are going to talk about kerberoasting, a well known attack in active directory hacking. let’s start and have some fun.…..

First I will explain Kerberos, Kerberos is a network authentication protocol based on tickets. The protocol allows two parties ( a client and a server, for example ) to authenticate to each other over an insecure network channel , provided that both parties trust a third party the Kerberos server!.

Each party in a Kerberos environment authenticates to the Kerberos server and receives a ticket. More precisely, this is a ticket-granting-ticket: a ticket that can be used to request tickets. When one party (client) wants to use a service from a second party (server), the first party uses its ticket-granting-ticket to obtain a ticket for the second party from the Kerberos server and then presents it to the second party, thereby authenticating to the third party. Since both parties trust the Kerberos server, a ticket provided by the Kerberos server is trusted by both parties, leading to authentication and authorization.

If Kerberos cannot be used (various reasons apply), Windows will fall back to NTLM authentication.

In Active Directory, when a client successfully authenticates to a Domain Controller, the client is given a ticket-granting-ticket.

To authenticate, the user’s workstation will send a request to the Authentication Server (AS) on the domain controller. This request includes timestamp encrypted with the user’s NT password hash, which is also commonly referred to as the NTLM hash. The domain controller (AS) has the user’s password hash in its database and will attempt to decrypt the message. If successful and the timestamp is still valid, then the client will be given a ticket-granting-ticket (TGT) by the Ticket Granting Service (TGS), a logical role of the KDC which is part of the domain controller.

A ticket-granting-ticket is the ticket a client receives first, and it is a special ticket. It is a ticket for the krbtgt service and can thus be used to request other tickets. By default, a TGT is valid for 10 hours. When it expires, Windows will automatically and transparently request a new one.

Once a client has obtained the TGT, it can request access to other services, for example, a file share. To obtain this access, the client sends its TGT to the TGS along with the details of the service it wants to access.

To access the service (for example, a file share), the client will send the ticket to the service (the file server). Since the file server also trusts Kerberos (the TGS), it will accept tickets and grant access to the service once it has validated through cryptographic means that this is an authentic ticket issued by the TGS trusted by the service. The service will then decide if the user should have access and what level of access.

adsecurity.org

  1. Initial Request for a Ticket Granting Ticket (TGT):
  • The authentication begins with the user requesting a Ticket Granting Ticket (TGT) from the Domain Controller (acting as the Key Distribution Center or KDC).

2. Receipt of TGT and Session Key:

  • The user receives the TGT along with a session key from the KDC.
  • Both the TGT and the session key are encrypted using the NT hash of the krbtgt (Kerberos Ticket Granting Ticket) account.

3. Request for a Service Ticket:

  • Subsequently, the user wants to authenticate to a specific service, so they send a ticket request to the KDC (Domain Controller).

4. Service Ticket Issuance by the KDC:

  • Importantly, the KDC does not validate the user’s privileges for the target service at this stage. Privilege validation is left to the discretion of the target service.
  • The KDC responds by issuing a service ticket, which includes an encrypted portion. The server part of this service ticket is encrypted using the NT hash of the target service.
  • The user retains this service ticket and later presents it to the intended service for access.
  • When the service receives the service ticket, it can decrypt the ticket’s contents using its own hash to authenticate the user.

Given the above, we can attempt to crack the target service NT hash, as the hash is used to encrypt the server portion of the “Service Ticket”.

So how can we launch such an attack? Several tools are available that implement this attack strategy. Most of them operate using the following steps:
1. Query the Active Directory for accounts with a Service Principal Name (SPN).
2. Request RC4 service tickets from the DC using these SPN values.
3. Extract received Services Tickets and dump them to a file.
4. Launch offline brute force attacks against the tickets to recover the credential that was used to encrypt the Service Ticket.

Now some lab time

We have compromised a user, now we want to do kerbroasting, we will use GetUserSPNs.py from impacket.

see we got an error, now to resolve this error now run these commands

sudo apt install ntpdate
sudo ntpdate [dc-ip]

Now after that run again GetUserSPNs.py

Boom! here we got the hash and service principle name.

Now take this hash and save it in a file and now it is the time to crack it.

I used vim to make a file hash.txt and copied this hash in it. I think you know how to exit the vim :) .

Now I used John-the-ripper to crack the hash or you can use hashcat whatever you like.

Boom! we got the password of SQLService account.

What service accounts could be interesting?

  • The account should obviously have some elevated privileges that could be interesting.
  • The account should not be a computer account, as those are typically not possible to crack.

Here are some examples of potentially interesting accounts (from adsecurity.org)
• AGPMServer: Microsoft Advanced Group Policy Management
- Often has full control rights to all GPOs.
• MSSQL/MSSQLSvc
- Admin rights to SQL server(s), which often has interesting data.
• FIMService — Forefront Identity Manager Service
- Often has admin rights to multiple AD forests.
• STS — Security Token Service (VMware):
- VMware SSO service which could provide backdoor VMware access.

Mitigations.

  1. Your service account should have long passwords.
  2. Your service accounts should not be running as domain admins.

You can learn more about kerbroasting and its mitigations and detections here at adsecurity.org

I hope you enjoyed it, You can follow me here on LinkedIn or Twitter.