I noticed that the AS-REP Roasting functionality only supported RC4, so I added support for AES encryption types as well (etype 17 and 18) through the /aes flag, after encountering an environment where RC4 was apparently disabled completely.
For example, I would get the following error message when attempting AS-REP Roasting against accounts in this environment:
[X] KRB-ERROR (14) : KDC_ERR_ETYPE_NOTSUPP
To replicate this, I configured the following Group Policy setting on my test Server 2019 domain controller to only support AES128_HMAC_SHA1 and AES256_HMAC_SHA1:
Once this configuration is applied (on my Server 2019 setup at least), only the AES encryption types would work in Kerberoasting and AS-REP Roasting attacks, even if the "This account supports Kerberos AES 128/256 bit encryption" account settings aren't enabled on the target accounts. For this reason I followed a slightly different approach to how the Kerberoasting module handles AES. When the /aes flag is specified with asreproast, instead of searching for the UAC flags indicating whether an account supports AES, it will simply request etype 17 directly. If a KDC_ERR_ETYPE_NOTSUPP error is encountered it will try again with etype 18.
Hashcat and John output is supported. John output for etype 18 is in the format $krb5asrep$18$salt$edata2$checksum, as per the comments and test hashes in the source code for John's AS-REP Roasting module. Etype 17 is basically the same.
Haschat output for etype 18 is in the format $krb5asrep$18$user$realm$checksum$edata2. Hashcat doesn't currently support AES AS-REPs yet, but I've submitted a pull request (hashcat/hashcat#3729) for it that'll use this hash format, which is intended to be similar to Hashcat's format for AES TGS-REPs.
0xe7
commented
1 year ago
I noticed that the AS-REP Roasting functionality only supported RC4, so I added support for AES encryption types as well (etype 17 and 18) through the
/aesflag, after encountering an environment where RC4 was apparently disabled completely.For example, I would get the following error message when attempting AS-REP Roasting against accounts in this environment:
To replicate this, I configured the following Group Policy setting on my test Server 2019 domain controller to only support
AES128_HMAC_SHA1andAES256_HMAC_SHA1:Once this configuration is applied (on my Server 2019 setup at least), only the AES encryption types would work in Kerberoasting and AS-REP Roasting attacks, even if the "This account supports Kerberos AES 128/256 bit encryption" account settings aren't enabled on the target accounts. For this reason I followed a slightly different approach to how the Kerberoasting module handles AES. When the
/aesflag is specified withasreproast, instead of searching for the UAC flags indicating whether an account supports AES, it will simply request etype 17 directly. If aKDC_ERR_ETYPE_NOTSUPPerror is encountered it will try again with etype 18.Hashcat and John output is supported. John output for etype 18 is in the format
$krb5asrep$18$salt$edata2$checksum, as per the comments and test hashes in the source code for John's AS-REP Roasting module. Etype 17 is basically the same.Haschat output for etype 18 is in the format
$krb5asrep$18$user$realm$checksum$edata2. Hashcat doesn't currently support AES AS-REPs yet, but I've submitted a pull request (hashcat/hashcat#3729) for it that'll use this hash format, which is intended to be similar to Hashcat's format for AES TGS-REPs.