Kerberos Username Enumeration – Username Wordlists
I’ve been having a fair bit of joy with the auxiliary/gather/kerberos_enumusers metasploit module on internal engagements, however you do need to provide the module with a good quality username wordlist or wordlists.
On a recent engagement, using only the top 50 male and female userlists, I was able to guess 70 domain accounts from a possible 400, and of course several of them were found to be configured with the obligatory easily guessed password.
Most domains I see tend to leverage some form of firstname, surname combination for domain user usernames. For example:
[Firstname].[surname] e.g: JACK.SMITH
[Firstname, First Letter].[Surname] e.g. J.SMITH
To that end I have created some username lists that are likely to identify valid usernames when targeting large Windows domains. The lists are compiled from the top 500 most common firstname and surname as per the United Kingdom’s Office for National Statistics (ONS).
Initially, you will want to run a tool such as Responder which will help you determine the format for usernames within the target environment e.g. L.FOWLER or LIAM.FOWLER. Indeed, I typically conduct this username enumeration exercise whilst Responder is running in the background.
Once the format has been identified and assuming the format is used universally throughout the domain, Kerberos username enumeration can begin.
The username lists I have created can be seen in the table below. I have also included the raw firstnames and surnames lists should you need to create a custom format:
|Top 500 Female Firstnames
|Top 500 Male First Names
|Top 500 Surnames
|Top 50 Female Firstnames.Surnames
|Top 50 Male Firstnames.Surnames
|A.SMITH to Z.LEONARD
Note: All of the username wordlists (A.Surname through to Z.Surname) can be downloaded from: https://github.com/attackdebris/kerberos_enum_userlists
I’ll now walk through the complete attack process:
Initially we configure msf module auxiliary/gather/kerberos_enumusers with our wordlist:
We subsequently run the module. We’re obviously going to have a lot of failures but with no account lockout to worry about it doesn’t matter:
Running “creds” displays all of the successfully enumerated usernames:
The final stage is to leverage the auxiliary/scanner/smb/smb_login msf module to determine if any of our identified accounts are configured with weak passwords:
Obviously, the domain’s account lockout policy should be taken into consideration when attempting to guess passwords. A sensible approach is to attempt a single password at a time, restricting yourself to 2 guesses (system set to lockout after 3 invalid attempts) or 4 guesses (system set to lockout after 5 invalid attempts) against a single account every 30-minutes. 30 minutes is a typical “lockout observation window“.
Handily the auxiliary/scanner/smb/smb_login msf module’s “ABORT_ON_LOCKOUT” option will prevent too much damage being done, as long as it is enabled.