6 techniques for account enumeration in a penetration test [demo included]

Enumeration is one of the essential tactics that help you gain a foothold in your target’s ecosystem. As a penetration tester, you can gain a lot of speed and prep your exploitation phase more thoroughly if you get enumeration right.

That’s why we’re dedicating this guide to the methods that will get you usernames or email addresses for valid user accounts during a pentest engagement.

Why is account enumeration important during a penetration test?

If the application doesn’t properly validate the existence of a username/email address combo in its database, an unauthorized actor can easily trick the system to “reveal information about the product’s operation or internal state.”

According to CWE, the community-developed Common Weakness Enumeration list, this security flaw – CWE-203: Observable Discrepancy – reveals poorly protected resources that you, as a pentester, can use to establish an active connection to your target.

In a real-world situation, it allows an attacker to get a list of valid usernames contained within an application or piece of software, which they will use to launch Brute-Force, Dictionary, or Password Spraying attacks against the harvested accounts.

What makes this security issue a major source of concern is that many organizations accept it because it improves user experience. However, its widespread and highly exploitable nature enables malicious actors to systematically collect information about the target, making their attacks especially virulent.

Let’s go through the most commonly used techniques used to enumerate valid user identifiers (usernames or email addresses):

1. Account Enumeration through Login Error Message Discrepancy

2. Account Enumeration through the Forgot/Reset Password functionality

3. Account Enumeration through the Registration Form

4. Account Enumeration through Response Time Discrepancy

5. Account Enumeration through Response Size Discrepancy

6. Account Enumeration through Account Lockout Message

I also included video demonstrations for each of these tactics to help you go from theory to practice as fast as you can.

1. Account Enumeration through Login Error Message Discrepancy

This is one of the most common user enumeration methods found in most web applications. You can take advantage of it when the application responds with different messages to whether the username exists in the database or not.

When the username or email address is in the database, you get an “Invalid Password” message.

When the username or email address is not found, you get an “Invalid Username” message.

One well-known example of username enumeration through the login page is available on the Office365 authentication page. Why is it still there? Because Microsoft considered it an acceptable risk when considering the user experience and workflow.

Eager to see how to get to this screen? Check out this video demo that explains it:

How to mitigate account enumeration through Login Error Message Discrepancy

The recommended solution for this type of username enumeration is to display a generic message no matter if the username exists or not within the database. That’s why you’ve probably seen the “Username or password invalid” message as an internet user yourself.

You can recommend this mitigation approach to your customers in your pentesting report.

Source

2. Account Enumeration through the Forgot/Reset Password functionality

My second go-to method is to check if the application has a forgotten or reset password feature.

You will notice that most web apps allow you to enter only the email address associated with the username, which helps if they provide an email-based authentication mechanism. If you’re lucky, the application will allow you to fill in the username or email address.

This type of enumeration happens in the following scenario:

• you enter a username or email address that is in the database,

• the application will show you a “Password reset token was sent to the email associated with your account” green message.

• alternatively, you enter a username or email address that isn’t in the database, so the application tells you “The username or password is invalid.”

Let’s see how this works IRL:

How to mitigate account enumeration through the Forgot/Reset Password feature

The fix for this type of enumeration is actually simple and similar to the first one. Display the same kind of generic message – “If the username/email is valid, then a password link will be sent to your email” – even if the username or email exists in the app’s database or not.

Source

3. Account Enumeration through the Registration Form

When pentesting, you will find this by filling in a valid email address or username on the registration page of the web application. (You can get the email address or username through various ways, such as doing OSINT on the organization itself, or using a wordlist.) You’ll know this works when the app returns an “Existing Username” or “Existing Email” error message.

Hit play for a quick and self-explanatory demo:

How to mitigate account enumeration through the Registration Form

The recommended mitigation for this kind of enumeration that you can include in your pentest report is to display a generic message such as the one below if the entered username/email is already taken:

“An error occurred with your registration.

The cause of the error can be:

•  The username is invalid or is already taken. Select Another username.

•  The password is of an invalid length. Use a longer password.

•  Passwords do not match. Retype your passwords to ensure you entered them correctly.

•  The email address you entered is already registered or is invalid. Use another email address.

•  The captcha is invalid. Write the response for the captcha correctly.

•  You have not agreed to the terms of service. Make sure you agree to the terms of service and check the applicable checkbox below.

Correct any errors in registration and try again.

We do not disclose the reason why the registration failed for security reasons.”

This last phrase will earn you the goodwill of your customers for making them read all those details and jump through hoops to log in and use the app.

4. Account Enumeration through Response Time Discrepancy

This tactic is not as common and I’ve seen it missing from methodologies many penetration testers use.

You can check the response time of the web server and notice if there is any difference (considerable or patterns) in response times when you provide a valid or invalid username in a Login page, Forgot Password page, or Registration Form.

In order to test for that, I recommend sending 3 consecutive requests with a valid username and note down the response times. After that, send another 3 with an invalid username, but make sure to change a single letter/digit in the username or email.

For example, if you have the valid user “admin” and you received the following response times – 475 ms, 328 ms, 406 ms – then use the invalid user “bdmin”. If you receive the following response times – 779 ms, 821 ms, 944 ms – you can clearly notice that the application responds twice as fast when the username is valid.

Let’s see how this works:

How to mitigate account enumeration through Response Time Discrepancy

The security team should focus on implementing a fixed response time or use a random one to keep an attacker from figuring out they can use this vulnerability to gain access to the system.

Make sure to keep this list of recommendations and add them to your pentest report when you wrap up an engagement.

5. Account Enumeration through Response Size Discrepancy

The same pattern used for the previous method applies to this scenario. A thorough pentester will always look for the slightest difference in behavior (technological or human) to find the keys to the “kingdom.” The devil is in the details, as they say, and no one knows this better than penetration testers.

Case in point, sometimes the application can show the same generic message even if the username exists or doesn’t, but the response size can vary, even by one byte. To use this in your pentest workflow you can check the response size directly in the browser.

Play this demo to see how to do it:

How to mitigate account enumeration through Response Size Discrepancy

In your pentest report, recommend that the owner of the target deploys a fixed response size no matter if the username exists or not to avoid revealing this detail to unauthorized – and meddling – outsiders.

6. Account Enumeration through the Account Lockout Message

To test for this type of enumeration, follow these steps:

1. Send requests with a valid username or email address to confirm the lockout threshold.

2. Send the required requests until you reach the threshold.

3. If the username exists, you will be prompted with a message like “Your account is blocked.” However, if it doesn’t exist, you can still send a request and the application will not display a lockout error.

This is a risk as it can block the provided accounts while you are testing for this issue.

Actually, let’s watch this demo for the step-by-step overview:  

How to mitigate account enumeration through the Account Lockout Message

The solution for this one is very simple: whoever is in charge of remediation should stop displaying the lockout message. Yet another insight you can integrate into the pentest report that showcases your work and results.

Account enumeration mitigation cheat sheet

To quickly integrate these account enumeration methods in your workflow, I’ve prepared a pentesting cheat sheet that captures the essential recommendations:

Until next time, check out the other pentesting guides I’ve published on the blog and let me know if there’s a particular topic you’d like me to write about.