SCKit Campaign Hits ScreenConnect Partner Panels: What Health Care IT and Their MSPs Should Check Now

On the afternoon of November 11, 2026, attackers used access to multiple cloud-hosted ConnectWise ScreenConnect partner panels to push malware to managed endpoints through ScreenConnect's own Run Command feature. According to Huntress, the activity began at roughly 17:47 UTC. It reached at least 288 endpoints across 48 organizations, and about one-third of those were hit within the first 10 minutes. The payload is a toolkit researchers are calling SCKit. It installs attacker-controlled ScreenConnect clients for persistence, and it includes a component designed to reach back from an infected endpoint into the workstation of the MSP technician who connects to investigate.

No successful jump from a technician's machine to another customer has been confirmed in recovered logs or in testing. The design still deserves attention. If your organization relies on an MSP that uses ScreenConnect, or if your own IT team uses it, the tool you use to fix problems was the delivery mechanism in this campaign. Many small hospitals, Critical Access Hospitals, and clinics fall into one of those groups.

What happened

The attackers did not need to break into individual hospitals or clinics one at a time. They had access to the management panels that MSPs use to reach many customers at once. From there, they issued Run Command actions that deployed rogue ScreenConnect clients and the SCKit package to managed machines, according to Huntress and Beazley Security Labs. Run Command executes as SYSTEM, so a single panel gives an attacker the highest level of local privilege on every endpoint it manages.

ConnectWise told CyberScoop that it assesses the activity as likely involving abuse of third-party extensions. The company said it has no evidence of a compromise of its own infrastructure or a new ScreenConnect vulnerability. It disabled five third-party extensions across roughly 400 partner environments. The initial access method and full scope are still under investigation.

One of those extensions is RMM+. Versions 1.0.31 and 1.0.32 reportedly accepted a blank access key when no key had been configured. That would let a request bypass normal ScreenConnect accounts, roles, and multifactor authentication, according to The Register and CyberExperts. Not every research team has technically tied RMM+ to the SCKit deployments, as The Hacker News notes. ConnectWise has also cautioned that the presence of an extension alone does not confirm compromise.

How SCKit works

SCKit is a 16-file package of PowerShell, batch, .cmd, and configuration files, according to reporting summarized by Abijita. On an infected endpoint it does the following:

• Stops the legitimate ScreenConnect client and installs one or more clients that report to attacker-controlled infrastructure
• Creates the directory C:\ProgramData\RelayTrap\
• Registers a scheduled task named TrapWatch
• Adds a Run key value named RelayTrapLiteAlert
• Adds Microsoft Defender exclusions

The rogue clients matter most for cleanup. Removing the malware files but leaving an attacker's ScreenConnect client in place leaves the attacker with a remote session into the machine.

The component that makes this campaign different is RelayTrap. It waits for the thing an MSP is supposed to do: a technician notices a problem and connects to the endpoint. RelayTrap then attempts to pivot from the managed endpoint back to the technician's workstation in one of two ways, as described by Huntress and Blackpoint Cyber:

• Abusing CVE-2026-84869, a previously patched client flaw that allowed file transfer and execution through an active session without authorization or host confirmation
• Stealing and replaying authenticated session cookies, then pushing commands through legitimate ScreenConnect features such as Shared Toolbox

A technician's workstation usually has sessions into many customers. Compromising it could turn one infected clinic into a path toward every other organization that MSP supports. This is why researchers have described SCKit as worm-like.

Where CVE-2026-84869 fits

CVE-2026-84869 carries a CVSS 3.1 score of 9.9 and is classified as improper privilege management and missing authorization in the ScreenConnect client, per the NVD record. ConnectWise's disclosure states it was fixed in client version 26.6.5 on September 8, 2026, and that servers were not affected. CISA added it to the Known Exploited Vulnerabilities catalog on September 11, 2026.

Researchers confirmed in testing that patched clients block the file-transfer pivot, according to BleepingComputer. The versions observed in this campaign are newer than 26.6.5, which helps explain why no technician-to-customer spread has been confirmed. Patching does not close the second path, however. If an attacker obtains a valid operator session, cookie replay and legitimate management features remain usable. Patch the client, and treat session hygiene as a separate problem to solve.

Why this matters for health care

Consider a 25-bed Critical Access Hospital with two IT staff, plus three rural clinics and a long-term care facility, all supported by the same regional MSP. None of them were directly targeted. Each is one Run Command away from a SYSTEM-level rogue client if that MSP's panel is abused, and the clinics may have no on-site IT at all. The hospital's EHR workstations, the clinic's practice management server, and the nursing home's medication system would all sit behind the same remote access tool.

That concentration is the real lesson. RMM platforms and their add-ons are high-value targets because they deliver MSP-scale access in one step. A remote support tool that is trusted by every endpoint and allowed through every firewall is exactly what an attacker wants.

What to do now

If you run ScreenConnect (MSP or in-house)

1. Verify versions. Cloud instances were auto-updated, per ConnectWise. On-premises partners should confirm their instance is current, then reinstall or update host clients and access agents so every client is at or above 26.6.5. This includes technician workstations, which are the target of the pivot.
2. Audit extensions. Confirm the five extensions ConnectWise disabled remain disabled, and remove any extension you do not actively need. Review ConnectWise's Trust Center guidance before drawing conclusions from an extension's presence alone.
3. Review panel logs. Look for Run Command actions and extension activity on or after November 11 that no technician can account for. Earlier activity has not been ruled out, so look back further if your retention allows.
4. Revoke and rotate. Revoke active web sessions and rotate relevant credentials, as Beazley Security Labs recommends. This directly addresses the cookie-replay path.
5. Restrict new remote access installs. Application control or restrictions on new RMM installs make rogue clients harder to drop, as suggested by Secure.com. Even a simple allowlist of approved remote access tools is a meaningful start for a small shop.

For endpoint hunting, the following PowerShell function checks a single machine for the published indicators. Run it from an elevated session; Defender exclusions are not readable without administrator rights. It checks both the machine-wide and current-user Run keys because published reporting does not specify which hive SCKit uses, so the HKCU result only covers the account running the script. It lists every ScreenConnect service and Defender path exclusion for manual review rather than guessing which are legitimate.

Function Test-SCKitIndicators ($RelayTrapPath, $TaskName, $RunValueName) {
    $Findings = @()

    if (Test-Path -Path $RelayTrapPath) {
        $Findings += "Directory present: $($RelayTrapPath)"
    }

    $Task = Get-ScheduledTask -TaskName $TaskName -ErrorAction SilentlyContinue
    if ($Task) {
        $Findings += "Scheduled task present: $($TaskName)"
    }

    $RunKeys = @("HKLM:\Software\Microsoft\Windows\CurrentVersion\Run", "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run")
    foreach ($Key in $RunKeys) {
        $Value = Get-ItemProperty -Path $Key -Name $RunValueName -ErrorAction SilentlyContinue
        if ($Value) {
            $Findings += "Run value $($RunValueName) found under $($Key)"
        }
    }

    $Exclusions = (Get-MpPreference).ExclusionPath
    if ($Exclusions) {
        foreach ($Path in $Exclusions) {
            $Findings += "Defender path exclusion to review: $($Path)"
        }
    }

    $Services = Get-Service -DisplayName "ScreenConnect*" -ErrorAction SilentlyContinue
    foreach ($Service in $Services) {
        $Findings += "ScreenConnect service to review: $($Service.DisplayName) [$($Service.Status)]"
    }

    if ($Findings.Count -eq 0) {
        Write-Output "No SCKit indicators found on $($env:COMPUTERNAME)"
    }
    else {
        $Findings
    }
}

Test-SCKitIndicators "C:\ProgramData\RelayTrap" "TrapWatch" "RelayTrapLiteAlert"

A clean result on these checks is not proof the machine is clean. More than one ScreenConnect client is normal in some environments, so compare what you find against the instances your organization actually uses. If you find RelayTrap artifacts, treat the machine as compromised. Do not connect to it from a technician workstation through ScreenConnect until you are confident the session path is safe, because that connection is what RelayTrap is waiting for.

If you are a health care organization that uses an MSP

You may not have panel access, but you can ask direct questions. Ask them in writing so you have a record:

• Does our MSP use ScreenConnect, and is it cloud-hosted or on-premises?
• Were any of the disabled extensions, including RMM+, installed on the panel that manages our endpoints?
• Have our endpoints been checked for the RelayTrap indicators, and what were the results?
• Are all ScreenConnect clients, including technician workstations, at or above version 26.6.5?
• Have operator sessions been revoked and credentials rotated since November 11?
• Was there any Run Command activity against our machines that cannot be tied to a ticket?

HIPAA considerations

No HIPAA enforcement action is tied to this campaign. Existing Security Rule obligations still apply to remote access tools that reach systems holding ePHI.

Under 45 CFR 164.308(a)(1)(ii)(A), risk analysis is a Required implementation specification, and an accurate risk analysis should account for the RMM tool and its extensions as an access path. The information system activity review specification at 164.308(a)(1)(ii)(D) is also Required, and reviewing RMM panel logs for unexplained commands falls squarely within it. The access control standard at 164.312(a)(1) requires limiting access to authorized persons or software programs. An extension that accepts a blank key undermines that control. The audit controls standard at 164.312(b) requires mechanisms that record and examine activity in systems that contain or use ePHI.

Some related specifications, such as log-in monitoring at 164.308(a)(5)(ii)(C), are Addressable. Addressable does not mean optional. The organization must implement the specification if reasonable and appropriate, or document why not and implement an equivalent alternative where reasonable and appropriate, per 164.306(d)(3).

An MSP that manages systems containing ePHI is generally a business associate. Under 164.314(a)(2)(i)(C), the business associate contract must require the business associate to report any security incident it becomes aware of. A rogue client deployed through the MSP's panel to your endpoints fits the regulatory definition of a security incident in 164.304, which includes attempted unauthorized access. Whether it rises to a reportable breach is a separate determination. Under the breach definition in 164.402, an impermissible access is presumed to be a breach unless a documented risk assessment shows a low probability that PHI was compromised. Your own response obligations under 164.308(a)(6)(ii) (Required) include identifying, responding to, mitigating, and documenting the incident.

What is still unknown

Several questions remain open as of November 13, 2026. The exact initial access vector into the panels has not been confirmed. The full scope beyond Huntress-protected organizations is not known, nor is whether any technician workstation was actually compromised. Researchers have not ruled out earlier activity before November 11, or secondary tooling delivered through the rogue clients. Expect updates from ConnectWise, Huntress, and Blackpoint as investigations continue, and recheck your environment against any new indicators they publish.

This article is for informational purposes only and does not constitute legal or compliance advice. Covered entities and business associates should consult qualified legal counsel or compliance professionals before making decisions pertaining to HIPAA or IT infrastructure.

Sources

• Huntress: SCKit worm and rogue ScreenConnect clients
• CyberScoop: ConnectWise ScreenConnect SCKit attack
• Beazley Security Labs: Advisory BSL-A1245
• CyberExperts: ScreenConnect RMM+ extension attacks
• NIST NVD: CVE-2026-84869
• ConnectWise: CVE-2026-84869 disclosure
• The Register: Hackers exploiting ScreenConnect plugin flaw to spread malware
• Abijita: SCKit malware on ScreenConnect endpoints
• Blackpoint Cyber: ScreenConnect attack and SCKit
• BleepingComputer: New worm-like SCKit malware targets MSPs
• LAVX News: SCKit and ScreenConnect support sessions
• Secure.com: SCKit malware and MSPs
• The Hacker News: SCKit malware targets ScreenConnect
• eCFR: 45 CFR Part 164, Security and Privacy