blog.evan.lat (corporate-friendly)

security research & vulnerability analysis — main site at evan.lat. pgp for sensitive stuff: here.

Return to Sender: Hijacking Reserved Outlook Addresses and Abusing Domain Control Validation

2025-10-29

Scheduled for release October 31st, 2025. Full disclosure as of March 15, 2026.

Outlook Groups is a feature most people interact with without thinking much about. You create a group, give it a name, and it gets its own email address — yourgroup@groups.outlook.com — that can receive mail from anywhere. It’s a convenience feature, broadly useful for team inboxes and shared communication channels. And honestly? It’s also doing something far more interesting under the hood than the surface experience implies.

What I noticed is that when you create a personal (non-Microsoft 365) group and finalize its email address, the request that sets the address is wide open:

PATCH /Speedway/v1.0/Groups('OID:c8c90000-2952-4ca4-0000-000000000000@[REDACTED]') HTTP/2
Host: outlook.live.com

{"emailAddress":"helloworldserqwerqwerqwern@groups.outlook.com"}

The right question — and this is the load-bearing question — is: what happens if you change groups.outlook.com to just outlook.com?

{"emailAddress":"holy@outlook.com"}

It returns a 204. No error. The group now has holy@outlook.com as its address. Here’s where it gets interesting — genuinely, groundbreakingly interesting.

Attempting to register a new Outlook account with holy@outlook.com returns “unavailable” — the address shows as taken. And when I tried signing up for Twitter with that address, it worked. The email actually received the verification:

The implications here are specific but worth examining carefully: it’s not just any email address — it’s any Outlook address that’s been reserved, glitched, or invalidated — but whose original owner can no longer receive mail — that becomes claimable. If someone has an existing account on any platform tied to such an address, you can claim the inbox and trigger a password reset. The same technique worked across several related Microsoft domains — and the landscape of addresses this touches is enormous:

  • live.com
  • msn.com
  • windowslive.com

Escalating to Certificate Hijack

That’s already a notable account takeover primitive. But what I keep coming back to is the more transformative path — the one that runs through DigiCert.

DigiCert is a major certificate authority — one of the organizations that cryptographically vouches that a given server is who it claims to be. To issue a TLS certificate for a domain, DigiCert performs Domain Control Validation: they verify you actually own or control the domain before signing it. One of their validation methods is email-based: they send a verification link to a standard administrative address at the domain, such as webmaster@domain.com or administrator@domain.com.

You can probably see where this is going — and honestly? The throughline is almost uncomfortably direct. Taking over administrator@outlook.com was trivial with the same technique:

{"emailAddress":"administrator@outlook.com"}

As were webmaster@msn.com, webmaster@live.com, and administrator@msn.com. Each returned 204. I now controlled the DCV validation inboxes for outlook.com, msn.com, and live.com. In principle, I could request and obtain TLS certificates for those domains from DigiCert — giving me the ability to impersonate Microsoft’s own infrastructure. It’s not a theoretical threat — it’s a seamless, practical path to cryptographic impersonation of one of the world’s largest technology companies.

I confirmed the certificate request path was viable and reported to MSRC before going further.

Null Bytes and Broken Inboxes

While waiting on the report, I kept diving into the email validator. What happened when you injected a null byte?

{"emailAddress":"holy\u0000@outlook.com"}

The request succeeded. The inbox became completely broken — loading it caused a responsecode=undefined page with shattered CSS. Recovering required sending the same PATCH request again with a valid address.

{"emailAddress":"holy%00@outlook.com"}

Same result. The percent-encoded variant worked identically.

{"emailAddress":"holy%2500@outlook.com"}

Double-encoded: also worked, produced a similarly broken state.

I tried a few more approaches to pressure-test the normalization outright — arrays, malformed JSON structures, CRLF injections, OID objects:

{"emailAddress": ["invalid@outlook.com", "accept_me@outlook.com"]}

Some of these produced genuinely interesting responses. A few looked like they might have had secondary effects — there was something in the error rendering that hinted at a second vulnerability, something worth double-clicking on — but before I could fully characterize it, Microsoft patched the primary bug and started nuking affected group inboxes.

Notes on the Disclosure

One side effect of actually claiming administrator@outlook.com — and it’s worth noting this because it underscore just how real the access was: I started receiving DigiCert validation requests from random companies trying to get certificates. I also got emails from people who apparently believed administrator@outlook.com was a legitimate Microsoft support address and sent their passwords to it. Someone from Taiwan signed up for Roblox with it. I won’t be reproducing any of that here.

Microsoft acknowledged the report, said it would be fully addressed by December, and patched it. Reasonably quick turnaround given the scope — and the scope was, at its core, the ability to silently impersonate Microsoft’s own domains.

← back