SlashAndGrab: The ScreenConnect Flaw Ransomware Gangs Love

CISA formally added CVE-2024-1708 (the path traversal component) to its Known Exploited Vulnerabilities (KEV) catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2024-1708) on April 28, 2026, following a high-tempo wave of Medusa ransomware operations attributed to the threat actor tracked as Storm-1175 (also known as Octo Tempest) that specifically leveraged this vulnerability chain as a primary initial access vector, according to a Microsoft Security Blog post published April 6, 2026 (https://www.microsoft.com/en-us/security/blog/2026/04/06/storm-1175-focuses-gaze-on-vulnerable-web-facing-assets-in-high-tempo-medusa-ransomware-operations/). The vulnerability's older companion, CVE-2024-1709, had already been in the KEV catalog, marking both flaws as federally mandated patching priorities for U.S. government agencies.

Understanding the Vulnerability

To understand why this vulnerability is so dangerous, it helps to understand what ScreenConnect's setup wizard is supposed to do — and why it should never be accessible on an already-configured system.

When ScreenConnect is first installed, it presents administrators with a setup wizard at the URL path /SetupWizard.aspx. This wizard allows the administrator to create the first administrative account on the system. Once the system is configured, this wizard is supposed to be locked away — inaccessible to anyone, because allowing unauthenticated users to run the setup wizard on an already-configured system is functionally equivalent to leaving a "create new superuser" form open on the public internet.

The problem, as researchers at Huntress Security discovered and documented (https://www.huntress.com/blog/a-catastrophe-for-control-understanding-the-screenconnect-authentication-bypass), is that the authentication check protecting that wizard was embarrassingly fragile.

The Root Cause: A Single Slash in .NET

The authentication check in vulnerable versions of ScreenConnect (ScreenConnect.Web.dll, specifically the SetupModule/ISetupHandler components) worked like this: it checked whether the incoming request URL string exactly matched /SetupWizard.aspx. If it did, and the system was already configured, access was denied.

But ASP.NET — the Microsoft web framework ScreenConnect is built on — has a feature called Request.PathInfo. When a URL like /SetupWizard.aspx/anything is received, ASP.NET splits this into two parts:

• Request.Path → /SetupWizard.aspx
• Request.PathInfo → /anything

The vulnerable authentication code was checking the full URL string, which now reads /SetupWizard.aspx/anything and no longer exactly matches /SetupWizard.aspx. The check fails to recognize this as the setup wizard, so it waves the request through. But ASP.NET still routes the request to the setup wizard handler — because as far as the routing engine is concerned, SetupWizard.aspx is still the target page, just with some extra path info appended.

The result: any unauthenticated attacker on the internet can access the fully functional setup wizard of any already-configured, publicly exposed ScreenConnect instance simply by appending a slash and any arbitrary text to the URL.

That is the entire exploit for the authentication bypass. One HTTP request. No credentials. No special tooling. No exploitation framework. Just a URL with a trailing slash and some garbage text.

CVE-2024-1708: The ZipSlip That Seals the Deal

The authentication bypass (CVE-2024-1709, CVSS 10.0) is devastating on its own, but it is almost always chained with a second flaw: CVE-2024-1708, a path traversal vulnerability (CWE-22) with a CVSS score of 8.4, which is the subject of this KEV addition.

ScreenConnect supports extensions — essentially plugins that administrators can install to extend the platform's functionality. These extensions are delivered as ZIP archives. In vulnerable versions, the code that handles extracting these ZIP archives fails to properly validate the file paths contained within the archive. This is a well-known class of vulnerability called ZipSlip: an attacker crafts a malicious ZIP file in which internal file entries contain path traversal sequences (e.g., ../../) that, when extracted, cause files to be written outside the intended target directory.

In this specific case, the intended extraction directory is a sandboxed subdirectory within C:\Program Files (x86)\ScreenConnect\App_Extensions\[extension-id]\. But a maliciously crafted extension archive can break out of that subdirectory and write files directly to the root of C:\Program Files (x86)\ScreenConnect\App_Extensions\.

Why does that matter? Because files placed in the App_Extensions root — particularly .aspx or .ashx web-accessible script files — are served and executed by the ScreenConnect web server with SYSTEM-level privileges. An attacker who writes a web shell to that location can then send HTTP requests to it and receive arbitrary command execution as the most privileged account on the Windows operating system.

The Complete Attack Chain

Putting both vulnerabilities together produces a seamless, end-to-end attack chain that takes a threat actor from zero access to full SYSTEM-level control with no credentials, no user interaction, and trivial technical skill:

Step 1 — Reconnaissance: The attacker scans the internet for publicly exposed ConnectWise ScreenConnect instances running version 23.9.7 or earlier. Shodan, Censys, and similar tools make this trivially easy at scale.

Step 2 — Authentication Bypass (CVE-2024-1709): The attacker sends an HTTP GET or POST request to /SetupWizard.aspx/[any arbitrary string]. This bypasses the authentication check and presents the attacker with the fully functional setup wizard.

Step 3 — Rogue Administrator Creation: Using the setup wizard interface, the attacker creates a new administrative user account. This action completely overwrites the ScreenConnect internal user database, instantly deleting every legitimate local administrator account on the system. Legitimate administrators are locked out of their own infrastructure in the same moment the attacker gains access to it.

Step 4 — Administrative Login: The attacker logs into the ScreenConnect management interface using the freshly created rogue administrative account.

Step 5 — Malicious Extension Upload (CVE-2024-1708 / ZipSlip): The attacker crafts a malicious ScreenConnect extension ZIP archive containing a web shell (e.g., an .aspx or .ashx file) with path traversal sequences in the archive's internal file paths. They upload this via the legitimate Extensions Management feature, now accessible with admin credentials.

Step 6 — Path Traversal File Write: Instead of extracting to the sandboxed extension subdirectory, the ZipSlip vulnerability causes the web shell to be written to the root of C:\Program Files (x86)\ScreenConnect\App_Extensions\, where it is directly web-accessible.

Step 7 — Remote Code Execution as SYSTEM: The attacker sends HTTP requests to the newly planted web shell. The ScreenConnect web server executes the embedded .NET code with SYSTEM privileges, completing the escalation from zero access to full operating system control.

Step 8 — Persistence, Lateral Movement, and Ransomware Deployment: With SYSTEM-level access to the ScreenConnect server and its RMM capabilities, the attacker establishes persistent backdoors, pivots to downstream client endpoints, exfiltrates data, and deploys ransomware payloads across the entire managed client base.

The Affected Components

According to analysis by Huntress and ConnectWise's own advisory, the following specific software components are affected:

• ScreenConnect.Web.dll (specifically the SetupModule / ISetupHandler event handler registration — the home of the flawed authentication check)
• SetupWizard.aspx (the setup page that should be inaccessible on configured instances)
• ScreenConnect.Core.dll
• ScreenConnect.Server.dll
• The Extensions Management Feature (the attack surface for the ZipSlip path traversal)
• ScreenConnect Web Server Service
• ScreenConnect Security Manager Service

Who Is Affected

Critical clarification: These vulnerabilities affect only the ScreenConnect server software — the central management application. ScreenConnect client agents installed on end-user machines are not directly vulnerable to these flaws and do not require updates to prevent exploitation of the server. However, that distinction offers cold comfort: an attacker who owns the server owns every endpoint those clients connect to.

ConnectWise cloud-hosted instances (those running on screenconnect.com or hostedrmm.com domains) were automatically mitigated server-side by ConnectWise within 48 hours of vulnerability validation, with no action required from administrators. Subsequent upgrades to version 23.9.8 on cloud infrastructure were also fully automated. The acute risk here falls entirely on self-hosted, on-premises ScreenConnect deployments — a significant portion of the MSP market.

Real-World Risk

Confirmed Active Exploitation

This is not a theoretical vulnerability. Exploitation in the wild was confirmed by ConnectWise's own Incident Response team and corroborated by CISA's addition of CVE-2024-1709 to the KEV catalog. According to Huntress, the first observed exploitation occurred on February 14, 2024 — one day after the vendor was notified and five days before public disclosure or a patch was available. This suggests threat actors may have independently discovered the vulnerability or had early access to vulnerability details through channels that remain unclear.

Known indicators of compromise tied to early exploitation campaigns include the following IP addresses, confirmed as attacker infrastructure by ConnectWise incident response:

• 155.133.5.15
• 155.133.5.14
• 118.69.65.60

Storm-1175 and the Medusa Ransomware Connection

Perhaps most alarming is the threat actor profile now associated with this vulnerability chain. According to a Microsoft Security Blog published April 6, 2026 (https://www.microsoft.com/en-us/security/blog/2026/04/06/storm-1175-focuses-gaze-on-vulnerable-web-facing-assets-in-high-tempo-medusa-ransomware-operations/), the threat actor Storm-1175 — also tracked in the industry as Octo Tempest, a sophisticated, financially motivated group known for high-impact extortion operations — has been actively leveraging the CVE-2024-1709/CVE-2024-1708 vulnerability chain as a primary initial access vector in high-tempo Medusa Ransomware-as-a-Service (RaaS) operations.

Medusa is a prolific ransomware operation that operates under a RaaS model, recruiting affiliates to conduct intrusions while the core group provides the ransomware tooling and manages victim negotiations. Storm-1175's use of ScreenConnect as an entry point is tactically shrewd: by compromising a single MSP's ScreenConnect server, an affiliate can potentially deploy ransomware across dozens or hundreds of that MSP's client organizations in a single coordinated operation — maximizing damage while minimizing the number of intrusions needed to achieve massive scale.

This attack vector — compromising MSP tooling to reach downstream clients — has become a signature tactic for ransomware operations targeting the managed services sector, reminiscent of the Kaseya VSA attack in 2021. The SlashAndGrab vulnerability lowers the bar for executing this style of attack to essentially zero technical skill.

Worst-Case Scenario

A successful exploitation of CVE-2024-1709 chained with CVE-2024-1708 against a managed service provider's ScreenConnect instance produces a catastrophic cascade:

1. Immediate administrative lockout — All legitimate local administrator accounts are deleted the moment the attacker creates their rogue admin via the setup wizard. The MSP loses access to their own management console.
2. SYSTEM-level code execution — The attacker gains the highest possible privilege level on the ScreenConnect server, enabling installation of persistent backdoors, credential harvesting tools, and additional malware.
3. Full visibility into the managed environment — The attacker can see and interact with every client endpoint the MSP manages through the ScreenConnect console, including browsing files, executing commands, and intercepting remote sessions.
4. Mass ransomware deployment — Using the RMM capabilities of ScreenConnect itself — the very tool built to push software and commands to client machines — the attacker can deploy ransomware payloads simultaneously to hundreds or thousands of downstream client endpoints.
5. Data exfiltration at scale — Credentials, proprietary data, client confidential information, and network architecture details are all exposed across the entire managed client base.
6. Reputational and legal devastation — For an MSP, a breach of this nature is not just a technical incident. It is an existential business event, exposing the company to breach notification obligations, client lawsuits, and potentially catastrophic reputational damage.

The CVSS 10.0 score on CVE-2024-1709 — the maximum possible rating — reflects all of this: network-accessible, no authentication required, no user interaction required, and a changed scope affecting resources beyond the vulnerable component itself (all managed client endpoints).

What You Should Do

If your organization operates a self-hosted ConnectWise ScreenConnect instance, the following actions are not optional. They are urgent.

1. Identify All Vulnerable Deployments Immediately

Conduct an immediate audit of all self-hosted ScreenConnect installations across your environment. Version information is visible in the ScreenConnect administrative console. Any instance running version 23.9.7 or earlier is vulnerable and must be treated as potentially compromised until proven otherwise.

2. Patch — But Follow the Correct Upgrade Path

Upgrade all vulnerable on-premises instances to version 23.9.8 or later. ConnectWise has also released version 23.9.10 as a subsequent update.

Critical warning: ScreenConnect upgrades must follow specific sequential version progression paths. Attempting to jump directly from a very old version to 23.9.8 without following the required path may fail. ConnectWise documents the mandatory upgrade sequence as:

2.1 → 2.5 → 3.1 → 4.4 → 5.4 → 19.2 → 22.8 → 23.3 → 23.9.8+

Skipping steps in this sequence can result in a failed upgrade, leaving the system vulnerable.

For off-maintenance partners (organizations whose ScreenConnect support contracts have lapsed and who cannot access the latest versions): ConnectWise has temporarily removed license restrictions to allow all partners to install the interim patched version 22.4.20001 at no charge. This patch is available at the ConnectWise ScreenConnect community forums (https://screenconnect.product.connectwise.com/communities/26/topics/3980-connectwise-control-224).

If you encounter license errors during the upgrade process, ConnectWise has documented the following workaround:

1. Stop all four ScreenConnect services: Session Manager, Security Manager, Web Server, and Relay.
2. Move the file C:\Program Files (x86)\ScreenConnect\App_Data\License.xml to your Desktop.
3. Proceed with the upgrade installation.
4. After the upgrade completes successfully, move License.xml back to C:\Program Files (x86)\ScreenConnect\App_Data\.
5. Restart ScreenConnect services.

Note that this workaround requires a brief service interruption.

3. Before Bringing Patched Systems Back Online: Hunt for Compromise

Patching a potentially compromised system without first investigating for attacker presence is dangerous — you may patch the vulnerability while leaving a backdoor in place. Before returning any patched ScreenConnect server to production, perform the following checks:

Check the administrative user database:

• Log into the ScreenConnect admin console and review the full list of internal user accounts.
• Look for any unknown, unexpected, or newly created administrative accounts.
• If all legitimate administrator accounts appear to have been deleted and replaced with unknown ones, treat the system as fully compromised.

Inspect the App_Extensions directory for web shells:

• Navigate to C:\Program Files (x86)\ScreenConnect\App_Extensions\.
• Look for any .aspx or .ashx files located directly in the root of this directory (not within named extension subdirectories). These files should not be there under normal circumstances and are a high-confidence indicator of web shell deployment via the ZipSlip path traversal.

Review IIS access logs for exploitation attempts:

• Search web server logs for any HTTP requests to SetupWizard.aspx that contain trailing path segments (e.g., SetupWizard.aspx/ followed by any text).
• On an already-configured, production ScreenConnect instance, any request to SetupWizard.aspx is inherently suspicious. Legitimate administrators have no reason to access the setup wizard after initial configuration.
• Detection rule (Sigma/YARA concept): Monitor IIS logs for HTTP requests matching the pattern SetupWizard.aspx/* (where * is any trailing string).

Check Windows Event Logs for user creation activity:

• Enable and review Windows Advanced Auditing logs (Event ID 4663) for evidence of the ScreenConnect server process writing to a temporary XML file — this is the mechanism by which the setup wizard creates the new user database and is a behavioral indicator of exploitation.

Check for suspicious file modifications in App_Extensions:

• Sigma rule concept: Detect any file creation or modification events at the root of C:\Program Files (x86)\ScreenConnect\App_Extensions\ that do not correspond to known, legitimate extension installations.

Hunt for known attacker IP addresses in network logs:

• Block and alert on connections to or from the following confirmed attacker infrastructure IPs:

Review with EDR tooling:

• Use your Endpoint Detection and Response (EDR) platform to hunt for suspicious process execution originating from the ScreenConnect server process (e.g., ScreenConnect.Service.exe spawning cmd.exe, powershell.exe, or other unexpected child processes).
• Microsoft Defender for Cloud generates alerts for suspicious process execution spawned from the ScreenConnect server process — review these alerts if available.

4. If Compromise Is Confirmed or Suspected

• Immediately isolate the affected ScreenConnect server from the network to prevent lateral movement.
• Do not simply patch and reconnect — a compromised system must be forensically examined before being returned to service.
• Preserve evidence: Take disk images and memory captures before remediation to support forensic analysis.
• Engage specialized incident response: ConnectWise has published a ScreenConnect Remediation and Hardening Guide in partnership with Mandiant — follow this guide in conjunction with professional incident response resources.
• Notify downstream clients: If your ScreenConnect instance managed client endpoints and you suspect compromise, those clients must be informed and their environments investigated for lateral movement and ransomware staging activity.

5. For Cloud-Hosted ScreenConnect Instances

If your ScreenConnect deployment is hosted on ConnectWise's cloud infrastructure (domains ending in screenconnect.com or hostedrmm.com), ConnectWise automatically applied server-side mitigations within 48 hours of validating the vulnerability, with no action required on your part. Subsequent version upgrades to 23.9.8 on cloud infrastructure were also handled automatically. However, it is still advisable to review administrative user accounts and extension directories as a precautionary measure.

The Bigger Picture

The SlashAndGrab vulnerability is, in many ways, a perfect storm of bad outcomes converging: a maximally severe flaw, in maximally consequential software, exploited at maximum speed by sophisticated ransomware operators. But beyond the immediate crisis, this incident illuminates several structural problems in the managed services and RMM ecosystem that deserve sustained attention.

RMM tools are ransomware's favorite highway. The same capabilities that make platforms like ScreenConnect invaluable to MSPs — centralized access to hundreds of client endpoints, the ability to push software and execute commands at scale — make them catastrophically attractive targets for ransomware affiliates. A single compromised RMM server is worth more to an attacker than hundreds of individually compromised workstations. The security community has been raising this concern for years. SlashAndGrab is the latest, most visceral demonstration of why it matters.

Authentication mechanisms deserve more scrutiny than they receive. The root cause of CVE-2024-1709 — a string comparison check that failed to account for ASP.NET's Request.PathInfo behavior — is the kind of subtle, easy-to-miss flaw that can survive years of code review. It is a reminder that security-critical access control logic requires adversarial testing, not just functional testing. "Does the check work when I access the wizard normally?" is a fundamentally different question than "Are there any ways to access the wizard that circumvent this check?"

The ZipSlip class of vulnerabilities remains widespread and underappreciated. CVE-2024-1708's path traversal mechanism — using crafted ZIP archive entries to write files outside the intended extraction directory — is a vulnerability class with a long history and continued prevalence across many software platforms. Any application that extracts ZIP files should be on the ZipSlip watchlist.

Patch velocity matters enormously. The window between vulnerability validation (February 13) and the first confirmed exploitation (February 14) in this case was essentially zero. Organizations operating on patch cycles measured in weeks or months are fundamentally outpaced by modern threat actors. For internet-exposed, critical-infrastructure-adjacent tools like RMM platforms, patch timelines must be measured in hours, not days.

For administrators who have not yet acted: the time to patch is not when your incident response firm is on the phone. It is right now. And for those in the security community building the next generation of RMM tools: this is a blueprint for what a catastrophic RMM vulnerability looks like. Study it carefully.