Microsoft has uncovered a phishing campaign in which threat actors abused legitimate remote monitoring and management software to establish persistent access to victim systems. The campaign, observed in July 2026, distributed a digitally signed MSP360 RMM installer through meeting invitations, PDF-themed lures, fake software updates and other social-engineering messages. The installer was disguised under filenames designed to resemble legitimate business documents or software packages, but once executed it installed the genuine MSP360 remote-management agent and gave the attackers a foothold on the system.

The important point is that MSP360 itself was not exploited through a software vulnerability. The attackers simply used the product exactly as it was designed to be used: to gain remote administrative control over an endpoint. The malicious element was the unauthorized deployment and ownership of the RMM instance. MSP360 has confirmed that Microsoft’s research describes abuse of legitimate remote-management functionality rather than exploitation of a flaw in the software.

That distinction matters because it explains why this type of activity can be difficult to detect. Security tools are generally trained to distrust unsigned malware, suspicious binaries and unusual persistence mechanisms. RMM software presents almost the opposite profile: it is legitimate, digitally signed, widely used by IT teams and designed to perform precisely the actions an attacker wants, including remote command execution, software deployment, file transfer and persistent service-based access. When attackers successfully persuade a user to install an RMM agent, they effectively inherit a fully developed remote administration framework without needing to write their own malware.

The initial phishing chain relied on a variety of lures and deceptive filenames, including fake meeting invitations, Zoom installers, Adobe PDF tools, RSVP invitations and Social Security-related documents. Microsoft observed filenames such as ZoomSetup_Installation_v2.5.0.67 and SSA.GOV_STATEMENT, all wrapping the legitimate MSP360 RMM version 2.5.0.67 installer. The payloads were hosted across attacker-controlled infrastructure as well as legitimate cloud platforms including Amazon S3, Cloudflare R2, Dropbox, GitLab and Supabase, allowing the attackers to rotate distribution infrastructure while continuing to serve the same underlying RMM installer.

Once the victim launched the installer, the process triggered Windows User Account Control elevation and, where the user approved it, installed MSP360 with elevated privileges. The installer registered MSP360 services, configured persistence and modified the Windows Firewall to permit inbound UDP traffic to the RMM agent on port 48678. Microsoft says the software registered services including RMM.Agent.exe and RMM.Agent.Launcher.exe and created registry-based autorun mechanisms so that the RMM components would continue launching after user sign-in.

The attacker did not stop with one remote-management platform. After establishing MSP360 access, the actor used the RMM channel to invoke PowerShell and silently download and install ConnectWise ScreenConnect, creating a second independent remote-access mechanism. This dual-RMM approach gives the attacker redundancy: if one tool is discovered, blocked or removed, the other may continue providing access. It also complicates incident response because defenders need to identify and remove multiple legitimate remote-administration products rather than one obvious malware family.

The basic intrusion chain can therefore be summarized as: phishing lure → victim downloads legitimate MSP360 installer → UAC elevation → MSP360 services installed → remote administrative foothold established → PowerShell invoked through RMM → ScreenConnect silently installed → second persistent remote-access channel → credential access and information collection.

That second remote-access channel is strategically important. Microsoft explicitly says it did not observe exploitation of a ScreenConnect vulnerability in this activity. The attackers again abused legitimately obtained remote-administration software. ScreenConnect was used to transfer and execute additional tools through its native functionality and supported later stages involving information collection, credential-access operations and deployment of further utilities.

This makes the campaign an example of living off trusted administration software rather than traditional living off the land. Instead of relying only on native Windows tools such as PowerShell, WMI or scheduled tasks, the attacker introduces commercial remote-management software whose legitimate purpose already includes persistent access, command execution and file transfer. The malicious behavior is therefore hidden inside workflows that can look remarkably similar to ordinary IT support.

That creates a major detection challenge for organizations that already use RMM tools. A process such as RMM.Agent.exe may be entirely legitimate in one company and highly suspicious in another. Even inside an organization that uses MSP360, a new agent installed by the wrong account, controlled by an unfamiliar tenant or communicating from an unexpected endpoint should not automatically be trusted merely because the binary is signed.

Security teams therefore need to answer three contextual questions: Is this RMM tool approved? Who controls this specific instance? And why is it installed on this endpoint? Simply identifying a binary as MSP360, ScreenConnect, AnyDesk or another known remote-support product is no longer enough to determine whether it is benign.

Microsoft also observed a separate July campaign where attackers substituted Faronics Deploy Agent for MSP360 but still used it to install ScreenConnect afterward. That strongly suggests the actor’s strategy is not tied to any one vendor. The objective is to obtain an initial remote-management channel using whatever legitimate administrative software can be successfully delivered, then add ScreenConnect or another secondary channel for resilience.

That is an important defensive lesson because blocking a single RMM product may simply cause the actor to switch tools. The underlying behavior is more durable: a user unexpectedly downloads a remote-management installer, approves elevation, new privileged services appear, outbound communications begin and another remote-access product is subsequently installed.

Organizations should therefore monitor for new or uncommon RMM installations, particularly from user download directories, temporary folders or recently downloaded installers. It is also useful to alert when remote-management agents are first seen on endpoints that historically did not use them, or where more than one RMM product suddenly appears on the same machine.

The presence of multiple RMM tools on a single workstation should receive particular scrutiny. There are legitimate cases where an MSP transition or vendor support arrangement results in overlapping tools, but an unexplained sequence where one RMM agent installs another is a strong behavioral indicator. In this campaign, MSP360 followed by ScreenConnect is far more suspicious than either binary considered independently.

Application control can significantly reduce the effectiveness of this technique. Organizations should maintain an approved list of remote-administration software and prevent unauthorized RMM tools from executing, even when they are legitimately signed. Code signing proves the software came from the vendor; it does not prove that its installation was authorized by the organization.

This is a recurring misconception in enterprise security. A digital signature answers:

“Who signed this file?”

It does not answer:

“Should this file be running here?”

The distinction is particularly important for RMM products because threat actors deliberately seek software with strong reputations and valid signatures to avoid triggering antivirus or endpoint controls.

Microsoft also recommends restricting the execution of unapproved RMM tools and monitoring uncommon remote-management activity. Organizations can combine endpoint telemetry, software inventory and network monitoring to identify unexpected RMM deployments. Security teams should also review services, autorun keys, firewall modifications and installation events associated with remote-administration products rather than relying only on malware detections.

The phishing component remains important because the attack still requires the victim to initiate installation. The installer is masqueraded as something the recipient expects to open, such as a meeting invitation or software update. Users therefore need to understand that legitimate software can itself be weaponized through deception. Security awareness cannot simply teach people to avoid obviously malicious executables; a perfectly genuine signed installer can still be the payload if the attacker controls the account behind it.

The UAC step offers another defensive opportunity. In successful cases, the victim approved elevation, allowing the RMM software to install services with elevated privileges. Organizations that tightly control local administrator access and require privileged credentials for software installation can therefore reduce the success rate of this attack chain. Standard users who cannot authorize arbitrary administrative installation present a much harder target.

The campaign also highlights the security importance of RMM vendor account controls. MSP360 says it investigated abusive activity, blocked associated accounts and strengthened verification, monitoring and enforcement after the campaign. The company now requires business verification before new accounts can perform high-risk actions such as enabling remote management or modifying product branding. MSP360 has also said it blocked close to 2,000 fraudulent accounts through monitoring and community reports and introduced additional safeguards around high-risk functionality.

Those measures are useful because abuse of legitimate remote-access platforms often begins at the provider-account level. If criminals can easily create an RMM tenant, generate customized installers and distribute them to victims, the product becomes attractive infrastructure for social engineering. Strong customer verification, abuse monitoring and rapid account suspension raise the attacker’s cost even when there is no software vulnerability to patch.

At the same time, vendor-side verification cannot replace endpoint policy. A verified RMM account can still be compromised, abused by an insider or deployed somewhere it does not belong. Organizations therefore need their own allowlisting and inventory controls independent of the vendor’s abuse-prevention measures.

The broader lesson is that remote administration software has become both a defensive necessity and an attacker asset. The same features that make RMM attractive to IT teams make it attractive to criminals: persistent services, remote execution, file transfer, software deployment and centralized control.

For defenders, this means RMM software deserves treatment similar to privileged-access infrastructure. Organizations should maintain a clear inventory of which remote-management platforms are approved, where they are installed, which tenants control them and which users or administrators are authorized to deploy them.

The compromise assessment should also look beyond uninstalling the unwanted RMM agent. If the attacker had remote administrative access, they may already have executed additional commands, collected credentials, installed other persistence or deployed secondary tools. Removing MSP360 or ScreenConnect does not prove the endpoint is clean.

The correct response sequence is therefore: identify unauthorized RMM installation → isolate the endpoint → determine which RMM account controlled it → remove all unauthorized remote-management channels → review commands and files transferred through those tools → inspect for credential theft and additional persistence → rotate potentially exposed credentials → validate that no secondary RMM or malware remains.

The campaign’s most important lesson is not specific to MSP360 or ScreenConnect. Attackers are increasingly exploiting the trust organizations place in legitimate administrative software. When the tool itself is genuine, traditional malware detection becomes much less useful.

The useful security question is no longer:

“Is this software malicious?”

It is:

“Is this legitimate software being used legitimately?”

That is a harder problem, but it is increasingly the one defenders need to solve.

Microsoft has warned of phishing campaigns distributing an installer for the MSP360 Remote Monitoring and Management (RMM) software under the guise of meeting invitations, PDF-themed lures, software update prompts, and other social-engineering content. "Once executed, the legitimate MSP360 installer, distributed under a deceptive file name established remote management access on affected

Source: Attackers Abuse MSP360 to Deploy ScreenConnect in Dual-RMM Phishing Attacks via The Hacker News — published 30 Sep 2026.