ScreenConnect RMM+ Extension Attacks on MSPs: Response and Hunting

On November 11, 2026, ConnectWise reported unauthorized access to ScreenConnect partner accounts and unauthorized remote access software in customer environments. Attackers used the partners’ own ScreenConnect access to push extra remote access tools to managed devices, which gives them a way back in that survives a password reset on the MSP side.

ConnectWise’s working theory is that the attackers abused third-party ScreenConnect extensions from the RMM+ family: Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link and RMM+ Password Link. These extensions expose an API that can run remote commands, protected only by a passphrase the partner chose during setup. ConnectWise disabled them in about 400 partner environments it could reach. On-premises partners must disable them themselves.

ConnectWise says it has found no compromise of its own infrastructure and no vulnerability in ScreenConnect itself. How the attackers first got in is still unknown, and there is no CVE and no patch. Early reports describe several MSPs and hundreds of customer endpoints affected within hours on November 11, with the count still rising.

Who is affected

• Partners with any RMM+ family extension installed, cloud or on-premises. Treat these as possibly compromised until you have checked the evidence below. ConnectWise stresses that having an extension installed does not prove compromise.
• Their customers. Any device managed through an affected ScreenConnect instance may now carry a second, rogue ScreenConnect client or other remote access software.
• Technician workstations. ConnectWise is checking reports that a technician’s own PC was compromised while connected interactively to an infected device. Until that is ruled out, any workstation that opened a session to a suspect device is in scope.
• Partners without the extensions. ConnectWise says it has “no reason to believe” they are affected, but asks every partner to stay on heightened alert.

What the attackers did

ConnectWise’s November 12 update lists these behaviors, which it says are still being validated:

• Account access. Sign-ins to partner ScreenConnect accounts. The initial access method is not confirmed. Stolen credentials, hijacked technician sessions and abuse of the extension API passphrase are all possible.
• Rogue ScreenConnect clients. Use of ScreenConnect’s own functions, such as Run Command, to install additional ScreenConnect clients that report to attacker relays, including 185.99.255[.]28. The installers were requested with a company field of the form c=Exploited<N>.
• PowerShell loaders. A batch file, sckit-run.bat, fetches and runs sckit-decoder.ps1 from ns.mo7sen[.]dev, staged in %TEMP%\sckit-* folders.
• SYSTEM persistence. A C:\ProgramData\RelayTrap\ folder holding TrapWatch.ps1, a scheduled task named TrapWatch that runs as SYSTEM, reportedly every 10 seconds, and a Run key value named RelayTrapLiteAlert.
• Lateral movement. Scripts named Run-Lateral-Full.bat and Panel-Lateral.ps1.
• Browser session theft. A copy of the legitimate sqlite3.exe used to read browser stores of cookies, sessions and saved credentials.

One of the rogue client IDs, ed630cc2c873b091, was in a Windows batch file that appeared in a public malware repository in late July 2026. That file added Defender exclusions, set Startup and Run key persistence and checked for the rogue client before reporting success. The infrastructure is older than the November activity, so look back further than November 11.

Why the technician workstation matters

A ScreenConnect session runs in both directions. CVE-2026-84869, fixed in ScreenConnect 26.6.5 in September, let files be transferred and run through an active session without the host’s confirmation, and CISA lists it as exploited. ConnectWise has not linked it to this activity. Still, a technician client below 26.6.5 that connects to an infected device is the path to worry about. Make sure every host client was reinstalled after the 26.6.5 upgrade, and investigate suspect devices with other tools.

What to do now

1. Disable the extensions. In ScreenConnect go to Administration > Extensions and disable or uninstall Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link and RMM+ Password Link. Cloud partners should check that ConnectWise’s change took effect. Do not re-enable or reinstall them until ConnectWise says it is safe.
2. Preserve evidence first. Export the ScreenConnect audit records for authentication, extension installs, administrative changes, Run Command and Toolbox use before you change anything else. On-premises partners should also copy the server’s App_Data folder and IIS or web logs.
3. Stop opening sessions to suspect devices. Use your EDR, not ScreenConnect, to investigate customer devices, and include every technician workstation that connected to them.
4. Revoke and reset. End all active ScreenConnect sessions and identity provider sessions for technicians, reset their passwords from a clean device, enforce MFA, use unique passwords and remove admin rights nobody needs. Review the extension API configuration and passphrase before deciding what to do with the extensions.
5. Hunt for rogue clients and persistence on every managed device with the queries below, and remove any ScreenConnect client whose relay is not your own instance.
6. Contain confirmed compromises. Isolate affected devices and technician PCs, follow your incident response process, and validate the cleanup before you reconnect them. Disabling the extensions and resetting credentials does not remove software or persistence already on endpoints.
7. Patch and harden. Keep the ScreenConnect server at 26.6.5 or later, reinstall host clients and update access agents, and follow ConnectWise’s ScreenConnect security guide. Restrict the Run Command, Toolbox and file transfer permissions to the roles that need them.

How to check your environment

Start with the ScreenConnect side, then the endpoints.

• Extensions. List installed extensions under Administration > Extensions and record when each was installed and by whom.
• Accounts. Under Administration > Security, look for users you do not recognize, including the names Addmin and rmmserver, and for role or permission changes since late July.
• Audit. Under Administration > Audit, filter for logins from new locations, repeated failures, Run Command and Toolbox use, and file transfers on November 11 and 12 and the weeks before.
• Sessions. Look for access sessions you did not create, especially any running the installers or scripts named above.

Threat hunting

These hunts look for rogue ScreenConnect clients, the published infrastructure, the RelayTrap persistence and browser data theft. Run them across every customer you manage, not just your own estate.

Example KQL for Microsoft Sentinel and Defender

The KQL below is example code for Microsoft Sentinel and Microsoft Defender for Endpoint. Adapt table and field names to your environment and test each query before relying on it.

Hunt 1: ScreenConnect clients that report to someone else’s relay

Every ScreenConnect client service carries its relay host on the command line in the h= parameter, and its instance ID in the install folder name. List them all, then remove your own instances.

// Example: Defender XDR, ScreenConnect client services by relay host and instance ID
let MyRelays = dynamic(["instance-xxxx-relay.screenconnect.com", "support.example.com"]);   // replace with your own
DeviceProcessEvents
| where Timestamp > ago(120d)
| where FileName =~ "ScreenConnect.ClientService.exe"
| extend Relay = extract(@"[?&]h=([^&""]+)", 1, ProcessCommandLine),
         InstanceId = extract(@"ScreenConnect Client \(([0-9a-f]{16})\)", 1, FolderPath)
| where Relay !in~ (MyRelays)
| summarize Devices = dcount(DeviceId), Sample = make_set(DeviceName, 20), First = min(Timestamp), Last = max(Timestamp)
    by Relay, InstanceId
| order by First asc

Any relay you do not own is a lead. Relay 185.99.255.28 or instance IDs 2588ef5c15954b10 and ed630cc2c873b091 are confirmed indicators.

Hunt 2: ScreenConnect installers pushed by Run Command

Commands run through ScreenConnect start as children of the client service. This finds installs of another ScreenConnect client and script downloads launched that way.

// Example: Defender XDR, installers and downloads started from a ScreenConnect session
DeviceProcessEvents
| where Timestamp > ago(120d)
| where InitiatingProcessFileName =~ "ScreenConnect.ClientService.exe"
    or InitiatingProcessParentFileName =~ "ScreenConnect.ClientService.exe"
| where ProcessCommandLine has_any ("ScreenConnect.ClientSetup", "ClientSetup.msi", "Exploited", "sckit", "mo7sen", "Invoke-WebRequest", "iwr ", "DownloadString", "curl ", "bitsadmin")
    or (FileName =~ "msiexec.exe" and ProcessCommandLine has "http")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName
| order by Timestamp desc

Hunt 3: connections to the published infrastructure

// Example: Defender XDR, network connections to the ConnectWise-published indicators
let BadIPs = dynamic(["185.99.255.28", "155.94.150.39"]);
let BadDomains = dynamic(["mo7sen.dev", "payproofkit.com", "cdn007-digitaldownloads.com", "newnewnew.gotdns.org", "soxnewwork.homedns.org"]);
DeviceNetworkEvents
| where Timestamp > ago(120d)
| where RemoteIP in (BadIPs) or RemoteUrl has_any (BadDomains)
| project Timestamp, DeviceName, InitiatingProcessAccountName, InitiatingProcessFileName, InitiatingProcessCommandLine, RemoteIP, RemotePort, RemoteUrl
| order by Timestamp desc

For devices without Defender, run the same lists against firewall logs:

// Example: Sentinel, firewall traffic to the published addresses (CEF)
CommonSecurityLog
| where TimeGenerated > ago(120d)
| where DestinationIP in ("185.99.255.28", "155.94.150.39")
    or RequestURL has_any ("mo7sen.dev", "payproofkit.com", "cdn007-digitaldownloads.com", "gotdns.org", "homedns.org")
| summarize Hits = count(), Sources = make_set(SourceIP, 50), First = min(TimeGenerated), Last = max(TimeGenerated)
    by DestinationIP, RequestURL, DeviceAction
| order by First asc

Hunt 4: RelayTrap persistence and the loader files

// Example: Defender XDR, RelayTrap files, sckit staging, lateral scripts and the TrapWatch task
let Files = dynamic(["sckit-run.bat", "sckit-decoder.ps1", "TrapWatch.ps1", "Panel-Lateral.ps1", "Run-Lateral-Full.bat", "runnew.cmd", "ToolboxRelayUploader.exe"]);
union
(DeviceFileEvents
    | where Timestamp > ago(120d)
    | where FileName in~ (Files) or FolderPath has @"\ProgramData\RelayTrap" or FolderPath matches regex @"(?i)\\Temp\\sckit-"
    | project Timestamp, DeviceName, Evidence = strcat(ActionType, " ", FolderPath), InitiatingProcessCommandLine),
(DeviceRegistryEvents
    | where Timestamp > ago(120d)
    | where RegistryValueName =~ "RelayTrapLiteAlert" or RegistryValueData has "RelayTrap"
    | project Timestamp, DeviceName, Evidence = strcat(RegistryKey, " ", RegistryValueName, "=", RegistryValueData), InitiatingProcessCommandLine),
(DeviceEvents
    | where Timestamp > ago(120d)
    | where ActionType startswith "ScheduledTask" and AdditionalFields has_any ("TrapWatch", "RelayTrap")
    | project Timestamp, DeviceName, Evidence = strcat(ActionType, " ", tostring(AdditionalFields)), InitiatingProcessCommandLine)
| order by Timestamp desc

If you collect Windows Security events in Sentinel, task creation shows as event 4698:

// Example: Sentinel, scheduled task TrapWatch created
SecurityEvent
| where TimeGenerated > ago(120d)
| where EventID == 4698 and EventData has_any ("TrapWatch", "RelayTrap")
| project TimeGenerated, Computer, SubjectUserName, EventData

Hunt 5: sqlite3.exe reading browser data

sqlite3.exe is a legitimate tool, but it has no business reading browser cookie or login databases on an endpoint.

// Example: Defender XDR, sqlite3 touching browser cookie, login or session stores
DeviceProcessEvents
| where Timestamp > ago(120d)
| where FileName =~ "sqlite3.exe" or ProcessVersionInfoOriginalFileName =~ "sqlite3.exe"
| where ProcessCommandLine has_any ("Cookies", "Login Data", "Web Data", "Local State", "cookies.sqlite", "logins.json", "Network\\")
| project Timestamp, DeviceName, AccountName, FolderPath, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc

Hunt 6: technician workstations receiving files or running code from a session

On technician PCs the ScreenConnect host client is ScreenConnect.WindowsClient.exe. It should not be writing executables or starting shells.

// Example: Defender XDR, ScreenConnect host client dropping executables or starting shells
union
(DeviceFileEvents
    | where Timestamp > ago(120d)
    | where InitiatingProcessFileName =~ "ScreenConnect.WindowsClient.exe"
    | where FileName matches regex @"(?i)\.(exe|dll|ps1|bat|cmd|vbs|js|hta|msi|lnk)$"
    | project Timestamp, DeviceName, Evidence = strcat("File ", ActionType, ": ", FolderPath), InitiatingProcessAccountName),
(DeviceProcessEvents
    | where Timestamp > ago(120d)
    | where InitiatingProcessFileName =~ "ScreenConnect.WindowsClient.exe"
    | where FileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe", "msiexec.exe")
    | project Timestamp, DeviceName, Evidence = strcat("Process: ", ProcessCommandLine), InitiatingProcessAccountName)
| order by Timestamp desc

Files the technician saved on purpose will show here too. Check each one against the session it came from.

How to tell if a device was compromised

• A second ScreenConnect client. More than one ScreenConnect Client (...) service or folder, or one whose relay is not your instance (Hunt 1).
• RelayTrap. The C:\ProgramData\RelayTrap\ folder, the TrapWatch task, the RelayTrapLiteAlert Run key value or %TEMP%\sckit-* folders (Hunt 4).
• Traffic to the published hosts from the device or its firewall (Hunt 3).
• Defender changes. New exclusions, disabled real-time protection or tamper protection alerts around the time of the install.
• Browser data theft. sqlite3.exe against browser stores (Hunt 5), then sign-ins to the user’s cloud accounts from new places using stolen sessions.

ConnectWise warns that file names, account names and legitimate tools alone may not prove compromise, and that finding none of the indicators does not rule it out.

Removing a rogue client

1. Isolate the device with your EDR first, so the attacker cannot see the cleanup coming.
2. Record the evidence: the service name, install folder, relay host, instance ID and install time.
3. Remove the rogue service and folder, then the RelayTrap task, folder and Run key value, and any Defender exclusions you did not set.
4. Reset credentials used on the device, and revoke browser sessions for any user whose data may have been read.
5. Check your own client on the device is genuine and current before you reconnect it.

Indicators of compromise

Published by ConnectWise on November 12, 2026. Do not browse to or run any of these.

Timeline

• Late July 2026: A batch file containing rogue client ID ed630cc2c873b091 appears in a public malware repository.
• September 8, 2026: ConnectWise releases ScreenConnect 26.6.5, fixing CVE-2026-84869 in the client.
• September 11, 2026: CISA adds CVE-2026-84869 to its Known Exploited Vulnerabilities catalog.
• November 11, 2026, afternoon UTC: Rogue ScreenConnect clients start appearing on customer devices of MSPs using cloud-hosted ScreenConnect.
• November 11, 2026, 22:45 UTC: ConnectWise publishes its advisory and disables the RMM+ family extensions in about 400 partner environments.
• November 12, 2026, 02:45 UTC: ConnectWise updates the advisory with indicators, the extension API detail and fuller guidance. It finds no compromise of its infrastructure and no ScreenConnect vulnerability.

Frequently Asked Questions

Is this a ScreenConnect vulnerability? ConnectWise says it has found no vulnerability in ScreenConnect and no compromise of its own systems. The attackers used legitimate ScreenConnect functions after getting into partner accounts, and ConnectWise suspects the third-party RMM+ family extensions played a part.

Which extensions should I disable? Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link and RMM+ Password Link. ConnectWise disabled them in the environments it could reach. On-premises partners have to disable them under Administration > Extensions.

We never installed those extensions. Are we safe? ConnectWise says it has no reason to believe you are affected. It still asks all partners to watch for unusual sign-ins, new admin accounts, unexpected Run Command or Toolbox use and unapproved remote access software on customer devices.

Does disabling the extension remove the attacker? No. Any rogue client, scheduled task or other software already installed on endpoints stays there. You have to hunt for it and remove it on every managed device.

Why should technicians stop connecting to suspect devices? ConnectWise is checking reports that technician workstations were compromised during interactive sessions with infected devices. Investigate with your EDR instead, and treat any technician PC that connected to a suspect device as in scope.

Is a patch coming? There is nothing to patch yet, since ConnectWise has not found a ScreenConnect flaw. Keep servers, host clients and agents current, at least 26.6.5, and watch the ConnectWise Trust Center for updates.

How far back should we look? At least to late July 2026. One of the rogue client IDs was in a malicious file from that time, so this infrastructure predates the November activity.

How ThreatDefence is responding

ThreatDefence has added the ConnectWise indicators, the rogue client IDs and the RelayTrap persistence to our detection content. Across all monitored environments, our SOC is:

• hunting for ScreenConnect clients that report to unknown relays, and for installs pushed through ScreenConnect sessions
• alerting on connections to the published infrastructure, the TrapWatch task and RelayTrap files
• watching technician workstations for files and processes started from ScreenConnect sessions, and for browser data access by sqlite3.exe

If you run ScreenConnect for your customers and want help checking them, contact us. Read more about our managed detection and response.

Sources

• ConnectWise Trust Center, ScreenConnect security advisory: Precautionary extension disabling and partner guidance (November 11 and 12, 2026)
• ConnectWise, ScreenConnect 26.6.5 Security Patch bulletin (September 8, 2026)
• ConnectWise Documentation, ScreenConnect Extensions page: uninstall an extension
• ConnectWise Documentation, ScreenConnect security guide
• CISA, Known Exploited Vulnerabilities catalog (CVE-2026-84869 added September 11, 2026)
• NVD, CVE-2026-84869
• Microsoft Learn, DeviceProcessEvents table (Defender XDR advanced hunting)