Attackers are hiding a genuine remote-monitoring-and-management (RMM) tool inside fake Zoom and PDF installers, tricking victims into granting full remote access to their own machines. The technique has now been observed running across two separate toolchains, making it harder to shut down with a single fix.
What happened
Threat actors are distributing MSP360 RMM client software under file names designed to look like meeting-app installers, PDF readers, meeting invitations, or business documents. The trick leans on the same misplaced trust that makes any familiar-looking, signed installer effective: it borrows brand recognition from Zoom and common PDF tools to slip past a victim's instinctive caution.
Once a target runs the file and approves the Windows administrator prompt, MSP360 installs its services, adds itself to startup, and opens a firewall rule allowing inbound traffic to its remote-access agent. From there, MSP360 quietly uses PowerShell to pull down a second tool — a ConnectWise ScreenConnect client — giving the attacker two independent remote-access channels into the same machine. Shut down one, and the other can still be sitting there.
Once ScreenConnect is running, researchers have seen it fetch follow-on utilities built for stealing saved passwords, harvesting browser data, hiding windows and cursors from the victim, and launching further payloads — the building blocks for credential theft and movement into the wider network.
None of this relies on a software flaw. MSP360 and ScreenConnect are legitimate, widely used IT tools; the attackers are simply running them as designed — the remote session just belongs to someone who shouldn't have it. That's exactly what makes the activity hard to catch: it can look identical to routine technical support.
A related campaign spotted in July 2026 used a different legitimate deployment agent to push ScreenConnect, showing the "trusted tool as remote-access trojan" approach isn't tied to one vendor. Delivery infrastructure is just as fluid — attacker-controlled sites, compromised websites, and cloud storage on Amazon S3, Cloudflare R2, Dropbox, GitLab, and Supabase have all been used to host the fake installers.
Why it matters
Dual-channel RMM abuse gives an intruder resilience: killing one tool doesn't end the intrusion, and because both programs are legitimate and often allow-listed by IT teams, the traffic tends to blend into normal technical-support activity instead of tripping alerts. For any organization that doesn't tightly control which remote-access software is allowed to run, a single approved admin prompt can hand over durable, hands-on-keyboard access — plus a credential-theft toolkit — without a single exploit ever being fired.
What to do
- Maintain an inventory of approved remote-management tools and block anything outside it, ideally by publisher certificate rather than filename.
- Require MFA on all sanctioned remote-access software and keep cloud-based endpoint protection active and enforced.
- Treat any unexpected RMM installation as an incident until proven otherwise — don't wait for a second-stage payload before investigating.
- Hunt for campaign-specific indicators: unexpected MSP360 or ScreenConnect services, PowerShell spawned by a remote-access agent, and silent Windows Installer activity.
- If an unauthorized RMM deployment is confirmed, reset credentials for any accounts used in the install, and dig deeper if system-level credentials were exposed.
- Restrict and audit remote process-creation paths such as PsExec and WMI, which attackers commonly use to move laterally after the first foothold.