SimpleHelp + DragonForce: When Your MSP's Remote Tool Becomes the Ransomware Vector

On April 24, CISA added CVE-2024-57726 and CVE-2024-57728 to the Known Exploited Vulnerabilities catalog. The patching deadline for federal civilian agencies is May 4. Both CVEs affect SimpleHelp, a remote support and remote monitoring and management (RMM) tool that is widely deployed inside the managed service providers (MSPs) that small and midmarket businesses rely on for IT.

If your organization outsources IT to an MSP, your attack surface includes their remote support stack — even though you have probably never logged into it, never patched it, and never seen it on a vulnerability scan. The DragonForce ransomware operation has been weaponizing these exact bugs against MSP customers since at least May 2025. The KEV listing is a reminder that the campaign has not stopped.

This post explains the exploit chain, what the MSP supply-chain attack actually looks like from the customer side, and the questions every SMB should be asking their MSP this week.

The vulnerability chain

SimpleHelp is a Java-based remote support platform. Technicians use it to take control of customer endpoints, push software, and manage helpdesk sessions. Many MSPs use it as their primary delivery vehicle for everything from antivirus updates to scheduled maintenance scripts. The platform was last unpatched in early 2025; the relevant fixed versions are SimpleHelp 5.3.9, 5.4.10, and 5.5.8.

Three CVEs disclosed together in January 2025 enable a complete unauthenticated-to-RCE chain on any vulnerable server:

• CVE-2024-57727 (path traversal): An unauthenticated attacker sends a crafted HTTP request and downloads serverconfig.xml from the SimpleHelp host. That file contains hashed credentials and reversible secrets.
• CVE-2024-57726 (privilege escalation, CVSS 9.9): A low-privileged technician account — or an attacker who cracked credentials from the leaked config file — can create API keys with excessive permissions and escalate to server admin.
• CVE-2024-57728 (arbitrary file upload, zip slip): An admin account uploads a crafted ZIP archive that escapes its intended path and writes arbitrary files anywhere on the host. That gives the attacker code execution as the SimpleHelp server user, which on most deployments is a local administrator or root.

Chained together, the result is unauthenticated remote code execution on the SimpleHelp server. CISA's April 24 KEV listing names CVE-2024-57726 and CVE-2024-57728 specifically, but treat all three as one bug. The chain breaks if any single CVE is patched, which is why upgrading to a fixed version solves the entire problem.

Why this is an MSP-shaped problem, not a SimpleHelp-shaped problem

The DragonForce attack pattern, as documented by Sophos in May 2025 and continuing into 2026, looks like this:

1. Attacker scans the internet for SimpleHelp servers below 5.5.8. These servers are easy to find — the SimpleHelp web interface has a recognizable banner.
2. Attacker uses the CVE chain to gain RCE on the MSP's SimpleHelp server.
3. Attacker uses the legitimate SimpleHelp client deployment mechanism to push installers to every endpoint the MSP manages — across every customer.
4. Once the attacker has SimpleHelp agents installed on customer endpoints, they execute commands through the legitimate RMM channel: reconnaissance, credential collection, lateral movement, and finally ransomware deployment.
5. Data exfiltration runs in parallel for double extortion. The MSP's customers see ransomware notes and stolen data leak threats; some customers see encryption blocked at the endpoint by EDR; others lose everything.

The Sophos investigation that originally documented this campaign noted that one of the affected MSP's customers had Sophos MDR deployed and managed to block the encryption. The other downstream customers — those without independent endpoint protection or detection — were ransomed. The attacker spent zero time exploiting any of the customer environments directly. They walked in through the MSP's tools, which the customers had implicitly trusted by virtue of paying for managed IT.

This is the model SMBs need to internalize. When you outsource IT to an MSP, you inherit the security posture of their administrative tools. If their SimpleHelp, ConnectWise ScreenConnect, Kaseya, NinjaOne, or Atera instance is unpatched and internet-facing, that is your unpatched and internet-facing administrative tool, even if you have never seen its login page.

The detection signature

For organizations whose MSP uses SimpleHelp, two indicators are worth flagging to your endpoint protection or SOC partner.

Unexpected SimpleHelp installer activity. Sophos's published indicator was a pushed installer at C:\ProgramData\JWrapper-Remote Access\JWAppsSharedConfig\working\toolbox-9759076704687761247win.exe. The DragonForce binary's SHA256 from that incident is cee6a7663fad90c807c9f5ea8f689afd0e4ece04f8c55d7a047a7215db6be210. Any new SimpleHelp-pushed payload that is not on a known-good list — application installers, MSI packages, scripts — should generate a high-priority alert.

SimpleHelp connections from unexpected addresses. Your MSP's SimpleHelp server should connect from a defined set of source addresses. If your endpoints are receiving SimpleHelp commands from a brand-new public IP, especially one geolocated outside the MSP's known operations region, treat it as a potential takeover.

A quick PowerShell check on Windows endpoints under MSP management:

# Find SimpleHelp clients and their working configs
Get-ChildItem -Path "C:\ProgramData\JWrapper-Remote Access\" -Recurse `
    -Include *.exe,*.cfg -ErrorAction SilentlyContinue |
    Select-Object FullName, LastWriteTime, Length |
    Sort-Object LastWriteTime -Descending |
    Select-Object -First 20

# Look at recent SimpleHelp installer drops
Get-ChildItem -Path "C:\ProgramData\JWrapper-Remote Access\JWAppsSharedConfig\working\" `
    -ErrorAction SilentlyContinue |
    Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-30) }

If the most recent files include executables you cannot account for through normal MSP operations, that is a finding. Forward to incident response immediately and do not call the MSP through SimpleHelp — use a known-good phone number or out-of-band channel, because the attacker may have observability into the MSP's helpdesk if they still have RMM access.

The five questions every SMB should ask their MSP this week

Whether or not your MSP uses SimpleHelp specifically, the broader pattern — RMM tool exploitation as a supply chain attack — applies to every remote support platform on the market. Send your MSP the following five questions over email this week and ask for written responses. The quality of the answers tells you most of what you need to know about their security maturity.

1. What RMM and remote support tools do you use to manage our endpoints, and what versions are they on right now? Acceptable answer: a specific product name and a specific version number, with a recency stamp. "We always run the latest version" is not an answer.
2. Is your management server internet-facing? If yes, what protections are in place — IP allow-listing, MFA, geo-blocking — and how are they monitored? A management server that is open to the entire internet without IP allow-listing is the same risk profile as the MSP that got ransomwared in the Sophos report.
3. How do you detect anomalous activity on your RMM platform, and what is your response time for an alert? The right answer involves a SIEM or MDR platform, defined alert thresholds, and a documented response-time SLA. "Our techs would notice" is not a control.
4. If your RMM platform were compromised tomorrow, what is your customer-notification SLA, and where is that documented in our contract? Many SMB MSP contracts have no breach-notification clause covering MSP-side incidents. If yours does not, that is a contractual gap to close before the next renewal.
5. What endpoint protection do you deploy by default on our endpoints, and is it independent of your RMM tool? The most important word is "independent." If your endpoint protection is managed through the same platform that the attacker takes over, the attacker disables it before deploying ransomware. The Sophos customer who survived the original DragonForce incident survived specifically because their EDR was independent of the compromised RMM.

If your MSP cannot answer these questions in writing within a week, that is a finding. If they answer them but the answers do not include version numbers, monitoring details, and contractual notification commitments, that is also a finding. Mature MSPs have these answers ready. They have heard these questions before from larger customers and from cyber insurance underwriters.

What to do on your own infrastructure

Most SMBs are not running their own SimpleHelp server. If you are, the response is simple: upgrade to 5.5.8, 5.4.10, or 5.3.9 today. Rotate any technician credentials. Pull serverconfig.xml off the host and review it for what may have been exposed during the window the host was vulnerable.

For the broader category — any remote support, remote access, or RMM platform you operate yourself — three controls are worth closing on this quarter:

• Get the management plane off the public internet. Put it behind a VPN or a strict allow-list. The remote-control session itself can be internet-reachable if your architecture requires it; the admin console almost never needs to be.
• Require MFA for every technician account, including service accounts where the platform supports it. Most RMM compromises that turn into ransomware operations start with a single technician password reused on a credential-stuffed list.
• Deploy independent endpoint detection. Your remote management tool should not be the only thing watching your endpoints. EDR managed through a separate channel — ideally a separate vendor — is the control that survives an RMM compromise.

The bigger lesson for SMB risk modeling

SMB threat models almost always center the company's own perimeter: its email, its VPN, its identity provider. The MSP supply chain is rarely modeled at all, even though for most midmarket organizations the MSP is the largest single concentration of administrative privilege in the environment. A successful attack on your MSP's RMM is functionally indistinguishable from a successful attack on your domain admin account.

The DragonForce campaign is one of several active operations that have learned this. ConnectWise ScreenConnect was hit by AuthBypass exploitation in early 2024. Kaseya was the canonical example back in 2021. The pattern is not new, and it is not slowing down. CISA's April 24 KEV listing is a useful forcing function for the conversation, but the underlying issue — that your MSP's tooling is part of your attack surface — does not depend on this week's CVE.

The SMBs that handle this well are the ones whose security and IT functions are not the same function. The MSP delivers IT. An independent advisor evaluates the risk that the MSP introduces. Those two roles need different incentives, and they need to be staffed by different organizations.