Detecting ExchangePriv vulnerability with Azure ATP
NTLM relay vulnerability is not a new phenomenon. With the added security mechanisms implemented in signed NTLMv2 making successful attacks seem more and more unlikely, it would appear there would be very little to talk about here. Right?
Wrong!
In fact, there are attack vectors that remain where NTLMv1 or unsigned NTLMv2 is relayed by attackers in the domain environment. In addition, although NTLMv1 and unsigned NTLMv2 should no longer be in use, our most recent research found that NTLMv1 is still commonly used in about 30-40% of the environments. These legacy protocols are used, by default, on servers running old versions of Windows (Windows Vista or Windows Server 2008 and earlier versions) but can also be seen in new versions which support backward compatibility, or processes that implement the authentication mechanism themselves (such as Python modules like “Impacket”). Furthermore, newly discovered vulnerabilities can lead to easy exploitation of domain controllers, even faster than previously thought possible.
Signed NTLMv2 has a signing and sealing mechanism that prevents tampering and relay impersonation. The version of NTLM, however, used in each domain depends on the source computer that initiates authentication. The source computer in different domains can be configured differently based on operating system version, LMCompatibilityLevel registry override or Group Policy Object (GPO) configuration. In other words, even if you are running newer versions of Windows and Active Directory servers, you may be running client services that still use NTLMv1 without realizing it, leaving your organization equally exposed.
While new vulnerabilities in NTLM relay have occasionally been revealed, the most recent discovery from a few weeks ago, of remote NTLM triggering on-premises Exchange Servers against the original configuration is unique and especially concerning to organizations that still have NTLMv1 in use.
Red-teamer, Dirk-jan found that three vulnerabilities, when combined, can potentially be a new NTLM relay attack. Dirk-jan’s proposed triangle, is based on historical vulnerabilities of the NTLM challenge-response authentication method, and is especially relevant when NTLMv1 is in use, or less commonly deployed, but equally vulnerable, unsigned or unsealed NTLMv2.
In the proposed attack, Exchange Server can be configured, remotely by a user with an inbox on the Exchange Server, to trigger NTLM authentication with the Exchange Server account credentials to a malicious remote http server. The remote http server waits for the sensitive Exchange Server account to relay its authentication to any other server. Once Exchange Server account impersonation is targeted to an Active Directory Domain Controller, the sensitive permission of the Exchange Server account can be used to push changes in the directory over different protocols such as LDAP or LDAPS.
If the attacker succeeds in impersonating the Exchange Server account, they can even grab extended permissions to perform domain replication (“DcSync”) and also acquire credentials of all accounts in the domain.
When this new attack scenario was raised, Microsoft’s Azure Advanced Threat Protection’s (Azure ATP) security research team immediately started investigating this and realized the vulnerability was a real threat and created a new Azure ATP detection to alert SecOps teams if an attacker is leveraging this exploit. The new Azure ATP NTLM relay alert identifies use of Exchange Server account credentials from a suspicious source, alerts on the suspicious behavior, provides evidence and related entity information, and helps to swiftly remediate.
Screenshots from the Azure ATP portal of how the new alert looks when relaying from Linux or Windows machines are shown below. The first alert shows a detected relay that used NTLMv1 or unsigned (and not sealed) NTLMv2 protocol, and the second alert shows a detected relay that used secured NTLMv2 protocol, with suspicious IP address behavior.
We strongly recommend forcing the use of NTLMv2 in a domain. Force use via the Network security: LAN Manager authentication level,group policy. To learn more about force use of NTLMv2 see how to set the group policy on Domain Controllers or on Windows clients.
You can learn more about LDAP best practices for client signing requirements here.
Make your organization more secure with Azure ATP by leveraging the scale and intelligence of the Microsoft Intelligent Security Graph as part of Microsoft 365’s E5 Suite.
Get Started Today
- Read about customers using Azure ATP today: Customer Stories
- Learn more about Azure ATP here: Technical Documentation
- Start a trial from our Azure Advanced Threat Protection Product Page
- Join the Azure ATP community: Technical Community