SCKit ScreenConnect Attack: MSPs Must Hunt Now

Introduction

Microsoft has published new guidance on an active threat campaign abusing ConnectWise ScreenConnect to compromise managed service providers (MSPs) and customer endpoints. This matters because the attack can create a second, attacker-controlled remote-access path and potentially pivot into technician sessions, extending compromise across downstream managed devices.

What’s new

Microsoft says threat actors are using legitimate ScreenConnect functionality to:

• Install an unauthorized ScreenConnect client on managed endpoints
• Deploy a malicious worm called SCKit
• Establish persistence through scheduled tasks and registry Run entries
• Use RelayTrap to target technician workstations during support sessions
• Leverage hijacked authenticated sessions to spread payloads to other managed devices

The report also highlights a reported server-side entry route involving the RMM+ extension family. ConnectWise has described an authentication flaw in RMM+ versions 1.0.31 and 1.0.32 where an empty access key could be accepted if no key was configured. Microsoft notes the exact initial-access path is still under investigation.

Why this is important for IT admins

This is more than a standard remote tool abuse case. According to Microsoft, attackers can:

• Maintain access independently of the legitimate MSP ScreenConnect instance
• Execute commands remotely on affected endpoints
• Target technician workstations through malicious client-side behavior
• Use the technician’s management console to push payloads to additional devices

A key takeaway is that removing the unauthorized client is not enough. Persistence mechanisms may remain in place, and exposed web sessions may still be valid.

Recommended next steps

Administrators, especially MSPs and security teams, should:

1. Investigate technician workstations for signs of session hijacking or malicious payload delivery.
2. Review downstream managed endpoints for unauthorized ScreenConnect clients, scheduled tasks, and registry persistence.
3. Patch and validate ScreenConnect-related extensions, including checking for exposure tied to CVE-2026-84869 and affected RMM+ versions.
4. Use Microsoft Defender XDR hunting queries and IOCs from Microsoft’s research to identify related activity.
5. Reset or invalidate exposed sessions and credentials where compromise is suspected.
6. Inspect command execution history for suspicious use of cmd.exe, curl.exe, PowerShell loaders, and MSI installs from untrusted infrastructure.

Bottom line

Organizations that use ScreenConnect, especially MSPs, should treat this as an urgent threat-hunting and containment scenario. The combination of unauthorized remote access, persistence, and technician-targeting behavior raises the risk of broad operational impact if not addressed quickly.