What happened

According to BleepingComputer, citing Huntress, an active campaign is targeting managed service providers (MSPs) that run cloud-hosted ConnectWise ScreenConnect. Huntress says it began around 17:47 UTC on Wednesday. At the time of reporting, Huntress had identified six compromised MSPs and 286 affected endpoints across 47 organizations, and the numbers were still rising.

The attackers use ScreenConnect's legitimate Run Command feature to install additional ScreenConnect clients on managed endpoints. Those clients point to infrastructure the MSP does not control, which gives the attacker remote access that survives even if the MSP cleans up its own instance. Huntress also warned of a possible reverse-pivot technique, where a technician's workstation is compromised when they open a session to an infected customer device. It is not yet clear whether that abuses a vulnerability or normal functionality.

Huntress has not confirmed the initial access method. Its telemetry points to compromised credentials and hijacked MSP support sessions. Sequential attacker-assigned tags suggest earlier MSPs may already have been affected. ConnectWise said it is investigating and advised partners to avoid interactive sessions to suspected compromised devices, review account activity, revoke active sessions, reset credentials from a trusted device and verify multifactor authentication.

Why it matters

The tooling is legitimate, signed and normally allowed by security products and by customers. One compromised MSP therefore becomes a path into every organization it manages. A rogue client also looks very similar to the real one, so it can sit unnoticed for months. Huntress' tags hint at exactly that, and BleepingComputer found an earlier batch script from July that references one of the same rogue client IDs, although it is unclear whether the two are linked.

What defenders should check

If you are an MSP or run your own ScreenConnect:

  • Review Run Command history and session logs, going back months rather than days.
  • Revoke active sessions, reset credentials from a clean device and confirm MFA on every technician and admin account.
  • Check for unknown users, extensions or installer pages on the server.

If you are an MSP customer:

  • Ask your provider in writing whether they are affected and which instance ID they use.
  • Inventory every ScreenConnect client on your endpoints. Each install registers a service named like ScreenConnect Client (<16-character ID>). Any ID that is not your provider's is suspect.
  • Review egress logs for connections to unfamiliar relay hosts.

Detection ideas

These are starting points to adapt and test in your environment, not production-ready rules.

List ScreenConnect client services across a fleet (PowerShell):

Get-CimInstance Win32_Service |
  Where-Object { $_.Name -like 'ScreenConnect Client*' } |
  Select-Object SystemName, Name, PathName, StartMode

Hunt for ScreenConnect client processes and their command lines (KQL, Defender-style schema):

DeviceProcessEvents
| where FileName =~ "ScreenConnect.ClientService.exe"
    or ProcessCommandLine has "ScreenConnect.ClientSetup"
| summarize count(), make_set(ProcessCommandLine) by DeviceName

Search proxy or DNS logs for the indicators Huntress published (defanged here): relay 185.99.255[.]28, domains newnewnew.gotdns[.]org, soxnewwork.homedns[.]org, cdn007-digitaldownloads[.]com, sc.payproofkit[.]com, and installer URLs containing /Bin/ScreenConnect.ClientSetup.msi with a c=Exploited parameter. Also search for rogue client IDs 2588ef5c15954b10 and ed630cc2c873b091, and for the files Panel-Lateral.ps1, runnew.cmd, ToolboxRelayUploader.exe and Run-Lateral-Full.bat.

A generic baseline is worth keeping after this incident: alert whenever a remote-access tool is installed that is not on your approved list.

Investigation

If you suspect compromise, investigate from separate tooling, as ConnectWise advises, rather than through ScreenConnect itself. Collect:

  • Server side: ScreenConnect session and audit logs, Run Command history, user and role changes, authentication logs.
  • Endpoint: service registry keys under HKLM\SYSTEM\CurrentControlSet\Services, install directories under Program Files (x86), MSI install events in the Application log (event ID 1033 and 11707), PowerShell script block logs, and Defender exclusion changes.
  • Network: firewall, DNS and proxy logs for the first connection to each rogue relay, which gives you a first-seen date for each endpoint.
  • Technician workstations: treat any that opened sessions to affected devices as potentially compromised, and review them for credential theft.

Build a timeline per endpoint and scope the earliest date from the oldest rogue install, not from the date the campaign was announced.

Mitigation

  • Follow ConnectWise guidance on the ConnectWise Trust Center as it is updated.
  • Rotate credentials and API keys for the ScreenConnect instance and any account used in sessions to affected devices.
  • Enforce phishing-resistant MFA for technician access and restrict who can use Run Command.
  • Allow-list the exact ScreenConnect instance ID your provider uses, and block other ScreenConnect relays at the firewall where practical.
  • Remove rogue clients, then confirm persistence is gone (services, scheduled tasks, Startup folder and Run keys) before restoring trust.

If you need help scoping this, our compromise assessment and incident response teams can assist.