This is the third installment in a series of blogs on user enumeration. In Part 1 – Building Name Lists, I talked about ways of building usernames from OSINT and US census data. In this installment, I’m going to discuss putting this info to work in Windows environments. For this blog, I’m making some assumptions on where you’re positioned within a corporate network, and that you have the ability to use some kind of *nix operating system. For positioning, we’ll assume that you’re on a standard internal network pen test, so you’re directly connected to some segment of the corporate network, or you’re on an external and have somehow managed to get VPN connectivity to the corporate network. We’ll also assume your client hasn’t given you any info except for IP, subnet and gateway, and hopefully they gave you some DNS resolvers.
What’s our domain?
Simply doing a reverse lookup on the DNS server IP is usually enough. As you can see below, with nslookup , we know the domain is SIEGE.LOCAL.
nslookup on name server IP
We could also find that by reviewing nmap results for domain controllers. DCs typically will have all or most of these TCP ports open: 53, 88, 135, 139, 445, 389, 464, 593, 636, 3268, 3269. The nmap smb-os-discovery script for my lab DC shows the domain name as well.
It used to be that you could find SMB null session support just about anywere and all you needed was enum4linux -a. We’ll assume that your client has disabled null session support. There are still options for getting usernames if all we have is a name list. For this test I’ve got a Server 2016 DC set up with 50 local users. The usernames were selected at random from the list of 26,000 names generated from census data.
Option #1 – Kerbrute
Kerbrute is a fantastic tool for user enumeration and password spraying. Kerbrute tests against Kerberos and takes advantage of the way Kerberos responds to queries for invalid users. When Kerberos is sent a TGT request with no preauthentication for an invalid username, it responds with KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN. Valid usernames will result in either a TGT in a AS-REP response or a KRB5KDC_ERR_PREAUTH_REQUIRED response. As an added bonus, Kerbrute is also incredibly fast at password spraying.
The following example uses the userenum module. As you can see, it took 3.355 seconds to test 26,000 usernames to discover 50 users. That’s pretty fast!
Username Enumeration with Kerbrute
Option #2 – nmap
The nmap krb5-enum-users script uses the same Kerberos behavior as Kerbrute to perform user enumeration. As you can see in the example below, you’ll need to specify the realm (domain) and your username list with –script-args. To get through the same list of 26,000 usernames it took just over 2 minutes to complete.
User Enumeration Using nmap krb5-enum-users Script[/caption]
Option #3 – Metasploit
The Metasploit framewrok also has a Kerberos user enumeration module. The auxiliary/gather/kerberos_enumusers module is similar in speed to the nmap script. The output is quite verbose, however, so you’ll want to have a database set up to store the results in the creds table, or spool the output to a file for review. The following examples shows how to run the module and what a successful result looks like.
Metasploit kerberos_enumusers User Enumeration
These are just a few of the tools and techniques that you can use for user enumeration in a Windows environment. I focused strictly on user enumeration for this post and didn’t cover password spraying. While you could also do a spray with the current season+year password, that will only tell you what users, if any, have that password. You also add a failed password count for every valid username that didn’t have that password. Whenever possible, I prefer to start by enumerating usernames and then spraying the users I’ve identified. Once I have at least one valid username and password combination, I can pull the full list of users from the domain for additional password spraying.
In upcoming posts I’ll discuss enumeration on more kinds of services. In the meantime, don’t hesitate to reach out to us with questions on Twitter or through email.
Related StoriesView More
Moving beyond T4 – Deconstructing Nmap Tuning
By Red Siege | July 6, 2022
by Alex Norman, Senior Security Consultant Nmap -T4 -iL targets.txt This is a very common scan string that many people use to get initial recon done on assessments and, to […]Learn More
Creating a Simple Windows Domain for Offensive Testing: Part 4
By Red Siege | June 23, 2022
By: Justin Palk, Security Consultant This is part four of my series of blog posts on creating a windows domain for offensive security testing. In part 1, I stood up […]Learn More
Creating a Simple Windows Domain for Offensive Testing: Part 3
By Red Siege | June 15, 2022
by Security Consultant Justin Palk Welcome back to my series on setting up a Windows domain for offensive testing. In the first two installments (Part 1, Part 2), I stood […]Learn More