ConnectWise disables five ScreenConnect extensions in about 400 environments; Huntress: six MSPs compromised

About 400 environments were disabled. Huntress counts six compromised MSPs.

ConnectWise's advisory, read at 06:57 UTC on 12 November 2026, says ConnectWise identified approximately 400 partner environments with at least one independently developed third-party extension from the RMM+ family installed, and disabled the extensions "wherever ConnectWise can take action". BleepingComputer, quoting a post by Huntress, reports six compromised managed service providers (MSPs) and 286 or more endpoints. Divide one by the other and it is 66.7 to 1, or 1.5 per cent (derived). That arithmetic is shown only to be rejected. ConnectWise says its figure is "environments with the extensions installed, not confirmed compromises". Huntress's six is what it was tracking, and BleepingComputer says it began receiving alerts when rogue clients appeared on monitored endpoints. Neither source says the six are among the 400, and neither says how many partners were actually accessed.

The clock is the second derived fact. Huntress says the campaign it is working "started around 17:47 UTC" on 11 November. ConnectWise published its original advisory at 22:45 UTC that evening, 4 hours 58 minutes later (derived), and its latest update at 02:45 UTC on 12 November, 8 hours 58 minutes after the Huntress start (derived). The advisory's status is "Investigation ongoing". Neither time is a first access date: Huntress says sequential attacker-assigned tags suggest other MSPs may have been compromised earlier, and ConnectWise prints no date for when anyone was first accessed.

ConnectWise sells ScreenConnect, so its statement that it has found no flaw in the product is also a statement in its own commercial interest. Huntress is a security company, and its counts are its own tracking. BleepingComputer relays both. This briefing reports what each says and where it says it.

What ConnectWise says it found and did, in its own order

Status. The page lists the advisory first, titled "ScreenConnect security advisory: Precautionary extension disabling and partner guidance", with the status "Investigation ongoing" and a latest update at 02:45 UTC on 12 November. It opens: "ConnectWise is investigating reports of unauthorized access to certain partner ScreenConnect environments." The original advisory, published 22:45 UTC on 11 November, says ConnectWise "is aware of reports of unauthorized access to ScreenConnect partner accounts and the deployment of unauthorized remote-access software in customer environments". Both say reports. Neither says ConnectWise has confirmed access in a given number of environments.

Assessment. "At this time, we have found no evidence of a compromise of ConnectWise infrastructure or a vulnerability in ScreenConnect itself." Its initial assessment "suggests the activity may involve a threat actor's abuse of independent third-party extensions installed in partner environments", which it is still validating. "The initial access method and full scope remain under investigation." The original advisory adds that attackers were reported to be using ScreenConnect functionality after gaining unauthorized account access, and describes "potential compromise of technician workstations during interactive connections to affected devices", with the note that "these reported behaviors remain subject to validation".

The population. ConnectWise "identified approximately 400 partner environments with at least one independently developed third-party extension from the RMM+ family installed". "Their presence alone does not establish compromise." The extensions "provide an API capable of executing remote commands", and "access to that API is protected by a passphrase configured by the partner during setup". The five extensions named for precautionary disabling are Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link and RMM+ Password Link.

Actions. ConnectWise disabled the extensions in the approximately 400 environments wherever it can act, and says this "represents environments with the extensions installed, not confirmed compromises". It advised on-premises partners to disable them, because it cannot do so on their behalf. It published guidance in the Trust Center at 22:45 UTC on 11 November and says it is contacting all ScreenConnect partners. Partners are told not to re-enable or reinstall the extensions pending further guidance.

Its own limit. ConnectWise says it "does not have visibility or telemetry into activity within partner environments following initial access" and cannot independently determine what happened in affected partner or customer environments. Partners must assess their own environments. That limit sits beside the statement that no vulnerability has been found: the absence of evidence is evidence from a party that says it cannot see most of the places where the activity would show.

Two numbers, three speakers, and what each counts

The first diagram separates what ConnectWise states from what Huntress is quoted as saying and from what nobody states. The two headline numbers are not on the same scale: one counts where an extension is installed, the other counts intrusions Huntress has seen.

Zoom

Labels that do the work of evidence

"Precautionary" and "disabled" are not "removed". ConnectWise is plain about this: "Disabling extensions and resetting credentials alone may not remove unauthorized software, persistence mechanisms, or access already established on endpoints." A partner who reads "disabled in your environment" and stops has dealt with the extension, not with whatever was deployed through it.

"No evidence of a vulnerability" is a statement about what has been found so far. It comes from a party that also says it has no telemetry into partner environments after first access. Huntress's quoted description is "abuse of legitimate functionality", which is consistent with no flaw but does not show where the abuse began.

"Protected by a passphrase" is a statement about a setting the partner chose. The advisory prints no minimum length, no rotation rule, and nothing on whether any passphrase was guessed, reused, leaked or never set. BleepingComputer says Huntress has not determined how the attackers are gaining access, but that its current telemetry points to compromised credentials or hijacked operator sessions. The advisory does not link that to the extension passphrase, and this briefing does not either. ConnectWise's own steps include reviewing "extension API access and configuration".

"Independent third-party" names no one. The advisory does not name the extensions' developers, a publisher, a marketplace or an install count by developer. BleepingComputer says extensions are installed through ScreenConnect's built-in Extensions marketplace; the ConnectWise page does not say that. Whether any extension was itself malicious, or was merely used by an attacker who already had access, is not stated, and nor is whether the developers have responded. "RMM+ family" is the advisory's own grouping, and it does not say what makes an extension a member. Earlier general advice on the same Trust Center page (18 December 2025) said to review and manage extension usage, "installing only those extensions required for operational needs", and the 17 March 2026 entry said to ensure "only trusted and supported extensions are installed". Neither entry mentions these five.

Where the sources differ

The article follows the ConnectWise page where the two disagree, and says so. The differences stay unresolved.

The clock, and what it cannot show

The second diagram lines up the times each source prints. The intervals are derived from them. The ConnectWise block prints two times only: the original publication at 22:45 UTC and the latest update at 02:45 UTC. It prints no earlier update. The 17:47 UTC start comes from Huntress's quoted post and describes the campaign Huntress was working, not the first access to any partner.

Zoom

What is stated, and what is not

What to do, in order

ConnectWise's steps come first, in its order, from the 12 November update. The advisory links extension removal instructions on ConnectWise's documentation site; that page redirects to a sign-in and was not read, so this briefing does not describe the removal steps. The suggestions after ConnectWise's are this site's own, marked as such.

Technical details

ConnectWise's advisory prints 24 indicator rows in five groups, in tables headed "Reported indicators of compromise for investigation". It says they "support investigation" and "do not establish the initial access method or confirmed root cause". It prints no file hashes, no log field names, no queries and no detection rules. Each block below is copied from the advisory; the second column is ConnectWise's own wording for what it reports the item to be. Addresses and domains are defanged as printed. Do not browse to or execute them.

The five extensions. These are the names ConnectWise disabled, listed in its own order. A defender checks the Extensions page of each ScreenConnect instance for any of them, in cloud or on-premises installs, and does not re-enable them.

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

IP addresses. Two addresses ConnectWise associates with an attacker-controlled ScreenConnect relay and with secondary command-and-control. A defender searches firewall, proxy and endpoint connection logs for any contact with them.

185.99.255[.]28  |  Attacker-controlled ScreenConnect relay; hostname screen
155.94.150[.]39  |  Secondary command-and-control infrastructure; hostname WIN-FB5CKHMU4E1

Domains and URLs. Six entries, one of them a full staging URL with its query string. A defender searches DNS, proxy and email gateway logs. The advisory warns not to browse to them.

ns[.]mo7sen[.]dev  |  Malicious PowerShell loader delivery
hxxps://ns[.]mo7sen[.]dev/EadF.php?p=4  |  Specific payload staging URL
sc[.]payproofkit[.]com  |  Rogue ScreenConnect deployment and secondary command-and-control infrastructure
cdn007-digitaldownloads[.]com  |  Additional rogue ScreenConnect deployment
newnewnew[.]gotdns[.]org  |  Attacker command-and-control infrastructure
soxnewwork[.]homedns[.]org  |  Attacker command-and-control infrastructure

Files and scripts. Eight names. ConnectWise says filenames and legitimate utilities alone may not establish compromise, and marks sqlite3.exe as a legitimate utility whose presence alone is not evidence. It also says one filename was only partly visible in its original evidence and needs confirmation.

sckit-run.bat  |  Retrieves and executes the malicious loader
sckit-decoder.ps1  |  PowerShell decoder and loader
TrapWatch.ps1  |  Persistent SYSTEM-level execution
Panel-Lateral.ps1  |  Lateral movement component; filename partially visible in the original evidence and requires confirmation
Run-Lateral-Full.bat  |  Lateral movement and trap payload
runnew.cmd  |  Malware execution script
ToolboxRelayUploader.exe  |  Tool associated with malicious ScreenConnect deployment
sqlite3.exe  |  Legitimate utility reportedly abused to access browser-stored session and authentication data; its presence alone is not evidence of compromise

Filesystem and persistence. Paths, a scheduled task name and a registry Run key value. A defender checks the directory, the scheduled tasks list and the Run keys on endpoints and technician workstations. The advisory says the task reportedly runs every 10 seconds as SYSTEM.

C:\ProgramData\RelayTrap\  |  Malware installation and persistence directory
C:\ProgramData\RelayTrap\TrapWatch.ps1  |  Persistent PowerShell payload
%TEMP%\sckit-*  |  Malware staging directories
TrapWatch  |  Scheduled task executing as SYSTEM, reportedly every 10 seconds
RelayTrapLiteAlert  |  Registry Run-key persistence value

ScreenConnect specific indicators. Two rogue client fingerprints or IDs and two reported operator or account names. This site's suggestion: compare the IDs against client sessions and installed clients, and the names against the users list of each instance.

2588ef5c15954b10  |  Rogue ScreenConnect client fingerprint or ID
ed630cc2c873b091  |  Second rogue ScreenConnect client fingerprint or ID
Addmin, rmmserver  |  Reported attacker-associated operator or account names

An installer pattern, from BleepingComputer only. BleepingComputer prints this pattern as one of the indicators Huntress shared. The ConnectWise table does not print it. It is a shape of a request, with a counter in the last field, so a defender searches web and proxy logs for requests to a ScreenConnect installer path that carry such a marker. It is a secondary report of a vendor's indicator and is not confirmed by ConnectWise.

/Bin/ScreenConnect.ClientSetup.msi?...&c=Exploited<N>

Earlier ConnectWise briefings on this site

Two earlier briefings concern a different ConnectWise incident, the Cloud Backup application credential, which is about Microsoft 365 backup tenants: ConnectWise app credential: Huntress gives three tenant counts and Microsoft says Storm-0940 used ARTEX AI agents to try sign-ins at more than 2,250 tenants via ConnectWise. They are separate incidents unless a primary links them, and no primary read here does. The ScreenConnect advisory does not mention Cloud Backup. The Cloud Backup entry on the same Trust Center page, last updated 4 November, says there was "no indication that other ConnectWise products, services, or offerings are impacted by this incident", which was written before the ScreenConnect reports and so cannot speak to them. The page's other entries, on Axcient portal remediation, a ScreenConnect guest file transfer issue fixed in an earlier release, and older advisories, are not cited by the new advisory and are not used here.

The question the advisory leaves open

ConnectWise says it has no visibility into partner environments after first access, and Huntress says it has no information about patient zero. So which party can say whether the number of accessed partners is six, about 400, or something larger that neither of them can see?

Key facts