Attackers abused a blank access key in an RMM+ extension to push malware through ScreenConnect

A threat actor used cloud-hosted ConnectWise ScreenConnect panels to run commands on managed endpoints, and the way in went through a third-party extension rather than ScreenConnect itself. Huntress, which reported the campaign, says the attacks were observed on November 11 and that at least 6 MSPs and 288 hosts across 48 organizations were compromised. All 288 hosts were hit within 90 minutes.

What happened

The commands pushed rogue ScreenConnect clients and a toolkit Huntress calls SCKit. According to the report, SCKit gives persistent backdoor access, intercepts session cookies and can copy itself. It starts on a ScreenConnect panel, then waits for a technician to connect to the compromised endpoint. When that happens it infects the technician's workstation, tries to reach other sessions that technician can access, and spreads to other panels.

Huntress is careful about how much of that has actually been seen. Some of the toolkit's functions were observed in incidents; others were worked out by analysing the payloads. That distinction matters if you're scoping exposure, because a capability described from code isn't the same as a capability confirmed in the field.

The mechanism

The entry point was RMM+, a third-party extension for managing ScreenConnect sessions that uses a shared access key. Huntress says the attackers likely exploited a flaw in versions 1.0.31 and 1.0.32, where the access key defaults to blank if nobody configured one. An empty value then passes the check.

The tell in the logs is the absence of one. Commands reached endpoints within minutes, but there was no corresponding login activity, and the reviewed logs pointed at RMM+ instead. That's the shape of an authentication bypass: work gets done under an identity that never authenticated.

Huntress also notes that most RMM+ installations it encountered were legitimate, usually added for a project and left in place. That's the ordinary way extensions end up on a box, and it's why the flaw had reach.

ConnectWise's response was to disable five extensions from the RMM+ family across approximately 400 ScreenConnect environments: Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link, and RMM+ Password Link. The company pushed back on reading that as a victim count. In its words, presence alone does not establish compromise, and the extensions provide an API for remote commands that is protected by a passphrase the partner sets during setup. Both readings can be true at once: a disabled extension is a precaution, not a finding.

HackZoneLabs assessment

The interesting part of this campaign isn't ScreenConnect. It's the extension sitting next to it, holding an API that runs commands, with an authentication check that fails open when a setting is left alone. In our view, that's the pattern worth taking from this: the trust boundary moved to a component the vendor didn't write, and nobody's patch cycle covered it. ConnectWise could disable the extensions centrally because they were cloud-hosted. On-premises deployments don't get that help, which is why both Huntress and ConnectWise point at disabling the extensions there.

We'd also treat the 400 figure with some care. It's a count of environments where extensions were switched off, not a count of compromised customers, and the two numbers will get conflated in retellings. The 288 hosts and 48 organizations come from Huntress's investigation and are the figures to work from.

The speed is the other thing. Ninety minutes to touch 288 hosts across dozens of customers is what a management tool is supposed to do. The same reach that makes an RMM useful makes it a delivery mechanism once someone gets command execution inside it.

What remains unknown

The source doesn't name the threat actor or say what the malware did on endpoints beyond the described capabilities. It doesn't say whether data was taken, or how the attackers first got access to the cloud-hosted panels in order to run commands through them. It also doesn't say how many on-premises deployments still have the extensions installed, or whether a fixed version of RMM+ exists. Nobody has published a full technical write-up in what we've seen.

What to check first

• On-premises ScreenConnect deployments: look for the five RMM+ family extensions and disable them, as both Huntress and ConnectWise recommend.
• If RMM+ was installed, check whether an access key was ever configured. A blank key is the condition the flaw needs.
• Hunt for command execution on endpoints with no matching login, and for log entries attributed to RMM+ rather than ScreenConnect.
• Work through the IoCs both companies published, including rogue ScreenConnect clients and SCKit artefacts.
• Treat technician workstations as in scope. The toolkit's described behaviour targets the person connecting, not just the endpoint they connect to.