Detection Guidance for ConnectWise CWE-288

UPDATE: Read our full analysis of CVE-2024-1709 & CVE-2024-1708 and detection guidance here.

On February 19, 2024, ConnectWise released an advisory related to the disclosure of two vulnerabilities affecting their ScreenConnect software. This advisory was tagged by ConnectWise with a severity of “Critical” and a priority of “1 - High.”

The Huntress team was able to successfully reproduce and weaponize the vulnerability for CWE-288 Authentication bypass using an alternate path of channel. The POC for this vulnerability was recreated with ease and required minimal technical knowledge and resources. Given this, Huntress immediately released a post on this vulnerability and its potential impact. While Huntress strongly recommends immediately patching any ConnectWise software to version 23.9.8, the following is detection guidance for defense-in-depth.

Upon executing the POC, Huntress examined the [.highlight]User.xml[.highlight] file located in: [.highlight]C:\Program Files (x86)\ScreenConnect\App_Data\[.highlight]. The contents of this file may contain the following:


<?xml version="1.0"?>
<Users xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <User>
  <CreationDate>[IMPACT-TIMESTAMP]</CreationDate>
  <Email>anyemailaddress@theinternet.com</Email>
  <IsApproved>true</IsApproved>
  <IsLockedOut>false</IsLockedOut>
  <LastActivityDate>0001-01-01T00:00:00</LastActivityDate>
  <LastLockoutDate>0001-01-01T00:00:00</LastLockoutDate>
  <LastLoginDate>0001-01-01T00:00:00</LastLoginDate>
  <LastPasswordChangedDate>[IMPACT-TIMESTAMP]</LastPasswordChangedDate>
  <PasswordAttemptWindowStartTime>0001-01-01T00:00:00>/PasswordAttemptWindowStartTime>
  <InvalidPasswordWindowAttemptCount>0</InvalidPasswordWindowAttemptCount>
  <InvalidPasswordAbsoluteAttemptCount>0</InvalidPasswordAbsoluteAttemptCount>
  <Name>Administrator</Name>
  <PasswordHashHistory>
   <base64Binary>[REDACTED-BASE64]</base64Binary>
  </PasswordHashHistory>
  <Roles>
   <string>Control Administrator</string>
  </Roles>
 </User>
</Users>

Note that the [.highlight]0001-01-01T00:00:00[.highlight] timestamps indicate that there is no sane value yet. When a new user is just created, it does not yet have a [.highlight]LastLoginDate[.highlight] or [.highlight]LastActivityDate[.highlight].

To be clear, this [.highlight]User.xml[.highlight] file will be modified any time any user performs any activity. This was verified via Process Monitor that this [.highlight]User.xml[.highlight] file was overwritten after each successful attempt. This makes definitive identification of exploitation difficult, but unfortunately from our investigation, we found limited options for logging and forensic artifacts on a ScreenConnect server. If the newly created user were to log in, the timestamps would, of course, be updated. If the timestamps are not nulled, then this would indicate that the user has actually logged into the instance recently.

*Figure 1: Procmon activity during exploitation*

It’s important to note that the [.highlight]<random_value>.xml[.highlight] file in [.highlight]C:\Windows\Temp\ScreenConnect\23.9.7.8804\[.highlight] is created on disk, but immediately removed. The GUID in the file name appears to be unique for each instance. These files are recoverable via disk forensics, however, which can help you recover previous attacker activities.

By configuring a host’s Advanced Auditing policy to log a successful Windows Event ID 4663 event and with a SACL set on the directory, we can see when the file is being modified.

*Figure 2: SACL Setting on* ***C:\Windows\Temp\ScreenConnect\23.9.7.8804\***

*Figure 3: Security Event ID 4663 During ScreenConnect Exploit*

This event can be forwarded to a SIEM, and with the contents of the [.highlight]User.xml[.highlight] file itself, we have a greater level of context to examine if an attack has occurred.

The aforementioned artifacts may be reviewed for DFIR/threat hunting purposes if an attacker has leveraged this exploit against a target system to see if an account was created outside of normal operating procedures. However, the artifacts alone may not be enough for a definitive indication or provide enough context for analysis and triage to indicate that the exploit was leveraged.

In addition to the artifacts mentioned in this blog, we also observed evidence of exploit execution within the IIS logs. We will forgo demonstrating the contents of these IIS log entries for now, until we’ve seen exploitation in the wild since doing so would tip our hand to the attackers.

Happy Hunting!

‍Stay tuned for more details as this unfolds.

‍Special thanks to John Hammond, Caleb Stewart, Dave Kleinatland, Andrew Schwartz, Jason Phelps, Jai Minton, Tim Kasper, Andrew Kaiser, Jason Slagle, Jamie Levy, and many others for their contributions to this write-up.

‍