{ "id": "2f583fe8-7918-4615-aef7-67ee3f74eafb", "created_at": "2026-04-06T00:12:47.468026Z", "updated_at": "2026-04-10T03:23:18.149927Z", "deleted_at": null, "sha1_hash": "0d26ea08d29f9bc11bc25f856c7ffb4a599f3522", "title": "Cracking Kerberos TGS Tickets Using Kerberoast – Exploiting Kerberos to Compromise the Active Directory Domain", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 807940, "plain_text": "Cracking Kerberos TGS Tickets Using Kerberoast – Exploiting\r\nKerberos to Compromise the Active Directory Domain\r\nBy Sean Metcalf\r\nPublished: 2015-12-31 · Archived: 2026-04-05 23:43:58 UTC\r\nMicrosoft’s Kerberos implementation in Active Directory has been targeted over the past couple of years by\r\nsecurity researchers and attackers alike. The issues are primarily related to the legacy support in Kerberos when\r\nActive Directory was released in the year 2000 with Windows Server 2000. This legacy support is enabled when\r\nusing Kerberos RC4 encryption (RC4_HMAC_MD5) since the NTLM password hash is used extensively with\r\nthis encryption type.\r\nThere are several Kerberos attacks that take advantage of Microsoft’s legacy support in Active Directory. When\r\nMicrosoft released Windows 2000 and Active Directory along with it, they needed to support Windows NT and\r\nWindows 95 which meant a wide variety of security (and less secure configurations). This support meant that\r\nMicrosoft needed to support several different clients and enable them to speak Kerberos. The easy way to do this\r\nwas to use the NTLM password hash as the Kerberos RC4 encryption private key used to encrypt/sign Kerberos\r\ntickets. Once the NTLM password hash is discovered, it can be used in a variety of ways, including re-compromising the Active Directory domain (think Golden Tickets \u0026 Silver Tickets).\r\nRC4 Kerberos encryption is still supported even now, 15 years later. In fact, AES encryption wasn’t available as\r\nan option on Windows until Windows Vista and Windows Server 2008. While AES Kerberos encryption is now\r\nused by default on the newer operating systems, there may still be significant use of RC4 Kerberos encryption on\r\nthe network, involving some interesting network devices that have AES Kerberos encryption disabled by default.\r\nWith the introduction of AES as a Kerberos encryption option, Windows uses AES for hashing which is a break\r\nfrom traditional Windows password hashing methods. This means that while Kerberos RC4 encryption leveraged\r\nthe NTLM password hash as encryption key, Kerberos AES encryption uses the AES hash to encrypt the Kerberos\r\ntickets. (in other words, when AES is the Kerberos encryption\r\nUpdate:\r\nWill @harmj0y Schroeder (blog.harmj0y.net) and I spoke at DerbyCon 6 in September, 2016 and demonstrated\r\nhow Kerberoast works. The slides and video from our talk are now available. The other demos Will did during the\r\ntalk are here.\r\nAll of the slides and most videos of my talks are on the Presentations page.\r\nThis article describes how Service Principal Names work and how to use Kerberoast to crack passwords offline.\r\nWill also posted on how to Kerberoast without using Mimikatz.\r\nActive Directory Kerberos Attacks:\r\nThere are several different types of Kerberos attacks ranging from recon (SPN Scanning), to offline service\r\naccount password cracking (Kerberoast), to persistence (Silver \u0026 Golden Tickets).\r\nhttps://adsecurity.org/?p=2293\r\nPage 1 of 8\n\nHere are the most popular AD Kerberos attacks:\r\nSPN Scanning – finding services by requesting service principal names of a specific SPN class/type.\r\nSilver Ticket – forged Kerberos TGS service ticket\r\nGolden Ticket – forged Kerberos TGT authentication ticket\r\nMS14-068 Forged PAC Exploit – exploitation of the Kerberos vulnerability on Domain Controllers.\r\nDiamond PAC – blended attack type using elements of the Golden Ticket and the MS14-068 forged PAC.\r\nSkeleton Key In-memory Malware – malware “patches” the LSASS authentication process in-memory on\r\nDomain Controllers to enable a second, valid “skeleton key” password with which can be used to\r\nauthenticate any domain account.\r\nThis post covers another type of Kerberos attack that involves Kerberos TGS service ticket cracking using\r\nKerberoast. This information is based on the presentations I gave at several security conferences in 2015 (BSides,\r\nShakacon, Black Hat, DEF CON, \u0026 DerbyCon) and Tim Medin’s DerbyCon “Attacking Microsoft Kerberos\r\nKicking the Guard Dog of Hades” presentation in 2014 (slides \u0026 video) where he released the Kerberoast Python\r\nTGS cracker.\r\nSPN Scanning\r\nTraditionally, attackers have performed recon using network port scanning, though this is usually not required on\r\nmodern networks thanks to use of Active Directory and Kerberos. I have previously written about “SPN\r\nScanning” for recon which involves requesting specific Service Principal Name (SPN) types from a Domain\r\nController (requires a user or computer account). For the attacker, one of the most useful SPN types to scan for is\r\n“SQL” to discover all SQL servers registered in Active Directory. All service types that leverage Kerberos\r\nauthentication have SPNs registered in Active Directory since SPNs are required for Kerberos to work. First, let’s\r\nreview how Kerberos works.\r\nI maintain a Service Principal Name (SPN) directory with the most common SPNs and what they are used for.\r\nSPN Scanning for Services\r\nSPN Scanning for Service Accounts\r\nhttps://adsecurity.org/?p=2293\r\nPage 2 of 8\n\nOnce the attacker has a list of Service Principal Names (SPNs) associated with service accounts, these SPNs can\r\nbe used to request Kerberos TGS service tickets useful for offline TGS password cracking.\r\nNote: Both of these screenshots are from PowerShell functions I wrote to perform SPN Scanning in my GitHub\r\nrepository.\r\nIf you have the Active Directory PowerShell module installed, you can easily find all SPNs of a specific type with\r\nGet-ADObject\r\nget-adobject -filter {serviceprincipalname -like “*sql*”} -prop serviceprincipalname\r\nThe AD PowerShell module quickly installs on Windows Server 2008R2 and newer:\r\nimport-module servermanager ; add-windowsfeature RSAT-AD-PowerShell\r\nKerberos Overview \u0026 Communication Process:\r\nUser logs on with username \u0026 password.\r\n1a. Password converted to NTLM hash, a timestamp is encrypted with the hash and sent to the KDC as an\r\nauthenticator in the authentication ticket (TGT) request (AS-REQ).\r\n1b. The Domain Controller (KDC) checks user information (logon restrictions, group membership, etc) \u0026 creates\r\nTicket-Granting Ticket (TGT).\r\n2. The TGT is encrypted, signed, \u0026 delivered to the user (AS-REP). Only the Kerberos service (KRBTGT) in the\r\ndomain can open and read TGT data.\r\n3. The User presents the TGT to the DC when requesting a Ticket Granting Service (TGS) ticket (TGS-REQ). The\r\nDC opens the TGT \u0026 validates PAC checksum – If the DC can open the ticket \u0026 the checksum check out, TGT =\r\nvalid. The data in the TGT is effectively copied to create the TGS ticket.\r\n4. The TGS is encrypted using the target service accounts’ NTLM password hash and sent to the user (TGS-REP).\r\nhttps://adsecurity.org/?p=2293\r\nPage 3 of 8\n\n5.The user connects to the server hosting the service on the appropriate port \u0026 presents the TGS (AP-REQ). The\r\nservice opens the TGS ticket using its NTLM password hash.\r\n6. If mutual authentication is required by the client (think MS15-011: the Group Policy patch from February that\r\nadded UNC hardening).\r\nUnless PAC validation is required (rare), the service accepts all data in the TGS ticket with no communication to\r\nthe DC.\r\nCracking Service Account Passwords with Kerberoast:\r\nKerberoast can be an effective method for extracting service account credentials from Active Directory as a\r\nregular user without sending any packets to the target system. This attack is effective since people tend to create\r\npoor passwords. The reason why this attack is successful is that most service account passwords are the same\r\nlength as the domain password minimum (often 10 or 12 characters long) meaning that even brute force cracking\r\ndoesn’t likely take longer than the password maximum password age (expiration). Most service accounts don’t\r\nhave passwords set to expire, so it’s likely the same password will be in effect for months if not years.\r\nFurthermore, most service accounts are over-permissioned and are often members of Domain Admins providing\r\nfull admin rights to Active Directory (even when the service account only needs to modify an attribute on certain\r\nobject types or admin rights on specific servers).\r\nThe most effective mitigation of this attack is ensuring service account passwords are longer than 25 characters.\r\nManaged Service Accounts and Group Managed Service Accounts are a good method to ensure that service\r\naccount passwords are long, complex, and change regularly. A third party product that provides password vaulting\r\nis also a solid solution for managing service account passwords.\r\nNote: This attack will not be successful when targeting services hosted by the Windows system since these\r\nservices are mapped to the computer account in Active Directory which has an associated 128 character password\r\nwhich won’t be cracked anytime soon.\r\nThis attack involves requesting a Kerberos service ticket(s) (TGS) for the Service Principal Name (SPN) of the\r\ntarget service account. This request uses a valid domain user’s authentication ticket (TGT) to request one or\r\nseveral service tickets for a target service running on a server. The Domain Controller doesn’t track if the user ever\r\nactually connects to these resources (or even if the user has access). The Domain Controller looks up the SPN in\r\nActive Directory and encrypts the ticket using the service account associated with the SPN in order for the service\r\nto validate user access. The encryption type of the requested Kerberos service ticket is RC4_HMAC_MD5 which\r\nmeans the service account’s NTLM password hash is used to encrypt the service ticket. This means that\r\nKerberoast can attempt to open the Kerberos ticket by trying different NTLM hashes and when the ticket is\r\nsuccessfully opened, the correct service account password is discovered.\r\nNo elevated rights are required to get the service tickets and no traffic is sent to the target.\r\nTim Medin released the Kerberoast Python TGS cracker and discussed these methods at DerbyCon 2014.\r\nhttps://adsecurity.org/?p=2293\r\nPage 4 of 8\n\nAn attacker can crack service account passwords without ever getting admin access to the server or the network.\r\nThe attacker gets a foothold on a computer \u0026 Requests TGS tickets for several services with service accounts.\r\nExports the TGS tickets from memory, saves them to files, \u0026 uploads to a website or webservice (Google Drive).\r\nAn attacker owned computer on the internet grabs these files \u0026 runs Kerberoast against them until it identifies the\r\ncorrect NTLM password hash that will open one. Success in opening a TGS means the service account password\r\nwas found!\r\nNote that this attack can also work by sniffing network traffic and grabbing Kerberos TGS tickets encrypted using\r\nRC4_HMAC_MD5 off the wire.\r\nI’ll walk through this attack using a PowerShell script I wrote called Discover-PSMSSQLServers.ps1. This script\r\ndiscovers all the SQL servers in the domain/forest and identifies the associated service account. If it has a domain\r\nuser account, it is very likely the associated password is not very strong, so that account is targeted.\r\n1. SPN scan for SQL servers with service accounts.\r\nhttps://adsecurity.org/?p=2293\r\nPage 5 of 8\n\n2. After identifying the target, we use PowerShell to request the service ticket for this Service Principal\r\nName (SPN).\r\nNote that the service ticket requested has the RC4 encryption type.\r\nLooking at a packet capture, we can see the Kerberos communication and note that the ticket is RC4-HMAC-MD5.\r\nhttps://adsecurity.org/?p=2293\r\nPage 6 of 8\n\n3. Once the ticket is is received by the client, we can use Mimikatz (or other) to export all Kerberos tickets\r\nin the user’s memory space without elevated rights.\r\n4. After exporting the service ticket to a file, that file can be sent to our attacker machine running Kali\r\nLinux with Kerberoast. Depending on our wordlist file, we may be able to crack the service account’s\r\npassword associated with the ticket (file).\r\nThe attacker now knows the service account username and password valid on a server (or servers) and likely has\r\nadministrator rights.\r\nSince service accounts are typically over-permissioned in many enterprises, often with weak passwords, this is an\r\neasy way for an attacker to go from domain user to domain admin.\r\nMitigation:\r\nEnsure all service accounts (user accounts with Service Principal Names) have long, complex passwords greater\r\nthan 25 characters, preferably 30 or more. This makes cracking these password far more difficult. Service\r\nAccounts with elevated AD permissions should be the focus on ensuring they have long, complex passwords.\r\nEnsure all Service Account passwords are changed regularly (at least once a year). If possible use group managed\r\nservice accounts which have random, complex passwords (\u003e100 characters) and are managed automatically by\r\nActive Directory.\r\nDetection:\r\nDetection is a lot tougher since requesting service tickets (Kerberos TGS tickets) happens all the time when users\r\nneed to access resources.\r\nLooking for TGS-REQ packets with RC4 encryption is probably the best method, though false positives are likely.\r\nMonitoring for numerous Kerberos service ticket requests in Active Directory is possible by enabling Kerberos\r\nservice ticket request monitoring (“Audit Kerberos Service Ticket Operations”) and searching for users with\r\nexcessive 4769 events (Eventid 4769 “A Kerberos service ticket was requested”).\r\nReferences:\r\nSean Metcalf’s Presentations on Active Directory Security\r\nhttps://adsecurity.org/?p=2293\r\nPage 7 of 8\n\nKerberoast (GitHub)\r\nTim Medin’s DerbyCon “Attacking Microsoft Kerberos Kicking the Guard Dog of Hades” presentation in\r\n2014 (slides \u0026 video).\r\nMy GitHub repository\r\n(Visited 133,635 times, 4 visits today)\r\nSource: https://adsecurity.org/?p=2293\r\nhttps://adsecurity.org/?p=2293\r\nPage 8 of 8", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://adsecurity.org/?p=2293" ], "report_names": [ "?p=2293" ], "threat_actors": [ { "id": "8670f370-1865-4264-9a1b-0dfe7617c329", "created_at": "2022-10-25T16:07:23.69953Z", "updated_at": "2026-04-10T02:00:04.716126Z", "deleted_at": null, "main_name": "Hades", "aliases": [ "Operation TrickyMouse" ], "source_name": "ETDA:Hades", "tools": [ "Brave Prince", "Gold Dragon", "GoldDragon", "Lovexxx", "Olympic Destroyer", "Running RAT", "RunningRAT", "SOURGRAPE", "running_rat" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434367, "ts_updated_at": 1775791398, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/0d26ea08d29f9bc11bc25f856c7ffb4a599f3522.pdf", "text": "https://archive.orkl.eu/0d26ea08d29f9bc11bc25f856c7ffb4a599f3522.txt", "img": "https://archive.orkl.eu/0d26ea08d29f9bc11bc25f856c7ffb4a599f3522.jpg" } }