Add hash modes 19600 (krb5tgs enctype 17) and 19700 (krb5tgs enctype 18)#1955
Add hash modes 19600 (krb5tgs enctype 17) and 19700 (krb5tgs enctype 18)#1955jsteube merged 1 commit intohashcat:masterfrom
Conversation
|
|
||
| my $b_seed = $pbkdf2->PBKDF2 ($mysalt, $word); | ||
|
|
||
| printf "seed: %s\n", byte2hex($b_seed); |
|
|
||
| $b_key_bytes = $b_key_bytes . $cbc->encrypt ($b_key_bytes, $b_seed, $b_iv); | ||
|
|
||
| printf "key_bytes: %s\n", byte2hex($b_key_bytes); |
|
Awesome, thank you, go collect your bounty from #959! |
|
We are currently implementing support for the HIP backend and during first tests the new HIPRTC JiT fails in hash-mode 19600/19700 with the following errors: mode 19600: mode 19700: If I interpret this correctly, it thinks that there this is some logic error that needs fixing? It seems the switch can only enter case 0, probably ending up in false negative for the other cases. It's also possible that this is some sort of false report from the JiT, however we need to deal with it. Please try to rewrite this part so that the JiT can finish the compilation. Could you please review this part again? |
|
It looks like it possibly doesn't like that the mask variable is initialized inside the switch scope branch. If you declare "u32 mask;" before the switch and change the branch statements to assignment lines does that get rid of the error? The other message that the default branch can't be hit can safely be removed, it should never be hit. It simply has a return line. |
|
Good thinking. I have moved the mask declaration out of the switch case and that was enough for the compiler to stop complaining. |
Hi,
this PR adds 2 new formats:
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:
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 (GetUserSPNs.py).
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 GetUserSPNs.py...
So, you should use GetUserSPNs.py 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 fortra/impacket#584 to be accepted 😉
Countermeasures
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 👍
Performances
Provided a rig of 8 GTX 1080Ti:
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 😉
Cheers!
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!