Question:  What Can I Learn from Password Spraying a 2FA Microsoft Web App Portal?

Answer: Enough to make it worth it!

Penetration testers love to perform password spraying attacks against publicly available email portals as described here in this great post by Beau Bullock. Recently I performed a password spray against an Outlook Web App portal that had multi-factor authentication enabled using Microsoft MFA. The login page looked the same but the server responses gave away some very interesting information.

Outlook Web App Login

As I password sprayed this portal, which had two-factor authentication enabled, I was able to learn two important things:

1) Whether a username was valid or invalid (aka Username Enumeration)

2) Whether the password was correct for a given username (even though access was not granted)

Here at BHIS, we have learned through experience that the server response time when given a valid username is much quicker than when given an invalid username (many thanks to Brian Ferhman for all the things we’ve learned because of his work). The screenshot below shows examples of response times for valid versus invalid usernames.

Username Enumeration

We use the Burp Intruder tool to do password spraying. You can view the response time by turning on the “Response Completed” column in the results table view.

View Response Time with Burp Intruder

Cool! We just built a valid list of usernames which can come in handy later on in the test.

The next super cool thing we can learn is whether the password we guessed is correct for the user. Wait, what? You said two-factor was enabled! Read-on. . .

Microsoft Multi-Factor Authentication (MFA) requires users to acknowledge a phone call or a text message before granting access to the resource. After correct credentials are entered, the server waits for  the user to verify the attempt (by pressing “#” on the phone call they receive for example). This is awesome from a security perspective; however, Microsoft still gives away whether the password is correct in its server response to valid credentials. The response is only slightly different but it is enough, as shown below.

Response Contains “auth.owa” When Password is Correct

Login Response for Invalid Credentials

How cool is that? Now we have valid usernames and passwords to use elsewhere. If we have been successful, we have also caused an unsolicited text or phone call to some users so be careful!