Rogue ScreenConnect Clients Are Spreading Through MSPs Tonight. Disable Five Extensions, Check Run Command History, and Do Not Open a Session to a Suspect Host
If you are an MSP on ScreenConnect, do four things tonight. Confirm that the five third-party extensions ConnectWise named (Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link, RMM+ Password Link) are disabled, and disable them yourself if you run ScreenConnect on-premises, because ConnectWise cannot do it for you. Pull your Run Command history, Toolbox records, extension installs and authentication logs. Hunt your endpoints for the two rogue client IDs and the file names below. And do not open an interactive ScreenConnect session to a machine you suspect, because ConnectWise has reports, still being confirmed, of technician workstations compromised that way. Huntress found this campaign and published the indicators. The credit is theirs.
What to do, in order
Disable the extensions. Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link, RMM+ Password Link. ConnectWise says it disabled them in about 400 cloud partner environments, which is a count of environments that had the extensions installed, not a count of compromises. On-premises servers must be done by hand. Do not re-enable or reinstall them until ConnectWise says so. ConnectWise is explicit that disabling them "does not establish that unauthorized software, persistence mechanisms, or access already present on affected devices has been removed."
Check Run Command history even if nothing alerted. Huntress told BleepingComputer that "sequential attacker-assigned tags suggest other MSPs may have been compromised earlier". The rogue installer requests follow the pattern /Bin/ScreenConnect.ClientSetup.msi with a parameter of c=Exploited followed by a number. A number in that tag that is not the lowest one means someone was hit before.
Preserve before you clean. Keep authentication, extension installation, administrative, Run Command and Toolbox records. Look for new users, permission changes, unexpected software deployments and commands you did not send, including an operator or account named Addmin or rmmserver.
Investigate from outside ScreenConnect. Use your EDR or another trusted tool, not an interactive session. Include every technician workstation that connected to a suspect device in the scope.
Lock the front door from a clean device. Revoke active ScreenConnect and identity-provider sessions, reset the relevant passwords, enforce MFA on partner accounts, use unique passwords and remove admin rights nobody needs. If your extension exposes a remote-command API protected by a passphrase, rotate that passphrase and review who could reach it.
Block the infrastructure. Load the addresses and hostnames below into your firewall, proxy and DNS filtering, and search at least 30 days of logs for any contact.
Indicators to hunt for
These come from ConnectWise's advisory (which credits reports it received) and Huntress's indicators as quoted by BleepingComputer. ConnectWise says matches "do not establish the initial access method or confirmed root cause" and that no match does not rule out compromise.
Attacker ScreenConnect relay: 185.99.255.28 (hostname "screen")
Secondary command and control: 155.94.150.39 (hostname WIN-FB5CKHMU4E1), serving sc.payproofkit.com
Command and control hostnames: newnewnew.gotdns.org and soxnewwork.homedns.org. These are hostnames on free dynamic-DNS services. Block the exact hostnames, not gotdns.org or homedns.org, which serve many unrelated users.
Additional rogue ScreenConnect deployment: cdn007-digitaldownloads.com (Huntress called it a possible additional C2)
Loader delivery: ns.mo7sen.dev, payload URL hxxps://ns.mo7sen[.]dev/EadF.php?p=4
Rogue ScreenConnect client IDs: 2588ef5c15954b10 and ed630cc2c873b091. Search installed services and running processes for either string.
Files: sckit-run.bat, sckit-decoder.ps1, TrapWatch.ps1, Panel-Lateral.ps1 (ConnectWise notes the name was only partly visible and needs confirmation), Run-Lateral-Full.bat, runnew.cmd, ToolboxRelayUploader.exe. sqlite3.exe is listed as a legitimate utility reportedly abused to read browser-stored session data; finding it alone means nothing.
Persistence: a folder C:\ProgramData\RelayTrap\, a scheduled task named TrapWatch running as SYSTEM (reportedly every 10 seconds), a Run-key value named RelayTrapLiteAlert, and staging folders matching %TEMP%\sckit-*.
What is confirmed
The campaign is real and active. Huntress's SOC posted on r/msp that it was working "an active campaign that started around 17:47 UTC today targeting cloud-hosted ScreenConnect instances" and was "tracking 6 compromised MSPs and 286+ endpoints, and those numbers are climbing." BleepingComputer reports Huntress's figure of 47 organizations. All three numbers are Huntress's own telemetry, which covers Huntress customers only, so the real total is at least this and probably more.
The mechanism Huntress saw. Attackers used ScreenConnect's Run Command to push rogue ScreenConnect clients onto managed endpoints, giving them remote access that sits outside the MSP's own ScreenConnect instance. Huntress's Spike Brandt told BleepingComputer: "This appears to be abuse of legitimate functionality, aided using custom-built tooling that is, in some cases, compiled on the fly on the victim's computer."
ConnectWise's position. Its Trust Center advisory, first published November 11 at 22:45 UTC and updated November 12 at 02:45 UTC, confirms reports of "unauthorized access to ScreenConnect partner accounts and the deployment of unauthorized remote-access software in customer environments." It says it has "found no evidence of a compromise of ConnectWise infrastructure or a vulnerability in ScreenConnect itself." The named extensions "provide an API capable of executing remote commands," protected by a passphrase the partner sets during setup.
What is not known
How the attackers got in. ConnectWise says "the initial access method and full scope remain under investigation." Its working theory is abuse of the third-party extensions. Huntress told BleepingComputer its telemetry points to compromised credentials or hijacked operator sessions, and that it has "no information about how a 'patient zero' computer" started it. Those are two hypotheses, not a finding. There is no CVE.
The technician-workstation hop. Both companies describe compromise of a technician's machine during an interactive session to an infected device. ConnectWise says those reports are "still being confirmed," and the mechanism has not been published.
Whether July is the same actor. BleepingComputer found a separate batch script, SSA-2026-STATEMENT-15518787.bat, first uploaded to VirusTotal on July 25, 2026, posing as a Social Security statement. It fetches installer commands from amexsafekeyupdate.com, pulls ScreenConnect installers from cdn007-digitaldownloads.com, and checks for client ID ed630cc2c873b091 before reporting success over Telegram. BleepingComputer says the relationship to this week's campaign "remains unclear," and Huntress declined to comment on it. The shared client ID and download host are a strong link, but we are not calling it the same operation.
Who is behind it. Nobody has named an actor.
Why this one matters
An RMM tool is a key ring for every customer an MSP serves. One stolen partner login or one extension with a remote-command API turns into hundreds of endpoints in an afternoon, and a rogue ScreenConnect client looks like the legitimate one to most people glancing at a process list. The useful defensive habit here is the one ConnectWise spelled out: when you suspect a machine, stop reaching into it with the tool the attacker is using.
How we know, and what we did
Sources read. We read the ConnectWise Trust Center advisory in full and the BleepingComputer article in full. Huntress's r/msp post is the primary source for the campaign, but Reddit refused our automated fetches (HTTP 403 and a tool-level block) so we could not read the thread directly. Every Huntress quote here is as BleepingComputer and ConnectWise reproduced it. ConnectWise's indicator list and Huntress's indicators as quoted by BleepingComputer agree on every value they share.
Our feed. Before tonight, none of these values was attributed in our corpus. Our correlation lookup showed ns.mo7sen.dev held only from a third-party social-media feed (TweetFeed, at confidence 70, unattributed), and the other six addresses and hostnames were not held at all, with no neighbors in the same /24 or the same registered domain. We added both IPs and six hostnames, plus amexsafekeyupdate.com from BleepingComputer's July finding, to our public feed at confidence 80 under the campaign source manual-batch-screenconnect-msp-2026-11. These are Huntress's, ConnectWise's and BleepingComputer's indicators, cited, not our observations.
Left out on purpose. Anything under screenconnect.com (BleepingComputer's July sample also pulled an installer from a subdomain of ConnectWise's own cloud service, and blocking ConnectWise's domain would break legitimate support for everyone). The parent dynamic-DNS zones gotdns.org and homedns.org. The stager URL is in as its hostname only. Client IDs, file names and paths are not network indicators and belong in your EDR hunt, not a blocklist.
Our edge. Our edge covers only our own websites, and we do not run ScreenConnect, so this is a narrow check. Neither attacker IP appears in our edge blocks, edge canaries or origin honeypot since August 1 (342,777 block events, 119,414 canary records and 5,593 origin captures scanned). Requests for ScreenConnect paths (SetupWizard.aspx, /Bin/ScreenConnect, App_Extensions, PageService.ashx, or any path containing "screenconnect") also returned zero since October 12 across 301,985 block events, 50,185 canary records and 808 origin captures. We have no ScreenConnect decoy, so that zero means nobody probed our sites for it on paths we log, not that nobody is scanning for ScreenConnect. This campaign runs inside MSP tenants, where our sensors cannot see.
This is a fast-moving incident and some of the above will be revised as Huntress and ConnectWise publish more. Treat it as roughly 95% right tonight, and check the advisory before acting on anything that has changed.
Sources
Huntress, r/msp post "Active malware campaign abusing ScreenConnect", November 11, 2026 (primary; read through quotations, see above): https://www.reddit.com/r/msp/comments/1xts3f2/active_malware_campaign_abusing_screenconnect/
ConnectWise Trust Center, "ScreenConnect security advisory: Precautionary extension disabling and partner guidance", published November 11, 2026 22:45 UTC, updated November 12, 2026 02:45 UTC: https://www.connectwise.com/company/trust/advisories
BleepingComputer, "Active ScreenConnect attacks breach MSPs, impact dozens of organizations", November 11, 2026: https://www.bleepingcomputer.com/news/security/active-screenconnect-attacks-breach-msps-impact-dozens-of-organizations/
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Comments