What is the threat?
Remote attackers can exploit a vulnerability that has been discovered in Microsoft Exchange to gain Domain Controller admin privileges using the credentials of an Exchange Mailbox user. The attacker must exploit a combination of flaws to be successful and this this exploit works even on completely patched and updated versions of Exchange and Windows Server DCs.
Why is this noteworthy?
The Zero-day privilege escalation vulnerability is easy to execute since there is a readily available proof-of-concept tool which can be used by anyone to gain complete access to the Windows IT infrastructure of a company. Even updated Server versions are vulnerable to this and Microsoft has not yet released a patch. Only Exchange Online and systems which have NTLM disabled are not affected by this vulnerability.
What is the exposure or risk?
Successful exploitation will give the attacker admin access on the company’s Domain Controller which will give him the ability to setup backdoor access, give him access to the Exchange Server’s NTLM hash or the Windows computer account password.
The proof-of concept tools can be found on GitHub (PrivExchange). They have been tested on the following Exchange/Windows versions:
- Exchange 2013 (CU21) on Server 2012R2, relayed to a Server 2016 DC (all fully patched)
- Exchange 2016 (CU11) on Server 2016, relayed to a Server 2019 DC (all fully patched)
- Exchange 2019 on Server 2019, relayed to a Server 2019 DC
What are the recommendations?
There is no official patch from Microsoft for this vulnerability yet, but there are a few workarounds to address it. The links have detailed information about executing the workarounds mentioned below:
*Note: Customers are strongly encouraged to test workarounds prior to deploying them into production to understand the potential impact.
- Disable the creation of New EWS Subscriptions using Throttling policies. (The EWS throttling policy will negatively impact LOB and other third-party Applications that require EWS Notifications. A second policy will have to be created to whitelist trusted accounts.)
- Enable LDAP signing and enable LDAP channel binding to prevent relaying to LDAP and LDAPS respectively.
- Remove Existing Exchange Privileges which enable it to write to the Domain Object.
- Block Exchange servers from making connections to workstations on arbitrary ports.
- Remove the registry key which makes relaying back to the Exchange server possible.
- Enforce SMB signing on Exchange servers (and preferable all other servers and workstations in the domain) to prevent cross-protocol relay attacks to SMB.
- Enable Extended Protection for Authentication on the Exchange endpoints in IIS (but not the Exchange Back End ones, this will break Exchange). This will verify the channel binding parameters in the NTLM authentication, which ties NTLM authentication to a TLS connection and prevent relaying to Exchange web services.
References:
For more in-depth information about the recommendations, please visit the following links:
- https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV190007
- https://kb.cert.org/vuls/id/465632/
- https://www.zdnet.com/article/microsoft-exchange-vulnerable-to-privexchange-zero-day/
- https://dirkjanm.io/abusing-exchange-one-api-call-away-from-domain-admin/
- https://www.us-cert.gov/ncas/current-activity/2019/02/05/Microsoft-Releases-Security-Advisory-Exchange-Server
- https://unit42.paloaltonetworks.com/darkhydrus-delivers-new-trojan-that-can-use-google-drive-for-c2-communications/
If you have any questions, please contact our Secure Intelligence Center.
