Massive ScreenConnect Breach: 288 Devices Hit with SCKit Malware

Overnight on November 11, 2026, attackers commandeered cloud-hosted instances of ConnectWise’s ScreenConnect service, deploying a custom malware toolkit dubbed SCKit across 288 managed devices at 48 different organizations. All infections occurred within approximately 90 minutes, with about a third compromised in the first ten minutes. Security firm Huntress first detected the incident.

How the Attack Unfolded

The hackers leveraged ScreenConnect’s Run command feature via compromised panel extensions to execute commands across many endpoints simultaneously with SYSTEM-level privileges on Windows. The process involved checking for an existing ScreenConnect client, downloading a malicious installer to C:\Windows\TEMP\sc.msi, and installing it silently. Affected versions include 26.6.6.9747 and 26.7.6.9783. ConnectWise has stated that it has found no evidence its own systems were breached and sees no vulnerabilities in the core ScreenConnect software.

In an advisory issued November 11, ConnectWise named five extensions—Labtech Plus; RMM Plus; RMM+; RMM Plus Password Link; and RMM+ Password Link—as possibly tied to the exploit activity. About 400 partner environments that use ScreenConnect had these extensions turned off as a precaution. Because these extensions expose an API capable of running remote commands (protected by a passphrase set by the partner), simply having them installed does not necessarily mean that environment was breached. Partners who host their own servers must disable those extensions themselves, as ConnectWise cannot do so remotely.

Inside SCKit: How It Evades Detection

SCKit consists of 16 components—batch files, PowerShell scripts, settings—that work in concert to avoid detection and maintain persistence. Infected systems send machine-specific IDs to the attackers’ server, which returns a decryption key for a payload tailored to each device. Because of this bespoke approach, hash-based detection tools are unlikely to spot all variants.

Once deployed, the scripts install a second rogue instance of the ScreenConnect client, add Microsoft Defender exclusions, and establish a persistent presence via a folder C:\ProgramData\RelayTrap. A scheduled task named TrapWatch is used to stop the real client and swap in the attacker’s version, all while appearing normal to administrators. Huntress also notes that the RelayTrap component includes C# code that seems to be AI generated.

In addition to persistence, SCKit attempts a lateral move: it waits for legitimate ScreenConnect users (technicians) to connect, then tries to drop a payload onto their workstations. If successful, it steals their session cookie (.aspxauth) and tries to abuse it to infiltrate other sessions and inject payloads into shared panel tools. Huntress so far has not confirmed that spread is succeeding, but warns the design is dangerous.

Response & Mitigation Advice

Huntress and ConnectWise both urge users to stop using ScreenConnect sessions with machines suspected of infection, warning those sessions can carry malware back to clean workstations. Alternative methods like EDR live response or WinRM should be used during cleanup.

Other recommended actions include isolating compromised hosts (since some have re-infected when isolation was lifted), removing the rogue client, deleting the TrapWatch task and RelayTrap directory, wiping associated Run registry keys, reviewing Run Command and Toolbox histories for unauthorized entries, revoking web sessions, and rotating credentials using a clean device. Huntress also shared several indicators of compromise: unusual domains (e.g. newnewnew.gotdns[.]org), an IP address (185.99.255[.]28), and suspicious participant name (“Addmin”). The investigation remains ongoing.

This incident adds to a growing pattern of misuse of remote management tools. Just two months earlier, a known vulnerability (CVE-2026-84869) that allowed unsolicited file transfers in live ScreenConnect sessions was added to the U.S. government’s Known Exploited Vulnerabilities list. That flaw has since been patched.

Why this matters: The breach strikes to the core of trust in remote-management platforms. With SCKit’s tailored deployment, evasion through AI-like code, and sandboxed entry via partner extensions, traditional defense tools like AV or hash checks struggle to detect the threat. IT teams need to assume their remote access infrastructure can be weaponized—disable risky extensions, strictly control access, and monitor for atypical remote API activity. As cloud-hosted and edge tools proliferate, this is the kind of multifaceted attack that sets a new bar for both offense and defense.