Relaying Exchange?s NTLM authentication to domain admin (and more)

Published: 2019-01-28
Last Updated: 2019-01-29 18:35:50 UTC
by Bojan Zdrnja (Version: 2)
10 comment(s)

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 :/


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!


Keywords: exchange ntlmrelayx
10 comment(s)


Yes this is huge.
Pentesters doing internal pentests right now are really lucky ;)
Thanks for this post ! Not a lot of media coverage for this (why ??) so I'm glad you're talking about this beauty.

Monitoring AD "5136" events for a few GUID can help you to detect successful attempts of the PoC as explained here:

Thanks Davy!
Good catch on the event, indeed monitoring for 5136 can catch the relay.
As far as I can see the usernames are not directly visible (instead it logs SID's) but still such events should not happen too often - especially not coming from the Exchange server (since this is what will be logged as the Account Name).


You can also monitor for logins to AD with Exchange servers' computer account, e.g., EXCHANGE1$ with NTLM authentication.

If you have an ADC/load balancer, you can drop all connections that send a POST /EWS/ with's push subscription XML data.
We were looking at this yesterday. Exchange 2010 SP3, at least in our implementation, appears to be vulnerable. When we specified --exchange-version 2010_SP2 the CAS server made an outbound connection (as the CAS server computer account) and I was able to relay that to LDAP.

I thought the exploit had succeeded (PCAP showed successful LDAP bind), but after emailing Dirk-jan Mollema it looks like subsequent queries may have failed due to previously setting the registry entries for CVE-2018-8518. Still, with the potential impact if exploited it's probably a bad idea to not mitigate this for Exchange 2010.
"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 :/" I am struggling with this can you or Microsoft respond with the vulnerable versions? Does this mean 2007 and older are vulnerable or a misconfiguration in 2010 could make you vulnerable?
Regarding affected versions:

- Exchange 2013, 2016 and 2019 have been confirmed as vulnerable
- Exchange 2010 apparently has signing enabled so NTLM relaying should not work. I haven't tested this as I don't have Exchange 2010 handy
- Exchange 2007 is unknown status, however according to the documentation, it does support the PushSubscriptionRequest method so it could be affected.

I'll see about updating the diary as we get more information.

With the value deleted per the PoC seems to yield a false positive. Is this the removal of the value working, or another mitigation that may be in place? Can we confirm the PoC should work with the value removed?
From the testing I did with Exchange 2016, removing the registry key did not help in preventing the attack.
I updated Exchange to the latest patch level and noticed that the registry key was not removed.
Then I deleted it manually, but the exploit still worked. My understanding is that it prevents "reflection" attacks where you use NTLM relaying against the Exchange itself.

From my tests I noticed you can monitor for the POC exploit use by checking Event ID 4662 to check for when a user accesses the control {1131f6ad-9c07-11d1-f79f-00c04fc2dcd2} (DS-Replication-Get-Changes-All). This event will also show the actual user involved. There are sometimes machine names in the Account Name but you can filter that out by removing entries with $ sign at the end.

Sample log:

Subject :
Security ID: testdomain\testuser
Account Name: testuser
Account Domain: testdomain
Logon ID: 0x26BB12

Object Server: DS
Object Type: domainDNS
Object Name: DC=testdomain,DC=com
Handle ID: 0x0

Operation Type: Object Access
Accesses: Control Access

Access Mask: 0x100
Properties: Control Access

MS Advisory ADV190007 reports that Exchange 2010 SP3 RU26 is vulnerable.

Diary Archives