Threat Advisory: How to Threat Hunt (Detect) and Mitigate Microsoft Exchange Autodiscover Flaw

Threat Advisory: How to Threat Hunt (Detect) and Mitigate Microsoft Exchange Autodiscover Flaw

Microsoft Exchange Autodisover has a major flaw that reveals user credentials. Until now, researchers have got hold of around 372,072 Windows domain credentials, and that too within just four months. The numbers also include 96,671 unique credentials. The more alarming thing is that this is done by merely using Autodiscover domains after establishing a Microsoft Exchange server.

The leaked credentials are not for any dummy domains. Instead, these credentials are for valid Windows domains used to authenticate and access Microsoft Exchange servers.

What is Autodiscover?

Autodiscover is a service or feature that reduces configuration and deployment steps. The official description of Autodiscover given on Microsoft’s site reads, “the Autodiscover service minimizes user configuration and deployment steps by providing clients access to Exchange features. For Exchange Web Services (EWS) clients, Autodiscover is typically used to find the EWS endpoint URL. However, Autodiscover can also provide information to configure clients that use other protocols. Autodiscover works for client applications inside or outside firewalls and in resource forest and multiple forest scenarios”.

It is basically an Exchange email server feature that enables Outlook administrators and clients to automatically discover existing email servers, provide configurations, and set up configurations. The Autodiscover is designed to reduce the configuration steps to make the user’s life easier. However, it forgets that such designs need to be developed with security in mind. The reason is that cybercriminals are fond of such features that they can use for their own advantage.

Where does the Flaw Come into Play?

Autodiscover only requires the users to provide a username and password for their Outlook clients. It offers simplicity by completing the rest of the configuration part through Microsoft Exchange’s Autodiscover protocol.

The protocol completes the configuration by searching for a valid Autodiscover URL in the formats mentioned below.

https://autodiscover.xyz.com/autodiscover/autodiscover.xml
http://autodiscover.xyz.com/autodiscover/autodiscover.xml
httts://autodiscover.xyz.onmicrosoft.com/autodiscover/autodiscover.xml
httts://autodiscover.xyz.mail.onmicrosoft.com/autodiscover/autodiscover.xml
https://xyz.com/Autodiscover/Autodiscover.xml
http://xyz.com/Autodiscover/Autodiscover.xml

The xyz.com in the above format is replaced by the domain name that comes post the @ sign in the user’s email address.

Failing to complete the configuration, Autodiscover initiates a “back-off” procedure. This is the process where the flaw exists. During the “back-off” procedure, the protocol attempts to build an Autodiscover URL. This would concoct an Autodiscover URL that would look something like:

“http://Autodiscover.com/Autodiscover/Autodiscover.xml.” This will enable the owner of Autodiscover.com to get hold of all the requests and credentials that can’t reach the original domain.

The below flowchart shows the workflow of the process:

Thus, the person owning the domain autodiscover.com gets an opportunity here. Besides the .com, other Autodiscover top-level domain owners, such as autodiscover.us or autodisover.net, are at an advantage too. All the unresponsive requests from .us and .net domains will fall in the lap of autodiscover.us and autodiscover.net domain owners, respectively.

Moreover, since there is no authentication procedure required on the server side, it becomes easier for cyberattackers to get sensitive information. Additionally, when it comes to the client-side, there are no attempts to verify if the requested resource or servers are available or even exist before initiating the request. Thus, the users are sending their credentials to an unknown server to set up their Exchange account without any knowledge.

Since Microsoft Suite is a part of almost every organization, the consequences of domain credential leaks at such a large scale can be enormous. In fact, it can put the entire organization at risk, especially in the current pandemic era where ransomware attacks are a part of daily news. There is no easier way for an attacker to penetrate an organization than using the valid credentials accessed easily through domain servers.

Simple research done from our end highlights that most of the top TLDs for the Autodiscover domains are already taken. The below image shows some of those domains.

How to Mitigate?

Mentioned below are some of the quick steps that you can use to mitigate the vulnerability:

• Organizations that use Microsoft Exchange should block all the TLD domains (autodiscover.[tld]) at the firewall, DNS, Proxy server, or local file host level to ensure that the devices do not connect to them.
• Enterprises should ensure that basic authentication support is disabled and advanced authentication is enabled while deploying or configuring Exchange server setups. This is because basic authentication, such as HTTP, will send all the credentials in plain text without encryption, making them more accessible for the adversaries to intercept.

How to Detect?

Organizations can detect the connection of Autodiscover to unknown servers with the help of firewall, proxy, and endpoint logs. However, 24/7 monitoring is essential here to detect the connection as and when it occurs.

The detection can be done by watching the web traffic over port 443. Enterprises need to look if the traffic against url_path ‘/autodiscover/autodiscover.xml’ connects to any domains that are not a part of their organization.

An open XDR solution integrated with a firewall, proxy, EDR, Endpoint, and Cloud applications becomes handy to detect such attacks centrally. For instance, in the below example, the analyst searches for url_path “/autodiscover/autodiscover.xml” in the query while excluding all trusted domains. Thus, only the traffic going to unknown servers will be displayed here:

In the above example, we could see traffic going out to autodiscover.com with a matching url.path. This hints that user credentials were sent to an unknown (most probably attacker’s) server.

In case any web traffic is found going to other than own or trusted domains that means credentials might have been leaked. In such a scenario, it is recommended to ask the users to change their passwords immediately.