ScreenConnect attacks on MSPs: what to check today

Short read

This post covers the ScreenConnect attacks that hit managed service providers (MSPs) on 11 November 2026, in which attackers used access to ScreenConnect panels to install rogue remote-access clients and a toolkit called SCKit on hundreds of customer devices.

You'll learn what happened, why a third-party extension appears to be at the centre of it, and what to check today, whether you're an MSP using ScreenConnect or a business whose IT provider does.

The ScreenConnect attacks reported this week show how quickly a remote support tool can turn into a way into dozens of businesses at once. ScreenConnect is a remote access and support platform from ConnectWise, widely used by MSPs and internal IT teams to look after customer devices. On 11 November 2026, attackers used access to cloud-hosted ScreenConnect panels to push commands to groups of managed endpoints, installing their own ScreenConnect clients and a malicious toolkit. If your business uses ScreenConnect, or your IT provider does, this is worth an hour of your time today.

What happened

Huntress says it saw suspicious activity begin at about 17:47 UTC on 11 November across endpoints linked to several ScreenConnect environments. Over 90 minutes, at least 288 managed endpoints across 48 organisations were affected, about a third of them in the first ten minutes. BleepingComputer reports that Huntress had identified six compromised MSPs, and that the number of victims was still rising.

The attackers used the panel's Run Command feature to send commands, running as SYSTEM, to many endpoints in one go. Those commands:

• checked for an existing ScreenConnect client
• silently installed an attacker-controlled ScreenConnect client
• downloaded SCKit, a package of 16 scripts and files that sets up persistent remote access
• added exclusions to Microsoft Defender and stopped the legitimate ScreenConnect client, so the attacker's copy could take its place

The result is a backdoor that no longer depends on the MSP's own panel. The Hacker News adds that the attacker tagged each compromised MSP with a sequential number, and that the tags Huntress saw start partway through the sequence, suggesting other MSPs may have been hit earlier.

The extension at the centre of it

In its Trust Center advisory, ConnectWise says it has found no evidence of a compromise of its own infrastructure or of a vulnerability in ScreenConnect itself. Its initial assessment points to abuse of independently developed third-party extensions installed in partner environments. It found about 400 partner environments with at least one extension from the RMM+ family, and disabled them wherever it could:

• Labtech Plus
• RMM Plus
• RMM+
• RMM Plus Password Link
• RMM+ Password Link

ConnectWise stresses that having one installed doesn't on its own mean you've been compromised. On-premises partners have to disable these extensions themselves.

Huntress later linked the activity to RMM+ specifically. The extension lets another tool manage ScreenConnect sessions without a technician using the console, and it bypasses ScreenConnect's user accounts, roles and MFA, relying instead on a shared access key. In versions 1.0.31 and 1.0.32, if an administrator had never set that key, the extension accepted a blank one. That matches what Huntress saw: commands reaching endpoints across several instances within minutes, with no matching login activity.

Most RMM+ installations Huntress found were legitimate, usually added for a project and then left in place. That's the uncomfortable lesson: a forgotten add-on with a default setting can quietly sit outside every control you've put on the main product.

Why it could spread further

SCKit was designed to do more than sit on one device. According to Huntress's analysis of its code, when a technician connects to an infected endpoint through ScreenConnect, the toolkit tries to copy itself to the technician's workstation, steal the technician's ScreenConnect session cookie and use it to reach every other session that technician can access, pushing the payload out through the panel's Shared Toolbox.

Huntress says it hasn't yet seen this jump work: the console-takeover attempt failed in every recovered host log it checked. But the design is the reason for the most important piece of advice below. Huntress also notes that isolated machines have reinfected themselves shortly after isolation was lifted, so isolation alone isn't a clean-up.

What to do now if you use ScreenConnect

The guidance from ConnectWise and Huntress is consistent:

1. Check for the RMM+ family of extensions and make sure they're disabled, especially on on-premises servers. Don't re-enable or reinstall them until ConnectWise says otherwise.
2. Review Run Command and Toolbox history for mass activity you didn't start, even if you haven't had an alert.
3. Look for a second, unauthorised ScreenConnect client on managed endpoints and technician workstations.
4. Don't connect to a suspect machine through ScreenConnect. Investigate it with EDR live response, WinRM or another out-of-band tool. If a technician has already connected, treat their workstation as potentially exposed and check it from a clean device.
5. Isolate affected hosts and keep them isolated until the rogue client and its persistence are removed. Huntress lists what to look for, including a scheduled task called TrapWatch, the folder C:\ProgramData\RelayTrap\ and toolkit files beginning sckit- in the temp folder.
6. Revoke sessions and reset credentials from a trusted device. Because the toolkit can steal browser session tokens, revoke identity-provider sessions as well as ScreenConnect ones, and check that MFA is in place.
7. Watch for follow-on signs, such as unusual sign-ins, new administrator accounts, permission changes and unexpected MFA prompts.

What to ask if your IT provider uses ScreenConnect

If an MSP looks after your systems, you don't need to wait for them to get in touch. Ask them plainly:

• Do you use ScreenConnect, and did you have any RMM+ family extensions installed?
• Have you reviewed Run Command and Toolbox history for our devices since 11 November?
• Have you checked our machines for an unauthorised remote-access client?
• Have you revoked sessions and reset the credentials used to reach our environment?

A good provider will welcome the questions and give you clear answers.

The wider lesson

This is the second time in a week that the tools MSPs use to manage customers have been in the news, following the N-able N-central vulnerabilities. Remote management tools are built to run commands on many machines at once, which is exactly what an attacker wants. That makes it essential to know every extension and integration connected to them, to keep an audit trail of what they do, and to have someone watching endpoints and identity activity around the clock, so that a burst of commands nobody asked for is spotted in minutes rather than days.

You can read more about how urgentic approaches round-the-clock detection and investigation on our platform page.