A phishing operation investigated by Microsoft demonstrates why trusted administrative software can be as dangerous as conventional malware when deployed without authorization. Attackers distributed a legitimate, digitally signed MSP360 Remote Monitoring and Management installer under filenames designed to resemble workplace documents, meeting invitations and popular software.
The lures directed victims through fraudulent document-sharing pages, invitation workflows and fake Adobe Reader or Zoom downloads. Payloads were hosted across attacker-controlled systems and legitimate cloud services, including Amazon S3, Cloudflare R2, Dropbox, GitLab and Supabase.
One remote tool installs another
If a victim launched the package and approved its request for administrative privileges, MSP360 installed persistent Windows services and modified firewall settings. The attackers then used its remote-command capabilities to download and silently install ConnectWise ScreenConnect.
Microsoft found no evidence that vulnerabilities in MSP360 or ScreenConnect were exploited. The software performed as designed. The security failure came from allowing an attacker-controlled instance of a legitimate tool to become established on the endpoint.
Using two remote-management products gave the operators redundant access. If defenders discovered or removed one channel, the other could remain available. ScreenConnect was subsequently used to transfer utilities associated with browser credential collection, local reconnaissance and reduced user visibility.
Why traditional allowlisting can fail
Many organizations place considerable trust in digitally signed software. That approach is no longer sufficient for remote administration products because a valid signature proves who built an application, not who controls the deployed instance or whether the installation was authorized.
Defensive priorities
- Maintain an explicit inventory of approved RMM products, servers and administrator accounts.
- Block unauthorized remote-management tools through application control policies.
- Alert when a new RMM service, firewall exception or unattended-access component appears.
- Require multifactor authentication for approved remote-support platforms.
- Investigate endpoints where two unrelated RMM products are installed.
- Reset credentials and examine follow-on activity after any unauthorized installation.
In my view, the double-RMM technique is the most important element of this campaign. Attackers are applying resilience principles normally associated with enterprise IT, deliberately building backup access paths into compromised systems.
Security teams should therefore stop treating remote-management software as a simple application category. It is privileged infrastructure. Every deployment should have an owner, an approved management server and a documented business purpose. Anything outside that model should be handled as a potential security incident, even when every executable carries a valid digital signature.