MixedCase Usernames successful in userenum, but gives false negative in passwordspray

[bandrel]

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 for LIONEL.FUSCO it will return a valid user for [email protected].

However when you go to password spray even with the valid account password the authentication will fail with [email protected], but will succeed with the same password using the account [email protected]

[bandrel]

Version number dev (9cfb81e)

[bandrel]

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

[0xZDH]

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.