It’s been six months since the CVSS 10 ScreenConnect vulnerability (CVE-2024-1709), and now that the dust has settled, it’s a prime opportunity to glean go-forward security insights from lessons learned during the incident.
Below, we’ll walk through five lessons each MSP should review and consider regarding their own security posture.
Lesson 1: Enumeration is deadly
Enumeration is the first phase of an attack – and it’s only logical: you must have a target before you can do anything else. Attackers know this, and as we’ve covered in our webinar and blog about protecting ScreenConnect with a WAF, there are thousands of MSPs with their tools enumerated in IoT scanners like Shodan.
What’s even more mind-boggling is that the number of enumerable ScreenConnect instances has increased since the vulnerability:
Attackers were able to exploit the vulnerability so quickly because they could find targets in seconds (in ~6.5 seconds, Shodan shows 12,252 ScreenConnect instances as of August 2024). Shodan offers cheap API access, and it’s trivial to download the dataset and feed that data into a rudimentary exploit bot.
Unfortunately, this happened to numerous MSPs. They didn’t patch fast enough or had inadequate external security, and they fell victim to basic dumb-bot attacks. However, it is possible to protect MSP tools from enumeration with the proper security layers.
While enumeration was a serious problem, it was only the tip of the iceberg with CVE-2024-1709.
Lesson 2: Exploits can move at light speed
The initial security bulletin was posted on February 19th, and by February 21st, in-the-wild exploits had started.
It took less than 48 hours for the exploits to start, which we believe is the fastest-moving MSP attack in history.
By the 23rd, an exploit module for the ScreenConnect vulnerability had made its way into the Metasploit attack framework (the initial code was written and available by the morning of the 21st). While exploit code was already widely circulating, it’s worth noting that this, too, is likely another MSP record: this vulnerability was commercially exploitable within 96 hours of being announced.
Here at Automation Theory, we call this environment the “zero-day world,” and knowledge of how quickly exploits can move should inform how security is implemented for these critical systems.
Lesson 3: In-application security controls aren’t enough
MSP tool security seems to be predominantly focused on authentication controls. Everything from MFA to conditional access via SSO is touted as best-in-class security. Likewise, in-app IP restriction abilities lulled many MSPs into a false sense of security.
The nature of this attack (an authentication bypass) rendered all the authentication security measures moot (although we definitely recommend implementing robust authentication controls!). This is the fatal flaw in the prevailing “MFA, patch, and pray” security guidance in the industry: code vulnerabilities target the application directly. It doesn’t matter how user authentication is restricted if a request can be sent to a different part of the application that allows for SQL injection or code execution.
In-app IP restrictions typically don’t cover the whole application, and they are implemented at layer 7, so the request still reaches the application. Ultimately, these controls configure the application to defend itself, which can be helpful but isn’t a discrete security layer. Since the underlying application bug was a logical flaw regarding when the setup wizard was accessible, the IP restrictions didn’t work as intended (the application can’t block access to itself until the setup process is done).
In the case of the ScreenConnect vulnerability, the in-app controls wouldn’t have prevented unauthorized access – but IP access controls (or other logical access controls) implemented at a different layer would have been effective. In the physical world, security fences are put around buildings even though they have door locks – and the same lesson should be applied to how MSPs implement security controls.
Lesson 4: Controls must be implemented before the attack
While it might be obvious, security layers only work if they are implemented before they are needed.
With our WAF, we were able to see attacks happening against our client base. In our normal deployment guidance, we recommend switching FQDNs for RMM tools as an anti-enumeration measure. When screenconnect.mspname.com has been around for years, it’s harder to secure compared to updating to access.newdomain.com. We’ve actually seen bad actors perform blanket bot attacks on previously enumerated FQDN lists, so while it may seem trivial (and labor-intensive), fixing FQDN enumeration can be a very effective security control.
Within a week of the ScreenConnect vulnerability, we had real-world metrics to calculate control effectiveness with—and it boiled down to whether our guidance for zero-day resistant architecture was followed. The 88% of our clients who changed FQDNs didn’t receive any attack attempts—lesson 1 held true: you can’t attack what you can’t see.
The other 12% of our clients who brought their own FQDNs did see attacks. At this point, they were no longer in Shodan. Attackers were using historical records of ScreenConnect servers in these attacks (and it wasn’t just by IP – the bad actors had screenconnect.mspname.com on an existing list). All of our clients were patched, but there was a time when these MSPs could have been vulnerable (depending on their other proxy-level access controls).
In the chaos of a critical vulnerability, implementing security controls is quite difficult (even if the technical side is quick, the communication and business process changes can take time). MSPs would be wise to plan for and implement security controls before the next attack happens.
Lesson 5: Your cyber insurance might not cover you
Before we dive in, please note: we are neither insurance brokers nor legal advisors. The content here is for educational purposes only.
Insurance contracts have many definitions to be very granular about what is covered—after all, insurance prices would be astronomical if they paid any claim regardless of the circumstances. However, one term might be problematic for MSPs: widespread event exclusions.
Widespread events (aka systemic risk) are things that impact multiple customers of an insurance agency (like floods or wildfires in non-cyber contexts). Insurance provider Chubb defines it as:
a “systemic” event in the cyber context as one that could inflict widespread harm to many customers due to shared elements or commonalities – often a single point of failure that is exploited. Put simply, it’s a cyber incident that impacts multiple entities in a single act. One example of a systemic event is the exploitation of a vulnerability in a file transfer software utilized by thousands of businesses to deploy malware, exfiltrate data, or cause disruption in business. With so many clients exposed to loss by that single exploit, aggregate losses can be catastrophic.
Chubb
These events are normally excluded from regular insurance coverage (as a way to prevent the insurance company from going bankrupt if all the claims need to be paid out). Coverage for widespread events is often offered as an additional rider package.
Unfortunately, just like lesson 4, this coverage needs to be purchased ahead of time. That means that your technical controls might be the only difference between keeping the doors open or closing in the next zero-day event. Prudent MSPs will take note of this, implement robust controls, and ensure proper insurance coverage.
Applying the lessons
We hope the above lessons are valuable to any MSP wanting to have real conversations about risk and how to protect against it. However, as we’ve seen, action is required – simply talking about risk won’t result in meaningful protection.
Here at Automation Theory, we have a reverse proxy offering that prevents enumeration and offers a multitude of other technical controls that can be dropped in before the application layer. The time to set up such a solution is before the next zero-day, so sign up for your trial today!
