Kerberoasting Without Mimikatz harmj. Just about two years ago, Tim Medin presented a new attack technique he christened Kerberoasting. While we didnt realize the full implications of this at the time of release, this attack technique has been a bit of a game changer for us on engagements. More and more attention has been brought to Kerberoasting recently, with mubix releasing a three partseries on the topic, Sean Metcalf covering it several times, and leonjza doing a detailed writeup as well. Cal Tjader The Prophet on this page. Thanks to an awesome Power. View pull request by machosec, Kerberoasting is easier than ever using pure Power. Shell. I wanted to briefly cover this technique and its background, how weve been using it recently, and a few awesome new developments. Kerberoasting Background. I first heard about Kerberoasting from Tim at SANS Hack. Fest 2. 01. 4 during his Attacking Kerberos Kicking the Guard Dog of Hades talk he also released a Kerberoasting toolkit here. Ill briefly paraphrase some technical detail of the attack, but I highly recommend you read Tims slides andor Seans explanation for more detail. Theres also an excellent page of Microsoft documentation titled Kerberos Technical Supplement for Windows which finally clarified a few points involved in this process that were fuzzy to me. Heres my version of the obligatory this is how kerberos works graphic As far as how Kerberoasting fits into this process, this is how I understand it if I am mistaken on some point please let me know after a user authenticates to the key distribution center KDC, which in the case of a Windows domain is the domain controller they receive a ticket granting ticket TGT signed with the domain krbtgt account that proves they are who they say they are. The TGT is then used to request service tickets TGS for specific resourcesservices on the domain. Part of the service ticket is encrypted with the NTLM hash of the target service instance. So how does the KDC determine exactly what key to use when encrypting these service tickets The Windows implementation of the Kerberos protocol uses service principal names SPNs to determine which service account hash to use to encrypt the service ticket. There are two types of service principal names in Active Directory host based SPNs that are linked to a domain computer account and arbitrary SPNs that are usually but not always linked to a domain user account. As Microsoft explains, When a new computer account is created in Active Directory, host based SPNs are automatically generated for built in servicesIn reality, SPNs are only created for the HOST service and all built in services use the HOST SPN. Put another way, The HOST service represents the host computer. The HOST SPN is used to access the host computer account whose long term key is used by the Kerberos protocol when it creates a service ticket. Heres an example of a default computer account in my test domain You can see the HOSTWINDOWS1 and HOSTWINDOWS1. SPNs for the WINDOWS1 computer account. When a domain user requests access to WINDOWS1. C, the KDC maps this request to the HOSTWINDOWS1. SPN, indicating that the WINDOWS1 machine account NTLM hash which is stored both on WINDOWS1 locally and the NTDS. Active Directory database on the DCKDC should be used to encrypt the server part of the service ticket. The signedencrypted ticket is then presented to WINDOWS1. From the Kerberoasting perspective, we generally dont care about host based SPNs, as a computers machine account password is randomized by default and rotates every 3. However, remember that arbitrary SPNs can also be registered for domain user accounts as well. One common example is a service account that manages several MSSQL instances this user account would have a lt MSSQLSvcHOST PORT SPN for each MSSQL instance its registered for stored in the users serviceprincipalname attribute Sean keeps an updated list of SPNs here. If we have an arbitrary SPN that is registered for a domain user account, then the NTLM hash of that users accounts plaintext password is used for the service ticket creation. This is the key to Kerberoasting. Obligatory So Why Does This MatterBecause of how Kerberos works, any user can request a TGS for any service that has a registered SPN HOST or arbitrary in a user or computer account in Active Directory. Remember that just requesting this ticket doesnt grant access to the requesting user, as its up to the serverservice to ultimately determine whether the user should be given access. Tim realized that because of this, and because part of a TGS requested for an SPN instance is encrypted with the NTLM hash of a service accounts plaintext password, any user can request these TGS tickets and then crack the service accounts plaintext password offline, without the risk of account lockoutGentil Kiwis answer is correct. He developed this mimikatz tool that is able to retrieve nonexportable private keys. However, his instructions are outdated. To reiterate, any domain user account that has a service principal name set can have a TGS for that SPN requested by any user in the domain, allowing for the offline cracking of the service account plaintext password This is obviously dependent on a crackable service account plaintext, but luckily for us service accounts tend to often have simple passwords that change very infrequently. Z2L5F1hVj74/WfcqHp_EsRI/AAAAAAAAH9g/rAr6CPd3MWAGn8qTcsOqprivBaw4aNfnwCLcBGAs/s1600/1yhnpz.jpg' alt='Mimikatz 2017' title='Mimikatz 2017' />A new ransomware outbreak today has hit some major infrastructure in Ukraine including Kiev metro. Here are some details about this new variant of Petya. As an added bonus, Tim mentions on slide 1. Old School Kerberoasting. Tims outlined approachtoolkit used a combination of toolsets to request tickets, extract them from memory using Mimikatz, and transform them into a crackable format. In general, the process up until recently went as follows Enumerate the domain accounts with SPNs set either with Tims Get. User. SPNS. ps. 1 script, Seans Find PSService. Accounts. ps. 1 script, or Power. Views Get Net. User SPN. Request TGSs for these specific SPNs with the builtin Windows tool setspn. NET System. Identity. Model. Tokens. Kerberos. Requestor. Security. Token class in Power. Shell. Extract these tickets from memory by invoking the kerberos list export Mimikatz command, with the optional base. The tickets were then downloaded, or the base. Begin offline password cracking with Tims tgsrepcrack. John the Rippers  kirbi. Tims toolset and added an autokerberoast. Also, tifkin wrote a Go version of a TGS cracker that functioned a bit faster than the original Python version. New School Kerberoasting. A few recentish things really simplified our usage of Kerberoasting on engagements. First, Michael Kramer added the KRB5. TGS format to John the Ripper in September of 2. Second, Fist. 0urs committed the same algorithm to Hashcat in Febuary 2. GPU based cracking of these tickets. This was really a watershed for us, as it greatly expanded the range of service account passwords we could crack. And finally, Matan Hart machosecs pull request to Power. View removed the Mimikatz requirement. NET class Kerberos. Requestor. Security. Token used in previous approaches also had a Get. Request method, which returns the raw byte stream of the Kerberos service ticket. With a bit string manipulation, Matan was able to easily extract out the encrypted i. TGS. We are now no longer dependent on Mimikatz for ticket extractionI recently rolled the necessary functions into a single, self contained script that contains the necessary components from Power. View this has also been updated in Empire. We are currently in the process of refactoring large components of Power.