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:
- Offer peace of mind regarding the claimed vulnerabilities in ConnectWise Control
- Demonstrate proper responsible disclosure efforts and partnership between vendors
- Showcase other tradecraft that emphasizes the need for human security awareness, not just for end users but also system administrators and MSP businesses
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.
Our Timeline
- Q4 2022: Huntress observes an uptick in social engineering and phishing attempts against MSPs using Control
- 16 October: ConnectWise receives information from a security researcher suggesting there is a new critical vulnerability in Control that offers an adversary remote code execution
- 17 October: Silent Push offers one of the first advisory articles on malware utilizing ConnectWise Control for phishing and remote access.
- 21 October: ConnectWise publishes stable release of Control version 22.8.10013 with “… additional validation of client installer URL parameters to inhibit certain social engineering attacks”
- 09 November: Huntress attends the ConnectWise IT Nation Connect event
- Huntress researchers are personally notified of online posts claiming there are new major vulnerabilities in ConnectWise Control
- Huntress researchers reach out to the security researcher for clarification and understanding of this supposed security risk
- Huntress researchers meet and discuss with the ConnectWise CISO and security team. Both parties discern this report is not a vulnerability in Control
- Huntress expresses to the security researcher that there does not seem to be a vulnerability or threat of exploitation. The researcher was unwilling to provide a technical demonstration video as a proof-of-concept to showcase the impact
- 10 November: Huntress observes and responds to an r/msp Reddit thread from community members concerned with the recent claims.
- 29 November:
- Security researcher releases their public writeup, “Hijacking Connectwise Control & Screen Connect (v.22.9.10032, MULTIPLE) for Fun and Profit – From DDoS to Multi-OS RCE!”
- ConnectWise publishes an advisory acknowledging the recent uptick in social engineering schemes and phishing attempts utilizing Control
- 01 December:
- Huntress observes and responds to another r/msp Reddit thread alerting the community of continued phishing attempts including ConnectWise Control
- Reporter Brian Krebs publishes a news story on the security researcher’s work.
- 02 December: ConnectWise and Huntress partner together to prepare blog posts in response to the recent news stories and articles that further stir concern about this alleged vulnerability.
- 05 December:
- Security researcher shares another public writeup, “Bypassing Firewall and AV Rules at Scale – Where do old Connectwise Control FQDNs go when they die?”
- Huntress researchers determine separate tradecraft that could be used by an adversary in social engineering or phishing attempts against on-premises ConnectWise Control instances.
- 06 December: Security researcher publishes an additional public writeup, “Proof Of Concept: Connectwise Control Screenconnect Signed Executable to Arbitrary Code Execution via ARP Poisoning / DNS Hijacking / Unsanitized Client Parameters or Host Headers with CVE-2020-3147 (Cisco Sx / SMB Series Switches)”
- 07 December: Huntress researchers meet with ConnectWise CISO and security team in an effort of responsible disclosure to present this social engineering technique and align on joint writeup collaboration.
- 14 December: Huntress releases this response article.
Our Validation
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.
- Say your organization genuinely uses msp123.screenconnect.com for Control
- An end-user might receive an email with a link to the genuine msp123.screenconnect.com
- The URL parameters are modified to point towards attacker789.screenconnect.com
- The threat actor still needs to control attacker789.screenconnect.com to accept the request.
- (The threat actor may as well have just performed typo-squatting and used their own
msp-123.screenconnect.com, added hyphen, in the original phishing lure)
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.
Our Assessment
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.
Our Further Exploration
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.
Our Collaboration
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.
- ConnectWise released Control versions 22.8.10013 and 22.9.10032 to mitigate the URL manipulation reported by the security researcher.
- On all cloud instances and post-update on-premises installations, the social engineering schemes and scams are still very possible, but server redirection by parameters is no longer possible.
- Separate from the security researcher’s information, post-update the Host HTTP header tampering and custom ClickOnce scenario we described above:
- is only possible against on-premises installations of ConnectWise Control.
- is not possible on cloud instances, as the Host HTTP header is used for proxying
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.
Parting Thoughts
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.
Phishing Associated Domains & IPs
Source: https://www.huntress.com/blog/clearing-the-air-overblown-claims-of-vulnerabilities-exploits-severity