Discovering ConnectWise ScreenConnect RCE & LPE Vulnerabilities (CVE-2023-47256, CVE-2023-47257)

Discovering ConnectWise ScreenConnect RCE & LPE Vulnerabilities (CVE-2023-47256, CVE-2023-47257)

Discovering ConnectWise ScreenConnect RCE & LPE Vulnerabilities (CVE-2023-47256, CVE-2023-47257)

Author(s): Dennis Carlson


Before delving into the technical details of CVE-2023-47256 and CVE-2023-47257, it is important to recognize the ConnectWise team for their rapid response to this vulnerability disclosure. Gotham Security notes that throughout the disclosure process, ConnectWise worked as an exceptional cybersecurity partner. All disclosures made to ConnectWise were treated with a professional and timely response.

Vulnerability Overview

ConnectWise ScreenConnect is a remote support and remote administration tool that is widely used by both IT staff and IT managed service providers (MSPs). Once the ScreenConnect client is installed on a computer, administrators can remotely control the system as if they were physically in front of it. Across the IT industry, many leverage ScreenConnect as their primary resource to assist users or configure systems.

However, with the discovery of CVE-2023-47257, it was found that Man-in-the-Middle (MitM) attackers could perform Remote Code Execution (RCE) as “NT AUTHORITY\System” through the ScreenConnect client. If executed on a local network, it would be possible for an attacker to obtain RCE with local administrative permissions across all network-connected systems where the ScreenConnect client is installed, irrespective of the operating system. Although this attack is more practical to perform on a local network, it is technically possible for this attack to be executed anywhere in the routing chain, though this may prove much more difficult to accomplish.

With CVE-2023-47256, it was additionally found that the ScreenConnect client could be tricked into trusting proxy configurations from non-administrative local users. When combined with CVE-2023-47256, a non-privileged attacker with existing access to a system could reliably perform Local Privilege Escalation (LPE) and Remote Code Execution (RCE) as “NT AUTHORITY\System”. If an attacker leverages this implicit trust of user proxies, they would not need to perform a network-based MitM attack to exploit CVE-2023-47257.

Vulnerability Disclosure & Remediation Timeline


On October 30th, Dennis Carlson at Gotham Security discovered two high-risk vulnerabilities in the ScreenConnect client. A technical write-up and Proof-of-Concept (PoC) was quickly developed and disclosed to ConnectWise in accordance with their Vulnerability Disclosure Policy.

Within an hour of submission, ConnectWise triaged both vulnerabilities and assigned security engineers to replicate Gotham Security’s findings. Later that same day, both findings were confirmed as valid. ConnectWise then initiated the development of a security patch to address both vulnerabilities.

On November 3rd, ConnectWise contacted Gotham Security and requested confirmation of a security patch, which was released to their QA environment. Gotham Security inspected the changes made to the client and confirmed remediation on November 8th.

After coordinating a public disclosure plan with the ConnectWise team, a patch was released, and a security advisory was published on November 20th (see here). Gotham Security agreed to give sufficient time for patches to be applied before releasing further technical details, settling on a disclosure date of January 5th, 2024.

CVE-2023-47257 - Remote Code Execution (RCE)

To fully understand this vulnerability, it must first be understood how the ScreenConnect client generally operates under normal circumstances. ScreenConnect is typically used to provide remote assistance or remote administration of Linux, Windows, and Mac systems. This is done by installing the ScreenConnect client to the system as a local service, where the client maintains an active connection to ConnectWise relay servers. Although the client makes this connection outbound on TCP port 443, it does not utilize HTTPS. Instead, it leverages a custom protocol that similarly implements RSA key pairs for the negotiation of the socket’s encryption key.

When validating the authenticity of the relay server, the ScreenConnect client relies heavily on the server's ability to complete the initial handshake. This initial handshake expects the relay server to know a preconfigured RSA private key, which has been hard-coded into the client service’s launch arguments and configuration file. The relay server must use its RSA private key to decrypt a randomly-generated secret received from the client in order to begin encryption on the socket and subsequently complete the handshake. It should be noted that completion of this handshake is the only form of authentication performed by the client against the relay server.

Leveraging CVE-2023-47257, it is possible to skip the initial handshake (and, by extension, verification of the relay server) by sending crafted messages to the client. If the ScreenConnect client is also installed as a local service, which is commonly done when deployed for remote management, the MitM attacker could pose as a legitimate relay server and perform Remote Code Execution (RCE) as “NT AUTHORITY\System” under Windows or a privileged user account under Linux/Mac.

A reverse-shell demonstrated execution as “NT AUTHORITY\System”
A reverse-shell demonstrated execution as “NT AUTHORITY\System”

The vulnerable code exists within "ScreenConnect.Core.dll" under the ScreenConnect.SocketEndpointManager.RunIncomingThread function. By decompiling the code, we can see at the beginning of the message processing loop, all incoming messages will be validated as sub-classes of HandshakeMessage until IsHandshakeComplete is set. This is meant to ensure that a fake relay cannot send privileged messages until a handshake has been completed.

A message restriction is set until
A message restriction is set until IsHandshakeComplete is set to true

Looking further into the message processing loop, we can see that after checking whether the message is a HandshakeMessage, there are several other HandshakeMessage sub-classes allowed aside from the ServerHelloMessage. It should be noted that the ServerHelloMessage is what typically begins transparent encryption on the socket.

Several HandshakeMessage sub-classes are processed by the client outside of the ServerHelloMessage

Specifically, focus your attention on the SessionInfoMessage and SessionInfoMessageOld5 handler. Under this handler, we can see that the first action performed is to flip the session's IsHandshakeComplete value to true. Once this value is set, the message type restriction to HandshakeMessage is cleared, and the fake relay can then send arbitrary messages to the client.

The message type restriction is lifted once a
The message type restriction is lifted once a SessionInfoMessage is received

What this ultimately means is that if a remote attacker can route the client into connecting to their fake relay through something like a MitM attack, it is possible to bypass the socket's encryption and relay validation step by sending a fake SessionInfoMessage to complete the handshake. From that point onward, it is possible to transfer files, execute commands, or any other actions that would be allowed by a legitimate connection.

CVE-2023-47257 - CVSS Score

Supposing an attacker is able to perform a MitM attack anywhere in the routing process, we believe it is possible to leverage this vulnerability remotely. Given the level of access granted to the local system, which extends beyond just the ScreenConnect component, we believe this also widens the scope of the vulnerability. Taking into account the added complexity of performing a MitM attack, this levels out to a CVSS score of 9.0 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H).

CVE-2023-47256 - Local Privilege Escalation (LPE)

During the analysis of the ScreenConnect client, it was found that the local service could be tricked into trusting the proxy configuration for non-administrative local users. This vulnerability was not only reliable in exploitation but could also result in Local Privilege Escalation when chained with CVE-2023-47257.

The Proof-of-Concept (PoC) script successfully created a local administrator named “admini”
The Proof-of-Concept (PoC) script successfully created a local administrator named “admini”

If we decompile "ScreenConnect.Windows.dll" and look at the ScreenConnect.WindowsClientToolkit.WindowsProxyAttempter.GetPossibleProxyUris function, we can see the exact process used to determine which proxy URI should be used. For now, take note that this function will first attempt to use the configuration's ExplicitProxyUri and DiscoveredProxyUri values.

One of the first proxy configurations attempted will be the
One of the first proxy configurations attempted will be the DiscoveredProxyUri

If neither of these options produces a working proxy URI, ScreenConnect will attempt to enumerate through active user sessions and connect to the relay server using their proxy configurations. This is where we can trick the system into connecting to our fake relay. By setting the local user's proxy configuration to the fake relay, disconnecting from the network, and sleeping/awakening the device, ScreenConnect will see our proxy as functional, and we can perform privilege escalation through CVE-2023-47257.

This code attempts to utilize the proxy configuration for each active user
This code attempts to utilize the proxy configuration for each active user

Interestingly, this seems to be an intentional feature of ScreenConnect. If ScreenConnect encounters a situation where no other connections to the relay server are functional, it will save the first functional user proxy to its configuration file as the DiscoveredProxyUri value. As noted above, the DiscoveredProxyUri value is one of the first proxy URIs attempted. So once this change is made, re-connection through the proxy should be fairly reliable.

This function will overwrite the application’s
This function will overwrite the application’s DiscoveredProxyUri configuration once a working proxy is found

CVE-2023-47256 - CVSS Score

This vulnerability has a standalone negligible score. With the latest patches especially, this vulnerability simply allows users to route initial relay connections to a proxy server under their control. Without chaining this vulnerability, there is minimal impact to any resources. We believe this is worth rating as a 3.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N).

Together with CVE-2023-47257, the chained score for CVE-2023-47256 is boosted greatly compared to its standalone score. When these two vulnerabilities are chained, we believe that the ease of reproduction combined with the Local Privilege Escalation (LPE) attack vector contextually changes the score to an 8.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H).

For additional details, please see the ConnectWise security bulletin located at:

Who We Are


Initially founded in 2013 in the heart of New York City, Gotham Security is an Abacus Group company that focuses on providing boutique cybersecurity services. Gotham Security delivers high-quality penetration testing, malicious adversary simulation, compliance program development, and threat intelligence services to organizations all across the world, including many Fortune 1000 companies.

© 2023 Gotham Security