It’s the last part of that statement that makes this difficult. According to The Register, Microsoft responded that “the issue described assumes a shared domain web server has already been compromised by another method.” The implication being that the requirement for an attacker to have control of any web server in the victim’s domain makes this attack unlikely.

Once the attacker poisons the victim’s DNS to trick the mail client into going to a fake site of the attacker’s own devising, he can then perform van Beek’s attack. This enables him to capture the Autodiscover traffic and then to negotiate the client authentication to Basic mode, which has no encryption protecting the password. Once it’s in the clear and the attacker controls the conversation, he can sniff the password.

At that point, all the attacker needs is the user login name, which is the victim’s email address. Email addresses are pretty simple to obtain or even guess because they are nearly always based on the user’s name. Once determined, the attacker then has unfettered, undetected access to all of the victim’s email as well as calendar, task list, contacts, and whatever useful documents are kept there. This would be somewhat annoying for the average user if their information were disclosed. However, for an executive whose most critical written communication tool is email, this is really bad. (If you think the impact of a leader’s hacked email can’t be harmful, recall how the 2016 U.S. presidential election played out. Enough said.)

Furthermore, the password is usually the victim’s Windows Active Directory (AD) authentication credential. The password can give the attacker the victim’s normal login privileges, once he figures out the AD username (also pretty easy to guess). If the victim’s organization isn’t using strong authentication for its remote access gateways, the attacker can then gain access to the victim’s network, where he can pivot and hack at will.

So yes, in theory, three mostly underrated attacks can be lined up one after the other to cause some serious damage. But, is this really possible? Let us show you how.

Proof of Concept

We decided to run some tests to see if the Microsoft Exchange Autodiscover hole that van Beek discussed could be expanded upon by using an intercepting proxy server to further the attack. What we found is that an attacker with simple knowledge of an email address, sitting on a network, can poison a client’s DNS, downgrade the authentication (if necessary), and grab a user’s domain credentials. These credentials can then be used to log onto a corporate SSL VPN or other enterprise systems to launch further attacks.

The theory, according to van Beek, is that clients using Autodiscover will provide a user’s password over SSL to any web server on the same network as the client, which can then proxy the request on to the intended Exchange server. This is due to lack of validation or enforcement of the server’s SSL certificate.

Mail clients when not on the domain, will try to connect to the URL shown below to obtain relevant information to configure the client’s mailbox. It uses everything to the right of the “@” to obtain domain information, for example, user@example.com.

Microsoft documentation points to the following formats currently in use:

• “https://” + domain + “/autodiscover/autodiscover” + fileExtension
• “https://autodiscover.” + domain + “/autodiscover/autodiscover” + fileExtension

When sniffing the Outlook client, we noticed it uses
https://autodiscover.example.com/autodiscover/autodiscover.xml.