The Challenge
In July 2026, a phishing campaign exploited trust, posing a significant threat to security leaders. Attackers distributed a legitimate, digitally signed MSP360 RMM installer (v2.5.0.67) under misleading filenames. The software wasn't compromised, and the vendor wasn't breached. The tool functioned as intended, which was the core issue.
Microsoft Defender Experts observed victims downloading files with names like "VIP_ECARD_INVITATION_rmm_v2.5.0.67" and "ZoomSetup_Installation_v2.5.0.67" containing authentic MSP360 software. Once installed with elevated privileges, the RMM agent provided attackers with remote command execution, file transfer, and persistent access. They then used MSP360 to deploy ConnectWise ScreenConnect as a secondary remote access channel, complicating detection and remediation.
This wasn't a vulnerability exploit. It was operational capability turned against the organization.
The Environment and Constraints
RMM platforms solve real problems. Your IT team needs to patch systems, troubleshoot issues, and manage endpoints without physically accessing each device. MSP360, ScreenConnect, and similar tools provide broad administrative access through persistent connections.
The challenge is these tools don't differentiate between authorized administrators and threat actors who trick users into installing them. Once the MSP360 installer obtained User Account Control elevation, it deployed services, modified Windows Firewall rules to allow inbound UDP traffic on port 48678, and created registry-based autorun entries. Every step followed the vendor's documented installation process.
The attackers understood this environment. They distributed payloads through Amazon S3, Cloudflare R2, Dropbox, GitLab, and Supabase, services your defenses are configured to allow. They rotated lure themes across meeting invitations, PDF reader updates, tax documents, and job offers. Once a user clicked through a UAC prompt, attackers gained the same remote management capabilities your help desk uses.
The Approach Taken
Microsoft's detection focused on behavioral anomalies rather than blocking legitimate software. The key indicators weren't the presence of MSP360 or ScreenConnect, but the context and sequence of their installation.
The detection approach focused on three patterns:
Unusual installation sources: MSP360 installers launching from user Downloads directories under deceptive filenames, rather than through managed software distribution channels.
Rapid secondary tool deployment: RMM.Agent.exe spawning PowerShell to download and silently install ScreenConnect via msiexec.exe /qn within minutes of the initial MSP360 installation, bypassing change management workflows.
Post-compromise tool staging: ScreenConnect transferring executables like "DefenderControl.exe," "WindowsSecurity_Password.exe," and "WebBrowserPassView.exe" to user document directories, utilities designed to extract credentials, hide activity, and maintain persistence.
Microsoft Defender for Endpoint's behavioral monitoring flagged these sequences as they deviated from normal RMM deployment patterns. Legitimate MSP360 installations typically occur through group policy, MDM enrollment, or documented onboarding processes, not through phishing lures and user-initiated downloads.
Results and Metrics
The campaign's effectiveness stemmed from its abuse of trust. The MSP360 installer was digitally signed and legitimate, passing signature validation checks. The hosting infrastructure mixed attacker-controlled domains with compromised websites and trusted cloud services, making blocklisting ineffective. The social engineering themes covered workplace collaboration, software updates, and government documents, all plausible reasons for a user to download and install software.
Microsoft observed the threat actors establishing two independent remote access channels: the initial MSP360 deployment and the subsequent ScreenConnect installation. This redundancy meant that blocking or removing one tool didn't eliminate the threat actor's access. The ScreenConnect service launched with configuration parameters pointing to actor-controlled infrastructure and successfully established outbound communications, providing a backup control path.
The post-compromise phase showed systematic credential harvesting and information collection. Tools like WebBrowserPassView.exe and utilities designed to hide mouse cursors and remove UI elements indicated preparation for sustained access operations. The threat actors weren't conducting smash-and-grab attacks; they were establishing operational infrastructure for long-term access.
What They Would Do Differently
The core vulnerability wasn't technical, it was procedural. Allowing users to install software with administrative privileges creates an attack surface that endpoint protection can't fully close. The MSP360 installer required UAC elevation, and users granted it.
A more restrictive approach would require:
Application allowlisting: Permit only explicitly approved RMM tools to install and execute. This won't prevent phishing, but it stops unauthorized RMM deployments even when users click through UAC prompts.
Network segmentation for RMM traffic: MSP360 created a Windows Firewall rule allowing inbound UDP traffic on port 48678. Your network architecture should restrict which systems can receive inbound RMM connections and route that traffic through monitored channels.
Behavioral monitoring for RMM abuse: The pattern of MSP360 spawning PowerShell to download and install ScreenConnect should trigger immediate investigation. Legitimate RMM deployments don't typically chain-install additional remote access tools minutes after initial setup.
User education with technical controls: Training users to recognize phishing is necessary but insufficient. The technical control layer must assume some users will eventually install malicious software and detect the behavioral consequences.
Takeaways for Your Team
This case study reveals a fundamental tension in security architecture: the tools you need for operational efficiency are the same tools threat actors need for persistent access. You can't eliminate RMM platforms without crippling your IT operations, but you can't ignore their abuse potential.
Start with inventory. Do you know which RMM tools are authorized in your environment? Can you detect when unauthorized RMM software installs? The threat actors in this campaign deployed MSP360 and ScreenConnect, both legitimate products. Your detection logic must identify unauthorized instances of authorized tools.
Review your privilege model. The MSP360 installer required administrative access to deploy services and modify firewall rules. Which users in your organization can grant that elevation? What approval workflows govern software installation? The phishing campaigns succeeded because users had both the technical capability and the authority to install RMM tools.
Monitor for chained tool deployment. The sequence of MSP360 installing, then immediately deploying ScreenConnect via PowerShell, is a strong indicator of compromise. Legitimate RMM deployments follow change management processes with documentation, approval, and coordination. Threat actors operate on different timelines.
Finally, accept that detection will be behavioral rather than signature-based. The MSP360 installer was legitimate and digitally signed. Your endpoint protection won't block it based on file reputation. You need visibility into how RMM tools are deployed, what they do after installation, and whether their behavior aligns with your operational baselines.
The threat actors understood that your defenses are optimized for malware, not for legitimate administrative tools used maliciously. Your response must address that gap.
