You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
net user roastme /add /domain
net user roastme password
setspn.exe -S roast/duck roastme
then set the supported type to aes128 and aes256 in aduc boxy thing
Hashes are below - one retrieved using /SPN and the other with /user . (as I originally thought that it was the lack of user/domain that was breaking it)
Type 23 works fine with exact same account (using tgtdeleg).
hashcat version 6.2.5 fails to crack the things - cli used: -m 19700 -a 3 'passwor?a' --potfile-disable
Rubeus makes some assumptions regarding the Kerberos salt. If the salt doesn't match the salt stored in AD it will fail to crack. Easy way to see the salt for the account is to issue and asktgt with the /opsec flag
We also faced this issue using impacket (see fortra/impacket#1772 and fortra/impacket#1773).
Using the upn instead of the sAMAccountName gives better results. The upn used on the creation will be stored as the salt, even if the upn was changed afterwards.
Set up a SPN in a test lab with:
then set the supported type to aes128 and aes256 in aduc boxy thing
Hashes are below - one retrieved using
/SPN
and the other with/user
. (as I originally thought that it was the lack of user/domain that was breaking it)Type 23 works fine with exact same account (using tgtdeleg).
hashcat version 6.2.5 fails to crack the things - cli used:
-m 19700 -a 3 'passwor?a' --potfile-disable
The text was updated successfully, but these errors were encountered: