Over the past few weeks, the Huntress team has been tracking the recent conversations surrounding supposed ConnectWise Control vulnerabilities and alleged in-the-wild exploitation.
We have been in contact with both the ConnectWise CISO and security team, as well as the security researcher reporting on this. While there has since been some chatter and news articles, we would like to use this article to share our own perspective.
TL;DR: We politely disagree with the threat and criticality presented by the security researcher.
The reason for this writeup is threefold:
Additionally, we’ll share our own insights and what we are seeing for strictly social engineering and phishing attacks against ConnectWise Control.
We’ve got a proven track record of calling for responsible disclosure when there is something that could impact the MSP community at large. With that in mind, we charge not only ourselves, but the community as a whole to hold both security researchers and vendors accountable as we work to improve the security landscape together.
At IT Nation Connect on November 9th, the Huntress team was at our booth chatting with partners on the tradeshow floor, when a community member came up to speak with us expressing they had just been compromised “through ConnectWise Control.”
Hearing this, one of our team members remembered a recent post on LinkedIn suggesting that there was going to be information publicly disclosed on a new ConnectWise Control vulnerability that is being actively exploited in the wild. Our CEO and a small group of Huntress researchers rushed out of the booth, dashed to the nearest quiet corner, got out our laptops and started to investigate. We reached out to the researcher who posted this, set up a phone call, and created an internal Slack channel to communicate with the rest of our team.
We got to work reviewing our past incident reports and tracked activity against ConnectWise Control.
Throughout the last few months, our ThreatOps analysts have been seeing and notifying partners of attacks involving ConnectWise Control. However, these were not implications of DDoS, hijacking, poisoning, injection, botnets, amplification attacks, sideband attacks, remote code execution or any of the other critical-severity threats posed in the researcher’s article.
The most prevalent threat against ConnectWise Control that Huntress as well as the community has seen and shared is social engineering and phishing attempts. These are very common with scams and ploys to lure a victim into calling a phone number, where the adversary will answer and masquerade as a help-desk as a support line for companies like BestBuy or GeekSquad, and encourage the end user to download and run a legitimate Control client.
Huntress reported 14 cases of attacks involving ConnectWise Control, while this increased to 85 in November. Since the beginning of December, we have reported over 60 cases of these “rogue” Control installs.
On this front, Huntress is aware of multiple domains and IP addresses included in phishing attempts involving ConnectWise Control. This list is included at the very end of this writeup and available with this direct gist link.
From our understanding as well as ConnectWise’s assessment, there was a peculiar trick included in the security researcher’s initial report. Prior to the Control 22.8 release, the URL parameters h (host) and p (port) included in downloading a Control client were able to be manipulated to point the connection to another endpoint.
Video demonstration: requesting a URL with modified parameters to point to another ConnectWise Control Server
This means that the URL included within a phishing email may point to a trusted address, like a ConnectWise Control server that the end user recognizes for their own company or organization -- but the downloaded client would direct them to a different Control server altogether.
This weakness might aid in some social engineering and phishing ploys, but it would not be classified as an exploit. The adversary would still need their own ConnectWise Control server under their control to properly receive and respond to the connection request… which provides no advantage from what they would have already started with. Both parties still need to willingly accept and acknowledge the request.
Video demonstration: invoking the ConnectWise Control client pointed to another Control server and starting remote control
ConnectWise Control versions 22.8 and above address the issue of arbitrary h and p parameters and all cloud instances are updated to remediate this, including all available free trials of the software.
When a fellow community member, security researcher or anyone brings security concerns like this to us, we do our own internal analysis but we also coordinate with fellow vendors to validate our findings. Live in the back corner at IT Nation Connect, we spoke face-to-face with the ConnectWise CISO and members of the security team to see the big picture and determine what risk is posed to the security landscape as a whole. It is vital that vendors collaborate on security issues, and make our industry better together.
It is important to note that even generating a new client pointed to a different Control server is still just initiating a connection to another Control server. This is not arbitrary code execution from a signed binary, and does not allow an adversary to run commands or control the target without the user still being deceived under a social engineering ploy.
On the phone with the researcher on November 9th, Huntress came to the conclusion that ultimately this is not a novel technique and poses no new threat to organizations. With that said, we feel that ConnectWise’s decision to express this as a simple advisory and notification was the correct course of action.
Video demonstration: invoking the ConnectWise Control agent, pointed towards an attacker's netcat listener,
showcasing the TCP connection and packets but no arbitrary code execution.
In the following weeks after IT Nation Connect, the researcher expressed on LinkedIn there would be more details to come and their public blog post would soon be released.
On November 29, their public writeup was available and subsequently got the attention of some reporters and journalists. Huntress researchers spoke further with the individual, asking if they could share a video demonstration to more clearly showcase the claimed severity and impact, but they were unwilling to produce one.
The latter blog posts shared by the security researcher attempt to express this as a risk concerning domain names and certificate trusts. Further, the writeups suggest this alleged attack may be chained together with other potential old CVEs & vulnerabilities and devices that might be present within an internal network.
Our hesitation with this approach is that it is not an exploit targeting strictly ConnectWise Control, the core issue is still dependent on social engineering, and the claimed continued threat relies on hypotheticals of whether or not vulnerable devices might be present even inside a target environment.
The core threat posed against ConnectWise Control still remains to be social engineering and phishing -- nothing that could not be done with any other publicly available remote desktop control software like TeamViewer, AnyDesk, or others.
There are repeated claims by the security researcher that this does not require social engineering, but we (alongside other members of the community) contend that it does.
On 01 December, after Brian Krebs reported on this with his own news story, both us at Huntress and ConnectWise had a growing concern that this would stir more fear, uncertainty and doubt within the community. Still with an open mind, willing to better understand this and make sense of the posed claims, we spoke again with the researcher.
One byproduct of generating a new Control client was creating a new executable with a legitimate ConnectWise signed certificate. This led to some claims by the security researcher that it was an undetectable attack, bypassing antivirus and endpoint security controls and gaining remote code execution. However, again, this binary is still a pure ConnectWise Control agent that just reaches out to connect to a ConnectWise Control server.
We asked for more clarification and once again asked if they could provide a technical video demonstration to showcase the process and achieve this desired effect, but the researcher still refused.
With that said, during our communication the security researcher did note another oddity in ConnectWise Control’s behavior. Our team at Huntress pulled this thread a bit further and went down a different path, derivative of the security researcher’s claims but not strictly what they posed in their multiple articles.
Alongside the different pre-update and post-update versions of ConnectWise Control, we also have to consider the different variations of deployment: either an on-premises installation of the server or a cloud instance (accessible in free-trials).
The security researcher did include screenshots of an interesting trick while requesting a new client binary from a Control server: supplying your own modified Host HTTP header. Evident in their provided screenshots, their downloaded executable would attempt to connect to the desired endpoint, but fail to download or retrieve new data.
Video demonstration: modifying the HTTP Host header to download a signed ConnectWise Control installer,
pointing to an arbitrary endpoint to install the software.
This executable looked to be reaching out to fully install the software required for the ConnectWise Control connection, pulled once again from the server.
What we did not see tested in the security researcher's report was staging an endpoint to provide data that the new client binary was expecting to receive. Since we could control this Host header in the request, it is possible to generate a binary that will download and install a provided application from any location.
Video demonstration: inspecting the signed ConnectWise Control installer downloaded via the modified Host header,
observing how it reaches out to the supplied location to install and execute any arbitrary code.
If we could stage an endpoint to serve the same application files that the download would expect, it would install and execute our own provided code. That actually could turn into arbitrary code execution under a signed ConnectWise binary!
To validate this, we reviewed the error logs when the client-download procedure failed, and we could see it attempted to reach out to the provided Hostheader location and download a .application file.
Video demonstration: signed ConnectWise Control installer, modified by HTTP Host Header tampering to download an install separate software other than ConnectWise Control: in this case, a stub for the Windows Calculator application.
This .application file is a ClickOnce application, which is a native component and feature of Windows operating systems (with.NET frameworks version 2.0 or later) that will automatically install and then execute a program hosted from an online website with a single click.
To note, the ClickOnce application could be any C# code we might like. Spawning the calculator application is a fine sample test, but this could just as easily be any malicious payload: starting a reverse shell connection, invoking any other malware, or whatever nefarious activity one might like (still under the thumb of antivirus and other endpoint security controls).
Video demonstration: signed ConnectWise Control installer staged to start a reverse shell connection to the attacker.
The executable downloaded from the Control server is, still, a signed ConnectWise executable. But with this technique, we have the program download and install something else that is not ConnectWise Control!
It is worthwhile to mention that while the starting program will be a legitimate signed executable, the built ClickOnce application will prompt confirmation dialogues that show the installed application may not be signed. Running the downloaded client binary is one process, but the newly installed ClickOnce application will be spawned as its own new process.
Considering this executable does prompt for approval of this new installation, again this technique requires user interaction and ultimately social engineering. This might accomplish the task of running truly arbitrary code underneath a signed ConnectWise binary, but the core tradecraft still relies on human deception.
Additionally, this effort of modifying the Host HTTP header removes the only redeeming trick of the h and p URL parameter scheme. Because this relies on a HTTP header, the delivery can no longer be a simple text link embedded with an email. Granted, an attacker could (1) perform some cross-site scripting techniques to force the end user’s browser to request the URL, (2) stage other HTML and JavaScript code to coerce a drive-by-download of the binary itself, or (3) host or attach the downloaded binary to the email.
Needless to say, all of those stipulations add more complexities and dependencies to this tradecraft, and it may just not be worth it for an adversary in the first place. The necessity of social engineering throughout any of these attack scenarios greatly reduces the risk and criticality -- it all still relies on fooling the victim, and the best defense is security awareness and training.
Ultimately, after pushing this further based off of the security researcher’s claims and executing more than just regular ScreenConnect functionality under the signed binary, we continued to communicate and collaborate with ConnectWise.
When we shared this custom ClickOnce technique with ConnectWise, they were appreciative of us bringing it to their attention. Our conversations together clarified our own understanding of the attack surface, and re-emphasized the importance of security awareness and training for not only end-users, but system administrators just as well.
Team members at ConnectWise explained that, just by the nature of the beast with remote support software (especially offered via both cloud and on-premises environments), there is always a potential risk of social engineering scams. Trust and certification of executable binaries is an interesting discussion point.
The ConnectWise Control client binary that is downloaded is not signed by the on-premises server, as that server application certainly should not ship with the official signing permissions. From what we understand, some configuration information can be included after signing the executable without corrupting the signature. This attached configuration information instructs the client to download the actual ClickOnce application from any external location. Even if the on-premises instance is protected, it is technically possible to take any Control client executable and modify the configuration to have it reach out and download a potentially malicious application without invalidating the code signing.
This is a “necessary evil” in offering the remote desktop application in the freely accessible and available methods that they do. Signing executables but maintaining the ability to be hosted from individual organizations poses a peculiar and difficult problem to solve.
With that said, the Host header tampering technique is ineffective for cloud instances because the frontend service is not the true ConnectWise Control relay server. The Host HTTP header is used within the internal proxy to properly route to the correct cloud instance dedicated to the user’s deployment.
That means that manipulating the Host header in the cloud will not reach a proper endpoint to even download the client binary from.
Video demonstration: requesting a ConnectWise Control installer with modified Host headers fails against cloud instances.
For on-premises installations, it is crucial that the system administrators follow the proper installation procedures and manual, other hardening guides and the provided ConnectWise Control security checklist.
Present in the documentation, users with on-premises installations are recommended to configure their WebServerAddressableUrl and RelayAddressableUrl to prevent the proxying technique we demonstrated above (or define a specific alternate host to be used).
ConnectWise expressed to us that they are working with their education team to get this recommendation added to the best practice guide for Control partners.
To be clear, this response is not intended to point fingers or confront any parties involved. We hope to offer our own perspective, but remain receptive to new information or clarification that helps educate us just as well.
Between buzzword bingo, logical leaps of faith, uncertain hypotheticals and a core component that still presents nothing new or novel, we politely disagree with the proposed severity from the security researcher’s report.
Other community members have engaged in the conversation to better understand and clarify these issues, but there is a recurring message and theme: we all need to be responsible when sounding the alarm.
Without shown work or tangible proof, bold claims and technobabble only puts people into panic. Thousands of MSPs use tools like ConnectWise Control and when someone cries wolf, it undermines our entire industry.
We need to address the FUD and fluff that is all too common. We need to collaborate with others and solve problems, not make them worse. Let’s continue to work together to improve the security landscape.
Get insider access to Huntress tradecraft, killer events, and the freshest blog updates.
