It’s not uncommon on external pen tests and red team engagements to find very little attack surface on the customer’s internet-facing networks. Customers have started shifting services to cloud providers, making it harder to find targets. This blog describes how to enumerate users within the Microsoft O365 ecosystem.

Part 1 of this series is located here: https://www.redsiege.com/blog/2020/01/user-enumeration-part-1-building-name-lists/

O365 Login Page

We can use the login portal at https://login.microsoftonline.com to determine if our customer has services hosted within the Microsoft ecosystem. If the company does not have any resources hosted with MS, when we attempt to log in with a any email address for their domain, we’ll receive the following error:

Domain not hosted with MS

Domain Not Hosted In MS

 

If the customer does have resources within the Microsoft ecosystem, there are several different responses we may encounter. If we provide an invalid email address, we’ll receive an error similar to the following.:

Valid domain but Bad User

Invalid Email Address

 

If we have provided a valid email, one of two things may occur. The customer may be using the default O365 login page, in which case you’ll be prompted to enter in the user’s password.

Password Prompt

Password Prompt for Valid Email Address

 

Some customers may be using their own login portal, or using a 3rd party MFA solution, in which case you will be redirected to a different site and will see a message similar to the following.

Redirection to Custom Login Page

Redirection to Organization Sign-In Page

Automated Enumeration

Being able to manually tell if a company has resources in O365 is a great first step. Since this blog is about user enumeration, we likely want to do this in an automated fashion. The normal O365 login POST request contains a lot of headers and parameters, but we can strip out almost everything, leaving the following bare-bones request:

Login POST Request

Login POST Request

The server will respond with a 200 OK response containing JSON data. The specific component of the response we’re looking for is the IfExistsResult value. If the value is 1, the specified email address does not exist within the organization.

Invalid Email Address

Invalid Email Address

There are a number of blogs written about O365 user enumeration, and there are tools written to do enumeration. All of the ones I’ve seen are missing information about the IfExistsResult value, which could lead you to not identifying valid users. These blogs and tools look for an IfExistsResult value of 0 to determine if the username is valid. There are two additional codes, however, which also indicate a valid user – 5 and 6. I found this script on Github which seems to indicate the user’s email address has also been set up to use personal services, which will result in a prompt asking if this is a work or personal account. However, I haven’t been able to find other resources to confirm that this is indeed the nature of response values 5 and 6.

I typically use Burp Pro’s Intruder module to automate testing.  Setting up grep match rules for the various ifExistsResult codes allows me to quickly see which addresses are valid.   To wrap it all up, the following table summarizes valid IfExistsResult result codes.

IfExistsResult Meaning
0 Valid Email Address
1 Invalid Email Address /
Domain Not Hosted in O365
5 Valid Email Address
6 Valid Email Address