❌

Normal view

There are new articles available, click to refresh the page.
Before yesterdayHaboob

New Attack Path: Kerberoasting without pre-authentication

22 October 2022 at 19:05

Kerberos Armoring β€œFlexible Authentication Secure Tunneling (FAST)” provides a protected channel between the Kerberos client and the KDC. FAST is implemented as Kerberos armoring in Windows Server 2012, and it is only available for authentication service (AS) and ticket-granting service (TGS) exchanges. Microsoft says β€œKerberos armoring uses a ticket-granting ticket (TGT) for the device to protect authentication service exchanges with the KDC, so the computer’s authentication service exchange is not armored. The user’s TGT is used to protect its TGS exchanges with the KDC.”

So, the question now; is it possible to request service tickets (STs) from the authentication service (AS)?. The ability to request STs from the AS has several consequences including new attack path. This issue will be discussed and demonstrated in this post.

How Does The Kerberos Authentication Flow Works?

First, here’s a high-level overview of the typical Kerberos authentication flow:

  1. An account requests a TGT from the domain controller (DC).

  2. The DC responds with a TGT, which has its own session key.

  3. The TGT and its session key are used to request a service ticket (ST) from the DC.

  4. The DC responds with an ST, which has its own session key.

  5. The ST and its session key are used to authenticate against the end service.

Figure 1. Kerberos Authentication Flow

A Kerberos request has two main sections:

  • padata (pre-authentication data)

  • req-body (request body)

The req-body is sent mostly in plaintext and contains several pieces of information:

  • kdc-options: various options.

  • cname: name of the requesting account (optional).

  • realm: domain name.

  • sname: service principal name (SPN) for the resulting ticket (optional).

  • from: time from which the client wants the ticket to be valid (optional).

  • till: time until which the client wants the ticket to be valid.

  • rtime: the requested renew time (optional).

  • nonce: random number.

  • etype: list of supported encryption types of the client.

  • addresses: list of addresses of the requesting client (optional).

  • enc-authorization-data: various authorization data sections, encrypted with the session key that is usually used for local privileges (optional).

  • additional-tickets: list of tickets required for the request (optional).

Figure 2. Kerberos Req-Body

A Kerberos reply has several sections and contains an encrypted part:

  • pvno: version number.

  • msg-type: type of message.

  • padata: pre-authentication data (optional).

  • crealm: client domain name.

  • cname: name of the requesting account.

  • ticket: resulting ticket.

  • enc-part: encrypted data for use by the client.

Figure 3. Kerberos Reply

Β 

The Issue With AS Requested Service Tickets

The part of the Kerberos flow that this blog focuses on, is β€œAS-REQ/AS-REP” step 1&2 in Figure 1, which is usually used to request a TGT. if the (FAST) enforced, machine accounts still sent their AS-REQs unarmored. So, an AS-REQ could be used to request an ST directly, rather than a TGT. In otherwards, by specifying another SPN within the β€œsname” of an AS-REQ would cause the DC to reply with a valid Service Tickets for that SPN.

Figure 4. Service Ticket Requested From The AS.

So, By using a machine account, it is possible to request an ST without using armoring when FAST is enforced. What else is possible?

Β 

Kerberoasting Without Pre-Authentication – New Way To Kerberoast

In Kerberoasting technique, access to the user’s session key is not required. Only the resulting Service Ticket or more accurately, the encrypted part of the Service Ticket. Therefore, if any account is configured to not require pre-authentication, it is possible to Kerberoast without any credentials. This method of Kerberoasting has been implemented in Rubeus as we will see in the demo.

So, the new attack steps will be as follow:

  1. Identifying a valid list of domain users – [using Kerbrute tool].

  2. Using the found valid usernames list in step 1, determining accounts that do not require pre-authentication - [using Rubeus tool].

  3. With the list of usernames/spns of the current domain and the username of an account that does not require pre-authentication β€œfrom step 2”, the attack can be launched to obtain the service accounts hashes - [using Rubeus tool].

  4. The resulting output can be used to attempt offline password cracking. – [using hashcat or john tools].

Β 

Identifying a Valid List of Domain Users

First, We need to harvest and get valid domain users that exist in the current domain. Kerbrute tool with common random usernames list can be used.

Figure 5. Harvesting Domain Usernames.

Β 

Accounts That Do Not Require Pre-Authentication

Now, we need to find a domain user that do not require pre-authentication, we can do that using Rubeus and the valid usernames list that we got using Kerbrute tool in first step.

Figure 6. Accounts That Do Not Require Pre-Authentication

Note that preauthscan flag is used. The output shows that testuser domain user does not required Pre-Auth.

Β 

Launched The Attack and Perform a Kerberoasting

With the list of usernames/SPNs of the current domain and the username of an account that does not require pre-authentication β€œfrom previous step”, the attack can be launched to obtain the service accounts hashes using Rubeus. Note that /nopreauth flag is used with testuser which is the account that does not required pre-auth. The output shows two kerberostable users. These users’ hashes are obtained successfully.

Figure 7. Kerberoasting Attack Without Pre-Authentication.

Β 

Crack Service Tickets Hashes Offline

Finally, The resulting output can be used to attempt offline password cracking using Hashcat or John the Ripper. The cracked hashes can be used to move laterally across the domain environment based on user's permissions.

Figure 8. Crack Service Tickets Hashes Offline.

Β 

Video Demo

In this video, we demonstrate the whole attack from a machine that joined to VAPTLAB.LOCAL domain with a local administrator account β€œweb01\administratorβ€œ. The idea is to show that the new technique does not require any credentials. From local administrator account To Domain Admin without using any passwords :) .

Β 

Conclusion:

Kerberoasting Without Pre-Authentication opened a new path attack. As we explained, an attacker can use an account that does not require pre-auth to take over the whole environment. So, it’s highly recommended if you are using accounts that do not require pre-auth to setup then with strong passwords that can not be cracked offline β€œreally, really strong passwords, not P@ssw0rd :)”.

Β 

References:

  1. Rubeus

    https://github.com/GhostPack/Rubeus

  2. Kerbrute

    https://github.com/ropnop/kerbrute

  3. New Attack Paths? AS Requested Service Tickets - by CHARLIE CLARK

    https://www.semperis.com/blog/new-attack-paths-as-requested-sts/

New Attack Path: Kerberoasting without pre-authentication

❌
❌