Kerberoasting v2

Headline

One of the annual review digests back in 2020 stated that executing Kerberoasting attack as part of internal penetration testing routine results in 61% success. This fact inspired me to untangle the attack, looking for answers to why is Kerberoasting so popular, what are the existing protection approaches, and which of them are currently in use.

Before discussing the attack itself, it is essential to have a general understanding of how Kerberos authentication works.

Authentication

The following tools are involved in Microsoft authentication over Kerberos:

• Key Distribution Center (KDC) — one of the Windows Server security services running on a domain controller (DC);
• A Client that attempts to authenticate and access the service;
• A Server, which a user attempts to access.

The Client and the DC communication scheme can be represented as a message flow:

Fig. 1 The Client and the DC message flow scheme

AS_req

When the Client starts authentication, it sends a message AS_req (Authentication Service Request) to the DC. The AS_req-message includes UPN (UserPrincipalName), accessed service name (always krbtgt), and a timestamp encrypted by the user account password hash.

Fig. 2 The Client starts pre-authentication

The ASreqroasting attack is based on the latter. Executing MITM-attack, an attacker can intercept AS_req-message to extract the encrypted timestamp from it and implement brute force passively via hashcat (mode 7500 if timestamp is encrypted by RC4 or mode 19900 if timestamp is encrypted by AES256). For exploitation details refer to this link. ASreqroasting attack is less popular comparing to other Kerberos roast attacks, though it has being known since 2014.

Fig. 3. The attacker exploits MITM and intercepts the AS_req message

AS_rep

When the DC obtains AS_req-message, it first decrypts the timestamp by the user password hash. If the encrypted timestamp difference from the current time exceeds 5 minutes (Time Skew parameter by default), the PreAuth failed answer will be sent. When a timestamp is decrypted, the DC sends the AS_rep (Authentication Service Reply) message in reply. The AS_rep-message contains TGT (Ticket Granting Ticket), encrypted by the krbtgt account password hash and session key encrypted by the user account password hash. TGT ticket can also contain the same session key. The session key is required to encrypt subsequent message from the Client to the DC.

Fig. 4. DC sends the AS_rep message in response

And again the roast-attack can be executed here. The point is that timestamp signing in the AS_req message can be disabled for the user account (disabling Kerberos pre-authentication). This means that the attacker can enumerate the accounts with disabled pre-authentication and send AS_req message to the DC on their behalf. In reply they will receive the AS_rep message. As we know, this message contains a session key encrypted by the user account password hash. This attack type is known as ASREProasting. Though there are only a few cases when pre-authentication has been disabled, this attack has a number of advantages:

• Can be applied without any domain account (network access to DC is enough), although enumeration of user accounts with disabled pre-authentication may pose a problem;
• The received hash may be iterated over in passive mode the same way as in ASreqroast (hashcat mode 18200).

Fig. 5. Disabling pre-authentication

TGS_req

After passing pre-authentication, the Client sends DC a TGS_req (Ticket Granting Service Request) with the following content:

• SPN (Service Principal Name) — service name to which the Client requests the access. It is associated with either a computer account or a user account;
• UPN and time stamp encrypted by earlier obtained session key;
• TGT ticket.

Fig. 6 The Client sends the TGS_req message

TGS_rep

After the DC receives the TGS_req-message, it validates the SPN and TGT ticket validity period (TGT ticket validity period is 10 hours by default), decrypts, and analyzes the timestamp. If the SPN is correct, the TGT ticket validity period is not expired and all timestamps are within the valid range, then the DC will send the Client a TGS_rep (Ticket Granting Service Reply) message containing a TGS (Ticket Granting Service) encrypted by the password hash of the account used to launch the service. And this final part is what makes the Kerberoasting attack possible.

Fig. 7. Client obtains TGS ticket

Afterwards the AP_req and AP_rep messages will be sent for Kerberos authentication. There is little use describing them here since the given explanation should be sufficient for understanding the attack.

Kerberoasting

There are two reasons why Kerberoasting is possible. First, the DC does not authorize the Client, so the DC cannot grant the Client permission to access arbitrary services. Using a single domain account the attacker can create a legitimate TGS ticket request to all SPNs in the domain. The attacker is interested in the SPNs associated with user accounts rather than computer accounts due to the pointlessness in retrieving passwords of the latter. Second, TGS tickets are encrypted by the service account hash. This will help the attacker to retrieve the service account password if the password is not strong enough.

The attack can be divided to a number of stages:

1. The attacker begins authentication in a domain (AS_req and AS_rep).
2. The attacker uses a TGT ticket to request TGS ticket receipt for a specific SPN (TGS_req and TGS_rep).
3. The attacker extracts the hash from the encrypted TGS ticket from the TDS rep.

General facts about the attack:

• Easy to exploit. There is a wide variety of instructions on how to enumerate SPN requests to obtain TGS tickets, how to perform all the actions in parralel by using Impacket GetUserSPNs.py module etc.
• To launch the attack, it is sufficient to have a domain account with any privilege level plus network access to DC over UDP/88;
• Obtained service account hashes may be iterated over in passive mode.

The attack is often used by white hats and black hats alike. An offended participant of the Conti partnership program published a hacking group’s tutorial where Kerberoasting was described as one of the main attacks. The guide recommended to attempt Kerberoasting as the first option when attacking a domain.

Example of the attack exploitation by means of GetUserSPNs.py:

ntpdate 10.23.53.26; GetUserSPNs.py -request -dc-ip 10.23.53.26 TESTDOMAIN.local/testuser1:Testuser! > kerberoast.txt

where:

• ntpdate — time synchronization of a malicious actor computer with DC time. It is highly possible to get an error KRB_AP_ERR_SKEW(Clock skew too great) without this command;
• 10.23.53.26 — DC IP address;
• GetUserSPNs.py -request -dc-ip — running a script with options -request and -dc-ip;
• TESTDOMAIN.local — domain name;
• testuser1:Testuser! — domain account login and password;
• > kerberoast.txt — recording of script output GetUserSPNs.py to a text file.

Fig. 8. Output of kerberoast.txt

Then, hash will be iterated over and if the password is not strong enough, the attacker will be able to guess the password for the service account.

Countering the attack

1. Strong password policy and reduced service account privileges

The simplest way of protection is to set all passwords belonging to service accounts to be 25–30 character long and to ensure that all service accounts are given only essential privileges, for example, the service accounts should not be included in the domain administrator group. It sounds quite simple, but unfortunately, Kerberoasting effectiveness shows that usually these recommendations are not followed.

2. An SPN honeypot

Another efficient approach to detecting Kerberoasting. It involves creation of an unusable account and an SPN (the SPN created is not associated with any real application). Kerberos clients would never request a TGS ticket for a false SPN, therefore, if a 4769 event appears in the DC security log for this service, the Kerberoasting attack will be detected.

Example of a 4769 event (TGS ticket request), alerting that Kerberoasting attack is underway.

Fig. 9. 4769 events indicating that a TGS ticket has been requested for a non-existent service

In this event:

• Testuser2@TESTDOMAIN.LOCAL — the compromised account used by the attacker to request a TGS ticket;
• Testuser1 — a trap account. A false SPN is associated with this account;
• 10.23.53.29 — the ip address used for attack.

Therefore, security team can detect the fact of the attack and identify the source computer.

3. FAST (or Kerberos armoring)

Flexible Authentication Secure Tunneling (FAST) or Kerberos Armorin is a DC security configuration that establishes a protected channel between the Kerberos client and the KDC within AS_req, AS_rep, TGS_req and TGS_rep messages. It is supported by Windows Server 2012 and Windows 8 and up. Detailed approach description is provided in RFC 6113 and RFC 4851.

Here’s a description on applying Kerberos Armoring:

1. Enable Kerberos Armoring support on the DC. Open Group Policy Management, proceed to Default Domain Controllers policy, right-click to open context menu, select Edit. Select Computer configuration → Policies → Administrative Templates → System → Key Distribution Center. Open KDC support for claims, compound authentication and Kerberos armoring on the right part and set up Enable, enable Fail authentication requests when Kerberos armoring is not available.

Fig. 10. Enabling Kerberos Armoring support on the DC

2. Enable Kerberos Armoring support for the Kerberos Client. Open Group Policy Management, proceed to Default Domain Controllers policy, right-click to open the context menu, select Edit. Then select Computer Configuration → Policies → Administrative Templates → System → Kerberos. Open KDC support for claims, compound authentication and Kerberos armoring on the right part and set up Enable.

Fig. 11. Enabling Kerberos Armoring support on the Kerberos Client

If we care to intercept the Kerberos message by Wireshark, we will be able to see the error NT STATUS: Unknown error code 0xc00002fb:

For a detailed description of the error 0xc00002fb: An invalid request was sent to the KDC, refer to the link.

The DC refused the attacker in pre-authentication because it is expecting secure channel to send AS_req and AS_rep messages.

4. gMSA

Group Managed Service Accounts or gMSA represent the type of accounts in AD used for secure service start up. A 240-character password will be generated for each gMSA and by default it will change every 30 minutes. The password is managed by the AD and is not stored in the local system, therefore, it cannot be extracted from the LSASS process dump. gMSA authentication relies on Kerberos only. It is supported starting from Windows server 2012. For more details refer to the link.

An example of gMSA setup:

1. Create a server domain group with a permission to use group service account:

New-ADGroup testgMSA -GroupScope Global -PassThru -Verbose

where testgMSA is a name of the created domain group.

Next, add a server (i.e. WIN-D300I3D4GHE) to the testgMSA group:

Add-AdGroupMember -Identity testgMSA -Members WIN-D300I3D4GHE$

2. Сreate a gMSA group account:

New-ADServiceAccount -name gmsa -DNSHostname gmsa.testdomain.local -PrincipalsAllowedToRetrieveManagedPassword testgMSA -Verbose

where gmsa is the managed service account for the created group.

3. Enable the gMSA account on the server added earlier (in our case it would be the WIN-D300I3D4GHE):

Install-ADServiceAccount gmsa

Installation is possible only if gmsa is implemented on the server:

4. The last step is starting up a service on the gMSA behalf.

This way we can start up services on behalf of gMSA account, making password retrieval impossible, even in cases when the attacker has managed to obtain an encrypted TGS ticket hash.