On March 14, 2023, Microsoft published a blogpost describing an Outlook Client Elevation of Privilege Vulnerability (CVSS: 9.8 CRITICAL). The publication generated a lot of activity among white, grey and black hat researchers, as well as lots of publications and tweets about the vulnerability and its exploitation. Below, we will highlight the key points and then focus on the initial use of this vulnerability by attackers before it became public.
Affected products include all supported versions of Microsoft Outlook for Windows. Other versions of Microsoft Outlook, such as those for Android, iOS, macOS, and Outlook on the web and other MS365 services, are not affected.
From a technical point of view, the vulnerability is a critical EoP that is triggered when an attacker sends an Outlook object (task, message, or calendar event) within an extended MAPI property that contains a UNC path to an SMB share on a threat actor-controlled server, resulting in a Net-NTLMv2 hash leak. No user interaction is required. The NTLM leak occurs when the reminder window is displayed, not just when the message is received. However, an already expired reminder will be fired immediately upon receipt of the object!
The connection to the remote SMB server sends the user’s Net-NTLMv2 hash in a negotiation message, which the threat actor can use to either:
Note: as these are NTLMv2 hashes, they cannot be leveraged as part of a Pass-the-Hash technique.
The affected Net-NTLMv2 hash belongs to the user currently signed in to the Windows device where the Outlook client application is running, regardless of the identity that received the malicious message. If the user does not dismiss the Outlook reminder/task alert, or if the reminder is recurring (i.e., fires multiple times), the user’s Net-NTLMv2 hash may be leaked multiple times.
The fix in the Outlook client code for CVE-2023-23397 is that Outlook’s PlayReminderSound() now calls IsFileZoneLocalIntranetOrTrusted(), which uses MapUrlToZone() to honor the SMB URI only if it is in a trusted/local zone. This means that a UNC path to an INTRANET/TRUSTED local zone can still be abused even on a patched MS Outlook client (SMB local exploitability should still be possible).
It appears that the implemented fix could be easily bypassed by forging the malicious UNC path with a particular format, then even a patched client could still be vulnerable (feature bypass vulnerability has been assigned CVE-2023-29324 and patched in May 2023) However, the hotfix is still effective on the server side and the exploit vector couldn’t be a CVE-2023-23397 patched Exchange server because it removes the extended MAPI property containing the malicious UNC path on any object in transit.
In the MS Guidance for investigating attacks using CVE-2023-23397, there is a note about WebDAV reported below:
“Note: Interaction based on the WebDAV protocol is not at risk of leaking credentials via this exploit technique. While the threat actor infrastructure might request Net-NTLMv2 authentication, Windows will honor the defined internet security zones and will not send (leak) Net-NTLMv2 hashes. In other words, the vulnerability only affects the SMB protocol. If a target device can communicate to threat actor infrastructure over port 445 (SMB), Net-NTLMv2 hashes might be sent; however, if this communication via SMB is not possible, Windows will fall back to leveraging WebDAV. WebDAV will set up a connection with the threat actor infrastructure, but Net-NTLMv2 hashes will not be sent.”
It seems WebDAV already implements proper checks with regard to local intranet/trusted resources, and MS only considers the leak effective when it appears to an external entity. So, the logical assumption should be: “The WebDAV protocol is not at risk of leaking credentials via this exploit technique TO ANY NETWORK EXTERNAL ENTITY”. What about the local exploitability of WebDAV?
UNC paths can also be used to make a WebDAV request to an external domain, either by SMB falling back to WebDAV (if SMB traffic to the internet is blocked or otherwise fails, Windows will fall back to using WebDAV – if available – to try to complete the connection), or by forcing WebDAV by appending “@80” or “@[email protected]” to the host name.
Internal tests appear to confirm that WebDAV is locally abusable by forcing the use of WebDAV through appending @<port> to the hostname and by using a dotless hostname (considered local network zone by WebDAV); then local exploitability should be possible on a PATCHED client for both SMB and WebDAV.
Evidence of these vulnerabilities being exploited by an unknown attacker has been made public via the submission of samples to VirusTotal. Some samples submitted to VirusTotal in the past were later found to exploit CVE-2023-23397; others were published after the vulnerability was publicly disclosed.
Three variations of the samples were found on VirusTotal:
Many initial publications about these samples referred to April 2022 as the first available evidence because the “FirstSeen VT” field on the oldest sample timestamp was 2022-04-14 (with a received timestamp in the mail header on the same day).
However, a later sample appeared (in a different format – TNEF attachment in .eml – that was not detected by the first version of the YARA rule used by VirusTotal) with a “FirstSeen VT” timestamp of 2022-04-01 and a received timestamp in the mail header of 2022-03-18. In any case, the vulnerability was at the disposal of the first attacker for at least a year.
All publicly available samples found range from 2022-03-18 to 2023-03-29 (this is the last timestamp found in a sample related to a real-world exploit attempt by the attacker). All other samples with a “FirstSeen VT” timestamp starting from 2023-03-15 are mainly tests or POCs or just TNEF attachments missing target and reference timestamp details.
Timeline of detected samples
2022-03-18 – лист.eml
VT First Submission 2022-04-01 06:21:07 UTC
UNC path \\5.199.162.132\SCW (reminder time set to 2019-05-06 20:00)
Sent by: 5.199.162.132 on 2022-03-18 12:01:09 UTC <- THE OLDEST PUBLIC EVIDENCE FOUND TO DATE
Happy Birthday..msg
VT First Submission 2022-04-14 11:49:27 UTC
UNC path \\101.255.119.42\event\2431 (reminder time set to 2020-10-06 20:00)
Sent by: 101.255.119.42 on 2022-04-14 10:35:39 UTC
Celebration.msg
VT First Submission 2022-05-18 07:26:26 UTC
UNC path \\101.255.119.42\mail\a5b3553d (reminder time set to 2020-04-07 11:30)
Sent by: 101.255.119.42 on 2022-05-17 14:21:25 UTC
Information!.msg
VT First Submission 2022-08-05 08:22:49 UTC
UNC path relates to 181.209.99.204 based on VT information should be \\181.209.99.204\information
Silence..eml
VT First Submission 2023-03-23 09:03:23 UTC, but its TNEF attachment VT First Submission 2022-09-29 11:29:43 UTC
UNC path \\213.32.252.221\silence (reminder time set to 2020-03-10 10:30)
Sent by: 213.32.252.221 on 2022-09-09 09:04:23 UTC
Interest..msg
VT First Submission 2022-10-05 14:10:40 UTC
UNC path relate to 213.32.252.221 based on VT information
Information!.msg
VT First Submission 2022-10-25 10:00:00 UTC
UNC path \\168.205.200.55\test (reminder time set to 2019-02-17 19:00)
Sent by: 168.205.200.55 on 2022-10-25 09:12:02 UTC
Fwd..msg
VT First Submission 2022-11-04 09:28:28 UTC
UNC path \\213.32.252.221\fwd (reminder time set to 2020-03-17 02:30)
Sent by: 213.32.252.221 on 2022-11-03 11:07:23 UTC
Fwd..msg
VT First Submission 2022-11-04 09:27:32 UTC
Silence..msg
VT First Submission 2022-11-04 18:41:05 UTC
Silence..msg
VT First Submission 2022-11-08 20:41:31 UTC
Silence..msg
VT First Submission 2022-11-09 06:50:41 UTC
UNC path relate to 213.32.252.221 based on VT infos
Fwd..msg VT First Submission 2022-12-01 09:37:36 UTC
UNC path \\69.162.253.21\pets (reminder time set to 2020-03-09 23:30)
Sent on 2022-12-01 06:18:15 UTC
Fwd..msg
VT First Submission 2022-12-01 12:19:18 UTC
UNC path \\185.132.17.160\aojv43 (reminder time set to 2021-04-21 11:30)
Sent on 2022-12-01 11:59:46 UTC
Report.eml
VT First Submission 2022-12-14 08:47:25 UTC
UNC path \\69.51.2.106\report (reminder time set to 2021-05-19 00:30)
Sent by: 69.51.2.106 on 2022-12-14 07:05:18 UTC
Ticaret.msg
VT First Submission 2022-12-29 13:00:43 UTC & VT First Submission 2023-03-16 13:05:21 UTC
UNC path \\113.160.234.229\istanbul (reminder time set to 2022-09-05 22:00)
Sent by: 113.160.234.229 on 2022-12-29 12:39:33 UTC
Unknown
VT First Submission 2023-03-21 10:47:06 UTC
UNC path \\85.195.206.7\lrmng
Sent by: 85.195.206.7 on 2023-03-15 16:07:48 UTC
Alarms!.msg
VT First Submission 2023-03-16 13:02:30 UTC
UNC path \\85.195.206.7\lrmng (reminder time set to 2022-02-03 23:30)
Sent by: 85.195.206.7 on 2023-03-15 16:15:07 UTC
Power!
VT First Submission 2023-03-20 07:55:32 UTC
UNC path \\85.195.206.7\power (reminder time set to 2022-01-31 23:30)
Sent by: 77.238.121.148 on 2023-03-17 14:04:54 UTC
Reminder!
VT First Submission 2023-03-22 12:20:44 UTC
UNC path \\61.14.68.33\rem (reminder time set to 2022-06-28 21:30)
Sent by: 77.238.121.148 on 2023-03-21 11:13:14 UTC
Reminder!.eml
VT First Submission 2023-03-29 06:51:54 UTC
UNC path \\61.14.68.33\rem (reminder time set to 2022-06-28 21:30)
Sent by: 77.238.121.148 on 2023-03-22 09:13:09 UTC
Reminder!.eml
VT First Submission 2023-03-27 08:59:44 UTC
UNC path \\61.14.68.33\rem (reminder time set to 2022-06-28 21:30)
Sent by: 77.238.121.148 on 2023-03-22 09:17:19 UTC
CC.eml
VT First Submission 2023-03-29 13:51:50 UTC
UNC path \\42.98.5.225\ping (reminder time set to 2023-01-31 01:00)
Sent by: 42.98.5.225 on 2023-03-29 12:36:10 UTC
Threat-relevant IOCs are the embedded malicious UNC paths and IPs (not hashes of sample files, which are just an export in MSG/EML format of the malicious TASK exploiting the vulnerability and useless for threat detection/verification).
URLs (#16)
\\5.199.162[.]132\SCW
\\101.255.119[.]42\event\2431
\\101.255.119[.]42\mail\a5b3553d
\\181.209.99[.]204\information
\\213.32.252[.]221\silence
\\168.205.200[.]55\test
\\213.32.252[.]221\fwd
\\69.162.253[.]21\pets
\\185.132.17[.]160\aojv43
\\69.51.2[].106\report
\\113.160.234[.]229\istanbul
\\85.195.206[.]7\lrmng
\\24.142.165[.]2\req
\\85.195.206[.]7\power
\\61.14.68[.]33\rem
\\42.98.5[.]225\ping
IPs (#14)
5.199.162[.]132 (not in MS Guidance publication)
101.255.119[.]42
181.209.99[.]204
213.32.252[.]221
168.205.200[.]55
69.162.253[.]21
185.132.17[.]160
69.51.2[.]106 (not in MS Guidance publication)
113.160.234[.]229
85.195.206[.]7
24.142.165[.]2 (not in MS Guidance publication)
61.14.68[.]33
42.98.5[.]225 (not in MS Guidance publication)
82.196.113[.]102 (only in MS Guidance publication – on VT relating to hash 92df1d2125f88d0642e0d4919644376c09e1f1e0eaf48c31a6b389265e0d5576, but missing the sample and any additional information)
Any attempt to communicate to the IPs/URIs listed in the above IOCs and found in any logs should be considered suspicious and investigated further.
Alternatively, to determine if an organization has been targeted by attempts to exploit this vulnerability, Microsoft has provided documentation for a script that checks all Outlook objects (tasks, email messages and calendar items) to see if the specific property is populated with a UNC path. If objects are detected that point to an unrecognized share, they should be investigated further. Microsoft has provided detailed guidance on how to do this.
It’s easy to see that many of the IPs used by the attacker have/had similarities in terms of connected equipment.
IP | Net exposed service history |
---|---|
5.199.162[.]132 | No Info |
101.255.119[.]42 | HTTP redirect to HTTPS, HTTPS cert Subject: C=US, CN=UBNT Router UI, O=Ubiquiti Networks, SSH on port 2222 |
181.209.99[.]204 | HTTP redirect to HTTPS, HTTPS cert Subject: C=US, CN=UBNT Router UI, O=Ubiquiti Networks |
213.32.252[.]221 | HTTP redirect to HTTPS, HTTPS cert Subject: C=US, CN=UBNT Router UI, O=Ubiquiti Networks |
168.205.200[.]55 | HTTP redirect to HTTPS, HTTPS cert Subject: C=US, CN=UBNT Router UI, O=Ubiquiti Networks, port UDP 10001 Ubiquiti Networks Device_Hostname: _Product: N5N_Version: XM.ar7240.v5.6.6.29183.160526.1225 @2022-06-16 |
69.162.253[.]21 | HTTP redirect to HTTPS, HTTPS cert Subject: C=US, CN=UBNT Router UI, O=Ubiquiti Networks, port UDP 10001 |
185.132.17[.]160 | HTTP redirect to HTTPS, HTTPS cert Subject: C=US, CN=UBNT Router UI, O=Ubiquiti Networks, SSH on port 2222 |
69.51.2[.]106 | HTTP redirect to HTTPS, HTTPS cert Subject: C=US, CN=UBNT Router UI, O=Ubiquiti Networks, SSH on port 2222 |
113.160.234[.]229 | HTTP redirect to HTTPS, HTTPS cert Subject: C=US, CN=UBNT Router UI, O=Ubiquiti Networks, SSH on port 2222 |
85.195.206[.]7 | HTTP redirect to HTTPS, HTTPS cert Subject: C=US, CN=UBNT Router UI, O=Ubiquiti Networks |
24.142.165.2 | No Info |
61.14.68[.]33 | HTTP redirect to HTTPS, HTTPS cert Subject: C=US, CN=UBNT Router UI, O=Ubiquiti Networks, SSH on port 2222 |
42.98.5[.]225 | HTTP redirect to HTTPS, HTTPS cert Subject: C=US, CN=UBNT Router UI, O=Ubiquiti Networks, SSH on port 2222 |
82.196.113[.]102 | HTTP redirect to HTTPS, HTTPS cert Subject: C=US, CN=UBNT Router UI, O=Ubiquiti Networks, SSH on port 2222 |
This is obviously not random, but a common point for the attacker.
One of the IPs used by the attacker exposes the WebUI of an internet access router:
Some researchers have argued that an attacker may have exploited a vulnerability in the firmware of these routers to compromise them and use them in the attack. This may be possible, but it may also be that the attacker simply found this router configured with weak/default credentials and exploited it.
Further investigation into the type of network equipment used by the attacker confirmed that it could be an optimal platform for the threat. For example, this router is typically used by ISPs on the customer side and its firmware provides a Command Line Interface (CLI) accessible directly through a WebUI. Use of the CLI from WebUI doesn’t leave any source IP information in the OS logs because the connection originates locally from 127.0.0.1; only traces of connections to the WebUI could be stored in the firewall logs.
The screenshot of the router’s CLI (obtained from the test equipment)
Moreover, the router’s operating system has native Python 2.7 and there’s already a well-known fake SMB server for collecting NTLM hashes implemented by the hacking tool named “Responder”, which is coded as a Python script. It is worth noting that running an open SMB server on the public internet will receive a lot of connections due to scanning attempts unrelated to the use of the attacker’s samples. Thus, we can assume that the attacker collected all the data from the fake SMB server and then post-processed it to exclude the scanning attempts, extracting only the threat-relevant data.
In any case, using routers connected to the public internet as a source of attack is a clever way to collect the threat targets’ data without relying on a host, and it includes an easy way to delete any logs/traces of the malicious activity. ISP routers might have more aspect of its OS architecture that allow cybercriminals to exploit it for malicious activity, such as publicly known default credentials or highly volatile logs that are not recording the source IP information and can be lost with a simple reboot. For example, for the router which is assumed to have been used in the attack the log folder is mounted on a volatile in-memory filesystem:
tmpfs /var/log tmpfs rw,nosuid,nodev,noexec,relatime,mode=755 0 0 |
Organizations safeguard against cyberthreats targeting ISP routers through regular firmware updates, strong authentication, network segmentation, firewall configuration, IDPS deployment, monitoring and logging, as well as network traffic analysis, security awareness training for employees and regular security assessments.