Comprehensive analysis of initial attack samples exploiting CVE-2023-23397 vulnerability
Discription

![](https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2022/10/05080519/abstract_binary_connection-990×400.jpg)

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.

## The CVE-2023-23397 vulnerability

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:

* Relay for authentication against other systems that support NTLMv2 authentication.
* Perform offline cracking to extract the password.

**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 vulnerability fix

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.

### The WebDAV protocol

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 “@SSL@443” 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.

## The samples

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:

* MSG format (full email with message header) -> provide usage time reference and a supposed target
* EML format (full email with message header) -> provide usage time reference and a supposed target
* TNEF format (only TASK attachment in TNEF format) -> NO time reference and NO supposed target

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.

## Sample list

[![](https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2023/07/18105841/image1.png)]()

_Timeline of detected samples_

* Target: Government entity – UA

**2022-03-18 – лист.eml
**VT First Submission 2022-04-01 06:21:07 UTC
UNC path **\5.199.162.132SCW **(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**

* Target: Government entity – RO

**Happy Birthday..msg
**VT First Submission 2022-04-14 11:49:27 UTC
UNC path **\101.255.119.42event2431 **(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.42maila5b3553d **(reminder time set to 2020-04-07 11:30)
Sent by: 101.255.119.42 on **2022-05-17 14:21:25 UTC**

* Target: Energy transportation critical infrastructure – PO

**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.204information**

* Target: Military supplier – PO

**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.221silence **(reminder time set to 2020-03-10 10:30)
Sent by: 213.32.252.221 on **2022-09-09 09:04:23 UTC**

* Target: Transportation critical infrastructure – PO

**Interest..msg
**VT First Submission **2022-10-05 14:10:40 UTC **
UNC path relate to **213.32.252.221** based on VT information

* Target: Government entity – JO

**Information!.msg
**VT First Submission 2022-10-25 10:00:00 UTC
UNC path **\168.205.200.55test **(reminder time set to 2019-02-17 19:00)
Sent by: 168.205.200.55 on **2022-10-25 09:12:02 UTC**

* Target: Transport critical infrastructure – PO

**Fwd..msg
**VT First Submission 2022-11-04 09:28:28 UTC
UNC path **\213.32.252.221fwd **(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

* Target: Energy transportation critical infrastructure – UA

**Fwd..msg** VT First Submission 2022-12-01 09:37:36 UTC
UNC path **\69.162.253.21pets **(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.160aojv43 **(reminder time set to 2021-04-21 11:30)
Sent on **2022-12-01 11:59:46 UTC**

* Target: Energy production critical infrastructure – UA

**Report.eml
**VT First Submission 2022-12-14 08:47:25 UTC
UNC path **\69.51.2.106report **(reminder time set to 2021-05-19 00:30)
Sent by: 69.51.2.106 on **2022-12-14 07:05:18 UTC**

* Target: Military supplier – TK

**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.229istanbul **(reminder time set to 2022-09-05 22:00)
Sent by: 113.160.234.229 on **2022-12-29 12:39:33 UTC**

* Target: Government entity – UA

**Unknown****
**VT First Submission 2023-03-21 10:47:06 UTC
UNC path **\85.195.206.7lrmng**
Sent by: 85.195.206.7 on **2023-03-15 16:07:48 UTC **

* Target: Military interforce entity – TK

**Alarms!.msg
**VT First Submission **2023-03-16 13:02:30 UTC**
UNC path **\85.195.206.7lrmng **(reminder time set to 2022-02-03 23:30)
Sent by: 85.195.206.7 on **2023-03-15 16:15:07 UTC**

* Target: Space military supplier – IT

**Power!
**VT First Submission 2023-03-20 07:55:32 UTC
UNC path **\85.195.206.7power **(reminder time set to 2022-01-31 23:30)
Sent by: 77.238.121.148 on **2023-03-17 14:04:54 UTC**

* Target: IT integrator – UA

**Reminder!
**VT First Submission 2023-03-22 12:20:44 UTC
UNC path **\61.14.68.33rem **(reminder time set to 2022-06-28 21:30)
Sent by: 77.238.121.148 on **2023-03-21 11:13:14 UTC**

* Target: Government entity – SK

**Reminder!.eml
**VT First Submission 2023-03-29 06:51:54 UTC
UNC path **\61.14.68.33rem **(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.33rem **(reminder time set to 2022-06-28 21:30)
Sent by: 77.238.121.148 on **2023-03-22 09:17:19 UTC**

* Target: IT integrator – UA

**CC.eml
**VT First Submission 2023-03-29 13:51:50 UTC
UNC path **\42.98.5.225ping **(reminder time set to 2023-01-31 01:00)
Sent by: 42.98.5.225 on **2023-03-29 12:36:10 UTC**

## Initial attack IOCs

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[.]132SCW
\101.255.119[.]42event2431
\101.255.119[.]42maila5b3553d
\181.209.99[.]204information
\213.32.252[.]221silence
\168.205.200[.]55test
\213.32.252[.]221fwd
\69.162.253[.]21pets
\185.132.17[.]160aojv43
\69.51.2[].106report
\113.160.234[.]229istanbul
\85.195.206[.]7lrmng
\24.142.165[.]2req
\85.195.206[.]7power
\61.14.68[.]33rem
\42.98.5[.]225ping

**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)

## Threat verification

**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.

## A note about attacker infrastructure

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:

[![](https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2023/07/18105848/image2.png)]()

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.

[![](https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2023/07/18105854/image3.png)]()

_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.Read More

Back to Main

Subscribe for the latest news: