Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It was my flawed understanding (and I assume many people's as well), that the salt for AES types in Kerberos was
FQDN.Upper() + Username.Lower()
. However this is not the case.I believe Kevin Robertson details it the clearest in Get-KerberosAESKey
This came as such a surprise that I wondered how Windows determines the correct salt when supplying any username for authentication. The secret lies in an initial AS-REQ without a
PA-ENC-TIMESTAMP
section and withPrincipalName
set to the case-insensitive username. The KDC will then respond with anKRB5_ERR_PREAUTH_REQUIRED
containing aPA_ETYPE_INFO2
, which supplies the encryption type + the correct salt. As per usual, impacket already has this figured out:https://github.com/SecureAuthCorp/impacket/blob/d65c0d220a9613ae74db42adc9362a7947acdd66/impacket/krb5/kerberosv5.py#L200
So what to do? Well the extra back/forth might not be ideal in some scenarios (brute-forcing), but I'd be happy to implement it just to have it. Maybe a separate command like
getsalt
? It could also be added as part of thehash
command which I rather like. It does open itself up to a fair bit of complexity like extra flags, specifying whether the username is already cased properly, etc.Of course these steps are generally unnecessary if you just use the
samaccountname
from AD (machine accounts aside). Therefore I've started by just removing anyToLower()
calls when calculating the salt. This might also be best paired with some help/notes that indicate the username is case sensitive.Let me know what your thoughts are and I'd be happy to oblige.