About a week ago a very interesting proof of concept tool and blog post were published by security researcher Dirk-jan Mollema (@_dirkjan), which you can read at here.

Now folks, this is HUGE. Extremely huge. If you are running Exchange make sure that you read this diary and the original blog.

Basically, the PoC tool exploits the fact that Exchange servers have very high privileges in Active Directory domains – the WriteDacl privilege that allows them to change domain privileges. Exchange servers are part of the Exchange Trusted Subsystem group, which is further included in the Exchange Windows Permissions group which has this critical privilege enabled.

The issue is in Exchange Web Services (EWS) PushSubscription service, specifically PushSubscriptionRequest method that allows a user to subscribe for push events. The user specifies the location of the client Web service for push notifications. In other words, once an event happens, the Exchange server will connect to the URL specified in the call to the PushSubscriptionRequest method. 

Now, once a subscription has been created, relaying is the final step. The Exchange server will now try to connect to the attacker’s machine (the URL specified in the subscription) and will happily pass NTLM credentials. These can be then relayed to a Domain Controller (provided there is no SMB signing – see below for mitigations). Dirk-jan’s exploit relays the credentials to LDAP in order to escalate a user’s privilege: it adds the Replication-Get-Changes-All privilege to an account effectively allowing that account to perform any actions on the domain, including dumping all passwords from a Domain Controller by performing DCSync. With hashes of all users, the attacker can further impersonate any other user and takeover the complete domain.

Running the exploit is very simple - once the subscription is created, Exchange connects to the supplied URL as shown in the figure below:

Now, the biggest issue here is that this works with the latest version of Exchange, fully patched. Various versions are listed on the original blog, I tested with a fully patched version of Exchange 2016. Note that the deletion of registry key as specified in Microsoft’s advisory for CVE-2018-8581 does not fix this vulnerability! It prevents a malicious user from impersonating another user on the Exchange server, but not on a Domain Controller, through LDAP. Additionally, I have installed patches on an Exchange 2016 servers, and the registry key was not removed (even though Microsoft’s advisory says that they will remove it).

The best mitigation options as far as we are aware of are the following:

• First, if you do not use EWS push/pull subscriptions disable them (see here by @gentilkiwi),
• Additionally, use an internal firewall to prevent Exchange from connecting to your workstations – typically workstations should connect to Exchange, not the opposite. This does not prevent the exploit (an attacker can find a different server that Exchange can connect to), but makes exploitation a bit more difficult.
• Enable SMB and LDAP signing.
• Remove high privileges that Exchange has on the Domain object.

   

Of course, be very careful when modifying any of the settings above to make sure that you will not break your Exchange deployments.

Finally, the exploit does not work on Exchange 2010 which has signing enabled by default, but this setting does not exist in Exchange 2013, 2016 or 2019. Go figure :/

UPDATE 1:

Here's a bit more information about detection of the vulnerability:

• Regarding vulnerable servers, Exchange 2013, 2016 and 2019 have been confirmed as vulnerable. The screenshot above from my test was with a fully patched Exchange 2016.
• Exchange 2010 appears not to be vulnerable - it will send the request to the subscribed URL, but due to signing you should not be able to relay it.
• Exchange 2007 is unknown at this time, although it appears to have the required methods (PushSubscriptionRequest) so it might be vulnerable. If you manage to test it, let us know.
• The best way to check if the vulnerability has been abused against you is to monitor for network logon events on your domain controllers. This is what you'll be looking for:
  • EventCode=4624
  • LogonType=3
  • Authentication Package=NTLM
  • Account Name = YOUREXCHANGESERVER$
• By looking for events above you'll be able to detect NTLM relay attacks where Exchange server's credentials were used. The Source Network Address field will show the IP address of the attacker (where the ntlmrelayx / impacket was running).
• There is another good event (thanks to Davy for sending this), 5136. This event will show when the DACL was modified, but it will have the target account's SID only so you can't search by name.

Thanks to all readers for great and useful comments.

We’ll continue researching the issue – if you have any new or information to share - let us know!

--
Bojan
@bojanz
INFIGO IS