How SCKit Used ScreenConnect RMM+ Access to Reach Endpoints

The ScreenConnect SCKit campaign November 2026 turned remote management access into a way to push rogue clients to managed endpoints. On November 11, Huntress reported affected hosts in several ScreenConnect environments and identified SCKit on those systems.

The immediate risk is an operator using a trusted management panel to run commands at scale. A second risk comes from SCKit’s code: it was designed to reach a technician workstation during an interactive session. Huntress says that second route did not succeed in the recovered host logs it reviewed.

What Happened in the ScreenConnect SCKit Campaign November 2026?

Huntress observed an operator issuing ScreenConnect Run commands from multiple cloud-hosted panels on November 11. Its telemetry covered at least 288 managed endpoints across 48 organizations, all within about 90 minutes. Roughly one third of the hosts were affected in the first ten minutes, according to the researchers.

The commands installed an attacker-controlled ScreenConnect client and delivered SCKit, a toolkit intended to preserve access and expand it. These are Huntress’s observed endpoint cases, not a count of every organization that might have used the affected extension. The researchers saw the deployment through panels before analyzing SCKit’s additional spreading logic. A cyber threat intelligence platform can help security teams connect panel events, endpoint findings and external campaign signals.

ConnectWise said it found approximately 400 partner environments with one or more of five extensions it identified during its investigation. It disabled those extensions where it could and told on-premises partners to disable them immediately. ConnectWise explicitly says an extension’s presence alone does not establish compromise.

How Did the RMM+ Access Path Work?

Huntress links the activity to RMM+, a third-party ScreenConnect extension that lets another tool manage sessions without a technician using the console. Its analysis found a blank default access key in RMM+ versions 1.0.31 and 1.0.32. If an administrator had never set the key, Huntress says the extension accepted the empty value.

That matters because RMM+ uses its own shared key instead of ScreenConnect user accounts, roles and multifactor authentication. Huntress found commands across several instances within minutes, with no matching user logins. The reviewed logs associated those commands with RMM+, supporting the researchers’ access-path assessment.

The initial access method and the full scope were still under investigation in ConnectWise’s November 11 statement. The vendor describes possible abuse of independent third-party extensions, while Huntress identifies a specific RMM+ weakness in its investigation. These two statements carry different levels of certainty and should be read separately.

Huntress also says the then-current ScreenConnect versions 26.6.6.9747 and 26.7.6.9783 were affected by this activity. Those version numbers do not mean that a ScreenConnect core patch fixes an unset extension key. Teams should check the extension state and panel activity even when the base software is current.

What Ran on the Managed Endpoints?

The observed panel commands installed a rogue ScreenConnect client and then delivered the encrypted SCKit package. Huntress describes a multi-part toolkit that sets up a relay trap, changes the legitimate client’s behavior and keeps the attacker’s remote access available. The package was tailored to the individual Windows system, complicating simple file-hash hunting.

Once installed, the toolkit sought to make the malicious client appear in the normal support workflow. Huntress found a scheduled persistence mechanism and changes that could interfere with normal ScreenConnect activity. That is why a host may still look manageable while its remote access path is under attacker control.

1. 1Panel accessOperator issues Run commands across managed endpoints
2. 2Rogue clientCommands install an attacker-controlled ScreenConnect client
3. 3SCKit deliveryEndpoint receives a system-specific encrypted toolkit
4. 4PersistenceToolkit sets a relay trap and keeps unauthorized access available

This diagram covers the activity Huntress observed on endpoints. It does not show a confirmed technician-workstation compromise or a confirmed jump to further panels. Those later stages come from the researchers’ analysis of SCKit’s code.

What Was the Toolkit Designed to Do Next?

Huntress reconstructed a second route in the toolkit: wait for a technician to connect to an affected endpoint. The code would then try to run a payload on the technician workstation, collect its ScreenConnect session material and access other sessions available to that technician. It was also built to distribute a payload through shared support tooling.

Huntress says it has not observed a successful jump from an infected endpoint to a technician workstation, or from that workstation to other endpoints. The console takeover failed in every recovered host log the researchers checked. The code’s intended behavior is still important because an interactive support session could put a technician machine in the attack path.

For that reason, Huntress and ConnectWise both advise against interactive ScreenConnect connections to suspected compromised devices. Use a separate security tool to investigate and treat a technician workstation as potentially exposed if it already connected. A clean device should be used to review sessions and credentials.

How Can Defenders Find the Observed Activity?

Start with ScreenConnect Run Command and Toolbox history. Hunt for bursts of unplanned commands, unusual administrative activity and new or changed extensions. Correlate those events with panel audit logs, endpoint alerts and technician session times to identify which systems need deeper review.

On managed endpoints, look for an unapproved second ScreenConnect client and a persistence mechanism that reasserts control after a restart. Huntress warns that the toolkit’s scripts can carry different embedded values and its executable is built per host. Behavioral and administrative evidence is therefore more useful than one published file hash.

Review any workstation that connected to a suspect endpoint, even though Huntress did not confirm successful spread through that route. Check for unexpected remote-access software, session exposure and unusual access to other managed systems. Preserve relevant logs before removing the unauthorized software.

Panel logs and endpoint findings should be compared before the response is scoped. For a wider account of remote-management abuse, see our trusted software abuse analysis.

What Should an Affected Team Do First?

First, verify that the five named extensions are disabled, including RMM+, and do not reinstall them pending ConnectWise guidance. On-premises partners must take that action themselves, according to the vendor. Disabling an extension does not remove a rogue client or persistence already present on endpoints.

• Confirm the identified extensions are disabled on every relevant instance.
• Preserve panel audit, Run Command and Toolbox history before cleanup.
• Investigate suspect endpoints using a separate security tool, not an interactive ScreenConnect session.
• Isolate affected hosts and remove unauthorized clients and persistence after evidence capture.
• From a trusted device, end active sessions and rotate relevant ScreenConnect and identity-provider credentials.
• Validate clean client state and watch for reinfection before restoring normal access.

Huntress reports that some affected systems were reinfected shortly after isolation ended. Keep a host isolated until the rogue client and persistence are removed and its legitimate client is verified. ConnectWise also advises checking technician workstations and preserving suspicious activity logs.

Use an incident response plan template to assign owners for panel review, endpoint cleanup and credential revocation. Continue monitoring after restoration because the first access route and the campaign’s full scope remain under investigation.

What Is Confirmed and What Remains Under Investigation?

Brandefense Blackhole counted 27 SCKit dark-chat posts from August 15 through November 13, 2026. The unit is posts mentioning SCKit, and a post count does not identify distinct attacks, affected organizations or successful exploitation. It is a research signal for prioritizing review, not incident confirmation.

The stronger evidence is Huntress’s endpoint telemetry and code analysis, read alongside ConnectWise’s partner guidance. Huntress directly observed the panel-to-endpoint deployment and analyzed a possible workstation route. ConnectWise documented precautionary extension disabling while saying the initial access method and full scope remained under investigation.

For a defender, this distinction changes the immediate decision. Investigate the activity that was observed, remove established persistence and avoid a support session that could activate the code’s designed route. Do not use the approximately 400 extension-bearing environments as a victim count.