Overview
During the March “Patch Tuesday” security update, a new Outlook security vulnerability was revealed as being exploited in the wild. This is a serious vulnerability that has the potential to compromise domains through the leaking of NTLM hashes. This exploit is only the latest in a history of related vulnerabilities dating back to 2017, such as CVE-2017-8572 and CVE-2017-11927, which have allowed attackers to leak a user’s NTLMv2 credentials from Outlook. Armed with these credentials, an attacker can use them to impersonate the victim when authenticating with Windows hosts on the network, potentially granting unfettered access to critical servers depending on the victim’s user privileges.
How does this vulnerability work?
CVE-2023-23397 is a vulnerability that allows attackers to leak NTLMv2 hashes from Outlook. This can be accomplished remotely by sending a malicious calendar invite to a victim. Potentially any Outlook entity that is represented by the .msg format—and that supports reminders—could be used to trigger the vulnerability. The actual vulnerable API endpoint is PlayReminderSound within Outlook, which uses PidLidReminderFileParameter to specify a custom alert sound for reminders.
The issue arises when the PidLidReminderFileParameter is set to a UNC path that points to an attacker-controlled server, something that Outlook allowed prior to the update. An attacker can leverage this by sending a victim a calendar appointment with such a custom reminder sound location, causing the victim’s Outlook client to attempt to authenticate with the attacker-controlled server in order to fetch the reminder sound, which is done using NTLM authentication. This, in turn, will cause the victim to leak their NTLMv2 hash to the attacker. Attackers would likely also use the PidLidReminderOverride API parameter to force the use of the alert sound. This effectively triggers the use of the sound, with this parameter instructing Outlook to respect the values specified by PidLidReminderFileParameter. Without this parameter, Outlook may ignore the customized sound file that triggers the attack.
A NTLMv2 what?
NTLMv2 hashes are the latest form of Windows’ “LANMAN” hash used for various forms of authentication. The LM in NTLM stands for “LAN manager” and originated from an older Windows networking service. Legacy Windows applications used the NTLMv1 protocol, which used a cryptographically weak hashing algorithm. Therefore, NTLMv1 is no longer used in modern applications.
NTLMv2 is a challenge response protocol where two responses are sent after receiving a server challenge. Each response contains a hashed representation of the user’s credentials, including a hash of the username and password along with some other information.
What can the attacker do with my NTLMv2 Hash?
Many services use the NTLMv2 hash directly for authentication. Attackers may attempt a NTLM relay attack in order to gain access to hosts or services. In several scenarios attackers can directly authenticate to Windows hosts using the hash. This can in turn lead to full compromise of the domain, especially if NTLMv2 hashes are leaked for administrative users. Once a single user’s hash is leaked, it is not uncommon for attackers to traverse the domain and elevate privileges in these NTLM relaying scenarios.
Should I be worried?
Short answer: Yes!
Long answer: This vulnerability is exceedingly easy to exploit and has already been observed being leveraged in the wild. Additionally, the victim does not have to directly interact with the e-mail containing the malicious event at all. Interaction with the preview pane is not required.
Put simply, if your organization uses Outlook, you should be worried about this vulnerability.
Where is it being exploited?
Information is still coming to light about active exploitation, but there have already been several confirmed attacks using this vulnerability. Digital Forensics researchers have detected active exploitation campaigns, with some anecdotes coming to light about attacks against military contractors in Turkey.
How do I know if my organization is being targeted?
Microsoft has released a script that can audit Exchange for malicious messages and scrub them. A Yara rule can be found here.
In short, prior to exploitation, look for malicious .msg files using PidLidReminderFileParameter. Post exploitation, search for evidence NTMLv2 relay attacks on the network and signs that individual user accounts are being compromised via NTLMv2 hashes. These would take the form of abnormal logins from new or unrecognized IP addresses.
How do I remediate this issue?
First and foremost, apply the March security update for Outlook.
Second, perform an audit of your organization’s Exchange server using the script linked above.
Third, if immediate patching is not possible, consider following Microsoft’s mitigation guidance, which states:
- “Add users to the Protected Users Security Group, which prevents the use of NTLM as an authentication mechanism. Performing this mitigation makes troubleshooting easier than other methods of disabling NTLM. Consider using it for high value accounts such as Domain Admins when possible. Please note: This may cause impact to applications that require NTLM, however the settings will revert once the user is removed from the Protected Users Group. Please see Protected Users Security for more information.”
- “Block TCP 445/SMB outbound from your network by using a perimeter firewall, a local firewall, and via your VPN settings. This will prevent the sending of NTLM authentication messages to remote file shares.”
How does the patch address the issue?
After performing a patch diff of the Outlook.exe binary before and after applying the March security update, we saw that one of the changed functions was PlayReminderSound. Figure 1 above displays the decompiled code for this function before (left) and after (right) the patch was applied. It should be noted that this function is largely a wrapper function for HrAsyncPlayReminderSound, shown towards the bottom of the pre-patched function code, which actually does the work of fetching the reminder sound file and playing it.
We can see that a block of code has been added in the patched version, highlighted in red, which calls the function IsFileZoneLocalIntranetOrTrusted on the ReminderFileParam. IsFileZoneLocalIntranetOrTrusted, as its name might suggest, simply checks whether the passed in file path is path of the device’s local intranet or in a trusted domain – returning 1 (true) if it is and 0 (false) it isn’t. Notably, if this check fails, the ReminderPlaySound flag is set to 0 (false), which causes the function to skip to the CLEAN_UP step and avoids invoking HrAsyncPlayReminderSound altogether, thus making the vulnerable code path unreachable if the provided ReminderFileParam is deemed unsafe.
Further hardening measures for the future
If history has taught us anything, it’s that this will surely not be the last NTLMv2 hash leaking vulnerability. Take this opportunity to harden your organization’s infrastructure against NTLM relay attacks of all kinds. Thankfully, Microsoft has a KB article that offers some guidance for achieving this exact goal.
Beyond that, some general guidelines to get you started might include:
- Enabling SMB signing
- Enabling extended protection for authentication
- Ensure you are auditing logins and configure security logging mechanisms to effectively flag abnormal logins.
- Apply the principle of least privilege by limiting the spread of administrative privileges across the domain. NTLM relay attacks are often the first step toward a total domain compromise which is usually only possible when administrative credentials are shared too widely across an organization.
Further reading
- https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-23397
- https://learn.microsoft.com/en-us/office/client-developer/outlook/mapi/pidlidreminderoverride-canonical-property
- https://www.mdsec.co.uk/2023/03/exploiting-cve-2023-23397-microsoft-outlook-elevation-of-privilege-vulnerability/
- https://microsoft.github.io/CSS-Exchange/Security/CVE-2023-23397/
