New Microsoft Exchange Vulnerability Exposes Domain Admin Privileges: Here’s What to Do

Posted by Yaron Zinar on Feb 4, 2019 11:41:13 AM
Find me on:

Last week, the CERT Coordination Center (CERT/CC) issued a vulnerability note warning versions of Microsoft Exchange 2013 and newer are vulnerable to an NTLM relay attack that allows for attackers to gain domain admin privileges. Organizations that rely on Microsoft Exchange are currently at risk of a serious data breach. This attack is particularly concerning given that it obtains privileges to the domain controller, which is essentially the “keys to the kingdom.” We’ve simplified some of the specifics of this attack for the purposes of this blog, but for a full technical breakdown, please see research from Dirk-jan Mollema.

How Attackers Exploit Microsoft Exchange  

As a result of this vulnerability, attackers take advantage of a function with the Exchange Web Services API called ‘PushSubscriptionRequest’, which is used to cause the Exchange server to connect to an arbitrary website. The attacker would then relay over the NTLM authentication back to the Exchange Server or, more critically, back to the domain controller. Because the Exchange Windows Permissions group has access to the Domain object, the privileges can be obtained from Exchange. The relayed NTLM credentials will be used in an LDAP session, if LDAP server signing is not enabled, or LDAPS in the event that an attacker wishes to exploit CVE-2017-8563 (originally discovered by Preempt Research Labs). In that LDAP/S session, the attacker can be used to gain domain replication privileges that later will be used to launch a DCSync attack and compromise all accounts in the domain.

Microsoft

Because a majority of organizations rely on Microsoft Exchange 2013 and newer versions to conduct day-to-day business, the impact of a potential breach is far-reaching. With the ability to steal administrative privileges and access the domain controller, the attacker can then move to all servers, workstations, users, and applications that are serviced by the domain controller. With the privileged access rights, they can essentially make any kind of changes to all systems and accounts that are managed by Active Directory, and in turn corrupt your entire network.

Mitigation Strategies: Considerations and Long-Term Options

While Mollema’s research gives great ways to protect against NTLM relay attacks that exploit the vulnerability in Microsoft Exchange, he misses a critical point in his research. He encourages users to “enable LDAP signing and enable LDAP channel binding to prevent relaying to LDAP and LDAPS respectively.” While this is a technically correct approach, it is not always a feasible option given the unfortunately wide variety of enterprise software deployments in current use that do not support LDAP channel binding.

We believe there are proactive, long-term strategies virtually every organization should take to stop these types of threats.  These strategies will not only protect you against the current vulnerability in Microsoft Exchange, they will also protect you against many other attacks that exploit NTLM authentication:

  1. Enabling LDAP signing and channel binding is not enough. One of the reasons this attack is highly effective is that LDAP is not protected from NTLM Relay by default. In fact, the Preempt team uncovered CVE-2017-8563 in 2017, it was virtually impossible to protect LDAPS. In addition, it is very difficult to configure LDAP signing as some software packages don’t support the safe configuration. If you want to figure out if your network is safe from NTLM Relay over LDAPS, you can deploy the free Preempt Lite to find out. 

  2. Monitor network traffic and restrict NTLM. We have written extensively about the risks associated with NTLM. The nature of NTLM increases the risks of  NTLM Relay because it is very difficult to mitigate and inherently produces the risk of password cracking. While NTLM cannot be removed completely in most networks, it should be reduced and restricted as much as possible. The Preempt Platform offers full visibility and analytics into authentication protocol activity (NTLM, DCE/RCP, LDAP and Kerberos) activity and anomalies as well as the ability to apply dynamic policies with regard to blocking NTLM activity. Preempt can help organizations take a proactive role in controlling protocol usage and reducing risk of credential forwarding and password cracking and other credential-based attacks such as Pass-the-Hash and Golden Ticket. Preempt is now the only company handling decryption of the NTLM protocol in real-time for threat detection and real-time prevention.

  3. Track domain administrative (stealthy) privileges. Another key part of the attack was made possible by the fact that in many scenarios: the Exchange server is granted special permissions of the domain root object. At Preempt, we refer to such accounts as Stealthy Admins. Stealthy admins are created from various permissions given to users (delegation, replication privileges, etc). The Preempt Platform analyzes all accounts in the network and alerts administrators to the presence of any and all stealthy admin accounts.

  4. Continue to Monitor DCSync. The final exploitation is done with users performing a DCSync attack because they have privileged access to do domain replication. Preempt helps stop a DCSync attack by detecting the misuse of privileged access credentials and preventing the data breach of critical user information. 

Customers who have deployed Preempt have been consistently protected from NTLM relay attacks. The Preempt Platform is able to detect the attack over LDAP, allowing customers to prevent the malicious usage of privileged credentials to access the domain controllers. By taking this approach, you will not have any stealthy admins corrupting the systems and accounts managed by your Active Directory. For more information on how you can protect against this vulnerability in Microsoft Exchange 2013 and newer versions, please contact us at info@preempt.com.

Editor's note: Monnia Deng contributed to this blog.

Topics: NTLM, Microsoft