A phishing download disguised a signed MSP360 remote-management installer; after it ran with elevated rights, the agent installed ConnectWise ScreenConnect as a second way into the same Windows endpoint. Microsoft’s September 29 account describes July campaigns across multiple industries and follow-on credential-access and collection activity. For endpoint teams, two ordinary support products on one device can mean two attacker-controlled sessions to remove and investigate.
Start with the MSP360 agent service starting PowerShell, followed by a ScreenConnect client install and remote connection. Compare both agents with your approved support roster. A matching signed installer alone is a lead; the service, process and connection sequence tells you what access was established.
A signed installer gets the foothold
Meeting invitations, PDF and software-update lures sent users to downloads hosted on attacker infrastructure or shared services including Amazon S3, Cloudflare R2, Dropbox, GitLab and Supabase. The downloaded names looked like business documents or familiar installers, but samples contained legitimate MSP360 RMM v2.5.0.67. Microsoft gives the distributed installer’s SHA-256 as 108ef7e628d7a20bd6241a5b57149e27a6061f467123eb64061975559f8f73dc and says that sample’s signing certificate has since been revoked. Those shared hosting platforms were delivery routes, rather than attacker-owned services in their entirety.
On successful User Account Control elevation, the installer populated C:\Program Files\RMM Agent\, registered RMM.Agent.exe and RMM.Agent.Launcher.exe services, added tray-app autoruns and allowed inbound UDP 48678 for the agent in Windows Firewall. Its MSP360 RMM Agent installer event source recorded “Begin installation” and “End installation. MSP360 de Success.” These events and services give responders a sharper test than the lure filename. When users denied or abandoned elevation in Microsoft’s observations, installation stopped before the persistent services and remote management channel were established.
The agent installs another agent
After MSP360 was active, RMM.Agent.exe launched PowerShell to retrieve ClientSetup.msi; the endpoint silently installed a ConnectWise ScreenConnect client. ScreenConnect.ClientService.exe then connected to actor-controlled infrastructure and started ScreenConnect.WindowsClient.exe. This gave the operator another remote administration channel even if the first agent were interrupted. MITRE ATT&CK’s remote-access-tools description explains how a legitimate support agent can provide an interactive command channel and persist as a Windows service. Microsoft observed abuse of legitimately obtained software, rather than exploitation of a ScreenConnect flaw.
Microsoft saw the ScreenConnect session transfer and run tools using its RunFile feature. Staging locations included C:\Users\%user%\OneDrive\Documents\ScreenConnect\Temp\ and C:\Users\%user%\Documents\ScreenConnect\Temp\; observed names included WindowsSecurity_PIN.exe, WebBrowserPassView.exe and DefenderControl.exe. A transferred file merits examination, while process creation establishes execution. The report also describes separate July activity where FaronicsDeployAgent.exe installed ScreenConnect, so a hunt limited to MSP360 misses that route. Microsoft tracks the campaigns as unattributed activity.
Follow the service and session
Microsoft supplies advanced-hunting queries for the installer hash in DeviceFileEvents, agent-launched PowerShell in DeviceProcessEvents, ScreenConnect connections in DeviceNetworkEvents, and ScreenConnect RunFile process creation. The process-event schema includes parent-process and command-line fields; the network-event schema includes the initiating process and RemoteUrl. Use the published queries over the period your endpoint telemetry retains, then join the results by device and time. Microsoft’s example uses a 30-day lookback, while the activity it describes occurred in July.
For network triage, Microsoft’s observed ScreenConnect client domains include adswre[.]cfd and swedcorry[.]stefneyv[.]com. Reconcile matching destinations with the installed service and your approved ScreenConnect servers; a product match by itself can be ordinary help-desk traffic. The report’s installed-service events help distinguish a completed foothold from a failed elevation attempt. Microsoft, which sells Defender for Endpoint, lists detections named “Suspicious usage of remote management software” and “Uncommon remote access software,” alongside the published queries.
Remove unapproved remote access
Inventory MSP360, ScreenConnect and Faronics agents against your approved deployment list, including the owner and support ticket for each new installation. Microsoft recommends Application Control for Windows or AppLocker publisher rules to restrict unapproved management software and MFA where an approved RMM product supports it. Test your policy against the approved installer before enforcing it across support endpoints; an authentic signature says who signed a file, while your policy decides whether that tool belongs there. For the broader agent-policy work, our Cisco Talos review covers approved tools and session controls.
If you find an unauthorized installation, investigate both remote sessions, the ScreenConnect RunFile activity, transferred files and credential access. Microsoft recommends resetting passwords for accounts used to install the RMM services, with further investigation when a system-level account was involved. Removing one agent while the other still runs leaves the operator a working route back. On the affected endpoint, verify that the unauthorized services and associated connections are gone, then look for new process creation or remote sessions in the same telemetry. That checks the two access paths described here; the credential-access findings warrant their own response before the endpoint returns to normal use.