Dirk-jan Mollema, a pentester working for Foxit, found a very clever attack allowing any user, owning an Exchange mailbox, to obtain Domain Admin privileges.

The attack has been unveiled last week, strangely without a lot of media coverage (but things seem to change, the daily blogpost of the SANS ISC covered the subject yesterday). As there is still no fix (think software patch to install) from Microsoft, the term “0day” is around.

As Dirk-jan explained with a lot of details here the attack combines three weaknesses:

• Exchange servers have too high privileges by default;
• NTLM authentication can be relayed;
• Exchange servers can be asked to authenticate to an arbitrary IP using the EWS (Exchange Web Services) PushSubscription feature.

These vulnerabilities are well known so what’s new here and why should I be worried ? Dirk-jan simply found a way to combine the three vulnerabilities but in a very clever way resulting in a full Active Directory compromise. The root of the problem lies in the privileges given to the Exchange servers which can modify the domain itself including granting the rights to do DCSync operations. What could go wrong if you find a way to use Exchange privileges ?

The tool released by Dirk-jan does exactly that: it asks Exchange to connect to an arbitrary IP and when doing that… it authenticates itself. So, by firing a NTLM relay attack at the same time you can steal Exchange authentication and become the king of the domain.

The attack works very well on fully patched Exchange 2013/2016/2019 On Premise (Office365 seems safe), though in some cases a few things have to be tweaked (contact us if needed) and allows a user to obtain Domain Admin rights in less than a minute:

1. Subscription to the push notification feature (using privexchange.py tool):

PoC extract showing the Web Services call to the PushSubscriptionRequest feature:

2. Relay of the Exchange server authentication and privilege escalation (using ntlmrelayx from Impacket):

3. Profit (using secretdumps from Impacket):

Microsoft will probably release a hotfix soon but in between it could be safe to think about possible mitigations. A total of 7 mitigations are listed in the blog post (6 in the original post and a last one proposed by gentilkiwi). Unfortunately many of them can’t be applied easily/quickly.

If your users don’t use notifications, the easiest one, is to disable them by setting the EWSMaxSubscriptions setting to 0 as found by gentilkiwi.

If they do, you’ll have to consider the other mitigations. Block Exchange servers from making connections to workstations on arbitrary ports is effective and not so complicated to apply if you only enable the Microsoft firewall on the Exchange servers and add a “black list” to deny connections to your workstations/unsafe subnets.

The other mitigations could be complicated to implement as they may broke legacy applications.

You can also monitor your Domain Controllers logs for 5136 events and search for the following GUID (full list available here):

1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 (DS-Replication-Get-Changes)
1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 (DS-Replication-Get-Changes-All)
89e95b76-444d-4c62-991a-0facbeda640c (DS-Replication-Get-Changes-In-Filtered-Set)

If you get a hit this means that someone is playing with the PoC - without modifying anything in it - on your network !

And finally to the ones trying to run the PoC:

• if you get this output:

The message is self explanatory: the user you entered doesn’t have a mailbox. No mailbox, no notification so the attack failed. Use another account !

• and if you get this output:

Again, the message is self explanatory: the user can’t register new notification subscription, the sysadmin has probably set the EWSMaxSubscriptions setting to 0.

To summarise: this is literally a pentester silver bullet for internal pentests: a very strong privilege escalation trick which could lead in a few seconds to a full domain compromise so we advise you to run the PoC and apply at least one of the mitigations !