The MSP360 phishing campaign shows how attackers can turn trusted remote administration software into an initial access tool. Microsoft Defender Experts observed the activity across multiple industries in July 2026, before publicly disclosing the campaign on 29 September 2026.
Victims were persuaded to run a legitimate, digitally signed MSP360 Remote Monitoring and Management installer for Windows. Once a user approved its request for elevated privileges, the software established remote management access and downloaded ConnectWise ScreenConnect as a second, independent channel.
How the MSP360 phishing campaign reached victims
The attackers distributed MSP360 RMM version 2.5.0.67 through phishing pages designed to resemble familiar business services. These pages imitated document portals, meeting invitation workflows, collaboration platforms and software download sites.
Lures included Zoom and Google Meet installation prompts, Adobe Reader updates, PDF documents, RSVP e-cards, job offers, signature requests and delivery notifications. This variety allowed the operators to target different workplace situations while delivering the same signed MSP360 installer.
Observed filenames included:
- VIP_ECARD_INVITATION_rmm_v2.5.0.67_[redacted].exe
- ZoomSetup_Installation_v2.5.0.67_[redacted].exe
- PDF Reader & Editor the Adobe Acrobatte_rmm_v2.5.0.67_[redacted].exe
- RSVP_INVITATION_E_CARD_rmm_v2.5.0.67_[redacted].exe
- SSA.GOV_STATEMENT_rmm_v2.5.0.67_[redacted].exe
Downloads were hosted on attacker-controlled or potentially compromised websites, as well as common cloud platforms. Reported services included Amazon S3, Cloudflare R2, Dropbox, GitLab and Supabase. Using established hosting providers helped the traffic resemble ordinary business activity and allowed infrastructure to be changed quickly.
The initial file was not a counterfeit application containing an exploited software flaw. It was a genuine, signed MSP360 package presented under a misleading name. That distinction is important because valid signatures and familiar administration software can make malicious deployment harder for users and security tools to recognise.
MSP360 phishing campaign installation chain
User approval was required
After a victim launched the installer, Windows displayed a User Account Control prompt requesting elevation. If the user rejected that request, the installation stopped and did not create the services or persistence needed by the attackers.
If elevation was approved, the installer placed its components in the MSP360 RMM Agent program directory and checked the available .NET runtimes. It also registered the MSP360 services RMM.Agent.exe and RMM.Agent.Launcher.exe, creating persistent remote management capability on the Windows endpoint.
The installation added autorun configuration for tray applications and changed Windows Firewall settings. A new rule allowed inbound UDP traffic to RMM.Agent.exe on port 48678. These changes were consistent with the operation of the legitimate RMM product, but they were made following a deceptive installation initiated through phishing.
ScreenConnect created redundant remote access
The MSP360 phishing campaign did not rely on the first RMM connection alone. After installation, RMM.Agent.exe launched PowerShell, changed the session execution policy and used Invoke-WebRequest to retrieve a ScreenConnect ClientSetup.msi package from attacker infrastructure.
Windows Installer then ran the package silently through msiexec.exe with the /qn switch. This produced ScreenConnect.ClientService.exe and ScreenConnect.WindowsClient.exe, along with related service registrations, uninstall information and authentication configuration.
ScreenConnect gave the operator a remote access route independent of MSP360. This redundancy could preserve access if defenders identified or removed one of the two tools, while both applications could appear consistent with normal remote support activity.
Microsoft explicitly found no exploitation of a ScreenConnect vulnerability. The attackers installed and operated its legitimate client after obtaining execution and elevated privileges through social engineering.
Post-compromise activity and related RMM abuse
Once ScreenConnect was active, operators used its RunFile capability to transfer and execute additional utilities. The tools supported credential access, local information collection and defence evasion, extending the MSP360 phishing campaign beyond simple remote control.
ScreenConnect RunFile activity commonly stages files beneath a user’s Documents\ConnectWiseControl\Temp directory. Unexpected executables in that location, particularly alongside a newly installed ScreenConnect service, can therefore provide useful evidence during an investigation.
Microsoft also identified a separate July 2026 activity set in which attackers used Faronics Deploy Agent to retrieve and install ScreenConnect. This indicates that the broader technique was not limited to MSP360. The common objective was to misuse a trusted deployment or RMM product to establish another legitimate remote access tool.
Microsoft did not attribute the activity to a named threat actor. This is an observed in-the-wild campaign rather than a proof of concept, but the available reporting does not establish whether the same infrastructure remained active on 1 October 2026.
Disclosure timeline and vendor response
- July 2026: Microsoft Defender Experts observed phishing activity across organisations in multiple industries.
- 29 September 2026: Microsoft published its analysis of the MSP360 to ScreenConnect infection chain and associated mitigations.
- 30 September 2026: Independent reporting expanded on the technical details, and MSP360 acknowledged the misuse of its software.
MSP360 said the incident involved abuse of legitimate tooling rather than a vulnerability in its product. The company blocked accounts associated with misuse, strengthened business verification before enabling sensitive capabilities, and increased monitoring and enforcement.
A reported SHA256 value for the disguised MSP360 installer is 108ef7e628d7a20bd6241a5b57149e27a6061f467123eb64061975559f8f73dc. Organisations should validate this indicator against current Microsoft threat intelligence before using it as the sole basis for blocking or incident conclusions.
Why this ScreenConnect deployment matters
The MSP360 phishing campaign is significant because signed administrative tools are often trusted or expressly permitted in business environments. For organisations using outsourced IT support, unexpected RMM activity may initially look similar to authorised maintenance.
Running two remote access products also complicates containment. Removing MSP360 without identifying the silently installed ScreenConnect client could leave the attacker with continuing access for credential theft and data collection.
Actions for organisations using remote support tools
Defenders should first establish which RMM products and ScreenConnect deployments are authorised. Microsoft recommends using Application Control for Windows or AppLocker publisher rules to prevent unapproved remote administration software from running.
- Hunt for unexpected RMM.Agent.exe, RMM.Agent.Launcher.exe, ScreenConnect.ClientService.exe and ScreenConnect.WindowsClient.exe processes or services.
- Review newly created firewall rules allowing inbound UDP traffic to RMM.Agent.exe on port 48678.
- Investigate ScreenConnect installations preceded by MSP360, PowerShell, Invoke-WebRequest or silent msiexec.exe activity.
- Enforce multifactor authentication for approved RMM platforms and restrict access to sensitive remote management functions.
- Reset credentials used from affected endpoints, with urgent investigation where privileged or system-level accounts were involved.
These checks should be treated as a connected investigation rather than isolated alerts. The defining feature of the MSP360 phishing campaign is the sequence from deceptive download, through approved elevation, to two legitimate remote access products operating under attacker control.
Originally reported by thecyberexpress.com.
