Kerberoasting
Adversaries may abuse a valid Kerberos ticket-granting ticket (TGT) or sniff network traffic to obtain a ticket-granting service (TGS) ticket that may be vulnerable to Brute Force.
Service principal names (SPNs) are used to uniquely identify each instance of a Windows service. To enable authentication, Kerberos requires that SPNs be associated with at least one service logon account (an account specifically tasked with running a service).
Adversaries possessing a valid Kerberos ticket-granting ticket (TGT) may request one or more Kerberos ticket-granting service (TGS) service tickets for any SPN from a domain controller (DC). Portions of these tickets may be encrypted with the RC4 algorithm, meaning the Kerberos 5 TGS-REP type 23 hash of the service account associated with the SPN is used as the private key and is thus vulnerable to offline Brute Force attacks that may expose plaintext credentials.
This same attack could be executed using service tickets captured from network traffic.
Cracked hashes may enable Persistence, Privilege Escalation, and Lateral movement via access to Valid Accounts.
Example:
First let us understand Kerberos it ensures a high level of security to network resources. It is compromised by 3 different parties.
The Key Distribution Center(KDC), the client user and the server with the desired access. The KDC is installed as part of the domain controller and performs two service functions: the Authentication Service (AS) and the Ticket-Granting Service (TGS).
AS (Authentication Service) Exchange
When initially login on to a network, users must negotiate access by providing a log-in name and password in order to be verified by the AS portion of a KDC within their domain. The KDC has access to Active Directory user account information. Once successfully authenticated, the user is granted a Ticket Granting Ticket(TGT) that is valid for the local domain.. The TGT has a default lifetime of 10 hours and may be renewed throughout the users' log-on session without requiring the user to re-enter his password. The TGT is cached on the local machine in volatile memory space and used to request sessions with services throughout the network.
The AS request identifies the client to the KDC in plain text. If preauthentication is enabled, a time stamp will be encrypted using the user's password hash as an encryption key. If the KDC reads a valid time when using the user's password hash (stored in Active Directory) to decrypt the time stamp, the KDC knows that request isn't replay of a previous request. The preauthentication feature may be disabled for a specific user in order to support some applications that don't support the security feature.
You can UN-check the "Do not require Kerberos" option in AD.
If the KDC approves the client's request for a TGT, the reply (referred to as the AS reply) will include two sections: a TGT encrypted with a key that only the KDC(TGS) can decrypt and a session key encrypted with the user's password hash to handle future communications with the KDC. Because the client system cannot read the TGT contents, it must blindly present the ticket to the TGS for service tickets. The TGT includes time to live parameters, authorization data, a session key to use when communicating with the client and the client's name.
TGS Exchange
The user presents the TGT to the TGS portion of the KDC when desiring access to a server service. The TGS on the KDC authenticates the user's TGT and creates a ticket and session key for both the client and the remote server. This information, known as the service ticket, is then cached locally on the client machine.
The TGS receives the client's TGT and reads it using its own key. If the TGS approves of the client's request, a service ticket is generated for both the client and the target server. The client reads its portion using the TGS session key retrieved earlier from the AS reply. The client presents the server portion if the TGS reply to the target server in the client/server exchange.
Client/Server Exchange Detail
The client blindly passes the server portion of the service ticket to the server in the client/server request to establish a client/server session. If mutual authentication is enabled, the target server runs a time stamp encrypted using the service ticket session key. If the time stamp decrypts correctly, not only has the client authenticated himself to the server, but the server also has authenticated to the client. The target server never has to directly communicate with the KDC. This reduces downtime and pressure on the KDC.
A TGT and a service ticket are needed to access services on remote computers, but they also are required to successfully log on to a local system. When the log-on window appears, password encryption using a one-way hash algorithm occurs immediately and negotiations commence with the KDC for a valid TGT and service ticket. The process is the same as accessing a remote service. An access token is created for the user containing all security groups to wich they belong. This access token is attached to the user's log-on session and is subsequently inherited by any process or application the users starts.
Referral Tickets
The AS and TGS functions are separate within the KDC. This permits the user to use the TGT obtained from an ASA in his domain to obtain service tickets from a TGS in other domains. This is accomplished through referral tickets.
Once a trust has been established between two domains, referral tickets can be granted to clients requesting authorizing for services in other domains. When there is a trust established between the two domains, an inter-domain key based on the trust passwords becomes available for authenticating KDC functions. This can be explained by example of a user/client seeking services in another domain.
User client in example1.com request authority from a server in example2.com. User utilizes referral tickets.
1. The client contacts it's domain KDC TGS using a TGT. The KDC recognizes a request for a session with a foreign domain server and responds by returning a referral ticket for the KDC in the foreign domain.
2. The client contacts the KDC of the foreign domain with the referral ticket. This ticket is encrypted with the inner-domain key. Given that the decryption works, the TGS service for foreign domains returns a service ticket for the server service.
3. The client performs the client/server exchange with the server and begins the user session with the service.
This is only a very small understanding on what is going on with Kerberos.
In a nutshell
Basically, Kerberos comes down to just this:
· a protocol for authentication
· uses tickets to authenticate
· avoids storing passwords locally or sending them over the internet
· involves a trusted 3rd-party
· built on symmetric-key cryptography
Example
On Kerberoasting let us use an incredible tool named Rubeus, its and Upgrade to some PowerShell tools (Not that they aren't necessary) and really great for various attacks on Active Directory.
First let's find some SPN users which we can use for grabbing there hash. Will use a great tool from Impacket to grab these hashes (
Please be aware that there are other methods to achieve this and would be great for you to experiment with such as Invoke-Kerberoast with PowerShell)
Now let's save this hash and try cracking it with John The Ripper.
Above we see the full command for saving the hash.
Now with John the Ripper we pass our custom wordlist (which I recommend to work with instead of random wordlists) and wait for the hash to crack.
Kerberoasting is an efficient technique for hackers who have limited rights within a domain. Depending on the strength of the passwords, an attacker can quickly gain access to multiple accounts and then use them to launch additional attacks and collect data. The attack itself cannot be prevented, but selecting strong passwords can make it more difficult. Service accounts should therefore be treated much like
. This includes creating a list of service accounts, checking when the password was last changed, as well as implementing a process for changing passwords on a regular basis.
References:
