Open bandrel opened 2 months ago
Version number dev (9cfb81e)
May be limited to the specific version mentioned. was unable to duplicate with version from go latest Version: dev (n/a) - 08/01/24 - Ronnie Flathers @ropnop
I ran into a similar scenario and decied to dig a bit deeper into Kerberos. It seems like this has to do with the way Kerberos will encrypt data by using the authenticating username as a part of the salt.
Normally, Windows will set the realm as the domain name with all characters forced to upper case. The username is then appended to the realm exactly as it is stored in Active Directory. For example, if the domain is lab.local
and the user is jDoe
(notice the capital D
), the encryption salt that Kerberos will use server-side will be LAB.LOCALjDoe
. In this scenario, if authentication is attempted for jdoe
(notice the lower case d
), the salt used client-side for encryption will be LAB.LOCALjdoe
and will fail to validate authentication.
The way I found to temporarily resolve this is, during user enumeration, attempt to extract the supported encryption type's salt in order to obtain the exact case-sensitive username format stored in Active Directory. This new username can then be used during follow up password spraying attempts.
This is more likely a nuance in how AD Kerberos is treated and not a bug in Kerbrute, but we wanted to make sure everyone knew about it.
if the samaccountname in AD is
lionel.fusco
and the userenum attack is ran forLIONEL.FUSCO
it will return a valid user forLIONEL.FUSCO@poi.local
.However when you go to password spray even with the valid account password the authentication will fail with
LIONEL.FUSCO@poi.local
, but will succeed with the same password using the accountlinonel.fusco@poi.local