Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add hash modes 19600 (krb5tgs enctype 17) and 19700 (krb5tgs enctype 18) #1955

merged 1 commit into from Mar 13, 2019


None yet
3 participants
Copy link

Fist0urs commented Mar 13, 2019

this PR adds 2 new formats:

  • krb5tgs encryption type 17 (AES128-CTS-HMAC-SHA1-96);
  • krb5tgs encryption type 18 (AES256-CTS-HMAC-SHA1-96).

The jtr implementation should also be there soon (cc @kholia) 馃憤

Issues related

This addresses issue #1384. Furthermore, #1386 being a subset of the algorithms implemented within this PR, it would be trivial to create such a new hash format and also close this issue (I'll do it later). Finally, this implementation could also permit to close #959 as same algorithms are involved... Later again 馃槈

How does it work

(not so) TL;DR: within a Windows Active Directory environment, registered services (as MsSQL or so) rely on a domain account in order to be functional.
This domain account should be a service account but administrators can provided whichever account they want provided that it has sufficient rights.
Such specific accounts are easily identifiable by their LDAP attribute servicePrincipalName (SPN) and can be listed by any authenticated user (whatever are his rights in the domain).
Furthermore any authenticated can request a TGS ticket for these accounts (/invoke Wikipedia). Nevertheless, if one can request such tickets, it does not mean that he would be able to impersonate these accounts.
Indeed, the important part, assuring that a user submitting a ticket is its legit owner, is encrypted with a key which is constructed from a secret only known by the legit account which is... its domain account password 馃槈 . This attack is known as "Kerberoast" and was discovered by Tim Medin.

So, having a valid domain user account, you can request tickets of accounts having a SPN and try to retrieve the password of concerned accounts 馃槉

Algorithms details

Active Directory offers 4 algorithms to generate the encryption key:

  • DES (disabled by default, not really usefull)
  • RC4-HMAC-MD5 (enctype 23)
  • AES128-CTS-HMAC-SHA1-96 (enctype 17) - with some nice 4096 iterations count PBKDF2 HMAC-SHA1 ...
  • AES256-CTS-HMAC-SHA1-96 (enctype 18) - same number of algo/iterations

I had already implemented enctype 23 back in the days but enctype 17 and 18 were missing, so here they are!

How can I haz ticketz?

Back in the days I coded a private tool (kerberom) based on the amazing impacket from @asolino. Then other tools became public and the attack is now within the impacket suite (
The sole interest of kerberom now is that it can be built as a Windows binary (it also supports Windows implicit authentication, which is really useful when you've managed to compromise a user account but don't have his password, as in phishing campains during redteam assessments for example)... but I also plan to implement this in
So, you should use from impacket in order to get these hashes! (if you have the password/hash of an authenticated user, of course, otherwise kerberom).
All you have to do is wait for this PR SecureAuthCorp/impacket#584 to be accepted 馃槈


Guys... we are in 2019... you should now use Managed Service Accounts. If not possible, create a dedicated domain account having a random password!
There are also other mechanisms, but these 2 are sufficient enough and easy to set-up 馃憤


Provided a rig of 8 GTX 1080Ti:

Hashmode: 13100 - Kerberos 5 TGS-REP etype 23 (RC4-HMAC-MD5)
Speed.#*.........:  3120.7 MH/s

Hashmode: 19600 - Kerberos 5 TGS-REP etype 17 (AES128-CTS-HMAC-SHA1-96)
(Iterations: 4095)
Speed.#*.........:  8643.4 kH/s

Hashmode: 19700 - Kerberos 5 TGS-REP etype 18 (AES256-CTS-HMAC-SHA1-96)
(Iterations: 4095)
Speed.#*.........:  4290.3 kH/s

The performances are not good compared to the RC4 algorithm, but meh you know... PBKDF2, AES, etc.
Anyway, these are still pretty good performances regarding involved alogirthms + iterations count (less than 5 minutes on enctype 17 to complete a 1.4GB dictionary!)

Further reading

@HarmJ0y and @PyroTek3 described all the mechanisms involved in these kinds of attacks. They also give a lot of insights on Active Directory on a global basis. I highly recommend you to read their awesome blogs (harmj0y's one and PyroTek3's one) whether you are a beginner or a confirmed Windows administrator/pentester.
If you are not afraid of Croissant's black magic I also recommend you to read some papers of the almighty Aur茅lien Bordes, pioneer in all this (here and here)

I hope you have all the information you need to Kerberoast a bit now 馃槈


PS: a big thanks to @skelsec who provided the algorithm and convinced me to implement it in hashcat as I was being lazy...
PS2: a big thanks to @jsteube for the insights on the new hashcat architecture I was not familiar with! This project is awesome and formats are really easy to implement now!

my $b_seed = $pbkdf2->PBKDF2 ($mysalt, $word);

printf "seed: %s\n", byte2hex($b_seed);

This comment has been minimized.

Copy link

jsteube Mar 13, 2019


Debugging leftover?

$b_key_bytes = $b_key_bytes . $cbc->encrypt ($b_key_bytes, $b_seed, $b_iv);

printf "key_bytes: %s\n", byte2hex($b_key_bytes);

This comment has been minimized.

Copy link

jsteube Mar 13, 2019


Debugging leftover?

@jsteube jsteube merged commit c99ab74 into hashcat:master Mar 13, 2019

1 of 2 checks passed

continuous-integration/appveyor/pr Waiting for AppVeyor build to complete
continuous-integration/travis-ci/pr The Travis CI build passed

This comment has been minimized.

Copy link

brandoncasaba commented Mar 13, 2019

Awesome, thank you, go collect your bounty from #959!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can鈥檛 perform that action at this time.