Microsoft Account Takeover Vulnerability Affecting 400 Million Users

During our first security investigation for critical vulnerabilities affecting Microsoft, we came across multiple vulnerabilities that, when chained together, allow an attacker to take over any Microsoft Outlook, Microsoft Store, or Microsoft Sway account simply via the victim clicking on a link.

We contracted an external security researcher Sahad Nk, a bug bounty hunter and security researcher working with SafetyDetective, who found the vulnerabilities. Immediately after finding these vulnerabilities, we contacted Microsoft via their responsible disclosure program and started working with them. The vulnerabilities were reported to Microsoft in June and fixed at the end of November 2018. While the vulnerability proof of concept was only made for Microsoft Outlook and Microsoft Sway, we expect it to affect all Microsoft accounts including Microsoft Store.

Vulnerability One: Subdomain Takeover of

Issue Description:

The subdomain was pointing to a Microsoft Azure Web App service with its CNAME record. During a simple host check, we realized the application was no longer up, and we were able to take-over the sub-domain by registering an Azure web-app with the name successcenter-msprod. (CNAME)

The CNAME record of is pointing to successcenter-

Reproduction Steps:

  1. Open the Azure Portal
  2. Click on “Create a resource” and select “Web”
  3. Click on “Web App”
  4. In the field App name, enter successcenter-msprod (note, this will not work anymore, as I’ve already claimed that name).
  5. Continue with the steps to select the preferred OS type and Plan.
  6. After the application is set up, from the side panel, click on “Custom domains” and add a hostname like and save the settings
  7. Choose from various deployment options to deploy an application

Now we can control the domain and whatever data is sent to it.

Vulnerability Two: Improper OAuth Checks

Microsoft Outlook, Store, and Sway allow as a valid “wreply” URL to receive login tokens after a successful authentication in the centralized login system. (This is suspected due to a * wildcard, allowing all subdomains to be trusted.)

Even if the authentication initiator is or, is allowing as a valid redirect URL and sending the login tokens to this domain we now control. This resulted in a token leakage to our server. One can exchange this token for a session token and use the tokens to log in as the victim without knowing any username/password.

This is meant to bypass all the OAuth and get a valid token; when a victim clicks on the following link, we will be able to take over their account.

The above link, when visited, sends the user’s token to a pre-authorized app by Microsoft (in this case Microsoft Store with id 74335) – and Microsoft will send a token to (a domain we control) – this way we will be able to leak the token and use it to sign-in as the user.

Vulnerability Two: Improper OAuth Checks

Original request sent by Microsoft to obtain tokens

Vulnerability Two: Improper OAuth Checks

Response to Microsoft

Vulnerability Two: Improper OAuth Checks

The domain we control to receive all the necessary tokens required to log in as a victim

It is important to be aware that hackers could easily access all the emails of the victims and that even an antivirus could not have protected them, which is why this breach is so serious.

About the Author

Sophie Anderson
Sophie Anderson
Cybersecurity researcher and tech journalist

About the Author

Sophie Anderson has spent the last 10 years working as a software engineer for some of the biggest tech companies in Silicon Valley. She now works as a cybersecurity consultant and tech journalist, helping everyday netizens understand how to stay safe and protected in an online world.