Meeting Mayhem: Understanding the Outlook Appointment Vulnerability

Ayan Saha
Keysight ATI
Published in
4 min readJun 7, 2023

Are you growing weary of those familiar Outlook appointment chimes? You might want to pay closer attention, as a newly discovered vulnerability could mean that your next reminder leaves you compromised (fortunately, I use Windows Mail). That’s right — researchers at MDsec recently uncovered a Microsoft Outlook flaw (CVE-2023–23397) that allows attackers to access recipients’ credentials through a seemingly innocuous appointment.

What’s the problem?

The vulnerability exists in Outlook, when sending an appointment, it’s possible to set the filename of the reminder tone to be played at the recipient side with the ‘PidLidReminderFileParameter’ option. This filename is an UNC path which means the resource can be fetched over network services like SMB. So, when an attacker sends an appointment with the path pointing to an SMB share, and the victim is reminded of the appointment, the vulnerable Outlook client tries to fetch the tone and, in the process, it will attempt to do NTLM authentication and leak the NTLM hashes of the victim. The ‘PidLidReminderOverride’ option is also used to force Outlook to use the file. The following image gives a pictorial representation of the attack.

Fig 1: CVE-2023–23397 Attack Flow

Preparing the vulnerable environment

To showcase the exploitation in a complete local environment, we deployed a local AD with local email servers. In real life the appointment could come from outside the network as well.

  • We deploy a Windows server to act as the Active Directory (AD) Domain Controller (DC). This can be done following the instructions of this blog here. The administrator of the AD will be our victim.
  • For sending local mails within a local AD, we installed an Exchange server on the same machine. You can follow any online instructions to do the same.
  • Now we deploy the vulnerable Outlook client on the victim machine. The list of vulnerable versions of Outlook can be found here.
  • We also created a new AD user to act as the attacker and create a new mailbox for the user. https://learn.microsoft.com/en-us/exchange/recipients/create-user-mailboxes.
  • Once the victim is set up, for the attacker we deploy another VM (Windows 10). We connect the victim to the same AD Domain following the same blog and login with the user created in the previous step. We install outlook client there as well to send the malicious appointment (Doesn’t need to be vulnerable).
  • We also need an attacker-controlled server which acts as the SMB share. For this we can use a tool like Responder which can be run using the command: sudo responder -I eth0 -v

Exploit in Action

We will use this GitHub PoC for showing the exploit — https://github.com/api0cradle/CVE-2023-23397-POC-Powershell/tree/main.

  • On the attacker machine in a PowerShell session, we execute the Send-CalendarNTLMLeak function from the GitHub POC as shown below:
Fig 2: POC script
  • This uses PowerShell commands to create a new Outlook Appointment object and sets the necessary parameters for the appointment along with the ReminderSoundFile and ReminderOverrideDefault which corresponds to PidLidReminderFileParameter and PidLidReminderOverride option mentioned previously.
  • Then the malicious appointment can be sent from the attacker VM. You might have to approve this from the outlook client:
Fig 3: Malicious appointment sent to the victim
  • Once we send it, the victim receives the appointment and once it’s accepted, it gets added to the calendar and when the reminder for the same comes, the credentials get leaked to the machine running the SMB server.
Fig 4: Malicious appointment received by the victim
Fig 5: Appointment reminder received by the victim
Fig 6: NTLM credentials of victim leaked to attacker

If you would like to test out the vulnerability without setting the environment up like we did, Tryhackme has a free room which lets you play around with this vulnerability.

What can you do with the NTLM hashes?

The leaked hashes can be cracked if the passwords are weak enough. For example, with the utility hashcat as you can see the password was obtained:

Fig 7.: Hashcat password bruteforce on NTLM creds

If the password is complex enough to resist bruteforce, the hashes could also be relayed to other services running on the network to get different access.

Mitigations

Microsoft has released some scripts to discover this vulnerability, but there are already patches out for this vulnerability. Updating to the patched version as per the advisory should help mitigate the attack.

Originally published at https://www.keysight.com.

--

--