great leak autodiscover microsoft

When Automation Hurts Security: Microsoft Autodiscover

Share on facebook
Share on twitter
Share on linkedin

One of my favourite parts of working at Guardicore is seeing the cool stuff that our Labs team does, and their latest piece of research is no different. Our Area VP of Security Research, Amit Serper took infosec Twitter by storm last week with his research on the leaky Autodiscover domains.

If you missed the original research release, I’ll break it down in a high-level here, just like I did for the Indexsinas research that was done a while back. Like, super high-level. If the actual research is more your jam, click that button below.

Who was affected?

With a total of almost 400 thousand total credentials globally and a fourth of that being unique ones, this puppy was a St. Bernard. These are valid Windows credentials that utilized the Exchange Autodiscover feature on a multitude of devices: IoS, Android, Outlook Client, and some third party apps (more to come on that 😏) Basically, the classic tale of trading security for ease of use.

What is the Autodiscover leak exactly?

Let’s start with what Autodiscover is. To make it easier for the user, autodiscover is a protocol that allows for automatic configuration on multiple devices. We have our email all over the place, and it would be a hindrance to a user to try and manually configure it every single time.

Enter the “back off” algorithm. This is where things get to be a little dicey.


The “back off” feature is the main villain in this story. Since this is intended for convenience, the Outlook client tries to create a series of URLs to grant authentication. 

This doesn’t sound too bad, except it will keep trying to do that until it succeeds – even if the URL’s domain isn’t owned by the end-user or Microsoft. For example: a domain that we own is – if a user in the UK tried to use Autodiscover and the other predetermined paths fail but that domain succeeds, we now have their credentials. In plain text, no less, thanks to basic HTTP authentication. Let that sink in a minute. Yikes.

The above was published by Shape Security in 2017 – it was even presented at Black Hat Asia that same year. This is still an issue, and even bigger than we thought. That’s a teaser though, like I mentioned before – more to come on that.

The ol' switcheroo

In addition to confirming that the vulnerability noted in 2017 was not remediated, Amit created a new attack which he aptly coined “the ol’ switcheroo.” Gotta be an attacker to understand them, amirite?

Using the knowledge above, the purchased domains and a LetsEncrypt SSL Certificate – badabing, badaboom – you get a legitimate Microsoft authentication screen. User inputs their creds, and now we have them in our logs. 

Mitigating this issue

The mitigation here (just like any other threat) isn’t a single-pronged process. It involves the end-users, software developers, and the Exchange administrators. In short, block extraneous autodiscover domains, disable basic HTTP authentication and more generally, don’t adopt the “fail up” approach that’s demonstrated in the “back off” portion of this. Psst: Centra makes this super easy to do.

Want to learn more?

Like I mentioned, this is just an overview of the incredible work Amit did. You can see the full research on our Labs blog. It’s, as the kids say, lit. 🔥 

From Guardicore's
Resource Center

Managed threat hunting delivered by Guardicore Labs
Synchronize and automate security across your entire network.

Subscribe To Our Newsletter

No spam, we promise. We’re only going to send you insights on how to reduce risk in your data center and clouds.

See Centra in Action

Reduce your attack surface and prevent lateral movement with fast and simple segmentation that works everywhere.

See Guardicore Centra in Action

Schedule a demo customized to your specific security needs