{ "id": "c99c7a45-2e46-48c0-a9a0-93beaf1320c9", "created_at": "2026-04-06T00:19:58.251262Z", "updated_at": "2026-04-10T03:28:02.930685Z", "deleted_at": null, "sha1_hash": "0e2bcda9b93f0b15b0e812d5493d863637ce8c84", "title": "Roasting AS-REPs", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 560743, "plain_text": "Roasting AS-REPs\r\nPublished: 2017-01-17 · Archived: 2026-04-05 19:53:50 UTC\r\nLast November, I published a post titled “Kerberoasting Without Mimikatz” that detailed new developments with\r\nPowerView and Tim Medin‘s Kerberoasting attack. This started me down the path of looking at Kerberos just a bit\r\nmore closely. Then a few weeks ago, my coworker Lee Christensen found an interesting presentation from Geoff\r\nJanjua of Exumbra Operations titled “Kerberos Party Tricks: Weaponizing Kerberos Protocol Flaws“, slides and\r\ntoolkit located here. One of the interesting points that Geoff mentioned, and that his Python-based “Party Trick”\r\ntoolkit executes, was abusing user accounts that don’t require Kerberos preauthentication.\r\nI recently dove much deeper into this topic and wanted to share what I was able to learn and develop. This post\r\nwill give some detailed background on the aspect of Kerberos we’re abusing, what the precise issue is, how to\r\neasily enumerate accounts that don’t need preauth, how to extract crackable hashes in these situations, and finally\r\nhow to crack these retrieved hashes efficiently. There is also an associated PowerShell toolkit, ASREPRoast, that\r\nis now live on GitHub.\r\ntl;dr – if you can enumerate any accounts in a Windows domain that don’t require Kerberos\r\npreauthentication, you can now easily request a piece of encrypted information for said accounts and efficiently\r\ncrack the material offline, revealing the user’s password.\r\nNote: this isn’t anything revolutionary, and obviously isn’t as useful as Kerberoasting, as accounts have to\r\nhave DONT_REQ_PREAUTH explicitly set for them to be vulnerable – you’re still reliant upon weak password\r\ncomplexity for the attack to work. However, this setting still exists on some accounts in some environments, we’re\r\njust not sure as to the frequency as it’s not something we normally looked for before. Our guess is that it’s likely\r\nenabled for older accounts, specifically Unix-related ones. If you happen to find it “in the wild”, we’d love to hear\r\nfrom you ;) (@harmj0y or will [at] harmj0y.net).\r\n[Edit] if you have GenericWrite/GenericAll rights over a target user, you can maliciously modify their\r\nuserAccountControl to not require preauth, use ASREPRoast, and then reset the value ;)\r\nhttps://blog.harmj0y.net/activedirectory/roasting-as-reps/\r\nPage 1 of 9\n\nBackground\r\nI’m not going to go through all aspects of Kerberos, as people like Sean Metcalf have already done a great job of\r\nthis. If terms like AS-REQ and AS-REP are completely foreign to you, I would recommend reading Sean’s\r\npost for some basic background first. The aspect we care for the purposes of this post is something called\r\nKerberos preauthentication.\r\nUnder normal operations in a Windows Kerberos environment, when you initiate a TGT request for a given user\r\n(Kerberos AS-REQ, message type 10) you have to supply a timestamp encrypted with that user’s key/password.\r\nThis structure is PA-ENC-TIMESTAMP and is embedded in PA-DATA (preauthorization data) of the AS-REQ –\r\nboth of these structure are described in detail on page 60 of RFC4120 and were introduced in Kerberos Version 5.\r\nThe KDC then decrypts the timestamp to verify if the subject making the AS-REQ really is that user, and then\r\nreturns the AS-REP and continues with normal authentication procedures.\r\nNote: the KDC does increase the badpwdcount attribute for any incorrect PA-ENC-TIMESTAMP attempts, so\r\nwe can’t use this as a method to online brute-force account passwords :(\r\nhttps://blog.harmj0y.net/activedirectory/roasting-as-reps/\r\nPage 2 of 9\n\nThe reason for Kerberos preauthentication is to prevent offline password guessing. While the AS-REP ticket itself\r\nis encrypted with the service key (in this case the krbtgt hash) the AS-REP “encrypted part” is signed with\r\nthe client key, i.e. the key of the user we send an AS-REQ for. If preauthentication isn’t enabled, an attacker can\r\nsend an AS-REQ for any user that doesn’t have preauth required and receive a bit of encrypted material back that\r\ncan be cracked offline to reveal the target user’s password.\r\nThis is something that has been known for a long time, after all, it’s the reason preauth was implemented in\r\nKerberos! In modern Windows environments, all user accounts require Kerberos preauthentication, but\r\ninterestingly enough, by default Windows attempts the AS-REQ/AS-REP exchange without preauthentication\r\nfirst, falling back to supplying the encrypted timestamp on the second submission:\r\nI have no idea why this behavior happens ¯\\_(ツ)_/¯\r\n[Edit] @munmap pointed out on Twitter that this behavior is due to the client not knowing the supported\r\nETYPES ahead of time, something explicitly detailed in section 2.2 of RFC6113.\r\nHowever, Windows offers a way to manually disable this protection for specific accounts through a\r\nuseraccountcontrol modification:\r\nhttps://blog.harmj0y.net/activedirectory/roasting-as-reps/\r\nPage 3 of 9\n\nIf you’re already an authenticated (but otherwise unprivileged) user, you can easily enumerate what users in the\r\ndomain have this setting with the LDAP filter (userAccountControl:1.2.840.113556.1.4.803:=4194304).\r\nPowerView‘s Get-DomainUser already has this implemented with the -PreauthNotRequired parameter:\r\nSo now we know what the issue is and how to identify vulnerable users. While people have executed brute-forcing\r\nof the AS-REQ’s PA-ENC-TIMESTAMP component of Kerberos exchanges for well over a decade (the hash\r\nhttps://blog.harmj0y.net/activedirectory/roasting-as-reps/\r\nPage 4 of 9\n\nformat is even in Hashcat, -m 7500/ ‘Kerberos 5 AS-REQ Pre-Auth’) the only toolset I’ve seen that attacks RC4\r\nAS-REPs is Geoff’s Python toolkit. We wanted something that was Windows based that also didn’t need\r\nadministrative privileges on a machine to allow us flexibility in our attack workflow. We also wanted a faster way\r\nto crack these hashes.\r\nASREPRoast\r\nMy first hope was to find something in .NET that exposed the raw bytes of the AS-REP similar to the\r\nKerberoasting approach. I spent a while searching for any .NET method that would allow access to the raw byte\r\nresponse of the AS-REP and unfortunately came up short. Though I can’t say definitively if this is impossible, my\r\ngut feeling is that it’s likely an abstraction level too deep for us to access easily through .NET. Even if there was,\r\nwe would still have one complication, as modern Windows Kerberos environments default to the the AES256-\r\nCTS-HMAC-SHA1-96 encryption in the AS-REP instead of the much quicker ARCFOUR-HMAC-MD5/RC4\r\napproach. RC4-HMAC is significantly quicker to crack, so we prefer it if possible.\r\nThe approach I ended up taking was to construct the AS-REQ by hand in order to control the necessary\r\nparameters, and parsing the KDC’s AS-REP response in order to determine success/failure and extract the\r\nencrypted material. Here was another roadblock- Kerberos uses ASN.1 encoding for its structures, something that\r\n.NET does not have built in encoders or decoders for. Luckily, there is an open source C# version of the Bouncy\r\nCastle crypto library that features, among many, many other things, robust capability for ASN.1 encoding and\r\ndecoding.\r\nUnfortunately, I don’t have time to give a full ASN.1 tutorial, but I will share a few pointers that helped me while\r\ndeveloping this tool. The specifications we care about for the AS-REQ are laid out on page 55 of RFC1510 and\r\npage 74 of RFC4120. Benjamin Delpy also documents all these ASN.1 structures amazingly in his Kekeo project.\r\nHere’s the structure description:\r\nAS-REQ ::= [APPLICATION 10] KDC-REQ\r\nKDC-REQ ::= SEQUENCE {\r\n pvno[1] INTEGER,\r\n msg-type[2] INTEGER,\r\n padata[3] SEQUENCE OF PA-DATA OPTIONAL,\r\n req-body[4] KDC-REQ-BODY\r\n}\r\nPA-DATA ::= SEQUENCE {\r\n padata-type[1] INTEGER,\r\n padata-value[2] OCTET STRING,\r\n -- might be encoded AP-REQ\r\n}\r\nKDC-REQ-BODY ::= SEQUENCE {\r\n kdc-options[0] KDCOptions,\r\n cname[1] PrincipalName OPTIONAL,\r\nhttps://blog.harmj0y.net/activedirectory/roasting-as-reps/\r\nPage 5 of 9\n\n-- Used only in AS-REQ\r\n realm[2] Realm, -- Server's realm\r\n -- Also client's in AS-REQ\r\n sname[3] PrincipalName OPTIONAL,\r\n from[4] KerberosTime OPTIONAL,\r\n till[5] KerberosTime,\r\n rtime[6] KerberosTime OPTIONAL,\r\n nonce[7] INTEGER,\r\n etype[8] SEQUENCE OF INTEGER, -- EncryptionType,\r\n -- in preference order\r\n addresses[9] HostAddresses OPTIONAL,\r\n enc-authorization-data[10] EncryptedData OPTIONAL,\r\n -- Encrypted AuthorizationData encoding\r\n additional-tickets[11] SEQUENCE OF Ticket OPTIONAL\r\n}\r\nAnother thing that helped me a lot was to Wireshark legitimate Kerberos exchanges, export the Kerberos packet\r\nbytes, and visualize the data using this JavaScript ASN.1 decoder:\r\nThis particularly helped during the next part, which was learning how to use Bouncy Castle through PowerShell to\r\nconstruct a proper ASN.1 encoded AS-REQ. But after a few struggles with tagging and finding the correct data\r\nstructures, I came up with New-ASReq, which takes a user/domain name, builds the properly nested components,\r\nand returns the raw bytes for the request.\r\nAnd because we’re building this by hand, we can include or omit anything we want. So we can include just the\r\nARCFOUR-HMAC-MD5 etype instead of all supported encryption etypes. This type and its use in Windows\r\nKerberos auth is explained in detail in RFC4757. What’s especially nice is that section 3 includes the message\r\nhttps://blog.harmj0y.net/activedirectory/roasting-as-reps/\r\nPage 6 of 9\n\ntypes for different uses of the algorithm. While the AS-REP ticket uses type 2 like a TGS-REP ticket (i.e.\r\nkerberoasting) this component of the response is encrypted with the service key, which in this case is the krbtgt\r\nhash and therefore not crackable. However, the AS-REP encrypted part, which is the section we can essentially\r\n‘downgrade’ to RC4-HMAC, is the same algorithm but of message type 8. This will come into play later during\r\nthe cracking section.\r\nA second function in ASREPRoast, Get-ASREPHash, wraps New-ASReq to generate the appropriate AS-REQ\r\nfor a specific user/domain, enumerates a domain controller for the passed domain, sends the crafted AS-REQ, and\r\nreceives the response bytes. Bouncy Castle is used to decode the response, checking whether it is a KRB-ERROR\r\nresponse or a proper AS-REP. If the request succeeded, we can extract out the enc-part section that’s RC4-HMAC\r\nencrypted using the specified user’s hash and return it in a nice format:\r\nThe final useful function in ASREPRoast is Invoke-ASREPRoast. If run from a domain authenticated, but\r\notherwise unprivileged, user context in a Windows Kerberos environment, this function will first enumerate all\r\nusers who have “Do not require Kerberos preauthentication” set in their user account control settings by using the\r\nLDAP filter (userAccountControl:1.2.840.113556.1.4.803:=4194304). For each user returned Get-ASREPHash\r\nis used to return a crackable hash:\r\nhttps://blog.harmj0y.net/activedirectory/roasting-as-reps/\r\nPage 7 of 9\n\nCracking The Hashes\r\nWe now have a nice set hash representations of RC4-HMAC AS-REPs, each of which are encrypted with a user’s\r\npassword. We should now be able to crack these offline à la Kerberosting (krb5tgs format in John the Ripper), but\r\nremember that despite using the same algorithm and approach as the existing TGS-REP format, the message type\r\nhere is 8 instead of 2.\r\nThis unfortunately means that existing plugins won’t work, but luckily for us, all we have to do is change this\r\nline to an 8 instead of a 2, remove some of the specific TGS ASN.1 speedups, and change the format naming. I\r\nhave a included a tweaked version of this krb5_asrep_fmt_plug.c plugin with the ASREPRoast project. Simply\r\ndrop it into the source folder for Magnumripper, run the normal build instructions, and you’d good to go for\r\ncracking the output of ASREPRoast.ps1:\r\nhttps://blog.harmj0y.net/activedirectory/roasting-as-reps/\r\nPage 8 of 9\n\nI believe that it should be simple to modify Hashcat’s existing TGS-REP format as well in a similar way, but I\r\nhaven’t attempted it yet. Also, because this is the same algorithm as the krb5tgs/Kerberoasting format, just with a\r\ntweak in key material, performance should be similar to the existing modules.\r\nClosing Thoughts\r\nAs I mentioned at the beginning, this obviously isn’t as useful as the Kerberoasting attack, as accounts have to\r\nhave DONT_REQ_PREAUTH explicitly set for them to be vulnerable, and you’re still reliant upon weak\r\npassword complexity for the attack to work. However, this setting is sometimes present in some environments,\r\noften on aging accounts for backwards compatibility reasons, and we feel that the toolset will be operationally\r\nuseful in some situations at least.\r\nDefensively, the same protections outlined for Kerberoasting apply here, specifically have really long passwords\r\nfor these types of accounts and alert when abnormal hosts are sent an AS-REP for the account. Also, audit what\r\naccounts have this setting, which is easy with PowerView (Get-DomainUser -PreauthNotRequired) or other\r\nLDAP toolsets with the (userAccountControl:1.2.840.113556.1.4.803:=4194304) filter. Carefully consider\r\nwhether accounts with this setting truly are needed.\r\n[Edit] also for the defensive side, @munmap suggested investigating Kerberos FAST pre-authentication and/or Public Key Cryptography for Initial Authentication in Kerberos (PKINIT).\r\nSource: https://blog.harmj0y.net/activedirectory/roasting-as-reps/\r\nhttps://blog.harmj0y.net/activedirectory/roasting-as-reps/\r\nPage 9 of 9", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://blog.harmj0y.net/activedirectory/roasting-as-reps/" ], "report_names": [ "roasting-as-reps" ], "threat_actors": [ { "id": "1a76ed30-4daf-4817-98ae-87c667364464", "created_at": "2022-10-25T16:47:55.891029Z", "updated_at": "2026-04-10T02:00:03.646466Z", "deleted_at": null, "main_name": "IRON LIBERTY", "aliases": [ "ALLANITE ", "ATK6 ", "BROMINE ", "CASTLE ", "Crouching Yeti ", "DYMALLOY ", "Dragonfly ", "Energetic Bear / Berserk Bear ", "Ghost Blizzard ", "TEMP.Isotope ", "TG-4192 " ], "source_name": "Secureworks:IRON LIBERTY", "tools": [ "ClientX", "Ddex Loader", "Havex", "Karagany", "Loek", "MCMD", "Sysmain", "xfrost" ], "source_id": "Secureworks", "reports": null } ], "ts_created_at": 1775434798, "ts_updated_at": 1775791682, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/0e2bcda9b93f0b15b0e812d5493d863637ce8c84.pdf", "text": "https://archive.orkl.eu/0e2bcda9b93f0b15b0e812d5493d863637ce8c84.txt", "img": "https://archive.orkl.eu/0e2bcda9b93f0b15b0e812d5493d863637ce8c84.jpg" } }