By Mark Bereza · March 17, 2023
This story was also written by John Dunlap.
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.
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.
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.
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.
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.
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.
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 of 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.
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:
Figure 1: PlayReminderSound before (left) and after (right) the March security update.
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 part 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.
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: