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
We discovered an issue on the TGS hashes with etype 17 (AES-128) and etype 18(AES-256).
The hash returned by GetUserSPNs.py are build using the sAMAccountName as the result which seems not to be correct.
The first hash shown below is the output of GetUserSPNs.py, which could not be recovered by hashcat. For the second hash we only changed the salt from thisisaveryverylongu to thisisaveryverylongusername. This hash could be recovered. (Password123)
Our first guess was that the UPN has to be parsed instead of the sAMAccountName. After implementing this fix, we got better results.
But after digging deeper into the issue we noticed that the UPN is also not the correct value here. If we change the UPN, still the old value was used as the salt. We could not find a way to query the salt in the AD.
@dirkjanm then told us that you can retrieve the salt by requesting a TGT for this user without credentials with getTGT.py -no-pass EMEA.ATT.LAB/thisisaveryverylongu. This gives us the correct salt as shown in the picture below.
Steps to reproduce
Create a user with a name longer than 20 characters (sAMAccountName is truncated to 20 characters)
Activate AES encryption
Set a SPN
Kerberoast the account
change UPN
Kerberoast the account again
The text was updated successfully, but these errors were encountered:
Configuration
impacket version: v0.12.0.dev1+20240327.181547.f8899e65
Python version: 3.10.12
Command
Additional context
We discovered an issue on the TGS hashes with etype 17 (AES-128) and etype 18(AES-256).
The hash returned by GetUserSPNs.py are build using the sAMAccountName as the result which seems not to be correct.
The first hash shown below is the output of GetUserSPNs.py, which could not be recovered by hashcat. For the second hash we only changed the salt from
thisisaveryverylongu
tothisisaveryverylongusername
. This hash could be recovered. (Password123)Our first guess was that the UPN has to be parsed instead of the sAMAccountName. After implementing this fix, we got better results.
But after digging deeper into the issue we noticed that the UPN is also not the correct value here. If we change the UPN, still the old value was used as the salt. We could not find a way to query the salt in the AD.
@dirkjanm then told us that you can retrieve the salt by requesting a TGT for this user without credentials with
getTGT.py -no-pass EMEA.ATT.LAB/thisisaveryverylongu
. This gives us the correct salt as shown in the picture below.Steps to reproduce
The text was updated successfully, but these errors were encountered: