← Playbooks

Rogue clients pushed through your ScreenConnect: contain without infecting your technicians (Nov 2026 MSP campaign)

For MSPs whose ScreenConnect instance was used to push a second, attacker-controlled client and toolkit to customer hosts (Nov 11, 2026 campaign). Built from ConnectWise's advisory and Huntress's incident notice.

For: MSP owner / operations, SOC, IT admin

1. Step 1 of 6

   Stop connecting to affected hosts

   The toolkit waits for a technician session and spreads to whoever connects.

   • Tell every technician: no interactive ScreenConnect sessions to suspected hosts, from any instance, including new or trial instances
   • Investigate with EDR or other separate tooling instead
   • Isolate affected hosts at the network level
2. Step 2 of 6

   Lock down the instance from a clean device

   Assume the attacker had valid access to your ScreenConnect.

   • From a trusted device: reset every user password, revoke all sessions (ScreenConnect and your identity provider), enforce MFA
   • Remove unknown users; review session groups, Toolbox items and extensions
   • Disable Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link and RMM+ Password Link if present; on-prem partners must do this themselves; don't reinstall
3. Step 3 of 6

   Scope it from records, not alerts

   Huntress says earlier victims may exist, so check even if nothing fired.

   • Export Run Command, Toolbox, extension-install, admin and login records from Nov 11 and earlier; preserve before cleanup
   • Hunt for a second ScreenConnect client (IDs 2588ef5c15954b10, ed630cc2c873b091), the TrapWatch task, C:\ProgramData\RelayTrap\ and C:\Windows\Temp\sckit-*
   • Block 185.99.255.28, 155.94.150.39, newnewnew.gotdns.org, soxnewwork.homedns.org, sc.payproofkit.com and ns.mo7sen.dev, and search DNS and proxy logs for them
4. Step 4 of 6

   Treat technician workstations as suspects

   Any workstation that connected to an affected host may have been taken over.

   • Check them for the same task and paths
   • Revoke their browser sessions and tokens; rotate their passwords from another device
   • Reimage if you can't rule it out
5. Step 5 of 6

   Rotate what the hosts held

   An attacker with SYSTEM on servers and DCs can take more than the RMM.

   • Rotate domain admin, service, backup and hypervisor accounts and browser-saved credentials first
   • Assume domain-level exposure where domain controllers were reached
   • Reboot and verify clean only after remediation is confirmed
6. Step 6 of 6

   Tell customers and keep evidence

   Customers need to know their hosts ran attacker code.

   • Notify affected customers with the time window and what you've done
   • Keep logs and installers for your vendor and any insurer or regulator
   • Follow ConnectWise Trust Center and Huntress updates for root cause before re-enabling anything you disabled

Original content by ctxsec. Printable checklist: use your browser's print view.